语音版本信令分析指导书
文件编号：1.1.1.1（根据在资料架构中的归属编号）版本：1.0
中兴通讯移动网规网优部发布
移动网规网优部GSM产品技术指导书
内部公开▲
目录
1语音版本介绍 (1)
2手机支持语音版本的信令分析 (1)
2.1 Setup/Call confirmed简析 (1)
2.2 Bearer capability详述 (3)
2.2.1 Bearer capability IEI (4)
2.2.2 Length 长度指示 (4)
2.2.3 Extension bit 扩展比特 (4)
2.2.4 Radio channel requirement (octet 3，MS to network) 无线信道要求 (4)
2.2.5 Coding standard (octet 3) 编码标准 (5)
2.2.6 Transfer mode (octet 3) 传输模式 (5)
2.2.7 Information transfer capability (octet 3) 消息传输能力 (5)
2.2.8 Speech version indication 语音版本指示 (6)
3手机支持语音版本的信令统计 (6)
3.1 注意事项 (6)
3.2 统计案例 (7)
附录A 信令数据 (11)
内部公开▲1 语音版本介绍
GSM手机一共支持如下几类语音版本：
（1）GSM full rate speech version 1（FR）
下表为Call confirmed消息内容的前几个字节：
Protocol Discriminator编码为0 0 1 1（Call Control）。
二者主要的不同之处在于Transaction identifier（TI）和Message type（MT）, 这
里不多做解释，通常二者编码如下：
注：如果消息由网络侧发起，那么Message Type 的比特7 为0；如果由手机侧
发起，则Bit 7保留用于发送序列号。
所以通常Setup的头两个字节编码为03 05/45，而Call Confirmed的头两个字节
编码为83 08/48。
协议规范中Repeat Indicator解释如下：
The BC repeat indicator information element is included if and only if bearer capability
1 information element and bearer capability
2 IE are both present in the message.
这个主要是用在dual service，没有细究，通常setup或者call confirmed中没有这
个字节，紧接着就是Bearer capability。
2.2 Bearer capability详述
Bearer capability中与语音版本相关内容的信令编码格式如下：
2.2.1 Bearer capability IEI
Bearer capability的IEI为04。
2.2.2 Length 长度指示
该消息单元指示后续bearer capability内容的长度。
2.2.3 Extension bit 扩展比特
在每个消息单元的首字节，如果为0，表示后续还有别的消息单元属于Bearer
capability，如果为1，表示这是bearer capability的最后一个字节。
2.2.4 Radio channel requirement (octet 3，MS to network) 无线信道要求
指示手机对无线信道的要求（是否支持半速率）。协议规范解释如下：
When information transfer capability (octet 3) indicates the value speech and speech
version indication(s) is(are) present in octet 3a etc：
Bits 7 6
0 0 reserved
0 1 the mobile station supports at least full rate speech version 1 but does not
support half rate speech version 1. The complete voice codec preference is
specified in octet(s) 3a etc. 至少支持FR1，但是不支持HR1
1 0 The mobile station supports at least full rate speech version 1 and half rate
speech version 1. The mobile station has a greater preference for half rate
speech version 1 than for full rate speech version 1. The complete voice
codec preference is specified in octet(s) 3a etc. 支持半速率，半速率优先。
1 1 The mobile station supports at least full rate speech version 1 and half rate
speech version 1. The mobile station has a greater preference for full rate
speech version 1 than for half rate speech version 1. The complete voice
codec preference is specified in octet(s) 3a etc.支持半速率，全速率优先。
2.2.5 Coding standard (octet 3) 编码标准
Bit 5：
0 GSM standardized coding as described below
1 reserved
2.2.6 Transfer mode (octet 3) 传输模式
Bit 4：
0 circuit mode
1 packet mode
2.2.7 Information transfer capability (octet 3) 消息传输能力
Bits 3 2 1：
0 0 0 speech
0 0 1 unrestricted digital information
…… 省略
所以字节3的编码主要有如下几类：
Bits 8 7 6 5 4 3 2 1
至少支持FR1，但是不支持HR1 0/1 0 1 0 0 0 0 0 (A0/20)
都支持，全速率优先0 1 1 0 0 0 0 0 （60）
都支持，半速率优先0 1 0 0 0 0 0 0 （40）
2.2.8 Speech version indication 语音版本指示
从字节3a开始，按照优先等级开始描述手机支持的每个语音版本，例如字节3a
（语音版本指示的第一个字节）具有最高优先级。
语音版本指示的编码如下：
Bits 4 3 2 1
0 0 0 0 GSM full rate speech version 1
0 0 1 0 GSM full rate speech version 2
0 1 0 0 GSM full rate speech version 3
0 0 0 1 GSM half rate speech version 1
0 1 0 1 GSM half rate speech version 3
综上所述，BearerCapability常见的几种编码如下：
（可能不全，只是从信令数据中得到）
只支持全速率04 01 A0 只支持FR
04 03 20 02 80 支持EFR
都支持，全速率优先04 06 60 04 02 00 05 81 支持AMR
04 04 60 02 00 81 不支持AMR
04 05 20 04 02 00 85 支持AMR全速
率和AMR半速率，不支持HR v1
都支持，半速率优先04 04 40 02 01 80 不支持AMR 3 手机支持语音版本的信令统计
3.1注意事项
进行信令统计时，必须注意下面几点：
（1）主叫手机对语音版本的支持能力的判断依据是Setup，而被叫手机对语
音版本的支持能力的判断依据是Call Confirmed；需要分别统计；
（2）对于主叫，不能单纯依靠Setup的信令筛选，因为不管主被叫，信令里
都有Setup消息，而被叫Setup消息里提供的信息可能是不准确的；
（3）如果只是单纯分析手机是否支持全速率或者半速率，那么只需看Radio
Channel Requirement这个字段即可，比如dual rate support mobile
station/full rate preferred或者full rate support only mobile station；
（4）如果需要进一步判断对AMR语音版本的支持，可能由于目前使用的
MA10版本低，MA10关于这类消息单元的解释有误，例如当手机不支
持AMR时，Speech version indication显示GSM full rate speech version
3；所以得根据具体的信息编码来判决。
3.2统计案例
由于被叫的Call confirmed 比较简单，本章节中以Setup为例来说明如何统计主叫
用户支持半速率的比例。
STEP 1：Filter → Message → DTAP CC → SETUP 筛选SETUP消息
STEP 2：Filter → Link Selection → Uplink 筛选SETUP消息，过滤掉无用的被叫Setup消息
STEP 3：双击任意一条SETUP消息，然后选择File → Export detail 输出为文本文档
STEP 4：用UltraEdit打开文本文档，使用UltraEdit的统计功能进行统计。
内部公开▲附录A信令数据
X2IPPATH配置问题导致切换不成功 关键字：X2IPPATH 切换 【现象描述】 切换测试时，从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败，HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE，进入该消息中可以看到cause为transport-resource-unavailable，切换不成功，如下图所示。 【原因分析】 对于切换流程失败而言，如果是切换准备阶段的失败，其原因通常为以下几种： （1）传输资源不够用； （2）没有配置IPPATH； （3）IPPATH中的邻居节点配置错误。 由于切换测试阶段的网络业务负载很小，接入用户数少，通过X2口传输的数据不多，一般来说不会出现传输资源不够用的情况。所以可以先重点怀疑IPPATH配置的问题，在处理过程中需要对X2口和IPPATH问题排查处理，一步步解决问题。 【处理过程】 每次切换到目标小区完成后，UE会读取目标小区的系统消息（RRC_SIB_TYPE1）,该消息中可以看到目标小区的CGI，通过CGI中的基站ID确认目标基站B2的ID。从该次切换的切换命令 （RRC_CONN_RECFG）可以找到目标小区CELL2的PCI，在目标基站B2中用MML命令查询确实存在小区CELL2，所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。 先查看B2基站对应的IPPATH有没有配置，如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。在webLMT上的命令如下： LST SCTPLNK；检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。 DSP X2INTERFACE；检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No，查看对应X2接口的标识X2InterfaceId。
1 信令分析 在分析问题时，请参照正确的流程，逐步检查到底哪一条消息没有收到，并且分析上一条消息里面携带的内容，从而定位原因所在。 1.1 主被叫呼叫建立流程 1.1.1正常信令 在分析接入问题时，请参照上图所示正确的流程，逐步检查到底哪一条消息没有收到，且分析上一条消息里面携带的内容，从而定位原因所在 【注】Abis-BTS setup消息里面，携带了接入的小区、扇区、walsh码、频点。 关键点1：BSC向MSC发送CM Service Request后，是否收到Assignment Request。如果没有收到MSC发的Assignment Request,等到6s后定时器超时，基站会给手机发送release order.这种情况是A1接口失败。 关键点2：BTS是否向BSC发送Abis-BTS Setup Ack。Abis如有问题，如误码高、信令链路带宽不足等，将会体现为Abis无法建链成功，话统原因“指配资源失败” 关键点3：是否发送ECAM（扩展信道指配消息）消息。如Abis正常建链，但却没有发送ECAM消息，在话统里面会体现为“指配资源失败”，可能原因是walsh、CE、power不足。 关键点4：是否在F-DSCH发送order message，如没有收到，说明捕获业务信道前导帧
失败。 关键点5：是否发送Assignment complete。如发送表明呼叫建立成功。如没有收到，在话统里面体现为“信令交互失败”。 被叫流程与主叫几乎完全一致，被叫中的Paging Response相当于主叫的origination message。 1.1.2典型异常信令 1、A1接口失败。 2、传输误码率高导致指配资源失败
信令跟踪在维护工作中的运用目前移动通信竞争激烈,客户对移动运营商的要求越来越高。运营商对我们的要求也就更高。优质的网络是我们公司发展的基础,确保网络的正常运行是我们公司的立足之本。在这里简要谈谈信令跟踪在网络维护工作中的运用。 所谓信令跟踪分析是指用仪表收集跟踪移动通信的无线链路上的信令数据并加以整理,从中查找出异常的指标数据;利用软件进行分析,找出故障所在,并有效地解决排除,最终达到提高网络运行质量的目的。 信令跟踪在网络优化工作中也是比较重要的一步,它主要用来查找硬件的隐性故障和干扰频点等问题;无线链路上的信令提供了较全面的质量数据。用阿尔卡特公司的DAFNE软件分析的数据中可以看到各频点的上下行接收电平、上下信道质量、上下行信道质量差、上下行路径损耗、上下行路径差、信道质量分布表、时间提前量分布、信令统计等信息。 那么我们怎么通过这些数据来分析网络中的隐藏的故障呢?下面通过对网络中平常的一些隐性故障的处理来介绍一下信令跟踪分析数据的运用。 由于无线环境的恶劣性,移动通信的无线信道无时不经受着来自外界或本身的干扰。我们怎么从信令数据中查找受干扰的频点呢?一般说来,干扰直接影响信道质量的下降,但对信道的电平则没有多大的影响。所以我们可以查看上下行信道的quality值和上下行的路径损耗值(一般要求上下行信道的quality值在0.5以下,假设某个频点的质量较差,而它的上下行路径损耗与其它频点相差不大,那么这个频点受干扰的可能性比较大。 网络设备的硬件隐性故障问题一直是我们维护人员最头痛的,比如说某基站的 无线原因掉话一直很多,我们可以在分析报告中查看路径损耗值及路径损耗差与信道质量。一般路径损耗差在-10至1dB之间(当然也可以将目标定得高一点,信道质量在0.5以下,如果上行损耗过大或下行损耗过大都很容易引起掉话,所以要更换相应频点的硬件。比如义乌小商品市场的一个基站,每天均有10多次的信道掉话,
目录 1高掉话高分配失败案例 (2) 1.1小区高掉话案例1 (2) 1.2小区高掉话案例2 (2) 1.3小区高掉话案例2 (2) 2信令分析案例 (4) 3区域性掉话案例 (6) 3.1区域性掉话案例1 (6) 3.2区域性掉话案例2 (6) 4切换失败案例 (8) 4.1INTER BSC切换失败高小区检查 (8) 4.2INTRA BSC切换失败高小区检查 (8) 5全网优化案例 (11) 6答案 (13) 6.1高掉话高分配失败案例答案 (13) 6.1.1高掉话高分配失败案例答案1 (13) 6.1.2高掉话高分配失败案例答案2 (13) 6.1.3高掉话高分配失败案例答案2 (13) 6.2信令分析案例答案 (14) 6.3区域性掉话案例分析答案 (14) 6.3.1区域性掉话案例答案1 (14) 6.3.2区域性掉话案例答案2 (14) 6.4切换失败案例答案 (15) 6.4.1INTER BSC切换失败高小区答案 (15) 6.4.2INTRA BSC切换失败高小区检查 (15) 6.5全网优化案例答案 (16)
1高掉话高分配失败案例 1.1小区高掉话案例1 以下是某个小区Abis信令统计数据， 所用频率平均上行 接收电平 平均下行 接收电平 平均上行 接收质量 平均下行 接收质量 平均上行 路径损耗 平均下行 路径损耗 上下行路径 损耗差值 上下行质 量差值 手机平 均发射 功率 基站平 均发射 功率 采样数呼叫 次数 1 -88.84 -73.79 1.0 2 0.32 120.44 112.79 7.65 -0.7 31.61 39 4369 85 91 -85.79 -77.3 3 0.06 0.18 115.7 4 116.33 -0.59 -0.11 29.9 5 34. 6 3023 41 82 -80.64 -76.62 0.15 0.29 106.79 111.59 -4.8 -0.14 26.15 34.9 7 633 19 49 -79.53 -76.71 0.31 1.12 106.46 113.46 -7 -0.81 26.94 36.5 3406 81 TA分布： TA 0 1 2 3 4 5 6 7 百分比11.8% 55.6% 29.4% 0.4% 0.4% 0.0% 0.4% 0.2% 问题1：判断导致该小区高掉话率、TCH高分配失败率的可能原因。 问题2：该小区BCCH是占用哪个频点。 问题3：该小区上下行路径损耗是否正常，路径损耗与哪些因素有关，写出相关的计算公式。 问题4：在空间损耗中，主要损耗原因有哪些？当这些因素扩大一倍，损耗相差几个db? 1.2小区高掉话案例2 现象：某小区的TCH分配失败率及掉话率很高；根据统计报告观察，均为MC736和MC746B掉话和分配失败，且集中在各个TRX上。 问题1：请列出在几种掉话种类及计数器。 问题2：发生此类问题有几种可能。 问题3：碰到此类问题，请列出优化思路及处理方法。 1.3小区高掉话案例2 瓦口1在几个忙时均为坏小区，掉话组成为MC14C，看告警，仅有LOSS-OF-SDCCH，推断为某频点硬件有问题，关跳频、创报告、观察每个频点的占
处理流程以及数据提取方法一、投诉处理流程 二、SEQ提取数据方法 VOLTE用户投诉处理（支持实时和历史记录详单） 1、登录后，SQM》投诉用户单据查询 2、投诉用户单据查询-跟踪号码 输入号码136XXXX0505
3、投诉用户单据查询-数据查询结果（均可钻取详单） 4、投诉用户会话跟踪-创建跟踪任务(提取信令) 5、投诉用户会话跟踪-实时跟踪结果 6、信令详单提取
7、语音质量单据查询（这功能暂时我们没权限） 可针对单号码进行语音、视频质量查询，查询单号码某次通话过程中GM\S1-U口丢包情况、是否存在单通、单通时长，同时可以通过5S分片具体定位丢包时间点。
三、VOLTE根据信令分析 TD-LTE__VoLTE-SIP完整信令解析 对关键流程的解释如下表所示： 1）主叫发INVITE消息，触发主叫RRC建立过程，INVITE消息中包含被叫方的号码，主叫方支持的媒体类型和编码等。
2）主叫建立SRB2信令无线承载，QCI9默认承载和QCI5 SIP信令无线承载。例如在本例中，信令无线承载SRB-ID=2;QCI=9的默认承载的eps-BearerID=5,DRB-ID=3;QCI=5的SIP信令承载的eps-BearerID=6,DRB-ID=4 3）核心网侧收到主叫的INVITE消息以后，给主叫发送INVITE的应答消息，INVITE 100表示正在处理中。 4）核心网向处于空闲态的被叫发INVITE消息，由于被叫处于空闲态，所以核心网侧触发寻呼消息，寻呼处于空闲态的被叫用户 5）被叫建立SRB2信令无线承载，QCI9默认承载和QCI5 SIP信令无线承载 6）核心网在QCI5 RB承载上，给被叫用户发送INVITE消息 7）被叫对INVITE消息的响应 被叫收到寻呼但未收到INVITE请求，核心网问题 8）被叫方通知主叫方，自己所支持的媒体类型和编码。 9）主叫建立QCI1的数据无线承载，用于承载语音数据，使用UM方式。例如本例中，eps-BearerID=7，DRB-ID=5。关键参数包括头压缩参数，TTI Bundling，SPS。DRX参数也会按照语音业务的要求进行重新配置。 10）被叫建立QCI1的数据无线承载。例如本例中QCI1承载的eps-BearerID=7，DRB-ID=5。 11）核心网通知主叫终端的SM层，建立QCI=1的承载,例如：eps-BearerID=7 12）主叫收到被叫的INVITE 183消息 被叫上发sip183后，在激活EPS承载之前，终端上报了1条A3测报，激活EPS后，发生切换重配置消息中释放了QCI=1的DRB。起呼时MME进行激活EPS承载流程过程中，恰好发生S1切换时，由于EPS承载建立未完成，MME在切换准备阶段，对下发到目标小区的切换准备的请求消息中不携带QCI=1的VOLTE专载，导致VOLTE专载源小区完成的情况下，在目标小区被释放，切换完成后呼叫中断，重配置消息释放DRB承载，无线网与核心网配合问题 13）核心网通知被叫终端的SM层，建立qci=1的承载 14）主叫收到INVITE 183消息以后，发送确认消息PRACK，启动资源预留过程， 15）被叫收到主叫的PRACK以后，返回PRACK 200响应，启动资源预留过程， 16）主叫收到被叫的PRACK 200以后，发送UPDATE消息，标明资源预留成功。
呼叫信令详解（前后台） 呼叫流程信令图 起呼过程分四个阶段：RRC连接建立，直传信令连接建立，RAB建立，震铃接通建立RRC连接 直传信令连接建立（含鉴权和加密）
RAB建立过程
振铃，接通 RRC建立过程 （1）UE 在取得下行同步后，向NodeB发送SYNC_UL，接收到NodeB 回应的FPACH 信息后，在RACH 信道上向RNC 发送RRC Connection Request 消息，发起RRC 连接建立过程。 （2）RNC 准备建立RRC 连接，分配建立RRC 连接所需要的资源，并发送一条Radio Link Setup Request 消息给NodeB。 （3）NodeB 配置物理信道，在新的物理信道上准备接收UE 消息，并给RNC 发送一条
Radio Link Setup Response 响应消息。 （4）RNC 通过ALCAP 协议，建立Iub 数据传输承载。Iub 数据传输承载通过AAL2 的绑定标识与DCH 绑定在一起。建立Iub 数据传输承载需要NodeB 确认。 （5）（6）通过Downlink Synchronisation 和Uplink Synchronisation. 控制帧，NodeB 与RNC 为Iub 数据传输承载建立同步，此后NodeB 开始DL 发送。（7）RNC 在FACH 信道上发送RRC Connection Setup 消息给UE。 （8）UE 在DCCH 上发送RRC Connection Setup Complete 消息给RNC，RRC 连接建立完成 建立初始直传/上下行直传 （9）UE 在DCCH 上给RNC 发送一条Initial Direct Transfer（CM Service Request）消息，该消息包括了UE 请求的业务类型等信息，例如12.2K语音业务。 （10）RNC 发起初始到CN 的信令连接，并发送一条Initial UE Message 消息给CN，通知CN 关于UE 请求的业务等内容。 通过初始直接传输过程后，可使用该信令连接传输UE 和CN 之间的NAS 消息。 （11）CN 发送RANAP 消息Direct Transfer （Authentication Request）到RNC，要求对UE 进行鉴权。 （12）RNC 发送RRC Downlink Direct Transfer（Authentication Request）消息给UE。NAS 消息由UTRAN 透明的传输到UE （13）UE 发送RRC Uplink Direct Transfer Message（Authentication Response）消息给RNC，告知网络侧UE 已经按照鉴权要求完成了鉴权。 （14）RNC 发送RANAP 消息Direct Transfer 给CN，将UE 的NAS消息转发给CN。NAS 消息被透明的传输到UTRAN。 安全模式控制 （15）CN 发送RANAP 消息Security Mode Command 给RNC，要求终端进行安全模式控制。 （16）RNC 在下行DCCH 上发送RRC Security Mode Command 给UE，开始/重启加密过程。 （17）UE 成功应用新的加密方式后，在上行DCCH 上发送RRC SecurityMode Complete 给RNC （18）RNC 发送RANAP 消息Security Mode Complete 给CN，双方完成安全模式控制。建立RAB （19）（20）（21）（22）上行和下行的直接传输过程，NAS 要求传输数据， UE 向网络侧说明Bearer Capability 以及Called Number 等内容。 （22）CN 向RNC 发送RANAP 消息Common ID，告知RNC 该UE 的IMSI。 （23）CN 向RNC 发送RANAP 消息Radio Access Bearer Assignment Request ，发起RAB
武 夷 学 院 课程设计报告 数学与计算机学院 课程名称： 软交换与NGN 设计题目： NGN 网络信令跟踪与分析（SIP ）协议 学生班级： 13通信工程（1）班 学生姓名： 张骞文 何凯翔 曾德彪 陈永荣 指导教师： 石贵民 完成日期： 2016-06-17
课程设计项目研究报告 目录 第 1 章项目简介 (1) 1.1 项目名称 (1) 1.2 开发人员 (1) 1.3 指导教师 (1) 第 2 章项目研究意义 (1) 2.1 课程设计概述 (1) 2.2 需求分析及研究意义 (1) 2.3 项目内容 (1) 第 3 章采用的技术 (1) 3.1 SOFTX3000实验脚本 (3) 3.2 IAD实验脚本 (5) 第 4 章课程设计项目进度表 (7) 第 5 章课程设计任务分配表 (7) 第 6 章达到的效果 (8) 6．1程序设计思想 (8) 6．2 程序最终结果 (8) 第 7 章设计心得 (21) 第 8 章参考文献 (22)
第 1 章项目简介 1.1 项目名称 NGN网络信令跟踪与分析（SIP）协议 1.2 开发人员 张骞文（组长）、何凯翔、陈永荣、曾德彪 1.3 指导教师 石贵民 第 2 章项目研究意义 2.1 课程设计概述 通过本次实验，让学生加深对语音分组交换的理解并初步掌握SIP协议的各种消息流程以及分组交换消息抓包解析方法。 2.2 需求分析及研究意义 1、SoftX3000 1台； 2、IAD若干台； 3、实验终端电脑若干台； 4、电话机若干部； 2.3 项目内容 SIP协议 会话启动协议SIP（Session Initiation Protocol ）是由 IETF 提出并主持研究的一个在IP 网络上进行多媒体通信的应用层控制协议，它被用来创建、修改、和终结一个或多个参加者参加的会话进程。这些会话包括Internet 多媒体会议、Internet 电话、远程教育以及远程医疗等。即所有的因特网上交互式两方或多方多媒体通信活动，统称为多媒体会话。参加会话的成员可以通过组播方式、单播联网方式或者两者结合的方式进行通信。
Layer 3信令分析及流程详解汇编 陈小永整理 （杭州东信网络技术有限公司）
Layer 3信令是看网络运行情况的信息层，从第三层可以看到网络的各种动作：如：呼叫流程、拥塞、用户忙、位置更新等，并且可以对路测中的各种问题如掉话、切换失败等网络事件的原因进行准确的分析。 系统信息一般有8个类型，分别是1、2、3、4、5、6、7、8，Type 1～4只出现在待机状态下，Type 5～6只出现在通话状态下，明白这点，对以后的分析至关重要。其中2中含有：2、2bis、2ter，5中含有5、5bis、5ter，所以总共有12种系统信息，系统信息1仅用于跳频，所以称为选择项。其中1、2、3、4、2bis、2ter 、7、8都在BCCH上发送，由IDLE模式下的移动台接收。5、5bis、5ter、6在SACCH上发送，由ACTIVE模式下的移动台接收。一般来说所有系统信息在连续的8个51复帧中发送完，如下图示： 上图中的TC表示复帧序列号，可以看出，当TC=4、5时，发送的内容是可选的，其它是固定的。 TC=0固定发送跳频信息，当出现上图示的1（3）时，表示跳频时发类型1，不跳频时发类型3 当类型4中发送的关于小区重选信息不够完整时，由类型7、8补充。且在TC=7、3时发送（上图示） 对于类型5、6在下行的SACCH上发送，并没有复帧规范，除非切换完成后要立即发送类型5、6。 1、System Information Type1
说明：系统信息类型1 （频率信息） 此类型仅用于跳频时，发送内容为： 第一、小区信道描述。用于通知移动，小区采用的频带与可以供跳频用的频点。对于GSM900与GSM1800采用的格式是不同的。对于GSM900： 有一个BIT MAP 0（比特位图）用于描述两方面信息，分别为： CA-NO，取值分别为：0、1、2，代表，GSM900、GSM1800、GSM1900。 CA-ARFCN，采用的有效射频频点，当为GSM900，将有一个相应于124个频点的124位图，当某个频点被采用时，相应的比特位被置为1，否则将被置为0. 对于GSM1800情况点不同。由于频点太多，不用位图，而用别的编码方式，FORMAD-IND=？来描述编码方式，后面跟一串编码比特来表示。 第二、RACH控制参数，描述的两个数据为；ACC、EC，ACC称为接入控制等级，分为0-9与11-15，0-9表示普通级，所有移动台被定义为0-9，11-15为优先级，10表示EC，如果此位取0，表示所有移动台允许进行紧急呼叫，取1时，只有11-15优先级的移动台可以进行紧急呼叫。
1覆盖类 1.1 概述 覆盖类问题只要涉及弱覆盖、越区覆盖、过覆盖、无主导小区、上下行不平衡及导频污染等。 在TD-LTE中一般认为RSRP<-110dBm，认为是弱覆盖。 越区覆盖：由于基站天线挂高过高或下倾角过小引起的该小区覆盖距离过远，从而越区覆盖到其他站点覆盖的区域，并且在该区域终端接收到的信号电平较好。 过覆盖：指网络中存在过度的覆盖重叠，容易引起干扰和乒乓切换； 无主导小区：指某一片区域内服务小区和邻区的接收电平相差不大，不同小区之间的下行信号在小区重选门限附近的区域，并且无主导覆盖的区域接收电平一般或者较差，在这种情况下由于网络频率复用的原因，导致服务小区的SINR不稳定，可能发生空闲态主导小区频繁重选、连接态频繁切换，无主导覆盖也可认为是弱覆盖的一种。 导频污染：指在某一点存在过多（一般认为大于等于3个）的强导频，但却没有一个足够强的主导频； 1.2弱覆盖 1.2.1弱覆盖分析 造成弱覆盖的原因有： 1、规划的站点由于种种原因如物业等没有开起来； 2、天线方位角、下倾角不合理，如下倾角过低； 3、在站建起来后，由于新建楼宇的遮挡，导致部分区域RSRP很差； 4、站点过高，如四十多米或更高，会造成塔下黑 5、下倾角、方位角由于条件所限，无法调整，如：美化邓杆站点不方便调整天线的方位角（3个天线方位要一起转，因为外面有罩子盖住下倾角无法调整，如科技园四、海德三路等；深大校园里站点天线都是放在美化罩子（长方体的箱子）里面，对天线的下倾角和方位角调整范围也有影响（如：深大、深大南校等））。 针对以上原因建议的方案有：
1、推动客户将规划站点尽快开起来； 2、调整天线方位角、下倾角到合理位置； 1.2.2天线方位角不合理导致弱覆盖 现象：科技园三的102和104小区由于天线被住宅楼遮挡,导致覆盖区域内部分道路信号较弱,存在弱覆盖，科技园三站点周围的地物如图： 图表 1科技园三周围地物 调整前道路的电平值如下图： 图表 2优化前科技园三覆盖 措施：将104小区的方位角由20度调整为40度；将102的方位角由150度调整到100度；调整后弱覆盖得到改善,如下图：
LTE核心网常见投诉案例分析 案例一：临时方案用户预换卡不能使用2、3G业务 【故障现象】 临时方案的用户，在更换USIM卡但未开通4G业务的情况下，在4G网络的覆盖下，用4G手机终端可能无法正常使用2,3G业务。只能在4G手机上设置“2,3G only”，才能恢复正常使用。 【故障分析】 临时方案的用户，在更换USIM卡但未开通4G业务的情况下，当前BOSS系统只是将用户的IMSI鉴权信息通过BOSS指令存储到HSS，并未建立IMSI和MSISDN的关联，即未放号为签约用户的任何2、3G的分组域、电路域和4G 业务的签约信息。这种场景下HSS给MME返回 DIAMETER_ERROR_USER_UNKNOWN的错误码，MME收到HSS的DIAMETER_ERROR_USER_UNKNOWN码后，给终端返回#8 “EPS services and non-EPS services not allowed”的NAS原因值。终端收到“EPS services and non-EPS services not allowed”的NAS值后，不再尝试重新选网。【故障解决】 针对这种临时方案的用户，如果只更换USIM卡不签约4G业务，根据测试，MME给终端返回#7 “EPS services not allowed”的NAS值能够使终端较快地重选到2、3G网络。根据协议中定义的映射规则，HSS需要给MME返回DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) with Error Diagnostic of NO_GPRS_DATA_SUBSCRIBED的错误原因值，对应到HSS上，
CELL SETUP REQUEST value NBAP-PDU ::= initiatingMessage : { procedureID { procedureCode 5, ddMode tdd }, criticality reject, messageDiscriminator common, transactionID longTransActionId : 1, value CellSetupRequestTDD : { protocolIEs { { id 124, criticality reject, value Local-Cell-ID : 0 }, { id 25, criticality reject, value C-ID : 14021 }, { id 43, criticality reject, value ConfigurationGenerationID : 1 }, { id 280, criticality reject, value UARFCN : 10080 }, { id 23, criticality reject, value CellParameterID : 110 }, {
id 131, criticality reject, value MaximumTransmissionPower : 330 }, { id 279, criticality reject, value TransmissionDiversityApplied : FALSE }, { id 274, criticality reject, value SyncCase : 1 }, { id 394, criticality reject, value Synchronisation-Configuration-Cell-SetupRqst : { n-INSYNC-IND 1, n-OUTSYNC-IND 20, t-RLFAILURE 50 } }, { id 359, criticality reject, value ConstantValue : 0 }, { id 384, criticality reject, value ConstantValue : 0 }, { id 381, criticality reject, value ConstantValue : 0 }, { id 287, criticality reject, value TimingAdvanceApplied : no }
1.1 在eNodeB下进行实时性能监控和测试 在“信令跟踪管理”界面下，还可以进行eNodeB传输性能、小区性能、用户性能和RRU性能的监控和测试。 图 1 eNodeB性能监控和测试功能 1.1.1监控小区性能 小区性能监控功能主要监控项有业务满意率监控、总吞吐量监控、业务数/用户数监控、RB使用情况监控、RSSI统计监控、ICIC监控、虚拟MIMO监控、干扰检测监控等，DBR统计和被调度用户统计。 小区性能监控任务登记，需要设置被监控小区的Local Cell ID，可以设置监控周期和文件保存的路径，文件保存的格式有“csv”和“mmf”两种。 图 2 小区性能监控
常用小区性能监控项有总吞吐量监控、用户数监控、RB使用情况监控和RSSI统计监控。 1.1.2监控扇区性能 扇区监控主要监控上行宽频扫描功能 图 1 扇区监控性能 1.1.3传输监控性能 传输性能监控主要包括IP链路监控、IP PATH性能监控、IP性能监控、SCTP性能监控、UDP 灌包测试监控、本地流过路流监控和资源组监控。 图 2 传输监控性能 1.1.4用户监控性能 用户性能测试功能主要监控项有下行RSRP/RSRQ监控、误码率监控、Power Headroom监控、信道质量监控、调度监控、RLC业务量监控、吞吐量监控、AQM监控、上行功控监控、下行功
控监控、上行ICIC监控和按MCS阶数统计监控。 图 3 用户性能测试 用户性能测试功能任务登记，需要选择被测量的基站（站点数目最多可以选择30个），设置跟踪用户的信息，监控周期和文件保存的路径，文件保存的格式有“csv”和“mmf”两种。 1.1.5R RU监控性能 该任务用于监测RRU输出功率和温度的性能状况，每个RRU最多能启动的监测任务为：●一个输出功率监测任务（注：SPC310之前的版本该项监控不准） ●一个温度监测任务 图 4 RRU监控性能
LTE典型案例分析
覆盖类 1.1 概述 覆盖类问题只要涉及弱覆盖、越区覆盖、过覆盖、无主导小区、上下行不平衡及导频污染等。 在TD-LTE中一般认为RSRP<-110dBm，认为是弱覆盖。 越区覆盖：由于基站天线挂高过高或下倾角过小引起的该小区覆盖距离过远，从而越区覆盖到其他站点覆盖的区域，并且在该区域终端接收到的信号电平较好。 过覆盖：指网络中存在过度的覆盖重叠，容易引起干扰和乒乓切换； 无主导小区：指某一片区域内服务小区和邻区的接收电平相差不大，不同小区之间的下行信号在小区重选门限附近的区域，并且无主导覆盖的区域接收电平一般或者较差，在这种情况下由于网络频率复用的原因，导致服务小区的SINR不稳定，可能发生空闲态主导小区频繁重选、连接态频繁切换，无主导覆盖也可认为是若覆盖的一种。 导频污染：指在某一点存在过多（一般认为大于等于3个）的强导频，但却没有一个足够强的主导频； 1.2弱覆盖 1.2.1弱覆盖分析 造成弱覆盖的原因有： 1、规划的站点由于种种原因如物业等没有开起来； 2、天线方位角、下倾角不合理，如下倾角过低； 3、在站建起来后，由于新建楼宇的遮挡，导致部分区域RSRP很差； 4、站点过高，如四十多米或更高，会造成塔下黑 5、下倾角、方位角由于条件所限，无法调整，如：美化邓杆站点不方便调整天线的方位角（3个天线方位要一起转，因为外面有罩子盖住下倾角无法调整，如科技园四、海德三路等；深大校园里站点天线都是放在美化罩子（长方体的箱子）里面，对天线的下倾角和方位角调整范围也有影响（如：深大、深大南校等））。 针对以上原因建议的方案有： 1、推动客户将规划站点尽快开起来；
LTE信令流程
目录 第一章协议层与概念 (5) 1.1控制面与用户面 (5) 1.2接口与协议 (5) 1.2.1NAS协议（非接入层协议） (7) 1.2.2RRC层（无线资源控制层） (7) 1.2.3PDCP层（分组数据汇聚协议层） (8) 1.2.4RLC层（无线链路控制层） (8) 1.2.5MAC层（媒体接入层） (9) 1.2.6PHY层（物理层） (10) 1.3空闲态和连接态 (12) 1.4网络标识 (13) 1.5承载概念 (14) 第二章主要信令流程 (16) 2.1 开机附着流程 (16) 2.2随机接入流程 (19) 2.3 UE发起的service request流程 (23) 2.4寻呼流程 (26) 2.5切换流程 (27) 2.5.1 切换的含义及目的 (27) 2.5.2 切换发生的过程 (28) 2.5.3 站内切换 (28) 2.5.4 X2切换流程 (30) 2.5.5 S1切换流程 (32) 2.5.6 异系统切换简介 (34) 2.6 CSFB流程 (35) 2.6.1 CSFB主叫流程 (36) 2.6.2 CSFB被叫流程 (37) 2.6.3 紧急呼叫流程 (39) 2.7 TAU流程 (40) 2.7.1 空闲态不设置“ACTIVE”的TAU流程 (41)
2.7.2 空闲态设置“ACTIVE”的TAU流程 (43) 2.7.3 连接态TAU流程 (45) 2.8专用承载流程 (46) 2.8.1 专用承载建立流程 (46) 2.8.2 专用承载修改流程 (48) 2.8.3 专用承载释放流程 (50) 2.9去附着流程 (52) 2.9.1 关机去附着流程 (52) 2.9.1 非关机去附着流程 (53) 2.10 小区搜索、选择和重选 (55) 2.10.1 小区搜索流程 (55) 2.10.1 小区选择流程 (56) 2.10.3 小区重选流程 (57) 第三章异常信令流程 (60) 3.1 附着异常流程 (61) 3.1.1 RRC连接失败 (61) 3.1.2 核心网拒绝 (62) 3.1.3 eNB未等到Initial context setup request消息 (63) 3.1.4 RRC重配消息丢失或eNB内部配置UE的安全参数失败 (64) 3.2 ServiceRequest异常流程 (65) 3.2.1 核心网拒绝 (65) 3.2.2 eNB建立承载失败 (66) 3.3 承载异常流程 (68) 3.3.1核心网拒绝 (68) 3.3.2 eNB本地建立失败（核心网主动发起的建立） (68) 3.3.3 eNB未等到RRC重配完成消息，回复失败 (69) 3.3.4 UE NAS层拒绝 (70) 3.3.5上行直传NAS消息丢失 (71) 第四章系统消息解析 (72) 4.1 系统消息 (73) 4.2 系统消息解析 (74) 4.2.1 MIB （Master Information Block）解析 (74) 4.2.2 SIB1 （System Information Block Type1）解析 (75) 4.2.3 SystemInformation消息 (77) 第五章信令案例解析 (83) 5.1实测案例流程 (84)
层三信令“Disconnect”原因值解析
原因值表1 下面是具体解释： ISUP消息中rel原因值 G3.1正常类别 原因NO.1：未分配的（未确定的）号码 "unassigned (unallocaled) number" 该原因表示不能到达主叫用户所请求的终点，因为虽然号码格式有效，但该号码目前尚未分配（未确定）。 原因NO.2：无路由到达规定的转换网络（国内使用） "no route to specified transit network(nationaluse)" unallocaled(unassigned) number 该原因表示发送该原因的设备已经收到一个通过特定未被识别的转接网络迂回呼叫的请求。发送该原因的设备不能识别该转接网络是因为该转接网络不存在或当它存在时并没有未该设备提供服务。 是否支持该原因由网络决定。 原因NO.3无路由到达终点 "no route to destination" 该原因表示不能到达被叫用户，因为呼叫所经过的网络不为所希望的终点提供服务。 是否支持该原因由网络决定。 原因NO.4发送特殊的信息音 "send special information tone" 该原因表示不能达到被叫用户的原因在于应向主叫用户返回特殊信息音。 原因NO.5转接前缀拨号错误（国内使用）
"misdialled trunk prefix(national use)" 该原因表示被叫方号码的转接前缀错误内含。 原因NO.6：不可接受的通路 "chnnel unacceptable" 该原因表示发送实体在呼叫中不接受使用最新标识的通路。 原因NO.7：呼叫已给出并正在已建立的通路上递交 "call awarded and being delivered in an established channel" 该原因表示已给予用户来呼叫，并表示这一来呼叫在已建立的通路上与类似的呼叫一起正在被连接到该用户。 原因NO.8：先占 "preemption" 该原因表示呼叫正在被预先占有。 原因NO.9：先占电路留作重新使用 "preemption-circuit reserved for reuse" 该原因表示呼叫正在被预先占有，电路留作先点交换的重新使用。 原因NO.16：正常的呼叫清除 "normal call clearing" 该原因表示呼叫正在被清除，这是因为呼叫所涉及的用户之一已经请求清除呼叫。 在正常情况下，网络不发送这一原因。 原因NO.17：用户忙 "user busy" 当被叫用户指示不能接受另一个呼叫时使用这一原因。 原因NO.18：无用户响应 "no user responding" 当被叫用户在规定的时间周期内不用提醒或连接指示响应呼叫建立消息时使用这一原因。原因NO.19：无用户应答（用户已提醒） "no answer from user(user alerted)" 当用户在规定的时间周期内提供提醒指示但未提供连接指示时使用这一原因。 注－该原因不一定由Q.931程序产生，而可能由内部网络定时器产生。 原因NO.20：用户缺席 "subscriber absent" 该原因用作移动应用，本规范暂不使用。 原因NO.21：呼叫拒绝 "call rejected" 该原因表示发送这一原因的设备不希望接收呼叫，虽然它可以接受呼叫，因为发送该原因的设备既不忙，也兼容。 该原因可以由网络产生，表示由于补充业务的限制而清除了呼叫。诊断字段可能包含有关补充业务的附加信息和拒绝原因。 原因NO.22：号码变更 "number changed" 当主叫用户所指示的被叫用户号码不再被分配时，该原因被返回到主叫用户。新的被叫用户号码可以作为任选项目包含在诊断字段中。如果网络不支持这种能力，将使用原因NO.1未分配的（未确定）的号码。 原因NO.26：清除未选择的用户
广播电视大学RRC重建分析 一、概述 省公司TOP小区派单中，无锡广播电视大学RRC重建较高，重建比例达到8.3%。经过KPI指标分析、信令跟踪已经研发支撑，确认问题原为：终端在FDD下测量TDD虚高，导致切换过去之后TDD的信道条件差，又重建回FDD小区。该问题跟因未知，但可以通过DRX参数缓解，修改参数后，切换失败导致的RRC重建现象明显减少。 二、指标详情 省公司通报的TOP小区中，无锡广播电视大学RRC重建较高，重建比例达到8.3%： 网管中提取指标，广播电视大学的RRC重建问题主要由TOP小区：“崇安_广瑞路广播电视大学7号宿舍楼一楼_室分_53”引起，触发RRC重建原因主要为切换失败导致，具体指标如下：
三、问题分析 切换失败分析： 通过查询两两小区间切换指标，TOP小区切换失败主要原因为：切往诺基亚TDD 站点“286683”站点，切换后系统判定“切换过早”，然后发起RRC重建回源小区 查询诺基亚“286683”站点为WXL4NTB崇安_现代环保
诺基亚TDD站点位置如下图：与TOP小区距离仅200米 切换参数核查： 异频切换失败时，需核查小区异频切换参数是否合理，查询小区切换门限设置，A2门限为-95dbm，A4门限为-93dbm，切换参数设置正常。
信令跟踪分析： 通过信令跟踪发现，UE占用的主服务小区RSRP达到-95dbm以下，启动异频测量。此时测量到TDD邻小区RSRP为-75dbm，为最优小区，因此发起TDD的小区切换，但切换后通过重建返回源小区。 进过研发人员协助分析，该现象主要原因是终端在FDD下测量TDD虚高，导致
Layer 3信令分析及流程详解汇编Layer 3信令是看网络运行情况的信息层，从第三层可以看到网络的各种动作：如：呼叫流程、拥塞、用户忙、位置更新等，并且可以对路测中的各种问题如掉话、切换失败等网络事件的原因进行准确的分析。 系统信息一般有8个类型，分别是1、2、3、4、5、6、7、8，Type 1～4只出现在待机状态下，Type 5～6只出现在通话状态下，明白这点，对以后的分析至关重要。其中2中含有：2、2bis、2ter， 5中含有5、5bis、5ter，所以总共有12种系统信息，系统信息1仅用于跳频，所以称为选择项。其中1、2、3、4、 2bis、 2ter 、7、8都在BCCH上发送，由IDLE模式下的移动台接收。5、5bis、5ter、6在SACCH上发送，由ACTIVE模式下的移动台接收。一般来说所有系统信息在连续的8个51复帧中发送完，如下图示： 上图中的TC表示复帧序列号，可以看出，当TC=4、5时，发送的内容是可选的，其它是固定的。 TC=0固定发送跳频信息，当出现上图示的1（3）时，表示跳频时发类型1，不跳频时发类型3 当类型4中发送的关于小区重选信息不够完整时，由类型7、8补充。且在TC=7、3时发送（上图示） 对于类型5、6在下行的SACCH上发送，并没有复帧规范，除非切换完成后要立即发送类型5、6。 1、System Information Type1
说明：系统信息类型 1 （频率信息） 此类型仅用于跳频时，发送内容为： 第一、小区信道描述。用于通知移动，小区采用的频带与可以供跳频用的频点。对于GSM900与GSM1800采用的格式是不同的。对于GSM900： 有一个BIT MAP 0（比特位图）用于描述两方面信息，分别为： CA-NO，取值分别为：0、1、2，代表，GSM900、GSM1800、GSM1900。 CA-ARFCN，采用的有效射频频点，当为GSM900，将有一个相应于124个频点的124位图，当某个频点被采用时，相应的比特位被置为1，否则将被置为0. 对于GSM1800情况点不同。由于频点太多，不用位图，而用别的编码方式，FORMAD-IND=？来描述编码方式，后面跟一串编码比特来表示。 第二、RACH控制参数，描述的两个数据为；ACC、EC，ACC称为接入控制等级，分为0-9与 11-15，0-9表示普通级，所有移动台被定义为0-9，11-15为优先级，10表示EC，如果此位取0，表示所有移动台允许进行紧急呼叫，取1时，只有11-15优先级的移动台可以进行紧急呼叫。 CB——小区禁止标志，用一个比特表示。