Cellular data communication protocol
 | This article may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
 | This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
The protocols described here are from different cellular data communication protocols.[according to whom?][citation needed]
BSMAP[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
The Base Station Management Application Part (BSMAP) supports all Radio Resource Management and Facility Management procedures between the MSC and the BS, or to a cell(s) within the BS. BSMAP messages are not passed to the MS, but are used only to perform functions at the MSC or the BS. A BSMAP message (complete layer 3 information) is also used together with a DTAP message to establish a connection for an MS between the BS and the MSC, in response to the first layer 3 interface message sent by the MS to the BS for each MS system requests.
BSSLAP[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
BSSLAP defines the SMLC-BSS layer 3 protocol . The following Location Services related messages are exchanged between the SMLC and the BSS, with the VMSC acting as a relay.
On the A interface the messages are contained in the Location Information IE which is encapsulated in the BSSMAP-LE Connection Oriented Information message as specified in 3GPP TS 08.08. On the Ls interface the messages are contained in the Location Information IE which is encapsulated in the BSSMAP-LE Connection Oriented Information message as specified in 3GPP TS 09.31.
The following messages types are available:
| Message | Encoding |
|---|---|
| Reserved | 00000000 |
| TA Request | 00000001 |
| TA Response | 00000010 |
| TOA Request | 00000100 |
| TOA Response | 00000101 |
| Reject | 00001010 |
| Reset | 00001011 |
| Abort | 00001100 |
| TA LAYER3 | 00001101 |
| MS Position Command | 00001111 |
| MS Position Response | 00010000 |
BSSAP[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
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.
Discrimination Distribution between the two sub-protocols: BSSMAP and DTAP.
BSSAPLE[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
BSSAP-LE is an extension to BSSAP that contains messages and parameters specific to the support of LCS. The BSSAP-LE is part of the LB interface. The following subsets of BSSAP-LE are defined: DTAP-LE and BSSMAP-LE. DTAP-LE messages are transferred between an SMLC and a Type A LMU. BSSMAP-LE messages are transferred between a BSC, MSC and SMLC.
The following BSSMAP-LE message types are available:
| Code | Message |
|---|---|
| 0X2B | Perform Location Request |
| 0X2D | Perform Location Response |
| 0X2E | Perform Location Abort |
| 0X1 | LMU Connection Request |
| 0X2 | LMU Connection Accept |
| 0X3 | LMU Connection Reject |
| 0X4 | LMU Connection Release |
| 0X2A | Connection Oriented Information |
| 0X3A | Connectionless Information |
| 0X30 | Reset |
| 0X31 | Reset Acknowledge |
BSSMAP[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
The BSS Management Application Part (BSSMAP) supports all of the procedures between the MSC and the BSS that require interpretation and processing of information related to single calls, and resource management. Some of the BSSMAP procedures result in, or are triggered by, Radio Resource (RR) management messages defined in GSM 04.08.
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.
BTSM[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
BTSM is the Base Station Controller to Base Transceiver Station (BSC - BTS) interface protocol (the A-bis interface). BTSM allows sending messages between the Base Station Controller and the Base Transceiver Station. Protocol messages consist of a series of information elements. For each message there are mandatory information elements and optional information elements. BTSM messages are transmitted on the A-bis interface using the I format of LAPD, except for the Measurement Result message which is sent in UI format.
Message discriminator 1-octet field used in all messages to discriminate between Transparent and Non-Transparent messages and also between Radio Link Layer Management, Dedicated Channel Management, Common Channel Management and TRX Management messages.
Message type Uniquely identifies the function of the message being sent. It is a single octet field.
CC[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
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.
Protocol discriminator[edit]
0011 identifies the CC protocol.
TI flag[edit]
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[edit]
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[edit]
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.
| 0x000000 | Escape to nationally specific message types |
| 0x00 | Call establishment messages: |
| 0001 | ALERTING |
| 1000 | CALL CONFIRMED |
| 0010 | CALL PROCEEDING |
| 0111 | CONNECT |
| 1111 | CONNECT ACKNOWLEDGE |
| 1110 | EMERGENCY SETUP |
| 0011 | PROGRESS |
| 0101 | SETUP |
| 0x01 | Call information phase messages: |
| 0111 | MODIFY |
| 1111 | MODIFY COMPLETE |
| 0011 | MODIFY REJECT |
| 0000 | USER INFORMATION |
| 1000 | HOLD |
| 1001 | HOLD ACKNOWLEDGE |
| 1010 | HOLD REJECT |
| 1100 | RETRIEVE |
| 1101 | RETRIEVE ACKNOWLEDGE |
| 1110 | RETRIEVE REJECT |
| 0x10 | Call clearing messages: |
| 0101 | DISCONNECT |
| 1101 | RELEASE |
| 1010 | RELEASE COMPLETE |
| 0x11 | Miscellaneous messages: |
| 1001 | CONGESTION CONTROL |
| 1110 | NOTIFY |
| 1101 | STATUS |
| 0100 | STATUS ENQUIRY |
| 0101 | START DTMF |
| 0001 | STOP DTMF |
| 0010 | STOP DTMF ACKNOWLEDGE |
| 0110 | START DTMF ACKNOWLEDGE |
| 0111 | START DTMF REJECT |
| 1010 | FACILITY |
DTAP (CDMA)[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
The Direct Transfer Application Part (DTAP) messages are used to transfer call processing and mobility management messages to and from the MS. The BS does not use DTAP messages, but must map messages going to and coming from the MSC into the appropriate air interface signaling protocol. Transaction IDs are used to associate the DTAP messages with a particular MS and the current call. The format of the header is shown in the following illustration:
Protocol discriminator[edit]
TI flag[edit]
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[edit]
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[edit]
The message type defines the function of each DTAP message.
Information elements[edit]
Each information element has a name which is coded as a single octet. The length of an information element may be fixed or variable and a length indicator for each one may be included.
DTAP (GSM)[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
The Direct Transfer Application Part (DTAP) are used to transfer call control and mobility management messages between the MSC and the MS. The DTAP information in these messages is not interpreted by the BSS. Messages received from the MS are identified as DTAP by the Protocol Discriminator Information Element. The majority of radio interface messages are transferred across the BSS MSC interface by DTAP, except for messages belonging to the Radio Resource (RR) management protocol.
The DTAP function is in charge of transferring layer 3 messages from the MS (or from the MSC) to the MSC (or to the MS) without any analysis of the message contents. The interworking between the layer 2 protocol on the radio side and signalling system 7 at the landside is based on the use of individual SCCP connections for each MS and on the distribution function.
Protocol discriminator[edit]
Identifies the L3 protocol to which the standard layer 3 message belongs. Values may be as follows:
| 0000 | Group call control |
| 0001 | Broadcast call control |
| 0010 | PDSS1 |
| 0011 | Call control; call related SS messages |
| 0100 | PDSS2 |
| 0101 | Mobility Management Messages |
| 0110 | Radio resources management messages |
| 1001 | SMS messages |
| 1011 | Non-call related SS messages |
| 1110 | Extension of the PD to one octet length |
| 1111 | Tests procedures described in TS GSM 11.10 |
Transaction ID / Skip identifier[edit]
Either a transaction identifier, or a skip indicator depending on the level 3 protocol. The transaction identifier contains the transaction value and flag which identifies who allocated the TI.
N(SD)[edit]
For MM and CM, N(SD) is set to the value of the send state variable. In other level 3 messages, bit 7 is set to 0 by the sending side. Messages received with bit 7 set to 1 are ignored.
Message type[edit]
Uniquely defines the function and format of each GSM L3 message. The message type is mandatory for all messages. 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).
Information elements[edit]
The message type may be followed by various information elements depending on the protocol.
MM[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
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
Protocol discriminator[edit]
0101 identifies the MM protocol.
Message type[edit]
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.
| 0x00 | Registration messages: | |
| 0001 | IMSI DETACH INDICATION | |
| 0010 | LOCATION UPDATING ACCEPT | |
| 0100 | LOCATION UPDATING REJECT | |
| 1000 | LOCATION UPDATING REQUEST | |
| 0x01 | Security messages: | |
| 0001 | AUTHENTICATION REJECT | |
| 0010 | AUTHENTICATION REQUEST | |
| 0100 | AUTHENTICATION RESPONSE | |
| 1000 | IDENTITY REQUEST | |
| 1001 | IDENTITY RESPONSE | |
| 1010 | TMSI REALLOCATION COMMAND | |
| 1011 | TMSI REALLOCATION COMPLETE | |
| 0x10 | Connection management messages: | |
| 0001 | CM SERVICE ACCEPT | |
| 0010 | CM SERVICE REJECT | |
| 0011 | CM SERVICE ABORT | |
| 0100 | CM SERVICE REQUEST | |
| 1000 | CM REESTABLISHMENT REQUEST | |
| 1001 | ABORT | |
| 0x11 | Miscellaneous messages: | |
| 0001 | MM STATUS |
MMS[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
The WAP Multimedia Messaging Service (MMS) uses WAP WSP/HTTP as underlying protocols to transfer MMS PDUs between the MMS Client, which resides on the terminal (MS) and the MMS Proxy -Relay.
This structure is based on the well-known message structure of Internet email binary encoding of MMS PDUs. Because of the limited bandwidth of the air interface of mobile networks MMS PDUs are transferred between an MMS Client and an MMS Proxy -Relay in binary encoded message format. This process is called encapsulation. WSP PDUs or HTTP messages, which contain MMS PDUs as their body, are used for this transport.
MMS PDUs, which are described in this specification, are included in WSP PDUs/HTTP messages of different types. The entire MMS information is contained in MMS PDUs, which are encapsulated in WSP PDUs/HTTP messages.
The content type of WSP PDUs/HTTP messages containing MMS PDUs is "application/vnd.wap.mms - message."
MMS has no header structure as it consists of messages.
| Field | Reference Number: |
| 0x81 | Bcc |
| 0x82 | Cc |
| 0x83 | X-Mms-Content-Location |
| 0x84 | Content-Type |
| 0x85 | Date |
| 0x86 | X-Mms-Delivery-Report |
| 0x87 | X-Mms-Delivery-Time |
| 0x88 | X-Mms-Expiry |
| 0x89 | From |
| 0x8A | X-mms-Message-Class |
| 0x8B | Message-ID |
| 0x8C | X-Mms-Message-Type |
| 0x8D | X-Mms-MMS-Version |
| 0x8E | X-Mms-Message-Size |
| 0x8F | X-Mms-Priority |
| 0x90 | X-Mms-Read-Report |
| 0x91 | X-Mms-Report-Allowed |
| 0x92 | X-Mms-Response-Status |
| 0x93 | X-Mms-Response-Text |
| 0x94 | X-Mms-Sender-Visibility |
| 0x95 | X-Mms-Status |
| 0x96 | Subject |
| 0x97 | To |
| 0x98 | X-Mms-Transaction-Id |
| 0x99 | X-Mms-Retrieve-Status |
| 0x9A | X-Mms-Retrieve-Text |
| 0x9B | X-Mms-Read-Status |
| 0x9C | X-Mms-Reply-Charging |
| 0x9D | X-Mms-Reply-Charging-Deadline |
| 0x9E | X-Mms-Reply-Charging-ID |
| 0x9F | X-Mms-Reply-Charging-Size |
| 0xA0 | X-Mms-Previously-Sent-By |
| 0xA1 | X-Mms-Previously-Sent-Date |
Message Type[edit]
The following message types are contained in the PDU:
| 128 | m-send-req |
| 129 | m-send-conf |
| 130 | m-notification-ind |
| 131 | m-notifyresp-ind |
| 132 | m-retrieve-conf |
| 133 | m-acknowledge-ind |
| 134 | m-delivery-ind |
| 135 | m-read-rec-ind |
| 136 | m-read-orig-ind |
| 137 | m-forward-req |
| 138 | m-forward-conf |
RR[jargon][edit]
| This section may have been copied and pasted from another location, possibly in violation of Wikipedia's copyright policy. (March 2016) |
| This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2016) (Learn how and when to remove this template message) |
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.
Protocol discriminator[edit]
0110 identifies the RR Management protocol.
Skip identifier[edit]
Value of 0000.
Message type[edit]
Uniquely defines the function and format of each RR message. The message type is mandatory for all messages. RR message types may be:
| 00111- - - | Channel establishment messages: |
| 011 | ADDITIONAL ASSIGNMENT |
| 111 | IMMEDIATE ASSIGNMENT |
| 001 | IMMEDIATE ASSIGNMENT EXTENDED |
| 010 | IMMEDIATE ASSIGNMENT REJECT |
| 00110- - - | Ciphering messages: |
| 101 | CIPHERING MODE COMMAND |
| 010 | CIPHERING MODE COMPLETE |
| 00101- - - | Handover messages: |
| 110 | ASSIGNMENT COMMAND |
| 001 | ASSIGNMENT COMPLETE |
| 111 | ASSIGNMENT FAILURE |
| 011 | HANDOVER COMMAND |
| 100 | HANDOVER COMPLETE |
| 000 | HANDOVER FAILURE |
| 101 | PHYSICAL INFORMATION |
| 00001- - - | Channel release messages: |
| 101 | CHANNEL RELEASE |
| 010 | PARTIAL RELEASE |
| 111 | PARTIAL RELEASE COMPLETE |
| 00100- - - | Paging messages: |
| 001 | PAGING REQUEST TYPE 1 |
| 010 | PAGING REQUEST TYPE 2 |
| 100 | PAGING REQUEST TYPE 3 |
| 111 | PAGING RESPONSE |
| 00011- - - | System information messages: |
| 000 | SYSTEM INFORMATION TYPE 8 |
| 001 | SYSTEM INFORMATION TYPE 1 |
| 010 | SYSTEM INFORMATION TYPE 2 |
| 011 | SYSTEM INFORMATION TYPE 3 |
| 100 | SYSTEM INFORMATION TYPE 4 |
| 101 | SYSTEM INFORMATION TYPE 5 |
| 110 | SYSTEM INFORMATION TYPE 6 |
| 111 | SYSTEM INFORMATION TYPE 7 |
| 00000- - - | System information messages: |
| 010 | SYSTEM INFORMATION TYPE 2bis |
| 011 | SYSTEM INFORMATION TYPE 2ter |
| 101 | SYSTEM INFORMATION TYPE 5bis |
| 110 | SYSTEM INFORMATION TYPE 5ter |
| 00010- - - | Miscellaneous messages: |
| 000 | CHANNEL MODE MODIFY |
| 010 | RR STATUS |
| 111 | CHANNEL MODE MODIFY ACKNOWLEDGE |
| 100 | FREQUENCY REDEFINITION |
| 101 | MEASUREMENT REPORT |
| 110 | CLASSMARK CHANGE |
| 011 | CLASSMARK ENQUIRY |
References[edit]
See also[edit]
This article "Cellular data communication protocol" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Cellular data communication protocol. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.
