|
BSMAP
TIA/EIA/IS-634-A, revision A
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 request.
The format of the header is shown in the
following illustration:
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
Message type |
1 |
Parameter |
2-n |
BSMAP
header structure |
|
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?

BSSLAP
http://webapp.etsi.org/key/queryform.asp 3GPP TS 08.71
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.
- TA Request
- TA Response
- TOA Request
- TOA Response
- Reject
- Reset
- Abort
- TA Layer3
- MS Position Command
- MS Position Response
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 protocol header appears as follows:
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
Message type |
1 |
Information elements |
2-n |
Message Type
The following messages types are available:
| Reserved |
00000000 |
| TA EQUEST |
00000001 |
| TA Response |
00000010 |
| TOA Request |
00000100 |
| TOA Response |
00000101 |
| Reject |
00001010 |
| Reset |
00001011 |
| Abort |
00001100 |
| TA LAYER3 |
00001101 |
| MS Position Command |
00001111 |
| MS Posiiton Response |
00010000 |
Interested in more details about testing this protocol?
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:
1 byte |
1byte |
|
Discrimination |
DLCI |
Length |
BSSAP
header structure |
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?
BSSAPLE
http://webapp.etsi.org/key/queryform.asp. 3GPP TS 09.31 and 3GPP TS 04.71
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 transfered between an SMLC and a Type A LMU. BSSMAP-LE messages are transferred between a BSC, MSC and SMLC.
The header appears as follows:
BSSMAP-LE Header
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
D=0 |
1 |
Length indicator = n |
2 |
BSSMAP-LE Message Contents |
3-n |
DTAP-LE Header
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
D=0 |
1 |
DLCI |
2 |
Length indicator = n |
3 |
DTAP-LE Message Contents |
4-n |
| Discrimination Indicator |
| BSSMAP-LE |
0 |
| DTAP-LE |
1 |
DLCI
The DLCI in octet 2 is applicable only to DTAP-LE messages.
For signaling to a type A LMU using an SDCCH and SAPI=0, the value of the DLCI is 10000000.
Length Indicator
The length indicator is coded in one octet, and is the binary representation of the number of octets of the subsequent BSSMAP-LE or DTAP-LE message parameter.
DTAP-LE Messages
The following DTAP message types are available:
| 0X32 |
REGISTER |
| 0X31 |
FACILITY |
| 0X21 |
RELEASE COMPLETE |
BSSMAP-LE Messages
The following BSSMAP-LE message types are available:
| 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 |
Interested in more details about testing this protocol?
BSSMAP
GSM 08.08 http://www.etsi.fr
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.
The format of the BSSMAP protocol is as follows:
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
Message type |
1 |
Information Element |
2-n |
BSSMAP
header structure |
|
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?
BTSM
GSM 08.58 http://www.etsi.fr
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.
The structure of BTSM messages is shown in
the following diagram:
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
|
Message discriminator |
1 |
|
Message type |
2 |
|
Information elements |
3-n |
| BTSM
structure |
|
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.
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:
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
|
Protocol Distriminator |
Transaction ID |
1 |
|
Message type |
2 |
|
Information elements |
3-n |
| CC
structure |
|
Protocol discriminator
0011 identifies the CC
protocol.
Transaction Identifier
The format of the transaction
identifier is as follows:
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
TI flag |
TI value |
- - - - |
1 |
Transaction
Identifier |
|
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.
| 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 |
Interested in more
details about testing this protocol?
DTAP (CDMA)
TIA/EIA/IS-634-A, revision A
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:
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
|
Transaction identifier |
Protocol discriminator |
1 |
|
Message type |
2 |
|
Information elements |
3-n |
|
DTAP header structure |
|
Protocol discriminator
The protocol discriminator specifies
the message being transferred (CC, MM, RR).
Transaction identifier
Distinguishes multiple parallel activities (transactions) within
one mobile station. The format of the transaction identifier
is as follows:
| 8 |
7 |
6 |
5 |
TI flag |
TI value |
| Transaction
identifier
|
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
The message type defines the function
of each DTAP message.
Information elements
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.
Interested in more
details about testing this protocol?
DTAP (GSM)
GSM 04.08, 08.06, 08.08 http://www.etsi.fr
The Direct Transfer Application Part (DTAP)
is 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.
The format of the DTAP header is shown in
the following illustration:
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
| Protocol Distriminator
|
Transaction / Skip |
1 |
| 0 |
N(SD) |
Message Type |
2 |
| Information Elements
|
3-n |
|
GSM L3 structure |
|
Protocol discriminator
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
Either a transaction
identifier, or a skip indictor depending on the level 3 protocol.
The transaction identifier contains the transaction value
and flag which identifies who allocated the TI.
N(SD)
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
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
The message type may
be followed by various information elements depending on the
protocol.
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
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
|
Protocol distriminator |
Skip indicator |
1 |
| Message type |
2 |
| Information elements
|
3-n |
MM
header structure |
|
Protocol discriminator
0101 identifies the MM
protocol.
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.
| 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 |
Interested in more
details about testing this protocol?
MMS
http://www.openmobilealliance.org/ OMA-MMS-ENC-v1_1-20021030-C.
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
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 |
Interested in more details about testing this protocol?
RR
GSM 04.08 http://www.etsi.fr
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.
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
|
Protocol distriminator |
Skip indicator |
1 |
| Message type |
2 |
| Information elements
|
3-n |
RR
structure |
|
Protocol discriminator
0110 identifies the RR
Management protocol.
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:
| 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 IN FORMATION 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 |
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:
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
|
Protocol distriminator |
Skip indicator |
1 |
| Message type |
2 |
| Information elements
|
3-n |
SMS
CP structure |
|
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:
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
| 0 |
0 |
0 |
0 |
0 |
MTI |
1 |
Message
Reference |
2 |
| Information
elements |
3-n |
SMS
structure |
|
MTI
Message type indicator. Values are as follows:
| Bit Value (3
2 1) |
Direction |
RP-Message |
| 0 0 0 |
ms -> n |
RP-DATA |
| 0 0 0 |
n -> ms |
Reserved |
| 0 0 1 |
ms -> n |
Reserved |
| 0 0 1 |
n -> ms |
RP-DATA |
| 0 1 0 |
ms -> n |
RP-ACK |
| 0 1 0 |
n -> ms |
Reserved |
| 0 1 1 |
ms -> n |
Reserved |
| 0 1 1 |
n -> ms |
RP-ACK |
| 1 0 0 |
ms -> n |
RP-ERROR |
| 1 0 0 |
n -> ms |
Reserved |
| 1 0 1 |
ms -> n |
Reserved |
| 1 0 1 |
n -> ms |
RP-ERROR |
| 1 1 0 |
ms -> n |
RP-SMMA |
| 1 1 0 |
n -> ms |
Reserved |
| 1 1 1 |
ms -> n |
Reserved |
| 1 1 1 |
n -> ms |
Reserved |
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?
SMSTP
ETSI TS 100 901. (You can download
all the ETSI files from www.ETSI.org)
The Short Message Transfer Layer Protocol
(SMSTP) short message point-to-point services comprise two basic
services:
- SM MT (Short Message Mobile Terminated
Point-to-Point).
- SM MO (Short Message Mobile Originated
Point-to-Point).
SM MT denotes the capability of the
GSM system to transfer a short message submitted from the SC
to one MS, and to provide information about the delivery of
the short message either by a delivery report or a failure report
with a specific mechanism for later delivery.
SM MO denotes the capability of the GSM system to transfer a
short message submitted by the MS to one SME via an SC, and
to provide information about the delivery of the short message
either by a delivery report or a failure report.
The message must include the address of that SME to which the
SC will eventually attempt to relay the short message.
The text messages to be transferred by means of the SM MT or
SM MO contain up to 140 octets.
The structure of the SMSTP protocol header is as follows:
| Information Element |
Type/Reference |
Presence |
Format |
Length |
| Message type |
Message type |
M |
V |
1 |
Message Type
The type of messge. The following message
types are available:
SC To MS -
0
1
2
3 |
SMS-DELIVER
SMS-SUBMIT-REPORT
SMS-STATUS-REPORT
Reserved |
MS To SC -
0
1
2
3 |
SMS-DELIVER-REPORT
SMS-SUBMIT
SMS-COMMAND
Reserved |
|