CN100382551C - 一种对通信系统消息进行编解码的方法 - Google Patents

Abstract

本发明公开了一种对通信系统消息进行编解码的方法，该方法包括：将通信系统消息定义按消息元素的信息及消息元素间的存在关系，存储到消息数据库；对通信系统消息进行编码时，根据消息名称到通信系统消息数据库中查找消息中包含的消息元素的记录；再根据该消息中各个消息元素的属性及消息元素间的存在关系，在消息元素记录中查找到该消息中用户定义的所有消息元素属性对应的比特数据，组成编码结果；解码过程与之相对应。本发明利用数据的维护管理来实现对通信系统消息的编解码，对通信系统消息数据库修改灵活，能够提高编、解码的速度，非常适用于用多种消息语法结构定义直接形成消息比特流的消息描述方法，在通信系统的研发及测试中用途广泛。

Description

一种对通信系统消息进行编解码的方法

技术领域

本发明涉及一种对通信系统消息进行编解码的方法。

背景技术

通信系统中存在着大量的消息定义，这些消息的描述都是以文档的形式出现，它们是对消息进行编、解码的基础。对消息进行编码就是将消息转换为通信系统设备能够处理和发送的比特流；解码就是将消息比特流解码为人能够读懂的消息描述。通过计算机来实现对消息的编解码，把消息定义转换为计算机能够处理的格式，是省时省事的办法。目前，用计算机来实现对消息的编解码有以下两种方案：

第一种方案，由于计算机语言本身就带有强大的结构定义和流向控制功能，所以把消息定义(包括消息名称、消息对应的比特流和消息描述)在头文件中用编程语言的结构定义出来，计算机编、解码程序在应用消息定义时调用该头文件，根据消息名称从该头文件找出相应的消息比特流或消息描述，将获得的消息比特流或消息描述输出给用户。这种方案头文件和处理消息的编、解码程序必须编译在一起。

可见，第一种实现方案的缺点主要是修改复杂：每次消息结构改动，或者有新的消息被定义出来，都需要把编、解码程序的相关部分重新调试编译一次；而且测试人员只能够使用固定编译在解码程序中的结构，不能够根据实际情况，灵活地修改程序中的消息。

第二种方案，把消息定义用编程语言的结构定义出来后，作为一个独立的文本文件，不和计算机编、解码程序编译在一起，编、解码程序运行时候根据需要搜索这个文件，根据消息名称从该文件找出相应的比特流或消息描述，将获得的比特流或消息描述输出给用户。

第二种实现方案的缺点是：随着通信技术的迅速发展，需要处理的消息数量越来越大，编、解码程序需要不停地从消息描述文件中查找需要的消息结构定义。这样，反复查找文本格式的消息，查找速度会随着消息数据量的增大而变得很慢，消息结构的修改、增加，文本格式的消息描述和维护也变得越来越麻烦。

因此，现有技术的两种编、解码实现方案都不能完全适应通信系统的迅速发展。

发明内容

有鉴于此，本发明的目的在于提供一种对通信系统消息进行编解码的方法，该方法在通信系统消息发生变化时，不需要修改编、解码程序，并能够提高编、解码的速度，适应通信系统的迅速发展。

为达到上述目的，本发明的技术方案具体是这样实现的：

一种对通信系统消息进行编解码的方法，该方法包括以下步骤：

1)将通信系统消息中消息及消息元素的信息设置为通信系统消息数据库记录的消息属性字段；并按消息元素间的存在关系，设置用于控制所述数据库记录搜索的附加字段；将消息定义按消息元素的信息及消息元素间的存在关系，存储到消息元素对应的记录中，建立通信系统消息数据库；

2)对通信系统消息进行编码时，根据消息名称到通信系统消息数据库中查找消息中包含的消息元素的记录；再根据该消息中各个消息元素的属性及消息元素间的存在关系，在消息元素记录中查找到该消息中所有消息元素属性对应的比特数据，组成编码结果；

3)对通信系统消息进行解码时，从比特流中找到一条消息的起始位置，读取该消息的消息头根据消息头到通信系统消息数据库中搜索对应的消息名称，再根据该消息名称，在通信系统消息数据库中查找到消息中包含的消息元素的记录；根据该消息中各个消息元素属性的比特数据及消息元素间的存在关系，在消息元素记录中查找到该消息中所有消息元素属性比特数据对应的消息元素描述，组成解码结果。

步骤1)所述的附加字段至少可以包括：消息或消息元素名称字段、消息或消息元素类型字段、编/解码级别字段、消息元素转向字段；编/解码级别字段中填写本消息元素比特数据的编/解码顺序；消息元素转向字段中填写本消息元素比特数据编/解码后，要转向的消息或消息元素表、消息名称、或消息元素的名称；

在编/解码过程中，根据消息名称字段中记录的消息元素名称，按编/解码级别字段中记录的顺序及消息元素转向字段的消息元素名称，进行顺序编/解码和跳转编/解码。

所述步骤1)可以进一步包括：将一个消息元素的所有记录设置为一个记录组，按该消息元素比特数据的顺序记录相应的消息元素描述。

所述步骤1)可以进一步包括：设置成对的逆序标识；依照协议规定，在记录组中需要从一个字节的低比特位向高比特位方向进行编/解码的消息元素的起始记录中添加起始逆序标识，在记录组中需要从一个字节的低比特位向高比特位方向进行编/解码的消息元素的的终止记录中添加终止逆序标识；

在组成编码结果/解码结果时，对于一对逆序标识间的比特流/消息元素描述，从后向前组织结果；对于逆序标识以外的比特流/消息元素描述，从前向后组织结果。

所述步骤1)可以进一步包括：设置索引标识，根据消息元素间的存在关系，在需要转向非本消息元素的消息元素记录中，添加索引标识；

在编/解码过程中，根据该索引标识转向非本消息元素的记录，进行查找。

所述步骤1)可以进一步包括：在通信系统消息数据库中，为每个有多选一属性的消息元素，建立比特数据与相应消息元素描述的对应表；

在编/解码过程中，根据消息中该消息元素的属性值，在上述比特数据与相应消息元素描述的对应表中，查找到相应的比特数据/消息元素描述。

所述步骤1)可以进一步包括：按照协议中的消息结构定义及对消息头的规定，在通信系统消息数据库中，建立消息名称与消息头对应表；

步骤3)所述搜索对应的消息名称的方法为：根据消息头，通过查找消息名称与消息头对应表，判断消息名称。

步骤3)所述从比特流中找到一条消息的起始位置的方法可以为：从比特流中查找出比特流传输过程中，为了区分不同消息在消息前增加的消息标识；在解码过程中不对该消息标识进行解码。

另外，该方法进一步包括：将组成的编码结果/解码结果，写成文本文件保存在计算机中。还可以将组成的编码结果/解码结果，通过计算机显示给用户。

由本发明的技术方案可见，本发明的这种对通信系统消息进行编解码的方法，采用了把消息描述和处理程序分开的办法，为消息定义建立数据库，利用数据库对数据的维护管理来实现对通信系统消息的编解码，使对通信系统消息修改灵活，并能提高编、解码的速度，非常适用于用多种消息语法结构定义直接形成消息比特流的消息描述方法如全球移动通信系统(GlobalSystem for Mobile Communications，GSM)，或物理层采用TD-SCDMA协议、高层采用GSM协议的TSM移动通信系统(TD-SCDMA over GSM，TSM)等描述的通信消息，以及其它类似的自定义通信消息的编解码工具开发，在通信系统的研发及测试中用途广泛。

附图说明

图1为利用本发明的附加字段控制通信系统消息数据库记录搜索的示意图；

图2为本发明对比特流进行解码的流程示意图；

图3为一段协议内容结构示意图；

图4为本发明对协议进行编码的流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明进一步详细说明。

本发明的这种对通信系统消息进行编解码的方法，将通信系统消息保存到数据库，利用数据库对数据的维护管理来实现对通信系统消息的编解码。

首先，将通信系统消息中消息元素的信息设置为数据库记录的消息属性字段；并按消息元素间的存在关系，设置用于控制数据库记录搜索的附加字段；将消息定义按消息元素的信息及消息元素间的存在关系，存储到消息元素对应的记录中，建立通信系统消息数据库。

然后，对通信系统消息进行编码时，根据消息名称到通信系统消息数据库中查找消息中包含的消息元素的记录；再根据该消息中各个消息元素的属性及消息元素间的存在关系，在消息元素记录中查找到该消息中所有消息元素属性对应的比特数据，组成编码结果。

对通信系统消息进行解码时，从比特流中找到一条消息的起始位置，读取该消息的消息头，根据消息头到通信系统消息数据库中判断搜索对应的消息名称，再根据该消息名称，在通信系统消息数据库中查找到消息中包含的消息元素的记录；根据该消息中各个消息元素属性的比特数据及消息元素间的存在关系，在消息元素记录中查找到该消息中所有消息元素属性比特数据对应的消息元素描述，组成解码结果。

以下先对一个较佳实施例的建立通信系统消息数据库过程进行具体说明。

通信系统消息一般都包含多个消息元素(IE)，有的IE还会包含多个IE，也可以说，消息是由多个IE组合、嵌套形成的。这就要求通信系统消息数据库记录的顺序与消息的结构保持一致，因此，本实施例以消息元素为基本单位存储消息，一般一条记录保存一个消息元素的一种协议定义，并将一个消息元素的所有记录设置为一个记录组，按该消息元素比特数据的顺序记录相应的消息元素描述。协议定义包括：该消息元素的比特数据和该消息元素描述。

本实施例中，消息元素记录主要包括两种类型的字段：用于记录通信系统消息中消息元素信息的消息属性字段、用于控制数据库记录搜索的附加字段。

其中，消息属性字段至少可以包括：消息元素描述字段(Description)、消息格式字段(Format)、消息元素长度字段(Length)。这里，Length字段存放的是消息元素的比特数，Description字段存放的是向用户显示的相应比特数的含义，也就是消息元素描述。

通过对各种消息结构进行分析和归纳，总结出如下基本消息元素。

一、基本消息元素：

1、若干比特数表示的一个值，例如一个7比特数表示的定时器值，数据库中Format字段用VD表示；

2、若干比特数表示的多选一的情况，数据库中Format字段用V表示，并在数据库中建立比特数据与相应消息元素的对应表，如表一：

Channel Set Mode：

表一

Belongto	Decode_Order	Message_Type	Description	Format	Length	Next_Step
							Channel_Set_Mode	1	65	Speech_full_rate_or_half_rate_version_3	V	8	No_More
Channel_Set_Mode	1	33	Speech_full_rate_or_half_rate_version_2	V	8	No_More
							Channel_Set_Mode	1	1	Speech_full_rate_or_half_rate_version_1	V	8	No_More
Channel_Set_Mode	1	0	Signalling_only	V	8	No_More
							Channel_Set_Mode	1	15	Data_14.5_kbit/s_radio_interface_rate	V	8	No_More
Channel_Set_Mode	1	3	Data_12.0kbit/s_radio_interface_rate	V	8	No_More

表二

在这里，Channel Set Mode自成一个消息记录组，它有8个比特，表示了6种情况，所有的6种情况都属于一个编解码步骤，所以Decode_Order为1，Message_Type就是具体的8个比特所代表的值，见表二。由于这个消息记录组编解码到这里就结束了，所以Next_Step写上No_More。

3、填充比特。通常用于消息描述最后的一个Byte中还剩了几个比特没有什么含义，只是用于填充，让消息流最终是Byte对齐，数据库中Format字段用ALN表示；

二、具有选择，控制作用的消息元素：

分界符(delimiter)，如：{0|1＜Value：bit(3)＞}第一个比特如果为0，后面的部分就不存在，如果为1，后面还接着3个比特表示其它含义，数据库中Format字段用VTB表示；

二、索引，就是对另外一个消息元素的应用，数据库中Format字段用TBL作为索引标识。如表三所示第2项消息元素；

表三

三、消息元素标识，有些消息元素是可选的，于是消息元素标识就成为辨识这个消息元素在比特流中是否存在的依据，数据库中Format字段用IEI表示，如表四，其中，7C就是消息元素为“Starting Time”的消息元素标识。

7C	Starting Time
		7D	End Time

表四

四、消息长度限定指示，有些消息定义本身是无限循环不结束的。于是在消息定义的前部会有一个消息长度指示，用于限定具体比特流中本消息的长度，数据库中Format字段用VDL表示。

在对数据库进行操作时，Message_Type和Format字段一起发挥作用，Format字段的值分别代表各种消息元素：VD、V、ALN、VTB、TBL、IEI、VDL、VR、VDR、ALR、N、RB、RE。

当Format指示本记录为数值(VD，VDR)的时候，Message_Type为0；

当Format指示本记录为依据数值选择一项(V，VR，VTB)的时候，Message_Type为作为依据的数值；

当Format指示本记录为消息元素标识(IEI)的时候，Message_Type中放的就是消息元素标识的数值；

当Format指示本记录为填充位(ALN，ALR)，跳转指示(TBL)时候，Message_Type为0，没有意义；

当Format为N的用途是用于标识数据库中此记录没有什么用。RB和RE是一对逆序标识，表示逆序解码开始和结束，他们对于的Message_Type为0，没有什么意义。

本实施例的附加字段包括了：消息或消息元素名称字段(Belongto)、消息或消息元素类型字段(Message_Type)编/解码级别字段(Decode_Order)、消息元素转向字段(Next_Step)；编/解码级别字段中填写本消息元素比特数据的编/解码顺序；消息元素转向字段中填写本消息元素比特数据编/解码后，要转向的消息元素的名称。

由于数据库中的记录只能够看做一个集合体，所以本方法设计3个特殊字段——Belongto、Decode_Order和Next_Step。消息元素间的顺序关系，选择关系，跳转关系等存在关系。其中Belongto填写的是消息元素名称，好像于地图上的路标；参见图1，图1为利用本发明的附加字段控制数据库记录搜索的示意图。Decode_Order和Next_Step配合起来做为指针，好像于指路牌，它们发挥作用如下：如果本记录的Next_Step还是指向本消息，那么就在Belongto字段相同的记录组中依照下一个Decode_Order寻找新的记录，如果Next_Step指向了一个新的消息元素名称(Belongto)，那么又从新的消息Decode_Order＝1开始搜索记录。

根据上面的描述，结合消息的类型和数据库字段的设计，可以总结出如下建立数据库的规则：

记录组是任何一组消息的基本结构，在数据库中它从decode_order＝1开始，以Format＝N和Next_Step＝No_More结束；

一个记录组中，每个记录依次Decode_Order加1；

正序时：

遇到若干比特表示一个值，选用Format＝VD，Next_Step指向下一个记录的Belongto；比如功率指示；

遇到若干比特用它们不同的值表示不同选项时，选用Format＝V，Next_Step指向下一个记录的Belongto；

遇到长度不定的填充位时，选用Format＝ALN，Next_Step指向下一个记录的Belongto；

遇到delimiter，由它来判别后面消息是否存在时，选用Format＝VTB，Next_Step指向下面要转向的Table名字。在下一个Table中，本消息的Description将用作Belongto；

遇到一大块消息，可以用Format＝TBL，转向下一个消息记录组；

遇到由IEI指示的可选消息记录组，用Format＝IEI表示本消息的IEI；

遇到长度限制的消息记录组，用Format＝VDL表示这个长度限制值；

逆序时：

每个反序记录组通常以Format＝RB的记录开始，Format＝RE的记录结束；

如果反序记录组中又有下一个消息组(VTB，TBL)的引用，被引用的消息组不用添加Format＝RB，Format＝RE记录；

尽量不要在一个反序记录组中架子消息组引用(VTB，TBL)

逆序解码中的V，VD，ALN分别用VR，VDR，ALR表示。

依照上述规则，消息结构就可以被放入到数据库中了。

另外，在通信系统消息数据库中，还可以按照协议中的消息结构定义及对消息头的规定，建立消息名称与消息头对应表；在进行消息解码时，可以通过查找协议类型与消息头对应表，判断消息名称。消息名称与消息头的对应也可以不单独列表，可以分别保存在不同消息元素的记录中。

建立了通信系统消息数据库后，就可以利用数据库对数据的维护管理来实现对通信系统消息的编解码。

以下先对利用该数据库进行解码的方法进行说明。

根据前面所述，把消息分解为数据库中的基本元素：记录组。记录组用Format格式来标识。Format有13种格式：N，VD，V，ALN，VTB，TBL，IEI，VDL，RB，RE，VR，VDR，ALR。它们是很重要的参数，起着控制前台程序解读消息比特流的走向。同时，数据库中还有其他必须要的附加字段，用来向解码程序提供本消息元素长度，本消息元素描述，以及下一步解码应该从数据库何处入口。

参见图2，图2为本发明对比特流进行解码的流程示意图。该流程包括以下步骤：

步骤201、找到一条消息的起始位置，读取该消息的消息头。本实施例的查找方法是：从比特流中查找出比特流传输过程中，为了区分不同消息在消息前增加的消息标识；该消息标识不在解码过程中解码。协议不同，比特流传输过程中增加的消息标识不同，在实际应用中，根据传输协议来设定查找消息起始位置的方法。

步骤202、根据消息头，通过查找消息名称与消息头对应表，判断消息名称。

步骤203、查找该消息名称包含的消息元素的记录，本实施例中是找到第一个消息元素的记录组。

步骤204、从当前消息元素记录中的相应字段获得消息元素信息。

步骤205、将从比特流中取出的比特数和消息元素信息中的消息元素解释描述组成该消息元素的解码结果通过计算机显示给用户，也可以将解码结果以文本文件的形式保存到计算机中。

步骤206、根据记录相应字段的指示，即Next_Step，转向下一个消息元素记录，返回步骤204继续进行解码，直到记录的Format字段为N和Next_Step＝No_More结束。

例如，对于比特流：...00000100 0000010 11110011 01001101...进行解码。这段比特流是一个消息的一部分。假设这消息的消息头和前几个消息元素已经解码完成。这段比特流对应的是协议中，“Bearer_Capability_UE_Originating”为“Set_Up_UE_Originating”消息的一个IE，内容参见图3。图3为一段协议内容结构示意图。其中octet1、octet2、octet3、octet3a分别代表一个字节。其中，octet1字节包含了一个消息元素：Bearer capability IEI；octet2字节包含了一个消息元素：Length of the bearercapability contents；octet3字节包含了四个消息元素：radio channelrequirement、codingstd、transfer mode、informtion transfer capability；octet3a字节包含了coding、spare、speech version indication等消息元素；0/1ext表示存在下一个字节。根据上述协议结构，数据库中保存了两个表：表五、表六。数据库中，表六为表五中第2条记录的详细内容。

Belongto	Decode_Order	Message_Type	Description	Format	Length	Next_Step
							Set_Up_UE_Originating	7	0	Repeat Indication	TBL	0	IE_Table
Set_Up_UE_Originating	8	0	Bearer_Capability_UE_Originating	TBL	8	IE_Table
							Set_Up_UE_Originating	9	0	Facility	TBL	0	IE_Table
…	…	…	…	…	…	…

表五

Belongto	Decode_order	Messase_Type	Description	Format	Length	Next_Step
							Bearer_Capability_UE_Originating	1	4	IEI_Bearer_Capability_UE_Originating	IEI	8	Bearer_Capability_UE_Originating
Bearer_Capability_UE_Originating	2	0	Length_Of_Bearer_Capability_UE_Originating	VDL	8	Bearer_Capability_UE_Originating
							Bearer_Capability_UE_Originating	3	0	Reverse_Begin	RB	0	Bearer_Capability_UE_Originating
Bearer_Capability_UE_Originating	4	1	Info_Transfer_Cap_Unrestricted_Digital	VR	3	Bearer_Capability_UE_Originating
							Bearer_Capability_UE_Originating	4	7	Info_Transfer_Cap_Reserved.	VR	3	Bearer_Capability_UE_Originating
…	…	…	…	…	…	…
							Bearer_Capability_UE_Originating	8	0	Bearer_Capability_UE_Originating_Octet3a	VTB	1	IE_Table
Bearer_Capability_UE_Originating	8	1	No_Extension	VTB	1	No_More
							…	…	…	…	…	…	…
Bearer_Capability_UE_Originating	27	0	End_Read_From_Low_Bit	RE	0	No_More

表六

这段比特流解码的具体过程包括以下步骤：

步骤1、消息的前一个IE(即表六中第一条记录)解码完成后，根据其字段“Decode_Order”“Next_Step”，指示下一个要解码的IE仍是该消息中的一个IE，即“Bearer_Capability_UE_Originating”；

步骤2、从数据库中“Bearer_Capability_UE_Originating”的字段“Decode_Order”＝1的记录开始读取：该记录中length＝8，因此从比特流中读出8比特，即第一个字节“00000100”，“Format”＝IEI，按照字段的含义，此时直接读取“Message_Type”，得到IE“Bearer_Capability_UE_Originating”中第一个字节为“IEI_Bearer_Capability_UE_Originating”；

步骤3、根据“IEI_Bearer_Capability_UE_Originating”的字段“NextStep”，指示下一个信息仍是IE“Bearer_Capability_UE_Originating”的内容，继续读取“Decode_Order”＝2记录的内容：该记录中length＝8，“Format”＝VDL，因此从比特流中读出8比特，即第2个字节，得到IE“Bearer_Capability_UE_Originating”中第二个字节为“Length_Of_Bearer_Capability_UE_Originating”，并且取值为00000010，即IE“Bearer_Capability_UE_Originating”的长度为2个字节；

步骤4、根据“Length_Of_Bearer_Capability_UE_Originating”的字段“Next Step”，指示下一个信息仍是IE“Bearer_Capability_UE_Originating”的内容，继续读取“Decode_Order”＝3记录的内容：该记录大“Format”字段为RB，意味着将开始逆序解码；也就是说对于本记录组中“Format”字段为开始逆序标识RB和终止逆序标识RE之间的记录解码后，按从后向前的顺序组织解码结果。

步骤5、继续读取“Decode_Order”＝4的记录的内容：读取长度为“length”＝3比特的字节流，即第3个字节的前三个比特“111”，十进制取值为7，“Format”＝VR，与记录中的“Message_type”比较，得到该信息为“Info_Transfer_Cap_Reserved”；

步骤6、继续读取“Decode_Order”＝5的记录的内容，进行解码，一直读完整个比特流。

应用本发明进行编码的过程与上述过程相似，编码是将用户构造的消息形成通信设备能够传输和识别的比特流。编码是解码过程的逆序，但是编码和解码查找数据库的方法是一样的。在编码时，先根据要构造的消息的消息名称到通信系统消息数据库中查找消息中包含的消息元素的记录；再根据该消息中各个消息元素的属性及消息元素间的存在关系，在消息元素记录中查找到该消息中所有消息元素属性对应的比特数据，组成编码结果。

参见图4，图4为本发明对协议进行编码的流程示意图。该流程包括以下步骤：

步骤401，用户给出要编码消息的消息名称，消息名称是用户已知的，在给出消息名称的同时，给出要构造的消息元素属性的取值。

步骤402，查找该消息名称包含的消息元素的记录，本实施例中是找到该消息名称中第一个消息元素的记录组。

步骤403，从当前消息元素记录中的相应字段获得消息元素对应的比特数据。

步骤404，将消息元素信息和对应的比特数据组成该消息元素的编码结果通过计算机显示给用户，也可以将解码结果以文本文件的形式保存到计算机中。

步骤405，根据记录相应字段的指示，即Next_Step，转向下一个消息元素记录，返回步骤403继续进行解码，直到记录的Format字段为N和Next_Step＝No_More结束。以下仍以图3所示协议内容结构和其在数据库中存储的表五、表六为例，对编码过程进行详细说明。

本实施例从表五中的第二条记录开始，在编码过程中要构造的消息用户是已知的，用户可以给出要构造的消息元素类型以及消息元素属性的值，假设属性取值如下：

Information transfer capability＝Unrestricted digital information，即1；

Transfer mode＝Circuit mode，即0；

Coding std＝GSM standardized coding，即0；

Radio channel requirement＝full rate support only MS/fullrate speech version 1supported，即1。

该编码过程包括以下步骤：

步骤1、根据消息的前一个IE记录字段“Decode_Order”“Next Step”检索到“Bearer capability”IE，之后便进入该IE进行编码。

步骤2、由于IEI是协议中规定的，只要IE名称确定，IEI取值就是唯一的，因此该IEI数值可以系统自动提供，不需要用户填充，也可以要求用户输入，根据该IEI的记录，“Length”＝8，取值为4，则编码为00000100。根据数据库中该记录的“decode order”和“Next step”字段，找到“Length of the bearercapability contents”IE。

步骤3、“Length of the bearer capability contents”的“Length”＝8，即该IE本身的长度是占8比特，该参数的含义是整个“bearer capability”IE的有效字节数。由于各个IE的有效字节数是不同的，且此时还未得到后续IE一共占多少字节的信息，所以该IE的取值可以先空出来8比特，与前面的编码结果组合起来，得到00000100 XXXXXXXX。待后续IE都编码完成后，再读取有效字节数，填入空出来的8比特。

同样根据数据库中该记录的“decode order”和“Next step”字段，找到下一个记录表示逆序编码开始，即下一个IE编码后在一个字节内部从低比特位到高比特为组织编码结果。

步骤4、继而找到下一个要编码的IE是“Information transfer capability”，用户给出的值为1，根据该IE的字段length＝3，该IE编码为对应的二进制为001，由于是逆序编码，放在下一个字节的3个低比特位，与前面的编码结果组合起来，得到；00000100 XXXXXXXX NNNNN001，其中N表示为了逆序编码而空出来的比特位。

步骤5、同样的方法IE“Transfer mode”＝Circuit mode，即0，并且占l比特长度，编码为0，与前面的编码结果组合起来，得到00000100 XXXXXXXXNNNN0001。

步骤6、同样，IE“Coding std”＝GSM standardized coding，即0，并且占1比特长度，编码为0，与前面的编码结果组合起来，得到00000100 XXXXXXXXNNN00001。

步骤7、同样，IE“Radio channel requirement”＝full rate support onlyMS/fullrate speech version 1 supported，即1，占2比特长度，编码为01，，与前面的编码结果组合起来，得到00000100 XXXXXXXX N0100001。

继续对下一个IE进行编码，一直编完整个消息形成比特流。

应用本发明可以实现离线的编解码功能，也就是对于已经保存在计算机内部的消息和比特流进行编解码，还可以实现实时消息跟踪功能，一般是在测试过程中，收到一段比特流就解码一段，来测试接收的比特流是否正确。可以将本发明应于核心网(CN)与基站控制器之间、基站控制器与基站之间、基站与移动终端之间，对传输的比特流进行实时消息跟踪。

由于消息的扩充只需增加数据库记录和编解码程序没有关系，所以随着规范的变动，只需要对数据库独立进行改动，在进行编解码时就立刻能够将最新信息显示出来。

由上述的实施例可见，本发明的这种对通信系统消息进行编解码的方法，采用了把消息描述和处理程序分开的办法，为消息定义建立数据库，利用数据库对数据的维护管理功能，实现了对通信系统消息的灵活修改和提高编、解码的速度，非常适用于用多种消息语法结构定义直接形成消息比特流的消息描述方法如全球移动通信系统(Global System for Mobile Communications，GSM)，或物理层采用TD-SCDMA协议、高层采用GSM协议的TSM移动通信系统(TD-SCDMA over GSM，TSM)等描述的通信消息，以及其它类似的自定义通信消息的编解码，在通信系统的研发及测试中用途广泛。

Claims (10)

1.一种对通信系统消息进行编解码的方法，其特征在于，该方法包括以下步骤：

1)将通信系统消息中消息元素的信息设置为通信系统消息数据库记录的消息属性字段；并按消息元素间的存在关系，设置用于控制所述数据库记录搜索的附加字段；将消息定义按消息元素的信息及消息元素间的存在关系，存储到消息元素对应的记录中，建立通信系统消息数据库；

2)对通信系统消息进行编码时，根据消息名称到通信系统消息数据库中查找消息中包含的消息元素的记录；再根据该消息中各个消息元素的属性及消息元素间的存在关系，在消息元素记录中查找到该消息中用户定义的所有消息元素属性对应的比特数据，组成编码结果；

3)对通信系统消息进行解码时，从比特流中找到一条消息的起始位置，读取该消息的消息头根据消息头到通信系统消息数据库中搜索对应的消息名称，再根据该消息名称，在通信系统消息数据库中查找到消息中包含的消息元素的记录；根据该消息中各个消息元素属性的比特数据及消息元素间的存在关系，在消息元素记录中查找到该消息中所有消息元素属性比特数据对应的消息元素描述，组成解码结果。

2.如权利要求1所述的方法，其特征在于，步骤1)所述的附加字段至少包括：消息或消息元素名称字段、消息或消息元素类型字段、编/解码级别字段、消息元素转向字段；编/解码级别字段中填写本消息元素比特数据的编/解码顺序；消息元素转向字段中填写本消息元素比特数据编/解码后，要转向的消息或消息元素表、消息名称、或消息元素的名称；

在编/解码过程中，根据消息或消息元素名称字段中记录的消息或消息元素名称，按编/解码级别字段中记录的顺序及消息元素转向字段的消息元素名称，进行顺序编/解码和跳转编/解码。

3.如权利要求1所述的方法，其特征在于，所述步骤1)进一步包括：将一个消息元素的所有记录设置为一个记录组，按该消息元素比特数据的顺序记录相应的消息元素描述。

4.如权利要求3所述的方法，其特征在于，所述步骤1)进一步包括：设置成对的逆序标识；依照协议规定，在记录组中需要从一个字节的低比特位向高比特位方向进行编/解码的消息元素的起始记录中添加起始逆序标识，在记录组中需要从一个字节的低比特位向高比特位方向进行编/解码的消息元素的终止记录中添加终止逆序标识；

在组成编码结果/解码结果时，对于一对逆序标识间的比特流/消息元素描述，从后向前组织结果；对于逆序标识以外的比特流/消息元素描述，从前向后组织结果。

5.如权利要求1所述的方法，其特征在于，所述步骤1)进一步包括：设置索引标识，根据消息元素间的存在关系，在需要转向非本消息元素的消息元素记录中，添加索引标识；

在编/解码过程中，根据该索引标识转向非本消息元素的记录，进行查找。

6.如权利要求1所述的方法，其特征在于，所述步骤1)进一步包括：在通信系统消息数据库中，为每个有多选一属性的消息元素，建立比特数据与相应消息元素描述的对应表；

在编/解码过程中，根据消息中该消息元素的属性值，在上述比特数据与相应消息元素描述的对应表中，查找到相应的比特数据/消息元素描述。

7.如权利要求1所述的方法，其特征在于：所述步骤1)进一步包括：按照协议中的消息结构定义及对消息头的规定，在通信系统消息数据库中，建立消息名称与消息头对应表；

步骤3)所述搜索对应的消息名称的方法为：根据消息头，通过查找消息名称与消息头对应表，判断消息名称。

8.如权利要求1所述的方法，其特征在于：步骤3)所述从比特流中找到一条消息的起始位置的方法为：从比特流中查找出比特流传输过程中，为了区分不同消息在消息前增加的消息标识；在解码过程中不对该消息标识进行解码。

9.如权利要求1所述的方法，其特征在于，该方法进一步包括：将组成的编码结果/解码结果，写成文本文件保存在计算机中。

10.如权利要求1或9所述的方法，其特征在于，该方法进一步包括：将组成的编码结果/解码结果，通过计算机显示给用户。

Images