Click here for more information on GPRS decoding and
analysis.
GPRS (general packet radio service) is used as a
data services upgrade to any GSM network. It allows GSM networks to
be truly compatible with the Internet. GPRS uses a packet-mode
technique to transfer bursty traffic in an efficient manner. It
allows transmission bit rates from 9.6 Kbps to more than 150 Kbps
per user.
The two key benefits of GPRS are a better use of
radio and network resources and completely transparent IP support.
GPRS optimizes the use of network and radio resources. It uses radio
resources only when there is data to be sent or received. As a true
packet technology it allows end user applications to only occupy the
network when a payload is being transferred, and so is well adapted
to the very bursty nature of data applications. Another important
feature of GPRS is that it provides immediate connectivity and high
throughput.
Applications based on standard data protocols
such as IP and X.25 are supported. In GPRS four different quality of
service levels are supported. To support data applications GPRS
utilizes several new network nodes in addition to the network nodes
in the GSM PLMN. These nodes are responsible for traffic routing and
other interworking functions with external packet-switched data
networks, subscriber location, cell selection, roaming and many
other functions that any cellular network needs for
operation.
GPRS in relation to the
OSI model
Protocols described here include:
See SS7 for a
description of SS7 protocols. See Cellular for
a description of GSM protocols.
NS
GSM 08.16 version 6.1.0 http://www.etsi.fr/
The Network Service performs the transport of NS
SDUs between the SGSN (serving GPRS support node) and BSS (base
station system). Services provided to the NS user
include:
- Network Service SDU transfer. The Network
Service entity provides network service primitives allowing for
transmission and reception of upper layer protocol data units
between the BSS and SGSN. The NS SDUs are transferred in order by
the Network Service, but under exceptional circumstances order may
not be maintained.
- Network congestion indication. Congestion
recovery control actions may be performed by the Sub-Network
Service (e.g. Frame Relay). Congestion reporting mechanisms
available in the Sub-Network Service implementation shall be used
by the Network Service to report congestion.
- Status indication. Status indication shall be
used to inform the NS user of the NS affecting events e.g. change
in the available transmission capabilities.
NS PDUs are of the following format:
1 byte |
PDU type |
Other Information
Elements |
NS PDU
structure
PDU type PDU type
may
be: NS-ALIVE NS-ALIVE-ACK NS-BLOCK NS-BLOCK-ACK NS-RESET NS-RESET-ACK NS-STATUS NS-UNBLOCK NS-UNBLOCK-ACK NS-UNITDATA
Information Elements The particular IEs present in a PDU depend on the PDU
type. The structure of IEs is as shown here:
1 byte |
Information element ID (IEI) |
Length indicator |
Information element
value |
NS IE
structure
Information element ID The first octet of an information element having the TLV
format contains the IEI of the information element. If this octet
does not correspond to an IEI known in the PDU, the receiver assumes
that the next octet is the first octet of the length indicator
field. This rule allows the receiver to skip unknown information
elements and to analyze any following information
elements.
Length indicator Information elements may be variable in length. The
length indicator is one or two octets long, the second octet may be
absent. This field consists of the field extension bit, 0/1 ext, and
the length of the value field which follows, expressed in octets.
The field extension bit enables extension of the length indicator to
two octets. Bit 8 of the first octet is reserved for the field
extension bit. If the field extension bit is set to 0 (zero), then
the second octet of the length indicator is present. If the field
extension bit is set to 1 (one), then the first octet is the final
octet of the length indicator.
Information element value The following IEs may be present depending on the PDU
type: Cause NS-VCI NS PDU BVCI NSEI
BSSGP
GSM 08.18 version 6.1.0 http://www.etsi.fr/
The NS transports BSS (base station system) GPRS
protocol PDUs between a BSS and an SGSN (serving GPRS support node).
The primary functions of the BSSGP include:
- Provision by an SGSN to a BSS of radio
related information used by the RLC/MAC function (in the
downlink).
- Provision by a BSS to an SGSN of radio
related information derived from the RLC/MAC function (In the
uplink).
- Provision of functionality to enable two
physically distinct nodes, an SGSN and a BSS, to operate node
management control functions.
BSSGP PDUs are of the following
format:
1 byte |
PDU type |
Other Information
Elements |
NS PDU
structure
BSSAP+
http://www.etsi.org/ GSM 09.18 version
7.1.0 release 1998
BSSAP+ defines use of mobile resources when
a mobile station supports both GSM circuit switched services and GSM
packet switched services. It defines procedures used on the Serving
GPRS Support Node (SGSN) to Visitors Location Register (VLR) for
interoperability between circuit and packet switched services. Layer
3 messages on the Gs interface are defined.
BSSAP+ |
|
BSSAP+ |
SCCP |
|
SCCP |
MTP
L3 |
|
MTP
L3 |
MTP
L2 |
|
MTP
L2 |
L1 |
|
L1 |
SGSN |
Gs |
MSC/VLR |
BSSAP+ protocol layer
structure over Gs
interface |
The Gs interface connects the databases in
the MSC/VLR and the SGSN. The procedures the of BSSAP+ protocol are
used to co-ordinate the location information of MSs that are IMSI
attached to both GPRS and non-GPRS services. The Gs interface is
also used to convey some circuit switched related procedures via the
SGSN.
The basis for the interworking between a
VLR and an SGSN is the existence of an association between those
entities per MS. An association consists of the SGSN storing the
number of the VLR serving the MS for circuit switched services and
the VLR storing the number of the SGSN serving the MS for packet
switched services. The association is only applicable to MSs in
class-A mode of operation and MSs in class-B mode of
operation.
All the messages in BSSAP+ use the SCCP
class 0 connectionless service.
When the return option in SCCP is used and
the sender receives an N_NOTICE indication from SCCP, the sending
entity reports to the Operation and Maintenance system (see ITU-T
Q.714).
The behaviour of the VLR and the SGSN
entities related to the Gs interface are defined by the state of the
association for an MS. Individual states per association, i.e. per
MS in class-A mode of operation and MS in class-B mode of operation,
are held at both the VLR and the SGSN.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
Message type |
1 |
Information elements |
2-n |
BSSAP+ beader structure |
|
The message type uniquely identifies the
message being sent. The following BSSAP+ message types
exist:
Value |
Message type |
00000000 |
Unassigned: treated as an unknown
Message type. |
00000001 |
BSSAP+-PAGING-REQUEST. |
00000010 |
BSSAP+-PAGING-REJECT |
00000011 |
|
to |
|
00001000 |
Unassigned: treated as an unknown Message
type. |
00001001 |
00001001BSSAP+-LOCATION-UPDATE-REQUEST. |
00001010 |
BSSAP+-LOCATION-UPDATE-ACCEPT. |
00001011 |
BSSAP+-LOCATION-UPDATE-REJECT. |
00001100 |
BSSAP+-TMSI-REALLOCATION-COMPLETE. |
00001101 |
BSSAP+-ALERT-REQUEST. |
00001110 |
BSSAP+-ALERT-ACK. |
00001111 |
BSSAP+-ALERT-REJECT. |
00010000 |
BSSAP+-MS-ACTIVITY-INDICATION. |
00010001 |
BSSAP+-GPRS-DETACH-INDICATION. |
00010010 |
BSSAP+-GPRS-DETACH-ACK. |
00010011 |
BSSAP+-IMSI-DETACH-INDICATION. |
00010100 |
BSSAP+-IMSI-DETACH-ACK. |
00010101 |
BSSAP+-RESET-INDICATION. |
00010110 |
BSSAP+-RESET-ACK. |
00010111 |
BSSAP+-MS-INFORMATION-REQUEST. |
00011000 |
BSSAP+-MS-INFORMATION-RESPONSE. |
00011001 |
Unassigned: treated as an unknown Message
type. |
00011010 |
BSSAP+-MM-INFORMATION-REQUEST. |
00011101 |
BSSAP+-MOBILE-STATUS. |
00011110 |
Unassigned: treated as an unknown
Message type. |
00011111 |
BSSAP+-MS-UNREACHABLE. |
Each message type has specific information
elements
00000001 |
IMSI. |
00000010 |
VLR number. |
00000011 |
TMSI. |
00000100 |
Location area
identifier. |
00000101 |
Channel Needed. |
00000110 |
eMLPP Priority. |
00000111 |
Unassigned: treated as an unknown IEI. |
00001000 |
Gs cause. |
00001001 |
SGSN number. |
00001010 |
GPRS location update
type. |
00001011 |
Unassigned: treated as an unknown IEI. |
00001100 |
Unassigned: treated as an unknown IEI.
|
00001101 |
Mobile station classmark
1.
|
00001110 |
Mobile identity.
|
00001111 |
Reject cause.
|
00010000 |
IMSI detach from GPRS service
type.
|
00010001 |
IMSI detach from non-GPRS service
type.
|
00010010 |
Information
requested.
|
00010011 |
PTMSI.
|
00010100 |
IMEI.
|
00010101 |
IMEISV.
|
00010110 |
Unassigned: treated as an unknown IEI.
|
00010111 |
MM information.
|
00011000 |
Cell Global
Identity.
|
00011001 |
Location information
age.
|
00011010 |
Mobile station
state.
|
00011011 |
Erroneous message.
|
00011100
|
|
to
|
|
11111111 |
Unassigned: treated as an unknown
IEI.
|
BCC
3G TS 24.069 version 3.1.0
The Broadcast Call Control (BCC) protocol
is used by the Voice Group Call Service (VGCS) on the radio
interface. It is one of the Connection Management (CM) sublayer
protocols (see GSM 04.07).
Generally a number of mobiles stations (MS)
participate in a broadcast call. Consequently, there is generally
more than one MS with a BCC entity engaged in the same broadcast
call, and there is one BCC entity in the network engaged in that
broadcast call.
The MS ignores BCC messages sent in
unacknowledged mode and which specify as destination a mobile
identity which is not a mobile identity of that MS. Higher layers
and the MM sub-layer decide when to accept parallel BCC transactions
and when/whether to accept BCC transactions in parallel to other CM
transactions.
The broadcast call may be initiated by a
mobile user or by a dispatcher. The originator of the BCC
transaction chooses the Transaction Identifier (TI).
The call control entities are described as
communicating finite state machines which exchange messages across
the radio interface and communicate internally with other protocol
(sub)layers. In particular, the BCC protocol uses the MM and RR
sublayer specified in GSM 04.08. The network should apply
supervisory functions to verify that the BCC procedures are
progressing and if not, take appropriate means to resolve the
problems.
The elementary procedures in the BCC
include:
- Broadcast call establishment procedures,
- Broadcast call termination
procedures
- Broadcast call information phase
procedures
- Various miscellaneous procedures.
All messages have the following
header:
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
Transaction identifier |
Protocol discriminator |
1 |
Message type |
2 |
Information elements |
3-n |
BCC beader structure |
|
Protocol discriminator The protocol discriminator specifies the message
being transferred
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 The
side of the interface initiating a transaction assigns TI values. 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 BCC
message. The message type defines the function of each BCC message.
The following message types exist:
0x110001 |
IMMEDIATE SETUP
|
0x110010 |
SETUP
|
0x110011 |
CONNECT
|
0x110100 |
TERMINATION
|
0x110101 |
TERMINATION REQUEST
|
0x110110 |
TERMINATION REJECT
|
0x111000 |
STATUS
|
0x111001 |
GET STATUS
|
0x111010 |
SET
PARAMETER
|
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.
GCC
3G TS 24.068 version 3.1.0
The Group Call Control (GCC) protocol is
used by the Voice Group Call Service (VGCS) on the radio interface
within the 3GPP system. It is one of the Connection Management (CM)
sublayer protocols (see GSM 04.07).
Generally a number of mobiles stations (MS)
participate in a group call. Consequently, there is in general more
than one MS with a GCC entity engaged in the same group call, and
there is one GCC entity in the network engaged in that group
call.
The MS ignores GCC messages sent in
unacknowledged mode and which specify as destination a mobile
identity which is not a mobile identity of that MS. Higher layers
and the MM sub-layer decide when to accept parallel GCC transactions
and when/whether to accept GCC transactions in parallel to other CM
transactions.
The group call may be initiated by a mobile
user or by a dispatcher. In certain situations, a MS assumes to be
the originator of a group call without being the originator. The
originator of the GCC transaction chooses the Transaction Identifier
(TI).
The call control entities are described as
communicating finite state machines which exchange messages across
the radio interface and communicate internally with other protocol
(sub) layers. In particular, the GCC protocol uses the MM and RR
sublayer specified in GSM 04.08. The network should apply
supervisory functions to verify that the GCC procedures are
progressing and if not, take appropriate means to resolve the
problems.
The elementary procedures in the GCC
include:
- Group call establishment procedures,
- Group call termination procedures
- Call information phase procedures
- Various miscellaneous procedures.
All messages have the following
header:
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
Transaction identifier |
Protocol discriminator |
1 |
Message type |
2 |
Information elements |
3-n |
GCC beader structure |
|
Protocol discriminator The protocol discriminator specifies the message
being transferred
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 The
side of the interface initiating a transaction assigns TI values. 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 GCC
message. The following message types exist:
0x110001 |
IMMEDIATE SETUP
|
0x110010 |
SETUP
|
0x110011 |
CONNECT
|
0x1100100 |
TERMINATION
|
0x110101 |
TERMINATION REQUEST
|
0x110110 |
TERMINATION REJECT
|
0x111000 |
STATUS
|
0x111001 |
GET STATUS
|
0x111010 |
SET
PARAMETER
|
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.
GMM
GSM 04.08 http://www.etsi.org
GPRS uses the GSM MM (Mobility Management)
protocol. Here it is known as the GPRS MM protocol (GMM). The main
function of the MM sub-layer is to support the mobility of user
terminals, for instance, informing the network of its present
location and providing user identity confidentiality. A further
function of the GMM sub-layer is to provide connection management
services to the different entities of the upper Connection
Management (CM) sub-layer.
The format of the header is shown in the
following illustration:
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
Protocol discriminator |
Skip indicator |
1 |
Message type |
2 |
Information elements |
3-n |
GMM beader structure |
|
Protocol
discriminator 1000 identifies the GMM protocol.
Skip
indicator The value of this field is 0000.
Message
type Uniquely defines the function and format of each GMM
message. The message type is mandatory for all messages. 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. GMM message types may be:
0 0 0 0 0 0 0 1 |
Attach request
|
0 0 0 0 0 0 1 0 |
Attach accept
|
0 0 0 0 0 0 1 1 |
Attach complete
|
0 0 0 0 0 1 0 0 |
Attach reject
|
0 0 0 0 0 1 0 1 |
Detach request
|
0 0 0 0 0 1 1 0 |
Detach accept
|
0 0 0 0 1 0 0 0 |
Routing area update
request
|
0 0 0 0 1 0 0 1 |
Routing area update
accept
|
0 0 0 0 1 0 1 0 |
Routing area update
complete
|
0 0 0 0 1 0 1 1 |
Routing area update
reject
|
0 0 0 1 0 0 0 0 |
P-TMSI reallocation
command
|
0 0 0 1 0 0 0 1 |
P-TMSI reallocation
complete
|
0 0 0 1 0 0 1 0 |
Authentication and ciphering
req
|
0 0 0 1 0 0 1 1 |
Authentication and ciphering
resp
|
0 0 0 1 0 1 0 0 |
Authentication and ciphering
rej
|
0 0 0 1 0 1 0 1 |
Identity request
|
0 0 0 1 0 1 1 0 |
Identity response
|
0 0 1 0 0 0 0 0 |
GMM status
|
0 0 1 0 0 0 0 1 |
GMM information
|
|
|
Information
elements Various information elements.
GSM
GSM 04.08 http://www.etsi.org
The main function of the GPRS session
management (SM) is to support PDP context handling of the user
terminal. The SM comprises procedures for: identified PDP context
activation, deactivation and modification, and anonymous PDP context
activation and deactivation.
The format of the header is shown in the
following illustration:
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
Protocol discriminator |
Skip indicator |
1 |
Message type |
2 |
Information elements |
3-n |
GSM beader structure |
|
Protocol
discriminator 1010 identifies the GSM protocol.
Skip
indicator The value of this field is 0000.
Message
type Uniquely defines the function and format of each GSM
message. The message type is mandatory for all messages. 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. GSM message types may be:
0 1 x x x x x x |
Session management
messages
|
0 1 0 0 0 0 0 1 |
Activate PDP context
request
|
0 1 0 0 0 0 1 0 |
Activate PDP context
accept
|
0 1 0 0 0 0 1 1 |
Activate PDP context
reject
|
0 1 0 0 0 1 0 0 |
Request PDP context
activation
|
0 1 0 0 0 1 0 1 |
Request PDP context activation
rej.
|
0 1 0 0 0 1 1 0 |
Deactivate PDP context
request
|
0 1 0 0 0 1 1 1 |
Deactivate PDP context
accept
|
0 1 0 0 1 0 0 0 |
Modify PDP context
request
|
0 1 0 0 1 0 0 1 |
Modify PDP context
accept
|
0 1 0 1 0 0 0 0 |
Activate AA PDP context
request
|
0 1 0 1 0 0 0 1 |
Activate AA PDP context
accept
|
0 1 0 1 0 0 1 0 |
Activate AA PDP context
reject
|
0 1 0 1 0 0 1 1 |
Deactivate AA PDP context
request
|
0 1 0 1 0 1 0 0 |
Deactivate AA PDP context
accept
|
0 1 0 1 0 1 0 1 |
SM
Status
|
Information elements Various information elements.
GTP
specifies a tunnel control and management
protocol which allows the SGSN to provide GPRS network access for an
MS. Signalling is used to create, modify and delete tunnels. In the
transmission plane, GTP uses a tunnelling mechanism to provide a
service for carrying user data packets. The choice of path is
dependent on whether the user data to be tunnelled requires a
reliable link or not.
The GTP protocol is implemented only by
SGSNs and GGSNs. No other systems need to be aware of GTP. GPRS MSs
are connected to a SGSN without being aware of GTP. It is assumed
that there will be a many-to-many relationship between SGSNs and
GGSNs. An SGSN may provide service to many GGSNs. A single GGSN may
associate with many SGSNs to deliver traffic to a large number of
geographically diverse mobile stations.
The GTP header is a fixed format 16 octet
header used for all GTP messages.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
Version |
Reserved |
LFN |
1 |
Message type |
2 |
Length |
3 |
Flow label |
4 |
LLC frame number |
5 |
X |
X |
X |
X |
X |
X |
X |
FN |
6 |
Reserved |
|
TID |
|
GTP header structure |
|
Version Set to 0 to
indicate the first version of GTP
Reserved Reserved
bits for future use, set to 1.
LFN Flag indicating
whether the LLC frame number is included or not.
Message Type Type
of GTP message.
Length Indicates
the length in octets of the GTP message (G-PDU).
Sequence number Transaction identity for signalling messages and an
increasing sequence number for tunnelled T-PDUs.
Flow label Identifies unambiguously a GTP flow.
LLC frame number Used at the Inter SGSN Routing Update procedure to
coordinate the data tranmsission on the link layer between the MS
and the SGSN.
x Spare bits x
indicate the unused bits which are set to 0 by the sending side and
are ignored by the receiving side.
FN Continuation of
LLC frame number.
TID Tunnel
identifier that points out MM and PDP contexts.The format of the TID
is as follows:
5 - 8 |
4 - 1 |
MCC digit 2 |
MCC digit 1 |
MNC digit 1 |
MCC digit 3 |
MSIN digit 1 |
MNC digit 2 |
MSIN digit 3 |
MSIN digit 2 |
MSIN digit 5 |
MSIN digit 4 |
MSIN digit 7 |
MSIN digit 6 |
MSIN digit 9 |
MSIN digit 8 |
NSAPI |
MSIN digit 10 |
TID
Format
MCC, MNC, MSIN digits Parts of the IMSI (defined in GMS 04.08).
NSAPI Network
service access point identifier.
LLC
GSM 04.64 version 6.1.0 http://www.etsi.fr/
LLC defines the logical link control layer
protocol to be used for packet data transfer between the mobile
station (MS) and a serving GPRS support node (SGSN). LLC spans from
the MS to the SGSN and is intended for use with both acknowledged
and unacknowledged data transfer.
The frame formats defined for LLC are based on
those defined for LAPD and RLP. However, there are important
differences between LLC and other protocols, in particular with
regard to frame delimitation methods and transparency mechanisms.
These differences are necessary for independence from the radio
path.
LLC supports two modes of operation:
- Unacknowledged peer-to-peer operation.
- Acknowledged peer-to-peer operation.
All LLC layer peer-to-peer exchanges are in
frames of the following format:
1 byte |
Address |
Control |
Information |
FCS |
LLC
structure
Address The address
field contains the SAPI and identifies the DLCI for which a downlink
frame is intended and the DLCI transmitting an uplink frame. The
length of the address field is 1 byte and it has the following
format:
8 |
7 |
5 6 |
4 - 1 |
PD |
C/R |
XX |
SAPI |
Address
field structure
PD Protocol Discriminator bit indicates whether a frame is
an LLC frame or belongs to a different protocol. LLC frames have the
PD bit set to 0. If a frame with the PD bit set to 1 is received,
then it is treated as an invalid frame.
C/R Identifies a
frame as either a command or a response. The MS side sends commands
with the C/R bit set to 0, and responses with the C/R bit set to 1.
The SGSN side does the opposite; i.e., commands are sent with C/R
set to 1 and responses are sent with C/R set to 0. The combinations
for the SGSN side and MS side are as follows.
Type |
Direction |
C/R
value |
Command |
SGSN side to MS side
|
1 |
Command |
MS side to SGSN
side |
0 |
Response |
SGSN side to MS
side |
0 |
Response |
MS side to SGSN
side |
1 |
XX Reserved.
SAPI Service Access
Point Identifier identifies a point at which LLC services are
provided by an LLE to a layer-3 entity.
Control Identifies
the type of frame. Four types of control field formats are
specified:
- Confirmed information transfer (I
format)
- Supervisory functions (S format)
- Unconfirmed information transfer (UI format)
- Control functions (U format)
Information Contains the various commands and responses.
FCS Frame check
sequence field consists of a 24 bit cyclic redundancy check (CRC)
code. The CRC-24 is used to detect bit errors in the frame header
and information fields.
RLP
GSM 04.22 version 7.0.1
http://www.etsi.fr
The Radio Link Protocol (RLP) for data
transmission over the GSM PLMN covers the Layer 2 functionality of
the ISO OSI reference model. It has been tailored to the needs of
digital radio transmission and provides the OSI data link service.
RLP spans from the Mobile Station (MS) to the interworking function
located at the nearest Mobile Switching Center (MSC) or beyond.
Three versions of RLP exist.
Version 0: |
Single-link basic
version
|
Version 1: |
Single-link extended
version
|
Version 2: |
Multi-link
version.
|
The RLP frames have a fixed length of
either 240 or 576 bits consisting of a header, information field and
an FCS field.
The format of the 240-bit frame is:
Header |
Information |
FCS |
16 bit |
200 bit |
24 bit |
24 bit |
192 bit |
24 bit |
RLP 240-bit
frame format |
The header is 16 bits in versions 0 and 1
and in version 2 (U frames). It is 24 bits in version 2 (S and I+S
frames).
The format of the 576-bit frame
is:
Header |
Information |
FCS |
16 bit |
536 bit |
24 bit |
24 bit |
528 bit |
24 bit |
RLP 576-bit
frame format |
The header is 16 bits in version 1 and
version 2 (U frames), and 24 bits in version 2 (S and I+S)
frames.
Header Contains control information of one
of the following 3 types: unnumbered protocol control information (U
frames), supervisory information (S frames) and user information
carrying supervisory information piggybacked (I+S
frames).
FCS This is
the Frame Check Sequence field. The RLP entity will be in the
Asynchronous Balanced Mode (ABM), which is the data link operation
mode; or Asynchronous Disconnected Mode (ADM), which is the data
link non-operational mode.
Header structure of
versions 0 and 1 N(S) is a bit 4 low order bit and N(R) is
a bit 11 low order bit.
U |
C/R |
X |
X |
1 |
1 |
1 |
1 |
1 |
1 |
P/F |
M1 |
M2 |
M3 |
M4 |
M5 |
X |
S |
C/R |
S1 |
S2 |
0 |
1 |
1 |
1 |
1 |
1 |
|
N(R) |
I+S |
C/R |
S1 |
S2 |
N(S) |
P/F |
N(R) |
Bits
1-16 |
Header structure of
version 2 S is a L2R status Bit, N(S) is a bit 1 low order
bit, N(R) is a bit 14 low order bit and UP is a UP bit.
U |
C/R |
X |
X |
1 |
1 |
1 |
1 |
1 |
1 |
P/F |
M1 |
M2 |
M3 |
M4 |
M5 |
X |
|
|
|
|
|
|
S |
X |
X |
X |
0 |
1 |
1 |
1 |
1 |
1 |
P/F |
S1 |
S2 |
N(R) |
X |
UP |
I+S |
N(S) |
P/F |
S1 |
S2 |
N(R) |
S |
UP |
Bits 1-24 |
|
|
|
|
C/R The
Command Response Bit indicates whether the frame is a command or a
response frame. It can have the following values:
P/F The
Poll/Final bit marks a special instance of command/response
exchange
X Don't
care
Unnumbered Frames
(U) The M1 M2 M3 M4 and M5 bits have the following values
in the U frames according to the type of information
carried:
SABM |
11100
|
UA |
00110
|
DISC |
00010
|
DM |
11000
|
NULL |
11110
|
UI |
00000
|
XID |
11101
|
TEST |
00111
|
REMAP |
10001
|
SABM11100 The Set Asynchronous balance mode
is used either to initiate a link for numbered information transfer
or to reset a link already established.
UA00110 The
Unnumbered Acknowledge is used as a response to acknowledge an SABMM
or DISC command.
DISC00010 The disconnect is used to
disestablish a link previously established for information
transfer.
DM11000 The
disconnected mode encoding is used as a response message.
NULL11110
UI
00000 Unnumbered information signifies that the
information field is to be interpreted as unnumbered
information.
XID11101 Exchange Identification signifies
that the information field is to be interpreted as exchange
identification, and is used to negotiate and renegotiate parameters
of RLP and layer 2 relay functions.
TEST
00111 The information field of this frame is test
information.
REMAP 0001 A
remap exchange takes place in ABM following a change of channel
coding. If an answer is not received within a specific time, then
the mobile end enters ADM.
S and I+S frames
N(S) The
send sequence number contains the number of the I frame.
N(R) The
Receive sequence number is used in ABM to designate the next
information frame to be sent and to confirm that all frames up to
and including this bit and been received correctly.
S S
represents the L2 status bit.
The S1, S2 bits can have the following
significance in the S and I+S frames:
RR |
00
|
REJ |
01
|
RNR |
10
|
SREJ |
11
|
RR Receive
Ready can be used either as a command or a response. It clears any
previous busy condition in that area.
REJ The
Reject encoding is used to indicate that in numbered information
transfer 1 or more out-of-sequence frames have been
received.
RNR The
Receive Not Ready indicates that the entity is not ready to receive
numbered information frames.
SREJ Selective Reject is used to request
retransmission of a single frame.
UP This is
used in version 2 to indicate that a service level upgrading will
increase the throughput.
SNDCP
GSM 04.65 version 6.1.0 http://www.etsi.fr/
Sub-Network Dependant Convergence Protocol
(SNDCP) uses the services provided by the LLC layer and the Session
Management (SM) sub-layer. The main functions of SNDCP
are:
- Multiplexing of several PDPs (packet data
protocol).
- Compression/decompression of user data.
- Compression/decompression of protocol control
information.
- Segmentation of a network protocol data unit
(N-PDU) into LLC protocol data units (LL-PDUs) and re-assembly of
LL-PDUs into an N-PDU.
The SN-DATA PDU is used for acknowledged data
transfer. Its format is as follows:
8 |
7 |
5 |
6 |
4 - 1 |
X |
C |
T |
M |
NSAPI |
DCOMP |
PCOMP |
Data |
SN-DATA PDU
structure
The SN-UNITDATA PDU is used for unacknowledged
data transfer. Its format is as follows:
8 |
7 |
5 |
6 |
4 - 1 |
X |
C |
T |
M |
NSAPI |
DCOMP |
PCOMP |
Segment offset |
N-PDU number |
E |
N-PDU number (continued) |
N-PDU number (extended) |
Data |
SN-UNITDATA
PDU structure
NSAPI Network
service access point identifier. Values may be:
0 |
Escape mechanisms for future
extensions |
1 |
Point-to-mutlipoint multicast
(PTM-M) information |
2-4 |
Reserved for future
use |
5-15 |
Dynamicallly allocated NSAPI
value |
M More bit. Values
may be: 0 Last segment of N-PDU 1 Not the last segment of
N-PDU, more segments to follow.
T SN-PDU type
specifies whether the PDU is SN-DATA (0) or SN-UNITDATA
(1).
C Compression
indicator. A value of 0 indicates that compression fields, DCOMP and
PCOMP, are not included. A value of 1 indicates that these fields
are included.
X Spare bit is set
to 0.
DCOMP Data
compression coding, included if C-bit set. Values are as
follows:
0 |
No compression. |
1-14 |
Points to the data compression
identifier negotiated dynamically. |
15 |
Reserved for future
extensions. |
PCOMP Protocol
control information compression coding, included if C-bit set.
Values are as follows:
0 |
No compression. |
1-14 |
Points to the protocol control
information compression identifier negotiated
dynamically. |
15 |
Reserved for future
extensions. |
Segment offset Segment offset from the beginning of the N-PDU in units
of 128 octets.
N-PDU number 0-2047
when the extension bit is set to 0; 2048-524287 if the extension
bit is set to 1.
E Extension bit for
N-PDU number. 0 Next octet is used for data. 1 Next octet is
used for N-PDU number extensions.
search ][ protocols by family
][
index of
protocols
|