MAP - Mobile Application Part protocol MAP enables the MSC to interwork with the VLR, HLR, EIR,

MSC, SMC through the B, C, D, E and G interfaces respectively. CAP - CAMEL Application Part CAMEL Application Part (CAP) has evolved from the Intelligent Network Applicati on Protocol (INAP) of the wired Intelligent Network (IN). CAP enables signaling interworking between GSM Service Switching Function (gsmSSF), GSM Specialized Re source Function (gsmSRF) and GSM Service Control Function (gsmSCF) of radio IN f unctional entities, for the purpose of supporting CAMEL services. CAP protocol is one of the parts of the Signaling System No. 7. CAP is the user part of the Transaction Capabilities Application Part (TCAP) in the SS7. CAP use s structured/unstructured dialog capabilities provided by the TCAP protocol, and realizes signaling interaction between functional entities. In SS7, CAP messages are conveyed as the component part of TCAP messages. ISUP - The Integrated Services Digital Network User Part The Integrated Services Digital Network User Part (ISDN User Part or ISUP) is on e of the User Parts of the Common Channel Signaling System No.7, which defines t he signaling messages, functions and procedures required to control voice and no n-voice services (for example, circuit switched data communication). The ISUP ca n not only implement the functions of the Telephone User Part (TUP) and the Data User Part (DUP), but also achieve the ISDN services on a wide basis, thus havi ng a spacious application scope. The ISDN User Part (ISUP) protocol supports the establishment, supervision and r elease of 64 kbps circuit switched network connections between exchanges in ISDN networks. In order to establish a traffic connection between two nodes a message initiatin g the connection needs to be defined. Initiating a traffic connection means rese rving one of the available traffic resources (a circuit) for the exclusive use o f this connection. In case of ISUP information about which circuit was booked fo r the purpose of the connection travels in an Initial Address Message (IAM). Thi s message shall also contain the called address (B-number) and other information relating to call routing and handling. BICC - The Bearer Independent Call Control Protocol The Bearer Independent Call Control (BICC) protocol is one of the application la yer control protocols. It is used to establish, modify and terminate calls and c an bear comprehensive PLMN/PSTN/ISDN services. BICC evolves from the ISUP protocol and has it developed. It is characterized by the separation between the call control level and the bearer control level, thu s the Call Service Function (CSF) is independent of the Bearer Control Function (BCF). In UMTS, BICC is applied to the call control interface between two MSC Servers. BICC signaling develops on the basis of ISUP signaling, and is basically similar to the ISUP protocol in the aspect of supporting basic call procedures and supp lementary service features. The additional Application Transport Mechanism (APM) in BICC makes it possible to exchange bearer related information between the ca ll control nodes at the ends of the Nc interface. Such information includes bear er address, connection reference, bearer characteristics, bearer setup mode and supported Codec list, and so on. BICC can also provide an optional tunnel transp

ort function on the Nc interface for the bearer control signaling between Media GateWays (MGWs). SCTP - Stream Control Transmission Protocol The SCTP endpoint: The SCTP endpoint is the logical sender/receiver of SCTP packets. It comprises a set of transport addresses (a combination of IP address and port number) for se nding and receiving SCTP packets between the two SCTP nodes. These transport add resses must be unique to the SCTP endpoint throughout the network. This is very similar to the signaling point code of a node being unique within the signaling network. SCTP Association: The SCTP association is the logical relationship between two SCTP end points. Th is association includes the protocol state information, Verification Tags and th e currently active set of Transmission Sequence Numbers between the two SCTP end points. It can be said that the SCTP association is like the logical grouping o f signaling links in traditional SS7, called a link set. (a link set provides m anagement for a specific group of links) Communication through an SCTP association requires transport addresses (a combin ation of IP address and port number). These are used by routers to route the IP payload through the IP network. The port numbers mentioned are defined at both e nds. The SCTP endpoint can be seen as the termination of the signaling stream. The protocol data units of SCTP are referred to as SCTP packets. If SCTP runs o ver IP then the SCTP packet forms the payload of an IP packet. The transport add resses for the SCTP endpoint are in reality the source and destination addresses /ports put in the headers of the IP packet and the SCTP message. SCTP packets co nsists of a common header and a payload field. The payload field can carry sever al bundled messages, so-called chunks. This multiplexing of messages results in better utilization of the signaling transport (less overhead). The SCTP packet structure is composed of a common header and chunks. This is enc apsulated inside an IP packet. Common header: The common header consists of 12 bytes. The source and destinati on ports (32 bits each to express the ports) of the header identify the specific association/application. In the SCTP header, along with the ports there is the verification tag (32 bits length) and finally the checksum (A lso 32 bits in length). The verification tag is a 32 bit unsigned integer that i s randomly generated. It provides a label that allows a receiver to verify that the SCTP packet belongs to a current association and is not an old or stale pac ket from a previous association. For the detection of transmission errors, the header implements a 32-bit checksu m (it uses the Adler32-algorithm). This is more robust than the 16-bit value che cksum used in TCP/UDP protocols. The check-sum protects both the common header a nd the chunks of the message. Packets failing the checksum are silently discarde d. Chunks: Following the header are a possible series of chunks . The number of chunk s following depends on the maximum size of the MTU that can be carried. These ch unks carry chunk specific content. The first field presented is the CHUNK type (16 bit expression); in fact this provides the SCTP m essage types . Chunk specific flags follow the chunk type and a length field that indicates length of the user data field is included. The final part is the user data field associated with the chunk.

H.248 Protocol H.248 is a protocol that is part of the ITU-T defined MEGACO protocol suite. H.2 48 is used between a media gateway control function (MGCF) instance and a media gateway function (MGF). In a distributed gateway system, this protocol may be op erated over TDM, ATM or IP and is used by the media gateway controller (MGC) to control and communicate with a media gateway (MGW). In the UMTS Rel-4 architectu re the protocol is used between the MGCF in the MSC server NE and the MGW NE. In UMTS, the MGCF-MGW interface is called the Mc interface and the 3GPP defines sp ecific usage of H.248 over the Mc. SIGTRAN - Signaling Transport Protocol Signaling Transport (SIGTRAN) protocol stack is defined by the SIGTRAN workgroup of the Internet Engineering Task Force (IETF) for interworking purposes between the Signaling System No. 7 (SS7) and the Internet Protocol (IP).This protocol s tack supports transmission of switched circuit network (SCN) signaling across IP network. This protocol stack supports the inter-layer standard primitive interf ace defined in SCN signaling protocol hierarchy model so as to ensure utilizati on of the existing SCN signaling application without modification. It also uses the standard IP transport protocol as the transmission bottom layer, and satisfi es the special transmission requirements of SCN signaling by adding its own func tions. SIGTRAN scenarios: SIGTRAN allows SS7 messages to be sent over IP networks. There are three network scenarios implemented for SIGTRAN, these are: Signaling between a signaling end point in an IP network and a Signaling point in a traditional SS7 network (TDM or ATM based). A signaling gateway is responsi ble to convert IP SIGTRAN messages into traditional SS7 messages. The two commun icating signaling entities may or may not belong to the same operator. Signaling between two signaling end points (SEP s) inside an IP network. A dual s ignaling transport stack can be used to provide redundancy and enable fallback t o legacy SS7. Signaling between two SGW s over an IP network. Each SGW is at the border of an a rbitrary network.