Telephony

For information on cellular and telecom protocol testing

See SS7 for a description of SS7 protocols.

BSSAP

GSM 08.06 http://www.etsi.fr

The MTP and the SCCP are used to support signalling messages between the Mobile Services Switching Center (MSC) and the Base Station System (BSS). One user function of the SCCP, called BSS Application Part (BSSAP) is defined. In the case of point-to-point calls the BSSAP uses one signalling connection per active mobile station having one or more active transactions for the transfer of layer 3 messages. In the case of a voice group or broadcast call there is always one connection per cell involved in the call and one additional connection per BSS for the transmission of layer 3 messages. There is an additional connection for the speaker in a broadcast call or the first speaker in a voice group call up to the point at which the network decides to transfer them to a common channel. Additional connections may also be required for any mobile stations in the voice group or broadcast call which the network decides to place on a dedicated connection. The BSSAP user function is further subdivided into two separate functions:

• The Direct Transfer Application sub-Part (DTAP), also called GSM L3, is used to transfer messages between the MSC and the MS (Mobile Station); the layer-3 information in these messages is not interpreted by the BSS. The descriptions of the layer 3 protocols for the MS-MSC information exchange are contained in the 04- series of GSM Technical Specifications.
• The BSS Management Application sub-Part (BSSMAP) supports other procedures between the MSC and the BSS related to the MS (resource management, handover control), or to a cell within the BSS, or to the whole BSS. The description of the layer 3 protocol for the BSSMAP information exchange is contained in Recommendation GSM 08.08.

Both connectionless and connection-oriented procedures are used to support the BSSMAP. Rec. GSM 08.08 explains whether connection oriented or connectionless services should be used for each layer 3 procedure. Connection oriented procedures are used to support the DTAP. A distribution function located in BSSAP, which is reflected in the protocol specification by the layer 3 header, performs the discrimination between the data related to those two subparts.

BSSAP messages include the following fields:

Discrimination
Distribution between the two sub-protocols: BSSMAP and DTAP.

DLCI
Only for DTAP. Used in MSC to BSS messages to indicate the type of origination data link connection over the radio interface.

Length
Subsequent Layer3 message parameter length.

Interested in more details about testing this protocol?

BSSMAP

GSM 08.08 http://www.etsi.fr

Message Type
A one octet field defining the message type. This mandatory field uniquely defines the function and format of each BSSMAP message.

Information Element
Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and may or may not include a length indicator.

Interested in more details about testing this protocol?

GSM L3 (DTAP Direct Transfer Application Part )

GSM 04.08 http://www.etsi.fr

Global System for Mobile Communications (GSM) is a cellular radio system. The signalling layer 3 provides the functions to establish, maintain and terminate circuit-switched connections across a GSM PLMN and other networks to which the GSM PLMN is connected. It provides the necessary supporting functions related to supplementary services control and short messages service control. Furthermore it includes the functions necessary for mobility management and radio resource management.

The layer 3 is composed of three sublayers comprising:

• Radio Resource Management (RR)
• Mobility management (MM)
• Connection Management (CM)

The Connection Management (CM) sublayer is composed of:

• Call Control (CC)
• Sort Message Support (SMS)
• Supplementary Services Support (SS)

Transaction ID / Skip identifier
The value of bits 5 to 8 depends on the protocol used.

Message type
Uniquely defines the function and format of each GSM L3 message. The message type is mandatory for all messages. The format of the message type is as follows:

Message type
The message type determines the function of a message within a protocol in a given direction. The meaning of the message type is therefore dependent on the protocol (the same value may have different meanings in different protocols) and direction (the same value may have different meanings in the same protocol, when sent from the Mobile Station to the network and when sent from the network to the Mobile Station).

Interested in more details about testing this protocol?

RR

RR (Radio Resource) management procedures include the functions related to the management of the common transmission resources, e.g., the physical channels and the data link connections on control channels. The general purpose of Radio Resource procedures is to establish, maintain and release RR connections that allow a point-to-point dialogue between the network and a Mobile Station. This includes the cell selection/reselection and the handover procedures. Moreover, Radio Resource management procedures include the reception of the uni-directional BCCH and CCCH when no RR connection is established. This permits automatic cell selection/reselection.

Skip identifier
Value of 0000.

Message type
Uniquely defines the function and format of each RR message. The message type is mandatory for all messages. RR message types may be:

Interested in more details about testing this protocol?

MM

GSM 04.08 http://www.etsi.fr

The main function of the Mobility Management (MM) sub-layer is to support the mobility of user terminals, such as informing the network of its present location and providing user identity confidentiality. A further function of the MM sub-layer is to provide connection management services to the different entities of the upper Connection Management (CM) sub-layer.

The structure of the MM sub-layer is the same as that of RR.

Message type
MM message types may be as follows. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station.

Interested in more details about testing this protocol?

CC

GSM 04.08 http://www.etsi.fr

The call control (CC) protocol is one of the protocols of the Connection Management (CM) sublayer. Every mobile station must support the call control protocol. If a mobile station does not support any bearer capability at all then it must respond to a SETUP message with a RELEASE COMPLETE message. In the call control protocol, more than one CC entity are defined. Each CC entity is independent from each other and communicates with the correspondent peer entity using its own MM connection. Different CC entities use different transaction identifiers.

Certain sequences of actions of the two peer entities compose elementary procedures. These elementary procedures may be grouped into the following classes:

• Call establishment procedures.
• Call clearing procedures.
• Call information phase procedures.
• Miscellaneous procedures.

The terms "mobile originating" or "mobile originated" (MO) are used to describe a call initiated by the mobile station. The terms "mobile terminating" or "mobile terminated" (MT) are used to describe a call initiated by the network.

The CC structure is shown here:

Transaction Identifier
The format of the transaction identifier is as follows:

TI flag
Identifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value.

TI value
TI values are assigned by the side of the interface initiating a transaction. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface.

Message type
CC message types may be as follows. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station.

Interested in more details about testing this protocol?

SMS

GSM 04.11 http://www.etsi.fr

The purpose of the Short Message Service (SMS)is to provide the means to transfer messages between a GSM PLMN Mobile Station and a Short Message Entity via a Service Center, as described in TS GSM 03.40. The terms "MO" - Mobile Originating - and "MT" - Mobile Terminating - are used to indicate the direction in which the short message is sent.

The SMS structure is as follows for control messages:

Protocol discriminator
1001 identifies the SMS protocol.

Transaction Identifier
See CC for the format of the Transaction ID.

Message type
The message type, together with the protocol discriminator, identifies the function of the message being sent. Messages may be of the following:
00000001 CP-DATA
00000100 CP-ACK
00010000 CP-ERROR

Information Element
Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and may or may not include a length indicator.

The SMS structure is as follows for relay messages:

MTI
Message type indicator. Values are as follows:

Message Reference
Used to link an RP-ACK message or RP-ERROR message to the associated RP-DaATA or RP-SMNA message.

Information Element
Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and may or may not include a length indicator.

Interested in more details about testing this protocol?

Mobile IP

RFC2002: http://www.cis.ohio-state.edu/htbin/rfc/rfc2002.html

Mobile IP enables nodes to move from one IP subnet to another. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol allows registration of the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. It can be used for mobility across both homogeneous and heterogeneous media. Mobile IP defines a set of new control messages, sent with UDP, Registrat ion Request and Registration Reply.

The IP packet consists of the IP source address and IP destination address, followed by the UDP source port and destination port followed by the Mobile IP fields. Mobile IP packets can be either Registration Request or Registration Reply. The format of the Mobile IP Registration Request header is shown in the following illustration:

Type
Type=1 specifies a registration request.

S
Simultaneous bindings. If the S bit is set, the mobile node is requesting that the home agent retain its prior mobility bindings.

B
Broadcast datagrams. If the B bit is set, the mobile node requests that the home agent tunnel to it any broadcast datagrams that it receives on the home network.

D
Decapsulation by mobile node. If the D bit is set, the mobile node will itself decapsulate datagrams which are sent to the care-of address. That is, the mobile node is using a co-located care-of address.

M
Minimal encapsulation. If the M bit is set, the mobile node requests that its home agent use minimal encapsulation for datagrams tunneled to the mobile node.

G
GRE encapsulation. If the G bit is set, the mobile node requests that its home agent use GRE encapsulation for datagrams tunneled to the mobile node.

V
Van Jacobson. The mobile node requests that its mobility agent use Van Jacobson header compression over its link with the mobile node.

Rsv
Reserved bits (2) are sent as zero.

Life Time
Life Time. The number of seconds remaining before the registration is considered expired.

Home Agent
IP address of the mobile node's home agent.

Care-of Address
IP address for the end of the tunnel.

Identification
A 64-bit number, constructed by the mobile node, used for matching Registration Requests with Registration Replies, and for protecting against replay attacks of registration messages.

Extensions
The fixed portion of the Registration Request is followed by one or more Extensions. The Mobile-Home Authentication Extension must be included in all Registration Requests.

The format of the Mobile IP Registration Reply header is shown in the following illustration:

Type
Type=3 specifies a registration reply.

Code
A value indicating the result of the registration request. The following values are defined for use within the Code field.
Registration successful:
0 Registration accepted
1 Registration accepted, but simultaneous mobility bindings unsupported
Registration denied by the foreign agent:
64 Reason unspecified
65 Administratively prohibited
66 Insufficient resources
67 Mobile node failed authentication
68 Home agent failed authentication
69 Requested Lifetime too long
70 Poorly formed Request
71 Poorly formed Reply
72 Requested encapsulation unavailable
73 Requested Van Jacobson compression unavailable
80 Home network unreachable (ICMP error received)
81 Home agent host unreachable (ICMP error received)
82 Home agent port unreachable (ICMP error received)
88 Home agent unreachable (other ICMP error received)
Registration denied by the home agent:
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
131 Mobile node failed authentication
132 Foreign agent failed authentication
133 Registration Identification mismatch
134 Poorly formed Request
135 Too many simultaneous mobility bindings
136 Unknown home agent address

Life Time
Life Time. If the Code field indicates that the registration was accepted, the Lifetime field is set to the number of seconds remaining before the registration is considered expired. A value of zero indicates that the mobile node has been deregistered. A value of 0xffff indicates infinity. If the Code field indicates that the registration was denied, the contents of the Lifetime field are unspecified and must be ignored on reception.

Other fields are as in registration request.

Interested in more details about testing this protocol?