［谷小勇 方一鸣 李培林］

基于TTCN-3的LTE非承载网络注册失败的分析与对策*

［谷小勇 方一鸣 李培林］

为了更好地满足端到端的QoS机制，以及对TD_LTE系统级测试仪表的开发，需要对附着注册过程中的异常机制进行研究和改进，在详细分析网络承载原因的基础之上，给出了一种新的对于非承载网络注册失败原因的研究，首先分许出有关的异常机制并对其中几种典型的异常机制进行流程设计，然后搭建TTCN-3软件平台，通过系统级测试平台验证，同时获取终端LOG图，对终端和网络端交互LOG信息进行打印，对流程设计进行验证。

TD-LTE 默认承载 非承载网络失败 TTCN-3

谷小勇

重庆邮电大学，硕士研究生，主要研究方向：TD-LTE系统协议栈开发。

方一鸣

重庆邮电大学，硕士研究生，主要研究方向：TD-LTE系统协议栈开发。

李培林

重庆邮电大学，硕士研究生，主要研究方向：TD-LTE系统协议栈开发。

引言

随着4G技术的普及和应用，分时长期演进TD-LTE以其技术上的优势正在推动着整个通信业的发展，针对其新技术的各种应用，测试环节显得尤为重要。长期演进系统中，UE实现端到端附着到网络建立PDN连接是必不可少的一个环节［1］，因为其关系整个LTE系统是否可以正常地实现各种所需业务。

在当前附着注册失败的测试环节中，一般都是针对于承载网络等异常机制［3］的测试，网络仅仅反馈给用户UE承载网络失败的原因，如网络端失败，UE端失败等，这使得对于异常机制的研究不够全面，仅仅是对一个异常方向的研究测试。本文将对非承载网络失败的原因，如业务原因，进行研究处理，设计基于测试和测试控制表示法（Testing and Test Control Notation Version 3，TTCN-3）的平台［2］，根据非承载网络失败后的处理流程设计编写测试用例［4］，按照测试流程进行非承载网络注册失败的测试。

1 LTE系统EPS总体架构

图1 EPS网络架构

演进分组系统EPS由LTE和SAE两部分组成。LTE部分包括了用户UE和eNB，SAE包括了包含了移动管理实体MME，服务网关Serving Gateway，分组数据网关PDN Gateway，以及策略与计费规则功能单元PCRF和归属用户服务器HSS等部分，各模块分别负责自己的相关功能，最终实现端到端的“永久在线”。

2 开机注册过程中默认EPS承载的分析

2.1 默认承载成功建立的过程设计

为了UE和要求的PDN之间建立一个默认的EPS承载［5］上下文，使UE获得对应PDN的IP连接。在UE第一次接入网络时，PDN连接流程需要联合EMM的附着流程。PDN连接请求消息和附着请求消息一起封装为NAS消息发送至网络端。如果网络端同意UE接入网络，则发起默认EPS承载文本激活流程。PDN连接流程具体如下：

① UE向MME发 送 PDN CONNECTIVITY REQUEST消息。

② MME收到PDN CONNECTIVITY REQUEST消息后，为UE分配该PDN连接的默认承载EBI，选择S-GW并向该S-GW发送CREATE SESSION REQUEST消息。

③ S-GW收到CREATE SESSION REQUEST消息后，在自己的EPS承载表中创建新实例，并向P-GW发送CREATE SESSION REQUEST消息。

④ P-GW收到CREATE SESSION REQUEST消息后，发起IP-CAN Session Establishment过程，与PCRF交互后确定默认承载的QoS参数并为该UE分配IP地址，然后在自己的EPS承载表中创建新实例并向S-GW发送CREATE SESSION RESPONSE消息。

⑤ S-GW收到CREATE SESSION RESPONSE消息后，向MME发送CREATE SESSION RESPONSE消息。

⑥ MME收到CREATE SESSION RESPONSE消息后，如果该PDN连接被P-GW接受，则向UE发送ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST消息，由eNodeB转发。

⑦ UE收到ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST消息后，保存EPS QoS和PDN address等信息，并向MME发送ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT消息，由eNodeB转发。

⑧ MME收到ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT消息标志着该PDN连接建立完成，意味着UE与P-GW之间已经激活了一个默认EPS承载文本。

图2 默认承载连接建立流程图

2.2 非承载网络注册失败的议程机制分析

然而上文分析的正常建立情况并不总能够顺利完成，异常机制是时常发生的。下面主要研究非承载网络注册失败的异常情况：

（1）当UE开始附着注册时，UE发送附着请求给eNB，eNB将附着请求消息给MME［6］；该过程对应于流程图中的①，②。

（2）MME，PGW，SGW，eNB，UE等在附着过程中进行交互，如果MME与PCRF交互后PCRF拒绝，则拒绝消息中携带的字段表示的原因为用户使用权限受限；该过程对应于流程图中的④，但是此时返回消息IP-CAN Session Establishment中包含的是失败原因#29：user authentication failed。

（3）如果PGW或者SGW在计费过程中，则拒绝消息中携带的字段表示失败的原因是运营商确定的禁止；该过程对应于流程图中的④，此时返回消息CREATE SESSION RESPONSE包含的是失败原因#8：operator determined barring。

（4）如果MME与传统的电路交换CS域交互后CS域拒绝，则拒绝消息中携带的字段表示的原因为用户业务使用权限受限。该过程对应于流程图中的④，此时返回消息CREATE SESSION RESPONSE包含失败原因#32：service option not supported；。

（5）在其他的实例中，如果MME与PCRF交互后PCRF拒绝，则拒绝消息中携带的字段表示失败的原因是PCRF返回的具体原因；如果MME与传统的电路交换CS域交互后CS域拒绝，则拒绝消息中携带的字段表示的原因为CS域返回的具体失败原因。

（6）表示失败原因的具体字段可以是现有字段，如协议配置选项PCO，也可以采用新增字段。

（7）MME通过eNB向UE发送携带了表示失败原因的字段的拒绝消息，然后UE端会把返回的失败原因告知给用户，这样手机用户就会根据返回的具体原因做出正确的决策，例如，假如非承载网络失败原因注册失败是由于用户的使用权限受到了限制，则使用用户可以根据自己的需求决定开通想用的业务，假如非承载网络失败原因注册失败是由于运营商确定的禁止，则用户考虑是否为用户欠费以决定续交费。

3 测试流程设计

测试流程步骤如下：

步骤1：当网络端MME收到PDN CONNECTIVITY REQUEST消息后。判定用户业务是否受限，当用户业务受限的情况下，直接返回携带非承载网络失败原因的拒绝消息给UE端的ESM层，由EMS进行原因值分析后，通过原语将失败原因传到SPV应用层，是的用户获知具体失败的原因，然后做相应的处理。

步骤2： 当网络端P-GW收到CREATE SESSION RESPONSE消息后。判定是否为运营商确定的禁止，当当前禁止的情况下，返回拒绝消息的操作通步骤1。

步骤3：当网络端MME与PCRF交互后PCRF拒绝后。判定是否为用户使用权限受限，当用户使用权限受限的情况下，返回拒绝消息的操作通步骤1，如图3所示。

4 TTCN-3仿真测试对比结果与对比分析

4.1UE开机附着过程EPS成功建立的仿真结果图：

图4为TTCN-3系统级测试平台的默认的EPS承载成功建立完成，此情况下网络端各个模块成功进行交互，没有发生任何非承载网络注册失败的异常，图5为终端由于在与网络端进行交互的过程中各个状态的变化情况，从图中可以看出终端UE成功接收到网络端EPS承载建立接受的消息，最终终端UE实现附着完成。

图6为网络端回复给UE的原语中携带的协议配置选项的内容，该内容包含在图中的ACT_DEF_EPS_ BEARER_CTX_REQ当中，由EMM层发送给ESM层，在注册过成功的测试中，不进行非承载网络注册失败原因的协议选项配置，仅仅包含网络端需要的发送给终端UE的一些所需信息。

4.2UE开机附着过程由于非承载网络原因失败的仿真结果图

图7为TTCN-3系统级测试平台中由于非承载网络原因默认的EPS承载建立失败的情况，此情况下由于网络端人为设置了非承载网络异常的设置，最终终端UE没有成功注册，没有建立EPS承载，图8为网络端人为设置了非承载网络异常的情况下，终端与网络端交互中各个状态的变化的情况，从图8可以看出终端UE收到了非承载网络失败的原因值，并且在SPV应用层成功显示了具体的原因，成功告知了用户非承载网络失败的具体原因。

图9为网络端回复给UE的原语中携带的协议配置选项的内容，在注册过失败的测试中，网络端进行了非承载网络注册失败原因的的协议选项配置，图中具体为EMM CASE ＜#8 failure＞，即非承载网络失败的原因为前文提到的运营商确定的禁止，测试中，终端UE成功接收到该配置选项并成功由会ESM层解析后发送给了SPV应用层，终端用户成功获得具体的非承载网络失败原因。

图3 测试流程设计图

图4 注册成功TTCN-3测试图

图5 注册成功UE终端消息收发logo图

图6 UE终端协议配置选项图

图7 注册失败TTCN-3测试图

图8 注册失败UE终端消息收发logo图

图9 UE终端协议配置选项图

5 结论

本文提出了一种TD-LTE系统中非承载网络注册失败的改进处理方法，通过携带表示非承载网络失败的原因给应用层用户，解决了在附着注册过程中，用户无法及时准确分辨出是承载网络原因还是非承载网络失败的原因，用TTC-3为测试平台对该过程进行测试和验证，测试结果表明，非承载网络原因注册失败的改进处理完全符合预期结果。

1 3GPP.3GPP TS 24.301，Non-Access-Stratum （NAS）protocol for Evolved Packet System （EPS）［S］.2012

2 陈发堂，牛勇清，韩娜娜.协议一致性测试平台的搭建及仿真实现［J］.电子技术应用，2014，40（4）：137-140

3 李小文，李媚媚.TD-LTE系统EMM的介绍及其异常机制的研究［J］.通信热点，2013，04

4 3GPP.TS 36.508 Technical Specification Group Radio Access Network； Evolved Universal Terrestrial Radio Access（E-UTRA）and Evolved Packet Core（EPC）；Common test environments for Use Equipment（UE）conformance testing［S］.France： 3GPP Organizational Partners，2012

5 刘向玉，张红帅.TD-LTE系统ESM层默认承载建立过程的研究与实现［J］.现代电信科技，2012，（03）

6 李小文，肖垒，宋海贝.TD-LTE系统移动性管理实体测试研究［J］.光通信研究.2011（04）

7 董宏成，张宁，李小文，TTCN-3在RRC协议一致性测试中的应用 ［J］，电子技术应用，2013第39卷第7期117-120

10.3969/j.issn.1006-6403.2016.08.015

2016-07-31）

国家科技重大专项资助项目“TD-LTE TTCN 扩展测试集仪表开发（无线资源管理部分）”（No.2012ZX03001024）