企业官网建设流程全解析

简介：这份PDF是一份系统讲解第三代移动通信系统的技术资料，适合通信工程专业学生、移动通信从业者及准备3G相关考试或课程设计的人群阅读，帮助理解3G系统架构、无线接入、核心网与业务应用的整体框架。文档围绕WCDMA、TD-SCDMA、CDMA2000等主流无线传输技术展开，并梳理了从接入层、传输层、控制层到业务应用层的分层结构，以及IMS多媒体子系统、HSDPA、MGW、CSCF等关键概念与网元功能，内容偏重理论与系统组成，适合作为入门到进阶的参考资料。资源为单个PDF文档，文件大小约680KB，共1个文件，便于直接打开阅读或打印。目前已有178人学习使用。文档在介绍3G基本概念的基础上，进一步给出了多媒体子系统、RNC/BSC/NodeB/BTS等无线接入设备的应用示例，有助于读者将抽象分层模型与具体网元对应起来，形成相对完整的知识体系。

1. 第三代移动通信系统不是过渡技术，而是分组化的奠基

很多工程师的硬盘里都躺着一份《第三代移动通信系统.pdf》，翻过前两章就被 UTRA、R99、WCDMA 这些缩写劝退。3G 在业务速率上确实输给 4G，但在网络设计上绝不是短命过渡：WCDMA 把移动通信从电路域拉进分组域，LTE 的 QoS 架构和状态机设计大量继承了 R99；今天不少 Cat.1 物联网模块的注册与 APN 协商流程，仍然沿用第三代移动通信系统里的 PDP 上下文激活逻辑。与其把这份资料当历史书读，不如按工程线索拆开：制式怎么选，无线侧参数怎么设，核心网流程怎么抓包验证，最后把现网最难区分的问题——覆盖受限还是干扰受限，用现成工具和数据分开。

2. 第三代移动通信系统的制式坐标：WCDMA、CDMA2000 与 TD-SCDMA

2.1 三种制式的参数对比与选型逻辑

第三代移动通信系统不是单一标准，而是 ITU IMT-2000 的落地产品集。IMT-2000 给出的目标速率是车速环境 144 kbps、步行环境 384 kbps、室内 2 Mbps，各区域标准化组织沿着不同技术路线实现，最终形成三大阵营：3GPP 的 WCDMA、3GPP2 的 CDMA2000，以及 3GPP R4 纳入的 TD-SCDMA。下表是读规范时最常对照的一组参数：

三种制式都叫 CDMA 或类 CDMA，但码片速率完全不同，不能拿同一套扩频因子概念去套。码片速率高，在相同业务速率下扩频增益更大，抗干扰能力更强；但代价是单个载波占用带宽大，频谱利用率在低频段会受到频率资源总量的制约。WCDMA 的 5 MHz 载波在同等频段里可规划的载波数最少，CDMA2000 的 1.25 MHz 载波扩容粒度最细，TD-SCDMA 的 1.6 MHz 窄带宽在室内分布改造中很灵活，但 TDD 对基站间同步和时隙配比的要求严格，干扰控制难度更大。工程选型没有绝对优劣，只有在你分配的频段里能不能把站拉开、把干扰压住的问题。

如果维护的是混合制式一张网，链路预算里还要注意：WCDMA 与 CDMA2000 都来自 IS-95 的 CDMA 框架，但功率控制速率不同，WCDMA 内环每秒 1500 次，CDMA2000 为 800 次，这决定了各自对抗快衰落的上限。读 PDF 里那些链路预算表格时，先看它针对哪种制式，否则把 WCDMA 的软切换增益挪到 TD-SCDMA 上算覆盖，会高估 2～3 dB。

2.2 看图纸和查终端，快速定位当前是哪种制式

拿到一张不认识的移动通信网络拓扑图，先看图里出现的是 Uu 还是 Um 接口。Uu 是 UTRAN 的无线接口，出现在 WCDMA 或 TD-SCDMA 图纸里；Um 是 GSM 的接口；出现 Iu-CS、Iu-PS 的说明是 3G 核心网组网，出现 A 接口数字中继的则更接近 cdma2000 或 GSM 网络。图例比正文可靠，这一步能避免把边角料章节当成主干读。

如果到了现场想确认终端当前注册在哪种制式，我一般用 ModemManager 而不是手机界面的信号格。Linux 下执行：

mmcli -L mmcli -m 0 --command='AT+COPS=?'

第一条命令列出机器上的 modem 编号，第二条命令让 modem 搜索当前可选网络。返回结果是一串网络和接入技术标识，标有 UTRAN 的对应 WCDMA 或 TD-SCDMA，标有 cdma2000/1x 的对应 CDMA2000，只有 GSM/GPRS 的说明还没有注册到 3G。这里-m 0是第一个 modem，多模组环境改成实际编号。这个查询指令是只读的，不会触发网络注册，可以在测试前放心先跑一遍。

3. 第三代移动通信系统的无线接入：码片速率、功率控制与软切换

3.1 扩频因子、码片速率和承载速率的关系

WCDMA 的信息比特先经过编码、交织变成符号，再用扩频码扩展到 3.84 Mcps 的码片速率。扩频因子 SF 表示每个符号占用的码片数，SF 越小，符号传输速率越高。下面是在配置 RRC 承载时常用的一张对照表：

表格里写的是“级别”而不是精确带宽，因为 R99 的实际无线承载还取决于编码速率、TTI 和是否多码道组合。做优化时，如果信令侧看到分配的是 SF=128，但业务类型是视频流，那基本可以判断网络侧没有按预期下发高速率承载，问题在 QoS 配置而不是空口质量。CQI、BLER 这些指标都要和 SF 一起看，手机下载速率慢但 SF 一直停在 128，先查核心网协商结果，而不是去调天馈。

3.2 功率控制的三层结构：开环、内环、外环

WCDMA 是自干扰系统，同一频点上所有小区共用频谱，功率控制如果不及时，一个用户就是整个小区的干扰源。三层功控链路各管一段：开环控制只用在随机接入前导阶段，终端测量 CPICH RSCP，估算路径损耗，再按目标 SIR 反推初始发射功率；专用信道建立后进入内环控制，NodeB 每个时隙（2/3 ms）比较接收 SIR 与目标 SIR，下发 TPC 命令，速率为每秒 1500 次；外环控制在 RNC 侧，按 BLER 目标周期性地调整内环的目标 SIR。

容易出问题的往往是外环目标设得太激进。现网有一次把 PS 域 BLER 目标从 10% 改成 1%，结果整网 RTWP 抬升了将近 3 dB，原因是终端为满足过高 SIR 目标不断加大发射功率，上行底噪被整体推高。后来按业务分开配置，语音 BLER 目标保持 1%～2%，数据保持 5%～10%，RTWP 才回落到正常水平。看到手机上行发射功率普遍偏高时，不要只查覆盖，先看功控步长和 BLER 目标再动天馈。

3.3 软切换的测量事件和 RRC 连接建立时延统计

WCDMA 的移动性靠同频软切换保证。终端测量邻区 CPICH，当邻区质量进入事件 1A 触发条件并持续一段时间，就上报测量报告；RNC 下发无线链路增加请求，把该小区加入激活集。事件 1B 是删除链路，事件 1C 是替换。工程上常用邻区 CIO 和延迟触发时间控制软切换比例，CIO 调负会让小区更难进激活集，延迟触发时间加大能让短暂起伏的信号不被纳入。越区覆盖导致的乒乓切换，我一般先往负方向调 0.5～1 dB CIO，再加大延迟触发时间，而不是直接压 CPICH 功率。

现场验证 Uu 口拥塞时，我会把 L3 消息导出成文本，用下面这段 awk 快速统计 RRC 连接建立时延：

grep -E "RRC CONNECTION REQUEST|RRC CONNECTION SETUP COMPLETE" l3_message.txt | awk ' /RRC CONNECTION REQUEST/ { start=$1; cause=$NF } /RRC CONNECTION SETUP COMPLETE/ && start!="" { printf "delay=%.3fs cause=%s\n", $1-start, cause; start="" }'

这段命令把同一条 RRC 连接从请求到完成的时间差算出来，$1是导出文件中的时间列，如果不是第一列要改成实际列号，时间如果是HH:MM:SS格式得先转成秒再相减。时延包含随机接入、调度和 RNC 资源分配，大量超过 500 ms 时，问题大概率在 Uu 口随机接入参数或 NodeB 资源拥塞。带上cause字段还能区分紧急呼叫和数据业务，判断是哪类用户把 RRC 连接资源耗尽。

4. 第三代移动通信系统的核心网分组域：从 IMSI 附着到 PDP 上下文激活

4.1 R99 核心网的两个域和三个关键接口

第三代移动通信系统的核心网在 R99 版本延续了 GSM/GPRS 的双域结构：电路域负责语音，节点是 MSC、VLR、HLR；分组域负责数据，节点是 SGSN 和 GGSN。无线侧 RNC 分别通过 Iu-CS、Iu-PS 接口接到两个域；SGSN 与 GGSN 之间是 Gn/Gp 接口。做数据业务排障时，真正重要的是 IuPS 和 Gn：

很多“上网慢”的投诉，一开始就被拉去抓空口，但真正的分界点在 PDP 上下文激活流程。PDP 上下文激活成功后，终端才拿到可路由的 IP 地址；激活失败或时延大，应用层再快也无法建立连接。所以我的习惯是先看分组域的附着与激活计数器，再决定要不要看无线侧。

4.2 附着与 PDP 上下文激活的信令顺序

分组域业务流程按下面几步记：

1. UE 发起 GPRS Attach Request，携带 IMSI 或 P-TMSI，SGSN 与 HLR 完成鉴权和位置更新。
2. SGSN 返回 Attach Accept，UE 进入 GPRS Attached 状态。
3. 用户发起上网时，UE 发送 Activate PDP Context Request，SGSN 根据 APN 解析出 GGSN 地址。
4. SGSN 向 GGSN 发送 Create PDP Context Request（GTP-C 类型 0x10），GGSN 分配 IP 地址并建立 QoS 与计费规则。
5. GGSN 返回 Create PDP Context Response（GTP-C 类型 0x11），SGSN 再向 UE 返回 Activate PDP Context Accept。

步骤 3 到 5 是最常见的故障区间。SGSN 解析 APN 依赖 DNS，DNS 配置错误会直接导致 APN not found；GGSN 资源池满时，响应中会带 No resources available，用户表现为能附着但打不开网页。还有一种情况是 QoS 协商失败：请求里带最大比特率 MBR、保证比特率 GBR，GGSN 侧如果不支持该等级，会把 QoS 降级或直接拒绝。因此排查时不要只看信令流程走到哪一步，还要展开 Create PDP Context Request 里的 QoS 信息元素。

4.3 用 GTP-C 消息类型过滤一次 PDP 激活

Gn 接口上 GTP-C 使用 UDP 2123 端口。抓包后用一条 tshark 命令就能看见整个 PDP 激活请求的时间分布：

tshark -r gn.pcap -Y 'gtp.message_type == 0x10' -T fields -e frame.time -e gtp.teid

0x10在 GTPv1-C 里对应 Create PDP Context Request。要把响应也显示出来，就把过滤器改成gtp.message_type == 0x11再跑一次，同一对 TEID 出现在两条记录里的时间差，就是 SGSN 到 GGSN 的处理时延。如果超过 1 秒，优先查 GGSN 负载和 DNS 解析 APN 耗时。-Y是显示过滤器，在导出 CSV 做统计分析时也可以换成-T fields -e frame.time_delta -e gtp.teid，把结果重定向到文件再导入表格。

Gn 抓包时还要注意接口区别：IuPS 接口的控制面是 RANAP，不是 GTP-C；用户面才是 GTP-U。RNC 到 SGSN 的报文用 RANAP 解析，SGSN 到 GGSN 的报文用 GTP-C 解析。如果看到大量 UDP 2152 的双向包，那是 GTP-U 用户面，不代表控制面有问题。用户面抓包关注的是 GTP-U 序号乱序和丢包，控制面关注的是消息类型和错误码，两条线不能混在一起看。

5. 第三代移动通信系统的现场优化：从路测 CSV 把覆盖和干扰分开

5.1 用 CPICH RSCP 和 Ec/Io 给采样点分类

WCDMA 路测里，CPICH RSCP 表示导频接收信号码功率，Ec/Io 表示码片能量与总干扰加噪声的比值。只看 RSCP 不看 Ec/Io 会犯方向性错误。RSCP 高于 -90 dBm 但 Ec/Io 低于 -12 dB，说明信号不弱、干扰很强，继续加功率只会恶化全网底噪；RSCP 低于 -105 dBm 且 Ec/Io 也低，才是典型的覆盖受限，适合加站或调整天馈。导频污染则表现为多个小区强度接近，RSCP 不差但 Ec/Io 持续波动。

5.2 最小可运行的分类脚本

下面脚本把路测 CSV 的采样点按覆盖、干扰、正常三档分开：

import csv count = {"coverage": 0, "interference": 0, "normal": 0} interference_points = [] with open("dr_test.csv", newline="") as f: for r in csv.DictReader(f): rscp = float(r["cpich_rscp"]) ecio = float(r["cpich_ecio"]) if rscp <= -105: count["coverage"] += 1 elif rscp > -90 and ecio < -12: count["interference"] += 1 interference_points.append((r["lng"], r["lat"], rscp, ecio)) else: count["normal"] += 1 print(count) print("干扰点位示例：", interference_points[:5])

阈值按工程经验设：-105 dBm 是 WCDMA 覆盖可接受下限，-12 dB 是 Ec/Io 的常见门限。运行前先用head -1确认 CSV 里字段名确实叫cpich_rscp和cpich_ecio，不同路测软件导出的列名不一样。脚本不只能输出统计，还会保留干扰点的经纬度，方便下一步做成点位图或栅格图。

5.3 先验证再动参数，一次只动一个变量

干扰受限的点位聚成一团时，先查 RTWP 和外部干扰源，再查邻区漏配；聚成一条线时，很可能是沿街基站天线下倾角不足，信号越区覆盖。覆盖受限的点位聚成一片，才考虑加站或增强 CPICH 功率，否则容易引入新的越区干扰。改完参数只跑一轮前后对照：同一路段、同一时间段，比较干扰点占比和软切换比例。如果干扰点减少但覆盖点增加，说明调整幅度偏大，按二分法回退即可。

我一般会在现场先跑这个脚本，再结合邻区测量数据看哪些小区频繁出现在干扰采样点里，把问题收敛到具体基站。整套流程十分钟做完，比对着话统盲调参数要省事得多。

本文还有配套的精品资源，点击获取