简介面向J2ME初学者的设备信息获取示例包围绕国际移动设备身份码IMEI读取与基站小区定位两个主题封装了通过MIDP API、Java通信API以及JSR 135 Location API访问设备底层信息的完整实现。IMEI码相当于移动设备的身份证号由15位数字构成在手机上拨号*#06#即可查看到基站则负责无线信号的收发与接入二者均是移动通信和位置服务中的基础概念。压缩包将这些获取方式放在同一工程中对照展示适合有基本Java语法基础、想了解手机串号结构或需要开发设备管理、位置估算类应用的嵌入式开发人员。压缩包共20个文件包含4个Java源文件、6个class编译产物以及properties配置文件、xml工程描述、jad/jar打包文件和manifest清单整体仅41KB工程目录将src与dist分离同时保留预验证等构建中间目录便于快速导入J2ME环境对照调试也适合在模拟器与真机之间切换验证。已有220人学习说明这套示例在小众J2ME开发领域具备一定参考热度。包内代码既演示了System.getProperty(com.sun.radiomgt.imei)这类在真机中获取IMEI的典型写法也覆盖了基于JSR 135的Cell ID监听流程让读者能拿到从设备串口识别、小区信息解析到LAC/CID上报的完整落地思路这些实现可直接迁移到自己的工程中对理解手机设备标识读取、基站定位原理以及权限申请细节有直接帮助。1. IMEI.rar里的基站数据值得好好拆一拆某天某实验室的A同学丢给我一个几十MB的RAR压缩包文件名就叫IMEI.rar解压后是一批终端上报的IMEI和基站信息。这种数据包在网络优化、终端资产盘点、合规审计里很常见核心思路并不复杂IMEI是设备身份基站字段记录设备当时接入的是哪个小区。把两者对上就能回答两个实际问题——哪些设备还在活跃哪些区域的覆盖明显偏弱。这篇文章会把从解压RAR、解析字段、清洗数据到做覆盖评估的完整流程拆开讲适合刚拿到类似数据包不知道从哪入手的工程师也适合想把自己的处理脚本做得更稳的人。2. 解压前先看懂数据RAR包内容、IMEI结构与基站字段拿到“IMEI.rar_IMEI_基站”这种文件最难的不是“解压”而是解压后发现字段对不上、编码乱掉、IMEI校验不过。先花十分钟摸清包里是什么、格式长什么样后面会省下大量返工时间。2.1 安全解压RAR并检查文件清单常见做法是先用7-Zip或者Linux下的unrar把包解到独立目录不要直接双击拖出来。原因有两个一是RAR包如果带了密码或分卷命令行工具能给出更明确的错误信息二是解压到独立目录可以避免文件名里的路径穿越把文件写进奇怪的位置。mkdir -p ~/imei_work cd ~/imei_work unrar l IMEI.rar unrar x IMEI.rar -d ~/imei_workunrar l只列出压缩包内的文件清单不实际解压适合先确认包内文件数量和命名。unrar x按完整路径解压保留包内目录结构-d指定目标目录避免文件散落。如果包中有加密文件unrar x会提示输入密码此时注意不要把密码硬编码进历史记录。解压完成后用ls -l查看文件大小再结合清单核对数量。我一般会重点确认有没有.txt、.csv、.xlsx这类主数据文件如果有多个文件优先处理命名里带当日日期或区域代码的那个。文件大小异常则需要警惕——如果一个声称“终端上报记录”的csv只有几十字节大概率是空模板。2.2 IMEI的结构与校验TAC、SNR和校验位IMEI一共15位由三部分组成前6位是TACType Approval Code型号核准码中间6位是SNRSerial Number序列号最后1位是校验位。IMEI本身不是随机的第15位通过Luhn算法对前14位计算得到因此可以先用校验函数判断数据质量。def luhn_check(imei_14): digits [int(d) for d in imei_14] reversed_digits digits[::-1] total 0 for i, d in enumerate(reversed_digits): if i % 2 1: d * 2 if d 9: d - 9 total d return (10 - total % 10) % 10代码中的reversed_digits从校验位前一位开始从右向左处理偶数位乘以2乘积大于9时减去9再累加最后得到校验位。函数入参应当是包含前14位数字的字符串不能带空格或连字符。如果提取到的IMEI是16位通常是IMEISV最后两位是软件版本号不能直接套用Luhn校验需要先截断前14位再判断。2.3 基站数据的常见字段与含义基站侧常见字段并不复杂但名称在不同数据源里差异较大。下表是处理“IMEI.rar基站”数据包时的常用字段对照字段缩写含义示例注意点MCC移动国家码460三位数字中国是460MNC移动网络码00/01/11不同运营商不同LAC/TAC位置区码/跟踪区码0x1A2B或十进制6683GSM叫LACLTE叫TAC含义类似CI/ECI小区标识0x2A3或675同一LAC下唯一RSRP参考信号接收功率-95 dBm数值越小信号越弱RSRQ参考信号接收质量-10 dB与干扰相关TA时间提前量1与距离有关单位约78m/78mTime上报时间2024-05-01 10:00:00时区要统一拿到数据后先看有没有MCC、MNC、LAC/TAC、CI四件套。只有IMEI而没有这些字段只能做设备维度分析四件套齐全才能进一步映射位置和覆盖。RSRP和TA经常存在缺失缺失不影响基础聚合但在做弱覆盖判断时需要先补默认值或过滤掉空值。3. 解析与清洗把非结构化记录变成可分析表格压缩包里的文件可能是空格分隔的文本、CSV或者Excel导出直接读进pandas经常会遇到编码、类型和缺失值问题。清洗阶段的目标是得到一张每行代表一条“IMEI在某时刻接入某基站”记录的标准表。这个过程中有两个关键点IMEI格式统一基站CGI列生成。3.1 用pandas读取文件并处理编码与类型常见做法是先读入原始文件打印行数和列名确认字段名是英文还是中文再处理类型。import pandas as pd raw_df pd.read_csv(imei_report.txt, sep\t, encodingutf-8-sig, dtype{IMEI: str, MCC: str, MNC: str, LAC: str, CI: str}) print(raw_df.shape) print(raw_df.head()) raw_df.columns [col.strip() for col in raw_df.columns]参数里sep\t表示按Tab分隔如果文件是逗号分隔就改为sep,。encodingutf-8-sig能自动去除UTF-8 BOM头避免第一列列名出现\ufeff前缀。dtype把所有ID类字段指定为字符串是最容易忽略的一步——如果让pandas把IMEI当成数字读取15位的整型会被截断成科学计数法。读取后立即打印shape和head判断字段数量是否与想象一致。3.2 IMEI标准化与批量校验读入后IMEI可能混有空格、连字符、TAC编号前缀。先用正则提取纯数字串再逐条做Luhn校验。import re def extract_imei(text): matches re.findall(r\b(\d{14,15})\b, str(text)) if not matches: return None digits matches[0] return digits if len(digits) 15 else digits.zfill(15) raw_df[IMEI_clean] raw_df[IMEI].apply(extract_imei) raw_df[imei_valid] raw_df[IMEI_clean].apply( lambda x: luhn_check(x[:14]) int(x[14]) if x else False )extract_imei用\b(\d{14,15})\b提取连续14到15位数字避免把十六进制基站ID或时间戳里的数字误抓。长度是15位则直接用如果只有14位且前导零被Excel吃掉用zfill(15)补回。luhn_check(x[:14]) int(x[14])把前14位带入之前的函数结果与第15位比较。校验失败的数据不是完全不能用但至少要标记出来单独检查是否来自某些老版本终端。3.3 关联基站信息用CGI作为唯一标识基站信息表里通常有经纬度但原始上报记录里一般只有LAC和CI甚至只有CGI字符串。CGICell Global Identity由MCC、MNC、LAC/TAC、CI拼接而成是全网唯一的基站小区标识。raw_df[CGI] ( raw_df[MCC].str.strip() - raw_df[MNC].str.strip() - raw_df[LAC].str.strip() - raw_df[CI].str.strip() ) cell_df[CGI] ( cell_df[MCC].str.strip() - cell_df[MNC].str.strip() - cell_df[LAC].str.strip() - cell_df[CI].str.strip() ) merged pd.merge(raw_df, cell_df[[CGI, latitude, longitude]], onCGI, howleft) print(merged[latitude].isna().sum())清洗时先对每个字段strip()防止ID里藏空格导致CGI匹配不上。两个DataFrame都在同一规则下生成CGI再pd.merge关联基站经纬度。howleft保留上报表的全部记录匹配不到的经纬度会变成NaN。打印缺失数量即可知道基站映射表的覆盖率。映射时注意LTE数据的TAC字段不能直接塞进LAC列虽然二者数值范围相似但在不同网络制式下语义不同混用会导致定位串站。4. 实际操作落地设备活跃度、基站负载与弱覆盖评估数据清洗干净后就到了最有价值的应用环节。最常见的三个方向分别是设备活跃度分析、基站负载统计、弱覆盖估算。这里的“IMEI.rar_IMEI_基站”包如果字段完整可以一次性做全。4.1 设备活跃度分析找出“活跃设备”和“僵尸设备”活跃度分析的逻辑很简单统计每个IMEI出现了多少次、接入过多少个不同基站、最后一次上报时间在什么时候。device_activity merged.groupby(IMEI_clean).agg( report_count(Time, count), cell_count(CGI, nunique), first_seen(Time, min), last_seen(Time, max), ).reset_index() device_activity[active_days] ( pd.to_datetime(device_activity[last_seen]) - pd.to_datetime(device_activity[first_seen]) ).dt.days print(device_activity.sort_values(report_count, ascendingFalse).head(10))report_count表示上报次数次数过高但保持不变的IMEI可能是测试终端或者上报机制异常。cell_count表示接入的独立小区数如果某IMEI一天内跨了几十个小区可能是高铁高速场景或者移动性异常。active_days用最后一次上报时间减去第一次上报时间计算出活跃天数便于筛出连续多天不活跃的设备。这里我习惯把结果再按report_count分桶0次说明数据包可能缺失该设备1次说明只有单条记录超过100次说明高频运行。对设备资产管理来说高频活跃设备需要重点关注单次记录设备则可能是偶发接入。4.2 基站维度统计定位高负载与覆盖边缘反过来按CGI聚合可以知道每个小区覆盖了多少台独立设备。这个数据对网络扩容和基站巡检很有指导价值。cell_load merged.groupby(CGI).agg( user_count(IMEI_clean, nunique), report_count(Time, count), avg_rsrp(RSRP, mean), avg_ta(TA, mean), ).reset_index() cell_load[signal_class] cell_load[avg_rsrp].apply( lambda x: good if x -90 else (medium if x -105 else weak) ) print(cell_load.sort_values(user_count, ascendingFalse).head(20))user_count是去重后的IMEI数量更能反映实际用户规模report_count含重复上报反映流量压力。avg_rsrp低于-105dBm的基站要重点验证覆盖avg_ta值过大则说明该小区下连接的设备较远可能是广覆盖基站。signal_class作为简单分类标签便于后续筛选。需要提醒的是基站维度聚合结果不能直接代表真实信号强度因为上报终端的芯片灵敏度、天线增益不一致但作为相对排名足够用。真要判断是否需要加站还要结合路测和工参中的天线挂高、站点类型一起看。4.3 弱覆盖估算RSRP与TA组合判定弱覆盖不能只看RSRP还要看TA。RSRP很低同时TA很小说明设备就贴着基站但信号差问题可能出在遮挡或室内污损RSRP低但TA大说明设备已经在小区边缘覆盖能力不足。merged[rsrp_valid] merged[RSRP].notna() merged[ta_valid] merged[TA].notna() merged[is_weak] ( (merged[RSRP] -110) (merged[TA] 2) ) weak_summary merged[merged[is_weak]].groupby(CGI).agg( weak_count(IMEI_clean, count), weak_users(IMEI_clean, nunique), ).reset_index() print(weak_summary.sort_values(weak_count, ascendingFalse).head(10))代码中先判断RSRP和TA字段是否为空缺失值不参与弱覆盖判定。is_weak的条件是RSRP小于-110dBm且TA大于2这两个阈值在不同指标定义下可以调整比如某些场景用-115dBm更合适。弱覆盖小区列表生成后可以再和基站经纬度表join输出给现场巡检。这个组合判定比单一RSRP阈值靠谱的原因在于RSRP是设备侧测量的参考信号功率受终端型号影响较大TA则是基站根据上行定时估计出来的设备距离两者互补能减少“远处强信号、近处弱信号”这种特殊场景的误判。5. 避坑指南IMEI与基站数据处理的5个常见翻车现场这类数据处理看似简单实际操作中翻车点非常集中。以下五条踩坑记录全部来自实际处理经验按“现象—原因—解决”的方式记录能帮你节省至少半天排查时间。5.1 现象解压后文件名乱码CSV读进来第一列变成\ufeff原因RAR包内的文件名或CSV文件本身以带BOM的UTF-8编码保存或者Windows下用GBK编码生成Linux和Mac默认UTF-8读取时必然错乱。解决解压时用unrar的-p指定密码文件编码用utf-8-sig或gbk尝试。如果文件名乱码使用unrar x -ai强制用系统编码重命名。读取CSV时可以写一个简单的编码探测with open(imei_report.txt, rb) as f: head_bytes f.read(200) for enc in [utf-8-sig, utf-8, gbk]: try: print(head_bytes.decode(enc)) break except UnicodeDecodeError: continue5.2 现象同一IMEI对应多个基站直接去重后数据急剧减少原因设备在移动过程中切换基站同一时间窗内上报多条记录是正常的。直接按IMEI去重会把非常宝贵的移动轨迹信息丢掉。解决先按时间排序再去重。merged merged.sort_values([IMEI_clean, Time]).drop_duplicates( subset[IMEI_clean, CGI, Time], keepfirst )如果数据存在多个采集源需要确认时间字段的时区避免同一时刻因为时区不同产生伪多记录。5.3 现象Luhn校验失败率过高几乎一半IMEI都被标记为无效原因数据源里的字段可能并非IMEI而是IMEISVIMEISV第15、16位是软件版本号不参与Luhn校验。也可能是OCR/手工录入导致个别数字识别错误。解决先区分两种格式IMEISV长度是16位先把最后一位去掉取前15位。如果前14位算出的校验位与第15位一致说明这是截断后的IMEISV。def imei_validate_with_sv(value): if len(value) 16: value value[:15] if len(value) ! 15: return False return luhn_check(value[:14]) int(value[14])5.4 现象基站LAC和CI字段部分显示为十六进制部分为十进制CGI关联失败原因RAR包中的基站字段可能来自两个不同系统一个输出十进制6683另一个输出十六进制0x1A2B没有统一转换。解决先判断是否为十六进制字符串再做转换。def to_dec(v): v str(v).strip() if v.lower().startswith(0x): return str(int(v, 16)) return v对所有LAC/TAC和CI字段应用该函数再拼接CGI。5.5 现象RAR解压过程中报CRC错误解压出来的文件被截断原因下载不完整、分包缺失或者RAR包本身在传输中被破坏。解决先校验包内文件CRC。unrar t IMEI.rarunrar t只测试文件完整性不真正解压。若CRC报错检查分卷是否齐全或重新下载。强制解压出来的文件即使能打开数据也是残缺的后续统计完全不可信。这一步是最容易无视的坑直接硬跑分析最后拿到的结论往往与真实情况偏差很大。6. 进阶用基站经纬度把覆盖盲区画成热力地图如果基站配置表里带了经纬度前面merge后的表可以直接用来画热力图。这一步非常适合快速向非技术同事解释“数据能说明什么”——一张布满红点的地图比任何报表都有说服力。import folium from folium.plugins import HeatMap cell_coverage merged.dropna(subset[latitude, longitude]) center_lat cell_coverage[latitude].median() center_lng cell_coverage[longitude].median() m folium.Map(location[center_lat, center_lng], zoom_start9) heat_data cell_coverage[[latitude, longitude, RSRP]].values.tolist() HeatMap(heat_data, radius15, blur10, min_opacity0.3).add_to(m) m.save(imei_cell_heat.html)HeatMap的radius控制点的影响半径数值越大地图上红色团越粗blur是模糊程度调大可以让热区更平滑min_opacity防止稀疏区域变成完全透明。注意传入的RSRP作为热力权重数值越大越红但RSRP实际是负数通常需要做一次线性映射。简单做法是先把RSRP调整为-RSRP再保存。如果没有经纬度也可以先按CGI聚合出基站负荷再把CGI关联到本地维护的基站台账表。注意台账表更新很关键很多情况下站点早已替换但经纬度仍是老位置导致热力图上的热点偏移几百米。画完图后把弱覆盖小区单独用不同颜色标记出来保存成HTML发给现场同事就能直接导航去现场抽测。我现在的习惯是拿到任意IMEI/基站压缩包先跑unrar t再读文件头最后才写清洗脚本。这一套流程已经在好几个类似数据包上验证过能稳定产出设备活跃度表和覆盖盲区清单。希望帮到你。本文还有配套的精品资源点击获取 从RAR解压到弱覆盖评估：IMEI与基站数据的完整处理流程
简介面向J2ME初学者的设备信息获取示例包围绕国际移动设备身份码IMEI读取与基站小区定位两个主题封装了通过MIDP API、Java通信API以及JSR 135 Location API访问设备底层信息的完整实现。IMEI码相当于移动设备的身份证号由15位数字构成在手机上拨号*#06#即可查看到基站则负责无线信号的收发与接入二者均是移动通信和位置服务中的基础概念。压缩包将这些获取方式放在同一工程中对照展示适合有基本Java语法基础、想了解手机串号结构或需要开发设备管理、位置估算类应用的嵌入式开发人员。压缩包共20个文件包含4个Java源文件、6个class编译产物以及properties配置文件、xml工程描述、jad/jar打包文件和manifest清单整体仅41KB工程目录将src与dist分离同时保留预验证等构建中间目录便于快速导入J2ME环境对照调试也适合在模拟器与真机之间切换验证。已有220人学习说明这套示例在小众J2ME开发领域具备一定参考热度。包内代码既演示了System.getProperty(com.sun.radiomgt.imei)这类在真机中获取IMEI的典型写法也覆盖了基于JSR 135的Cell ID监听流程让读者能拿到从设备串口识别、小区信息解析到LAC/CID上报的完整落地思路这些实现可直接迁移到自己的工程中对理解手机设备标识读取、基站定位原理以及权限申请细节有直接帮助。1. IMEI.rar里的基站数据值得好好拆一拆某天某实验室的A同学丢给我一个几十MB的RAR压缩包文件名就叫IMEI.rar解压后是一批终端上报的IMEI和基站信息。这种数据包在网络优化、终端资产盘点、合规审计里很常见核心思路并不复杂IMEI是设备身份基站字段记录设备当时接入的是哪个小区。把两者对上就能回答两个实际问题——哪些设备还在活跃哪些区域的覆盖明显偏弱。这篇文章会把从解压RAR、解析字段、清洗数据到做覆盖评估的完整流程拆开讲适合刚拿到类似数据包不知道从哪入手的工程师也适合想把自己的处理脚本做得更稳的人。2. 解压前先看懂数据RAR包内容、IMEI结构与基站字段拿到“IMEI.rar_IMEI_基站”这种文件最难的不是“解压”而是解压后发现字段对不上、编码乱掉、IMEI校验不过。先花十分钟摸清包里是什么、格式长什么样后面会省下大量返工时间。2.1 安全解压RAR并检查文件清单常见做法是先用7-Zip或者Linux下的unrar把包解到独立目录不要直接双击拖出来。原因有两个一是RAR包如果带了密码或分卷命令行工具能给出更明确的错误信息二是解压到独立目录可以避免文件名里的路径穿越把文件写进奇怪的位置。mkdir -p ~/imei_work cd ~/imei_work unrar l IMEI.rar unrar x IMEI.rar -d ~/imei_workunrar l只列出压缩包内的文件清单不实际解压适合先确认包内文件数量和命名。unrar x按完整路径解压保留包内目录结构-d指定目标目录避免文件散落。如果包中有加密文件unrar x会提示输入密码此时注意不要把密码硬编码进历史记录。解压完成后用ls -l查看文件大小再结合清单核对数量。我一般会重点确认有没有.txt、.csv、.xlsx这类主数据文件如果有多个文件优先处理命名里带当日日期或区域代码的那个。文件大小异常则需要警惕——如果一个声称“终端上报记录”的csv只有几十字节大概率是空模板。2.2 IMEI的结构与校验TAC、SNR和校验位IMEI一共15位由三部分组成前6位是TACType Approval Code型号核准码中间6位是SNRSerial Number序列号最后1位是校验位。IMEI本身不是随机的第15位通过Luhn算法对前14位计算得到因此可以先用校验函数判断数据质量。def luhn_check(imei_14): digits [int(d) for d in imei_14] reversed_digits digits[::-1] total 0 for i, d in enumerate(reversed_digits): if i % 2 1: d * 2 if d 9: d - 9 total d return (10 - total % 10) % 10代码中的reversed_digits从校验位前一位开始从右向左处理偶数位乘以2乘积大于9时减去9再累加最后得到校验位。函数入参应当是包含前14位数字的字符串不能带空格或连字符。如果提取到的IMEI是16位通常是IMEISV最后两位是软件版本号不能直接套用Luhn校验需要先截断前14位再判断。2.3 基站数据的常见字段与含义基站侧常见字段并不复杂但名称在不同数据源里差异较大。下表是处理“IMEI.rar基站”数据包时的常用字段对照字段缩写含义示例注意点MCC移动国家码460三位数字中国是460MNC移动网络码00/01/11不同运营商不同LAC/TAC位置区码/跟踪区码0x1A2B或十进制6683GSM叫LACLTE叫TAC含义类似CI/ECI小区标识0x2A3或675同一LAC下唯一RSRP参考信号接收功率-95 dBm数值越小信号越弱RSRQ参考信号接收质量-10 dB与干扰相关TA时间提前量1与距离有关单位约78m/78mTime上报时间2024-05-01 10:00:00时区要统一拿到数据后先看有没有MCC、MNC、LAC/TAC、CI四件套。只有IMEI而没有这些字段只能做设备维度分析四件套齐全才能进一步映射位置和覆盖。RSRP和TA经常存在缺失缺失不影响基础聚合但在做弱覆盖判断时需要先补默认值或过滤掉空值。3. 解析与清洗把非结构化记录变成可分析表格压缩包里的文件可能是空格分隔的文本、CSV或者Excel导出直接读进pandas经常会遇到编码、类型和缺失值问题。清洗阶段的目标是得到一张每行代表一条“IMEI在某时刻接入某基站”记录的标准表。这个过程中有两个关键点IMEI格式统一基站CGI列生成。3.1 用pandas读取文件并处理编码与类型常见做法是先读入原始文件打印行数和列名确认字段名是英文还是中文再处理类型。import pandas as pd raw_df pd.read_csv(imei_report.txt, sep\t, encodingutf-8-sig, dtype{IMEI: str, MCC: str, MNC: str, LAC: str, CI: str}) print(raw_df.shape) print(raw_df.head()) raw_df.columns [col.strip() for col in raw_df.columns]参数里sep\t表示按Tab分隔如果文件是逗号分隔就改为sep,。encodingutf-8-sig能自动去除UTF-8 BOM头避免第一列列名出现\ufeff前缀。dtype把所有ID类字段指定为字符串是最容易忽略的一步——如果让pandas把IMEI当成数字读取15位的整型会被截断成科学计数法。读取后立即打印shape和head判断字段数量是否与想象一致。3.2 IMEI标准化与批量校验读入后IMEI可能混有空格、连字符、TAC编号前缀。先用正则提取纯数字串再逐条做Luhn校验。import re def extract_imei(text): matches re.findall(r\b(\d{14,15})\b, str(text)) if not matches: return None digits matches[0] return digits if len(digits) 15 else digits.zfill(15) raw_df[IMEI_clean] raw_df[IMEI].apply(extract_imei) raw_df[imei_valid] raw_df[IMEI_clean].apply( lambda x: luhn_check(x[:14]) int(x[14]) if x else False )extract_imei用\b(\d{14,15})\b提取连续14到15位数字避免把十六进制基站ID或时间戳里的数字误抓。长度是15位则直接用如果只有14位且前导零被Excel吃掉用zfill(15)补回。luhn_check(x[:14]) int(x[14])把前14位带入之前的函数结果与第15位比较。校验失败的数据不是完全不能用但至少要标记出来单独检查是否来自某些老版本终端。3.3 关联基站信息用CGI作为唯一标识基站信息表里通常有经纬度但原始上报记录里一般只有LAC和CI甚至只有CGI字符串。CGICell Global Identity由MCC、MNC、LAC/TAC、CI拼接而成是全网唯一的基站小区标识。raw_df[CGI] ( raw_df[MCC].str.strip() - raw_df[MNC].str.strip() - raw_df[LAC].str.strip() - raw_df[CI].str.strip() ) cell_df[CGI] ( cell_df[MCC].str.strip() - cell_df[MNC].str.strip() - cell_df[LAC].str.strip() - cell_df[CI].str.strip() ) merged pd.merge(raw_df, cell_df[[CGI, latitude, longitude]], onCGI, howleft) print(merged[latitude].isna().sum())清洗时先对每个字段strip()防止ID里藏空格导致CGI匹配不上。两个DataFrame都在同一规则下生成CGI再pd.merge关联基站经纬度。howleft保留上报表的全部记录匹配不到的经纬度会变成NaN。打印缺失数量即可知道基站映射表的覆盖率。映射时注意LTE数据的TAC字段不能直接塞进LAC列虽然二者数值范围相似但在不同网络制式下语义不同混用会导致定位串站。4. 实际操作落地设备活跃度、基站负载与弱覆盖评估数据清洗干净后就到了最有价值的应用环节。最常见的三个方向分别是设备活跃度分析、基站负载统计、弱覆盖估算。这里的“IMEI.rar_IMEI_基站”包如果字段完整可以一次性做全。4.1 设备活跃度分析找出“活跃设备”和“僵尸设备”活跃度分析的逻辑很简单统计每个IMEI出现了多少次、接入过多少个不同基站、最后一次上报时间在什么时候。device_activity merged.groupby(IMEI_clean).agg( report_count(Time, count), cell_count(CGI, nunique), first_seen(Time, min), last_seen(Time, max), ).reset_index() device_activity[active_days] ( pd.to_datetime(device_activity[last_seen]) - pd.to_datetime(device_activity[first_seen]) ).dt.days print(device_activity.sort_values(report_count, ascendingFalse).head(10))report_count表示上报次数次数过高但保持不变的IMEI可能是测试终端或者上报机制异常。cell_count表示接入的独立小区数如果某IMEI一天内跨了几十个小区可能是高铁高速场景或者移动性异常。active_days用最后一次上报时间减去第一次上报时间计算出活跃天数便于筛出连续多天不活跃的设备。这里我习惯把结果再按report_count分桶0次说明数据包可能缺失该设备1次说明只有单条记录超过100次说明高频运行。对设备资产管理来说高频活跃设备需要重点关注单次记录设备则可能是偶发接入。4.2 基站维度统计定位高负载与覆盖边缘反过来按CGI聚合可以知道每个小区覆盖了多少台独立设备。这个数据对网络扩容和基站巡检很有指导价值。cell_load merged.groupby(CGI).agg( user_count(IMEI_clean, nunique), report_count(Time, count), avg_rsrp(RSRP, mean), avg_ta(TA, mean), ).reset_index() cell_load[signal_class] cell_load[avg_rsrp].apply( lambda x: good if x -90 else (medium if x -105 else weak) ) print(cell_load.sort_values(user_count, ascendingFalse).head(20))user_count是去重后的IMEI数量更能反映实际用户规模report_count含重复上报反映流量压力。avg_rsrp低于-105dBm的基站要重点验证覆盖avg_ta值过大则说明该小区下连接的设备较远可能是广覆盖基站。signal_class作为简单分类标签便于后续筛选。需要提醒的是基站维度聚合结果不能直接代表真实信号强度因为上报终端的芯片灵敏度、天线增益不一致但作为相对排名足够用。真要判断是否需要加站还要结合路测和工参中的天线挂高、站点类型一起看。4.3 弱覆盖估算RSRP与TA组合判定弱覆盖不能只看RSRP还要看TA。RSRP很低同时TA很小说明设备就贴着基站但信号差问题可能出在遮挡或室内污损RSRP低但TA大说明设备已经在小区边缘覆盖能力不足。merged[rsrp_valid] merged[RSRP].notna() merged[ta_valid] merged[TA].notna() merged[is_weak] ( (merged[RSRP] -110) (merged[TA] 2) ) weak_summary merged[merged[is_weak]].groupby(CGI).agg( weak_count(IMEI_clean, count), weak_users(IMEI_clean, nunique), ).reset_index() print(weak_summary.sort_values(weak_count, ascendingFalse).head(10))代码中先判断RSRP和TA字段是否为空缺失值不参与弱覆盖判定。is_weak的条件是RSRP小于-110dBm且TA大于2这两个阈值在不同指标定义下可以调整比如某些场景用-115dBm更合适。弱覆盖小区列表生成后可以再和基站经纬度表join输出给现场巡检。这个组合判定比单一RSRP阈值靠谱的原因在于RSRP是设备侧测量的参考信号功率受终端型号影响较大TA则是基站根据上行定时估计出来的设备距离两者互补能减少“远处强信号、近处弱信号”这种特殊场景的误判。5. 避坑指南IMEI与基站数据处理的5个常见翻车现场这类数据处理看似简单实际操作中翻车点非常集中。以下五条踩坑记录全部来自实际处理经验按“现象—原因—解决”的方式记录能帮你节省至少半天排查时间。5.1 现象解压后文件名乱码CSV读进来第一列变成\ufeff原因RAR包内的文件名或CSV文件本身以带BOM的UTF-8编码保存或者Windows下用GBK编码生成Linux和Mac默认UTF-8读取时必然错乱。解决解压时用unrar的-p指定密码文件编码用utf-8-sig或gbk尝试。如果文件名乱码使用unrar x -ai强制用系统编码重命名。读取CSV时可以写一个简单的编码探测with open(imei_report.txt, rb) as f: head_bytes f.read(200) for enc in [utf-8-sig, utf-8, gbk]: try: print(head_bytes.decode(enc)) break except UnicodeDecodeError: continue5.2 现象同一IMEI对应多个基站直接去重后数据急剧减少原因设备在移动过程中切换基站同一时间窗内上报多条记录是正常的。直接按IMEI去重会把非常宝贵的移动轨迹信息丢掉。解决先按时间排序再去重。merged merged.sort_values([IMEI_clean, Time]).drop_duplicates( subset[IMEI_clean, CGI, Time], keepfirst )如果数据存在多个采集源需要确认时间字段的时区避免同一时刻因为时区不同产生伪多记录。5.3 现象Luhn校验失败率过高几乎一半IMEI都被标记为无效原因数据源里的字段可能并非IMEI而是IMEISVIMEISV第15、16位是软件版本号不参与Luhn校验。也可能是OCR/手工录入导致个别数字识别错误。解决先区分两种格式IMEISV长度是16位先把最后一位去掉取前15位。如果前14位算出的校验位与第15位一致说明这是截断后的IMEISV。def imei_validate_with_sv(value): if len(value) 16: value value[:15] if len(value) ! 15: return False return luhn_check(value[:14]) int(value[14])5.4 现象基站LAC和CI字段部分显示为十六进制部分为十进制CGI关联失败原因RAR包中的基站字段可能来自两个不同系统一个输出十进制6683另一个输出十六进制0x1A2B没有统一转换。解决先判断是否为十六进制字符串再做转换。def to_dec(v): v str(v).strip() if v.lower().startswith(0x): return str(int(v, 16)) return v对所有LAC/TAC和CI字段应用该函数再拼接CGI。5.5 现象RAR解压过程中报CRC错误解压出来的文件被截断原因下载不完整、分包缺失或者RAR包本身在传输中被破坏。解决先校验包内文件CRC。unrar t IMEI.rarunrar t只测试文件完整性不真正解压。若CRC报错检查分卷是否齐全或重新下载。强制解压出来的文件即使能打开数据也是残缺的后续统计完全不可信。这一步是最容易无视的坑直接硬跑分析最后拿到的结论往往与真实情况偏差很大。6. 进阶用基站经纬度把覆盖盲区画成热力地图如果基站配置表里带了经纬度前面merge后的表可以直接用来画热力图。这一步非常适合快速向非技术同事解释“数据能说明什么”——一张布满红点的地图比任何报表都有说服力。import folium from folium.plugins import HeatMap cell_coverage merged.dropna(subset[latitude, longitude]) center_lat cell_coverage[latitude].median() center_lng cell_coverage[longitude].median() m folium.Map(location[center_lat, center_lng], zoom_start9) heat_data cell_coverage[[latitude, longitude, RSRP]].values.tolist() HeatMap(heat_data, radius15, blur10, min_opacity0.3).add_to(m) m.save(imei_cell_heat.html)HeatMap的radius控制点的影响半径数值越大地图上红色团越粗blur是模糊程度调大可以让热区更平滑min_opacity防止稀疏区域变成完全透明。注意传入的RSRP作为热力权重数值越大越红但RSRP实际是负数通常需要做一次线性映射。简单做法是先把RSRP调整为-RSRP再保存。如果没有经纬度也可以先按CGI聚合出基站负荷再把CGI关联到本地维护的基站台账表。注意台账表更新很关键很多情况下站点早已替换但经纬度仍是老位置导致热力图上的热点偏移几百米。画完图后把弱覆盖小区单独用不同颜色标记出来保存成HTML发给现场同事就能直接导航去现场抽测。我现在的习惯是拿到任意IMEI/基站压缩包先跑unrar t再读文件头最后才写清洗脚本。这一套流程已经在好几个类似数据包上验证过能稳定产出设备活跃度表和覆盖盲区清单。希望帮到你。本文还有配套的精品资源点击获取 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
