Analysis and decoding of CAP messages in communication network testers

1 Introduction

The signaling analysis in the communication network tester is aimed at a series of transport layer and application layer protocols in the protocol stack. The basis of instrument protocol analysis is to be able to decode and parse the received network data and perform more advanced statistical tracking functions on this function. When performing protocol analysis, in view of the differences in message formats and processing mechanisms between protocols, as well as the requirements for the implementation of software modularization, it is more effective to adopt the method of module encapsulation with a single protocol. The advantage is that it can ignore the subtle differences in functions and formats between protocols, and the analysis method of a single protocol can also be largely extended to other protocols.

The main content of this paper is the analysis of CAP messages. On the one hand, it describes how to decode the protocol message structure specified in the protocol standard. On the other hand, it discusses the statistics of CAP messages and call data record synthesis functions based on actual conditions.

2. CAP Protocol Overview

The intelligent network is a classic example of the integration of communication technology and computer technology. Its basic idea is to separate business control intelligence from the switching network, use the No.7 signaling system as a bridge, and link the control information of the switching network with a large-capacity distributed database for centralized control, so as to facilitate the introduction of new services and quickly adapt to changing market demands, without having to perform complicated modifications on a wide range of multiple models of switches as in the past.

In order to introduce intelligent networks into mobile communication systems, the European Telecommunications Standards Institute (ETSI) defined CAM-EL (Customised Applications for Mobile network Enhanced Logic) on GSM Phase 2+ in 1997. The characteristic of the CAMEL protocol is to provide users with a network-independent service consistency. Even if the user is not in the public land mobile network (HPLMN) to which he belongs, the CAMEL protocol can be used as a means to help network operators provide specific services to users. CAP (CAMEI, Application Part) is the application part of CAMEL, which is based on the INAP protocol of the intelligent network. The CAP protocol describes the standard communication procedures between various functional entities in the mobile intelligent network.

As an application layer protocol, CAP, INAP, and MAP are all users of TCAP. Their positions in the SS7 signaling system are shown in Figure 1.

The devices in the mobile intelligent network system are often provided by different manufacturers, so the accuracy and unambiguity of the CAP definition become very important. Currently, the grammar of CAP is defined using ASN.1.

ASN.1 (Abstract Syntax NotaTIonOne) is equivalent to a language that describes the transmission syntax. The encoding rules it defines are the conversion rules from different protocol languages ​​to unified transmission syntax. Therefore, in the specific implementation, an ASN.1 encoder must be set up on the sender to convert the message format that conforms to the sender's programming syntax to be transmitted into a format that conforms to the ASN.1 encoding rules and then send it out. Then, an ASN.1 decoder is set up on the receiver to decode the received message format that conforms to the ASN.1 encoding rules into a message format that conforms to the receiver's protocol syntax. In this way, the information described by ASN.1 is independent of any application system and transmission network, and will not cause ambiguous interpretations due to different application environments.

While developing ASN.1, ISO also introduced two encoding rules for ASN.1. One is the Basic Encode Rule (BER), for details, please see X.690; the other is the Packet Encode Rule (PER), for details, please see X.691. BER and PER are actually a kind of transmission syntax, which can express complex data structures described by abstract syntax into simple data streams, so as to facilitate transmission on communication lines. PER is an encoding rule designed on the basis of BER to reduce encoding overhead. It is more concise than BER encoding, but the current communication protocols are still mostly BER encoding. The CAP protocol follows the BER encoding rule [4].

3. CAP software module system design

3.1 Design requirements of CAP software modules

For the software module of the communication network test instrument, the CAP module needs to meet the functions of detailed decoding of CAP messages, information extraction, statistics, CDR synthesis, filtering, etc. Its design mainly considers the following aspects:

(1) Object-oriented and modular design of software

The modular design is adopted under the object-oriented concept, the internal structure of the module is clear and easy to understand, and each module is relatively independent. This makes it easy to check errors, save development time, and improve the stability, modifiability and reusability of the software system.

(2) Cooperation with the database

The communication test system involves a considerable number of database file systems. Information extraction, message statistics and CDR synthesis all need to cooperate with the database. Therefore, the database implementation of the module should be considered during the software module design.

(3) Module efficiency issues

In order to meet the test instrument's long-term heavy load monitoring and real-time decoding statistics and other functions, the module must improve its operating efficiency. In order to better improve the performance of the software, multi-threading and pipeline technology can be considered in software design.

3.2 Structural Analysis of CAP Module

Based on user needs, the system analysis adopts object-oriented thinking to analyze the CAP module in detail, divide the various parts of the system, clarify the hierarchical relationship between them, and then analyze the functions of each part as an object, process the data at each level, and provide necessary support to the upper level. The protocol message processing flow according to the overall software architecture is shown in Figure 2.

The data captured by the acquisition card is first saved in the message cache; the decoder takes out the messages from the message cache and roughly decodes them one by one to obtain the frame information and call information of each frame of data; these two types of information are handed over to the call synthesizer for call synthesis according to the protocol category, and the CDR set of each protocol is obtained and saved in the CDR cache; it is displayed and counted according to user needs. The statistical function can be performed directly on the CDR cache, or the CDR can be input into the database first, counted in the database, and then the statistical results are output. For the CAP module, we mainly implement the CAP decoder and call synthesizer.

Design and implementation.

3.3 Research and implementation of CAP software modules

3.3.1 CAP protocol decoding analysis

Before decoding and analyzing CAP, we must first know the basic encoding format of BER encoding. BER uses 8 bits as a basic transmission unit. For each transmitted value, whether it is a basic type or a constructed type, it is composed of three TLV fields. TLV refers to the identification type identifier field (TAG), data length field (LENGTH) and data field (VALUE) fields. Among them, the data field can nest multiple TLV fields of other data elements. The specific format of BER encoding is shown in Figure 3.

In the CAP protocol description, localValue, length, operator-code, and errorcode correspond to the TLVs in the BER encoding, forming a tree data structure diagram [1]. The specific decoding design will be analyzed below.

3.3.2 Decoder Implementation

In the communication test instrument, the main operation is on the PDU of the protocol and signaling. In order to meet the common operation of PDU, we have developed the CPdu base class, which mainly realizes the basic functions of creating, deleting, merging, memory management, length checking, pointer operation, etc. of PDU. On the basis of inheriting the CPdu class, we derive the CPduCap class, set the external interface function int Deeode (CString&res) in the CPduCap class, complete the detailed decoding process, and put the decoding result in the string of CString type by reference passing, so that the master can call the decoding result. The return value result is defined as follows: 1: Not the PDU of this layer, do not operate res; 0: Successfully decoded; 1: The PDU of this layer, the decoding error, the error information is added to the result string.

Due to the characteristics of ASN.1 syntax, the Decode(CString & res) function uses a tree-like traversal nested call method to decode until the basic function of BER is solved.

In the basic decoding function, we make extensive use of the template class in the C++++ standard template library: the container std::vector. Vector is a multifunctional template class and function library that can operate a variety of data structures and algorithms. In the environment of ASN.1 complex data structure, the use of vector facilitates the reading, storage, and conversion of various data types.

The implementation of detailed decoding is the basis for in-depth analysis of the communication protocol, as well as statistics and CDR synthesis. The following mainly focuses on the implementation of CAP CDR synthesis.

3.3.3 Call Synthesizer Implementation

The main function of the call synthesizer is to classify the frame messages by call according to the arriving frame information and call information, that is, to add the message ID to the corresponding CDR record and notify the CDR cache when the call ends. CDR (calldata record) means call data record in PSTN, and now it is extended to mean a complete process. CDR synthesis is the basis of the above functions. Messages in the network are classified according to the signaling process, and these messages are linked together by indexing, so that it is convenient to complete advanced functions such as call tracking and call loss statistics. The CDR synthesis algorithm mainly searches and matches based on some key parameters to determine whether they belong to the same message process. Therefore, in this process, some temporary storage methods are needed to save messages that are not matched. The memory allocation is relatively complicated and involves dynamic memory allocation.