ICDT08B5

ABB  ICDT08B5 GJR5251600R0101

 

　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协议中对消息中包含的参数做了规定[5]，如表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分析表a 

 

 

 

　　根据获取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的格式[5]如表6所示。