TD-SCDMA网络测试仪中SCCP协议解码

发布时间:2010-9-16 10:23    发布者:techshare
关键词: SCCP , TD-SCDMA , 解码 , 网络测试仪 , 协议
随着TD-SCDMA第三代移动通信系统相关技术在中国飞速发展,基于该标准的网络及终端设备已经研制成功,并已能满足商用要求。现阶段,TD-SCDMA测试设备是最薄弱的环节,一方面,这直接影响到TD-SCDMA产业链的完整性;另一方面,也影响到电信运营商对网络设备的部署与检测,基于这样的现实,具有自主知识产权的TD-SCDMA网络测试仪的研制具有重要意义。  

TD-SCDMA网络测试仪中的信令分析,针对的是无线接入网(UTRAN)和核心网(CN)的协议栈,其中包含一系列的传输层和无线层协议。仪表协议分析的基础是要能够实现对所接收到的网络数据进行译码解析,在此功能准确无误的基础上,仪表才可以进行更高级的统计追踪功能。在进行协议分析时,鉴于协议之间消息格式和处理机制的不同,以及软件模块化的实现要求,采取以单个协议进行模块封装的办法是更有效的,其好处在于能够忽略协议间功能和格式的细微差别,对单个协议的分析方法也能在很大程度上推广到其他协议。以UT-RAN内部的协议栈为例,从下至上分为信令适配层、传输层和无线网络层,其中信令适配层和传输层的协议在标准中都有明确的消息结构,而无线网络层的协议是采用ASN1(abstract syntax notation)语法进行描述,导致消息封装的方法有所不同,进而带来解码方式上的差异。  

我们在本文中研究的主要内容是TD-SCDMA的CN以及UTRAN协议栈中信令连接控制部分协议(signalling connection control part,SCCP)消息的分析,一方面描述如何根据协议标准中规定的协议消息结构进行解码;另一方面结合实际情况探讨SCCP协议上层PDU的获取方法。  

1、SCCP协议消息概述  

SCCP协议是7号信令用户部分的一种补充功能级,SCCP协议位于消息传输部分协议(message transfer part,MTP)之上,为MTP提供附加功能。  

在TD-SCDMA的CN以及UTRAN的协议栈中,都包含有SCCP协议,该协议位于协议栈的无线网络控制平面中,如图1所示。  



图1 Iu接口无线网络控制平面的协议栈

SCCP协议处于无线协议无线接入网络应用部分(radio access network application part,RANAP)以下,ATM适配层协议以上,位于传输层,对于网络的数据传输起着相当重要的作用。  

ITU-T在不改变原有MTP功能的基础上,增加了SCCP,目的就是在信令网中建立逻辑信令连接,以传送与电路无关的消息。因为随着通信网和通信新业务的不断发展,越来越多的业务需要和远端网络节点直接传送控制消息,这些消息和呼叫连接的电路无关,甚至根本与呼叫无关,如现在通信网中开放的智能网业务、移动电话的漫游业务、数据库以及网络的运行、管理和维护等,而这些业务仅仅用MTP已无法满足要求。  

SCCP能提供4类业务,2类无连接业务,2类面向连接业务。无连接业务类似于分组交换网中的数据报业务;面向连接业务类似于分组交换网中的虚电路业务。  

无连接业务不需要预先建立连接就可以在信令网中传送信令消息。无连接业务又分为基本无连接业务和有序的无连接业务,也称为0类业务和1类业务。0类业务不保证消息的顺序传输,各个消息被独立地进行传送,相互不发生关系,因而在这种情况下,不能保证按照发送的顺序把消息送到目的地信令点;1类业务给来自同一消息流的数据信息附上了同一信令链路选择SLS,即经由同一信令链路传送,因此可以保证按照发送的顺序把消息送到目的地信令点。  

面向连接业务在传送消息之前,需要在源点和目的点之间建立一条消息传送路径,即逻辑连接。这种方式适合传送大批量的数据。面向连接业务又分为基本面向连接业务和带流量控制的面向连接业务,即2类业务和3类业务。它们共同的特点是保证消息发送和接收的顺序一致。此外,3类业务具有流量控制功能、消息丢失及错序的检测功能等。在2类业务中,由于各个数据信息没有顺序号,因此不能完成顺序控制和流量控制。  

SCCP是在不改变原有MTP功能的基础上增加的,它对MTP的改进主要有以下功能:①能够传送各种与电路无关的信令消息;既支持无连接业务,又支持面向连接业务;②具有增强的寻址功能,扩大了业务范围;③具有地址翻译功能,可以在全球互连的不同7号信令网之间实现信令的直接传输;④具有管理功能,可以管理SCCP子系统状态。   

根据ITU-T Q.713,SCCP主要的消息类型如表1所示。



表1 SCCP消息类型

一条完整SCCP消息包含以下4部分,消息类型、必选固定部分、必选可变长部分以及可选部分,结构如图2所示。  



图2 SCCP消息整体结构

Message type字段的长度为1个字节,位于SCCP消息的开始,任何对SCCP消息的分析都要以判断消息类型作为第一步。  

SCCP协议是7号信令中的重要协议,处于无线接入网的Iu接口以及核心网接口中。网络接口的协议之间是以协议栈的方式进行组合的,而信令数据也是按照协议栈的分层关系进行封装的,由于SCCP层处于协议栈的中间,它上层协议的数据将作为SCCP的净荷数据封装在SCCP消息中,而SCCP消息整体又作为其下层协议消息的净荷封装进整条二进制数据。在实际的解码过程中,正是要按照协议栈由底向上的顺序对数据进行分析。以Iu接口为例,无线网络层RANAP协议处于SCCP层以上,因此,RANAP消息被装入SCCP的DATA数据中,SCCP消息则作为MTP3B协议消息的净菏继续被下层协议封装。基于这种不同协议间数据的封装关系,以解码为基础的信令分析还有另外一个需求,即定位和提取上层协议的数据。协议分析进行模块划分决定了解码是每个协议自身完成的任务,而数据总是由下层提供,也就是说每个协议层应该有2个基本的功能,一个是解码,另一个就是定位和提取上层数据。  

2、SCCP协议消息的解码分析  

SCCP协议消息的详细结构如图3所示。  



图3 SCCP消息详细结构

图3中,给出了SCCP协议消息的详细消息结构,从图3中可以看出每条消息是由4部分构成:消息类型+必选固定部分+必选可变部分+可选部分。下面对这4部分规则分别进行解释。  

●Message type code:消息类型字段只有一个字节,该字段是所有SCCP消息必须包含,SCCP协议的消息类型已经在前面的表格中有了说明。  

●Mandatory fixed part:必选固定部分参数是指那些在消息中必须存在的并且位置、参数长度以及出现顺序都由消息类型确定好的参数。因为这些参数的出现位置和长度都是固定的,因此在消息中并不需要额外的字段用来表示它们的类型和长度,只需在相应的位置提供参数内容即可。  

●Mandatory variable part:必选可变部分参数是指那些在消息中必须存在的但是参数长度可变的参数,每个必选可变部分参数都有一个指针指向该参数内容开始的位置,在不同的消息中,必选可变部分参数指针的顺序在消息中是固定排列好的,因此对于必选可变部分参数,也不需要提供参数类别,虽然必选可变部分参数的指针顺序是固定的,但是其内容顺序有可能与指针顺序不同,另外,因为这种参数的长度可变,所以每个参数内容中都包含1个或2个字节用来表示参数长度。  

●Optional part:可选部分参数是指那些在消息中定义了的可能出现也可能不出现的参数,整个可选部分的起始位置由必备可变部分参数的最后一个指针来指明,该指针指示的是可选部分第一个参数开始位置的指针。如果消息类型指示没有可选部分参数存在,那么这个指针将不存在,如果消息类型指示有可选部分存在,但对于一条具体消息时并不包含这些可选参数,那么该指针所在字段应该全为0。可选部分可以包含固定长度参数或者可变长度参数。另外,可选部分参数在消息中的发送顺序是不受限制的,比如一条SCCP消息3个可选部分参数,这3个参数出现的顺序和协议标准中描述的顺序可以不同,协议标准中只是说明这3个是可选的参数,并没有规定其出现的顺序。鉴于以上描述的可选部分参数的特点,任何一个可选部分参数都必须包括参数名,参数内容,如果参数长度可变,还必须包括参数长度。

●End of optional parameters octet:在可选部分参数的最后,有一个长度为1字节,内容为全0的end of parameters参数,这个参数用来表示可选部分参数的结束,该参数只有当可选部分参数在消息中存在的时候才出现。  

1)消息内容的发送顺序:在SCCP消息中,所有的参数都包含整数个字节,参数的格式都是按照字节栈的形式,在实际消息的传送过程中,先发送的是协议标准中描述的位于栈顶的低序号字节,最后发送的是位于栈底的高序号字节。  

2)长度参数的解码 规则:长度参数字段被解码为二进制值,用来表示参数内容字段的长度,长度参数字段的值不包括参数名称和参数长度占用的2个字节。

3)指针的解码规则:指针的二进制值表示了该指针的高位字节与该指针所指的参数之间相隔的字节数。  

在SCCP协议中,消息都是遵循上面描述的固定结构。对某一条具体的消息,比如CR(conneetion qequest),在Q.713协议中对消息中包含的参数做了规定,如表2所示。  



表2 SCCP CR消息参数表

SCCP消息中消息类型,必选固定部分参数和必选可变部分参数都是按照固定的顺序规定好的,而可选部分参数的情况并不固定,消息中只规定了可能包含的可选参数,但对可选参数在实际消息中是否出现以及出现的顺序并没有说明。  

在编写解码函数的程序时,由于SCCP协议最底层的解码单位是参数级别,即像Message type,Source local reference和Protocol class等参数,各自都有对应的参数解码函数,因此对于消息类型参数,必选固定部分参数,必选可变部分参数,只要按照顺序调用参数解码函数就可以完成解码,真正复杂的是对可选参数的处理,因为消息定义中的可选参数在实际消息中是否出现以及参数出现的顺序是不固定的,唯一确定的是,可以通过可选部分参数指针找到可选部分参数开始的位置,然后通过消息总长度减去固定部分长度得到可选部分长度,最后再根据可选参数部分的结构通过循环处理的方式进行解码,每次循环处理的过程是先判断可选参数的类型,然后调用相应的参数解码函数。下面用一个流程图来说明CR消息的解码过程,此过程可以推广到所有其他SCCP消息的解码,如图4所示。  



图4 SCCP协议CR消息的解码流程图

3、实际测试中的SCCP消息组装问题

网络中的SCCP消息长度一般在100个字节内,SCCP消息需要封装上层RANAP或者RNSAP的数据,而上层数据通常不会很长,一条SCCP消息完全可以容纳,但在少数情况下,上层数据需要分段由几条SCCP消息中传输,而多条SCCP消息再分散在底层的ATM信元中传送。这个现象从逻辑上是容易理解的,但从数据分析的角度,尤其是从数据接收端的角度来看,处理就要复杂很多,因为尽管数据分段的情况相对较少,但是信令分析注重消息解析的准确性和信令流程的连贯性,为了达到这2个要求,就要保证接收端能够准确完成数据的组装,在此基础上,对SCCP层的分析以及更高层如RANAP协议的分析才能够保证。  

在SCCP协议的消息中,绝大部分都包含data或longdata参数,这2个参数表示SCCP的用户数据(service data unit,SDU),也叫做SCCP上层协议的协议数据单元(protocol olata unit,PDU)。SCCP的大多数消息都包含数据参数,从而加大了获取PDU的难度,另外,消息类型的不同导致获取的方法也不同,包含Data参数的消息分类如表3所示。  



表3 包含Data参数的消息分类表

当调用SCCP协议模块的获取上层PDU函数时,首先判断消息类型,如果不在以上消息类型中,则不存在用户数据,那么仅仅完成解码即可;如果是以上消息类型中的一种,那么就需要调用相应的函数进行获取SDU的操作。由于包含用户数据的消息比较多,为了处理方便和逻辑清晰,在模块实现时为表3中的消息定义了各自的函数。  

表3中有两列内容分别是辅助参数和它们的存在性。辅助参数是指在相应消息中对于获取SDU有帮助的参数,而存在性就表示该辅助参数在相应消息中的存在可能,F和V表示一定存在,0表示可能存在。辅助参数的作用主要是用来告知消息中包含的Data是完整的还是需要分段传送的,如果完整,那么取得数据后函数就把PDU数据返回;否则要对来自多条SCCP消息的多个Data进行组装。在表3中用A,B,C,D对消息处理进行了分类,每个类型代表一种处理的复杂程度如表4所示。  



表4 获取SDU分析表

根据获取Data数据的复杂程度,把相应函数分为4类。每类函数根据处理的复杂程度,都需要辅助函数的支持,例如,类型2中对DT1和DT2的处理,这2条消息中都有参数包含more data indicator字段,其作用是指示本条数据消息后面是否有属于同一个SDU的数据,因此该参数是DT1和DT2消息获取数据的重要操作依据。对于其他类型的函数,辅助参数起着同样的作用,另外个别辅助参数本身是可选的,如类型4函数中的辅助参数segments,因此在类型4函数处理时需要判断的条件就很多,首先需要知道segments参数是否存在,存在的话才有组装的可能,不存在的话说明数据不需要组装。4类函数对参数的需要性如表5所示。



表5 获取SDU分析表b

在实际的SCCP消息中,大多都是用DT1消息来承载上层数据,获取DT1消息的函数属于表5中的第2类,下面就以该消息为例来说明SCCP协议获取上层PDU的方法,DT1的格式如表6所示。  



表6 DT1消息结构

第1个参数(Message type)表示消息类型,根据消息类型表格可知,DT1消息类型为OX0000 0110即6;第2个参数(Destination local reference)是目的地本地参考,表示目的地地址信息;第3个参数(Segmenting/reassembling)叫做分割/组装,长度是1个字节,格式如图5所示。  



图5 Segmenting/reassembling参数结构

该参数长度为一个字节,最低位是信息字段M,为0表示消息后面没有分段的数据;为1则表示有。图6表示在模拟真实的网络环境,以DT1数据的传输为例,说明所有可能的情况。  



图6 DT1数据在网络中传送的可能情况示意图

DT1消息在网络中的传送共4种可能,每种类型中右边的表示本条DT1消息,图6左边的表示上条DT1消息,两消息中都有M指示,下面分别说明。  

类型1:本条DT1数据和前面的DT1是连续的,另外本条DT1数据后面还有连续的数据,在此情况下,应该把本条DT1数据串接在前面的DT1后面,并且继续等待后面的包含同类内容的数据。  

类型2:本条DT1数据和前面的DT1是连续的,另外本条DT1数据后面没有连续的数据,在此情况下,应该把本条DT1数据串接在前面的DT1后面,构成一个完整的上层数据PDU交给上层处理。  

类型3:本条DT1数据和前面的DT1不是连续的,另外本条DT1数据后面有连续的数据,在此情况下,应该把本条DT1数据保存起来等待后面同类数据进行组装。  

类型4:本条DT1数据和前面的DT1不是连续的,另外本条DT1数据后面没有连续的数据,在此情况下,应该用本条DT1数据作为上层PDU。  

下面用流程图的形式来说明获取DT1消息上层数据的程序处理过程,如图7所示。  



图7 获取DT1消息上层PDU函数流程图

在真实的网络环境中,在使用CR消息建立完SCCP连接后,SCCP协议出现最多的就是DT1,SCCP层的主要作用是封装无线层的信令数据,而上层数据才是对分析网络以及应用最有价值的信息。基于这样的现实,分析DT1消息有重要意义,尽管在SCCP协议中还有其他消息也包含数据信息,但在实际信令中出现的情况并不多。  

5、结束语  

通过对SCCP协议解码和获取上层数据的分析,一方面为模块实现提供了设计方案,另一方面可以把SCCP协议的分析方法推广到TD-SCDMA标准协议栈中其他传输层的协议分析中。在TD-SCDMA网络分析仪的软件模块中,采用面向对象编程方法对SCCP部分进行了实现,该模块在仪表测试的过程中表现稳定,通过实践论证了设计方案的正确性。
本文地址:https://www.eechina.com/thread-27048-1-1.html     【打印本页】

本站部分文章为转载或网友发布,目的在于传递和分享信息,并不代表本网赞同其观点和对其真实性负责;文章版权归原作者及原出处所有,如涉及作品内容、版权和其它问题,我们将根据著作权人的要求,第一时间更正或删除。
您需要登录后才可以发表评论 登录 | 立即注册

厂商推荐

相关视频

关于我们  -  服务条款  -  使用指南  -  站点地图  -  友情链接  -  联系我们
电子工程网 © 版权所有   京ICP备16069177号 | 京公网安备11010502021702
快速回复 返回顶部 返回列表