<<

. 22
( 132 .)



>>

SMS traffic
session control context 1 context 2



Signalling SMS Packet Data Packet Data




NSAPI
SNDCP
SAPI
Logical Link Control
TLLI
RLC over BSS or BSSGP over Gb


Figure 4.12 Subnetwork-dependent convergence protocol
4.6 GPRS PROTOCOLS 99


different NSAPIs; however, it is possible for them to be associated with a single SAPI at
the LLC layer.
As can be seen from Figure 4.13, there are two separate frame formats, Figure 4.13(a)
shows the frame for the acknowledged mode transfer while Figure 4.13(b) shows the
frame for the unacknowledged mode. When using acknowledged mode the SNDCP layer
will buffer network layer N-PDU packets and keep them until all segments (SN-PDU) of
the N-PDU packet have been acknowledged by the receiving entity. In unacknowledged
mode, as soon as the N-PDU packets have been passed to the LLC layer for transmission
the packet is immediately discarded. The SNDCP will request the lower LLC layer to
transfer acknowledged data using the acknowledged frame format; it is the responsibil-
ity of the LLC to ensure that the data arrives in the correct order. During this request
the SNDCP can request QoS requirements such as precedence class, peak throughput
and the delay class in the SGSN as well as indicate the peak throughput of the mobile
device. A radio priority class can also be established for the mobile device, which will
be used by the RLC/MAC layer for data transfer. When unacknowledged data transfer
is requested, the QoS parameters at both the SGSN and mobile device will also include
a reliability classi¬cation which indicates whether the LLC layer should use protected
or unprotected mode2 and whether the RLC/MAC layer should use acknowledged or
unacknowledged mode.
The ¬elds of the frames shown in Figure 4.13 are de¬ned as follows:

• Spare bit (X): this is set to 0 by the transmitting SNDCP entity and ignored at the
receiver.
• First segment indicator (F): this bit is 1 if this is the ¬rst segment part of the N-PDU.
It indicates that the DCOMP, PCOMP and N-PDU number ¬elds are included in the
packet. It also indicates that there are more segments to follow. If this bit is 0 it indicates
that this is not the ¬rst segment part of the N-PDU and that data is to follow directly,
i.e. there are no DCOMP, PCOMP and N-PDU number ¬elds.


byte 1
X F T M NSAPI

byte 1 byte 2
X F T M NSAPI DCOMP PCOMP
N-PDU No.
byte 2 byte 3
DCOMP PCOMP Segment No.
Unack mode
byte 3 byte 4
N-PDU No. - Acknowledged mode N-PDU No. - Unacknowledged mode


Data segment Data segment
byte n byte n

a) b)

Figure 4.13 SNDCP frame formats

2
The LLC layer can detect errors in frames and depending on whether protected or unprotected
mode is being used will either discard or deliver the erroneous frame.
100 GENERAL PACKET RADIO SERVICE


• SN-PDU type (T): a 0 indicates that this is an SN-DATA (acknowledged) frame while
a 1 indicates that this is an SN-UNITDATA (unacknowledged) frame.
• More bit (M): since an N-PDU may consist of a number of SN-PDUs (segments), the
last one of these segments has to be indicated so that the N-PDU can be reassembled.
A 0 indicates that this segment is the last one of the N-PDU, while a 1 indicates that
there are more segments to follow.
• NSAPI: indicates which PDP context the SN-PDU is associated with since a number
of PDP contexts may share the same logical link connection.
0 This is an escape mechanism for future extensions
1 Point-to-multipoint multicast (PTM-M) information
2“4 Reserved for future use
5“15 Dynamically allocated NSAPI values, allowing for a maximum of 11 contexts.
• Data compression coding (DCOMP): this is only present in the ¬rst segment.
0 No compression
1“14 This points to the data compression identi¬er that has been dynamically negotiated
15 Reserved for future extensions.
• Protocol control information compression coding (PCOMP): this is only present in the
¬rst segment.
1 No compression
1“14 This points to the protocol control information compression identi¬er that has
been dynamically negotiated
15 Reserved for future extensions.
• Segment number: only required in unacknowledged mode. Since the LLC mechanism
will ensure delivery order in ack mode
0“15 Sequence number for segments carrying an N-PDU.
• N-PDU number “ acknowledged mode
0“255 number of the N-PDU.
• N-PDU number “ unacknowledged mode
0“255 number of the N-PDU.


4.6.3 Logical link control (LLC)
The LLC provides a reliable link between the mobile device and the SGSN for both
control and user data. It supports variable length information ¬elds from 140 bytes up to
a maximum of 1520 bytes for the payload and can transfer data and control messages,
which may or may not be encrypted. The LLC protocol supports both acknowledged and
unacknowledged modes of operation with the ability to also reorder frames that have
been received out of sequence. This could occur, for example, in the case of retrans-
mission of frames with errors. It is designed to be independent of the underlying radio
protocols to enable different radio solutions to be adopted. In the control plane LLC car-
ries GPRS mobility management (GMM) messages, such as attach, authentication, and
session management (SM) information, such as PDP context activation, as well as also
transporting SMS messages to the higher layers. In the user plane, LLC frames carry the
4.6 GPRS PROTOCOLS 101


SNDCP packets which will contain the user data such as IP packets. Figure 4.9 shows
how a single LLC is used for transporting signalling, SMS and different data connections
concurrently. An LLC connection is identi¬ed by a datalink connection identi¬er (DLCI).
This consists of the service access point identi¬er (SAPI) and the temporary logical link
identi¬er (TLLI) of the mobile device.
As was seen previously, in GSM for security reasons, the transfer of the user IMSI is
minimized, and thus a TMSI, assigned by the VLR, is used instead. In GPRS, the SGSN
will assign a user the equivalent for the packet network, known as a P-TMSI. Like a
TMSI, this is a 4-byte number, with local signi¬cance only. The mobile device will build
a TLLI from the P-TMSI and use this TLLI to refer to itself in subsequent transactions
with the network. This TLLI is a 32-bit number and uniquely de¬nes the logical link
between the mobile device and the SGSN. The mobile can build three different types of
TLLI: local, foreign and random. A local TLLI is derived from the P-TMSI allocated by
the SGSN in the current routing area (see later) and is therefore valid only within that
area. A foreign TLLI is derived from a P-TMSI from a different routing area. A random
TLLI is built if there is no P-TMSI available. Figure 4.14, shows how each is built.
The SAPI is carried within the LLC frame header and de¬nes the particular SAP
within the mobile device and SGSN with which it is associated. Since the TLLI is used
to uniquely identify the mobile device, it is therefore required to be present. However,
it can be seen from Figure 4.15 that there is no TLLI ¬eld within the LLC header. The
underlying BSSGP (between the BSC and SGSN) and the RLC/MAC (between mobile
device and BSC) during contention periods are required to transport the TLLI information
that uniquely identi¬es the mobile device.

31 30 29 0
local 1 1 bits 29-0 of P-TMSI

31 30 29 0
foreign 1 0 bits 29-0 of P-TMSI

31 30 29 28 27 26 0
random 0 1 1 1 1 chosen randomly

Figure 4.14 Format of the TLLI

8 1 S-frame
8 1
PD C/R X X SAPI 1 0 A X X N(R)
N(R) S1 S2
Control information
I-frame
Information Field variable in length up to
0 A X N(S)
1520 bytes N(S) X N(R)
N(R) S1 S2
CRC, 3 bytes long
UI-frame
1 1 0 X X N(U)
E PM
N(U)
U-frame
1 1 1 P/F M4 M3 M2 M1

Figure 4.15 LLC frame format
102 GENERAL PACKET RADIO SERVICE


4.6.3.1 Unacknowledged mode
For this mode of operation an entity may initiate transmissions to a peer entity without
having established a logical connection. The LLC does not guarantee in-order delivery of
the frames and no error recovery procedures are de¬ned. The LLC can however detect
errors in a received frame, and depending on whether protected or unprotected mode
has been used for the transmission will either discard or deliver the frame with errors.
Recall that data has no tolerance of errors so an indication of errors being present is
generally what is required, rather than a measure of how many errors are present. In
protected mode, a frame check sequence (FCS) in the form of a CRC covers both the
frame header and information ¬eld. In unprotected mode, on the other hand, the CRC
check covers the header and only the ¬rst 4 bytes of the information ¬eld, corresponding
to the maximum length of a SNDCP segment PDU header. The rest of the information is
unprotected and permits applications which can tolerate errors to receive frames that may
have errors. There is also no ¬‚ow control for this transfer option. The frame format used
is the numbered uncon¬rmed information (UI) frame. This mode of operation is referred
to as asynchronous disconnected mode (ADM). Unacknowledged mode of operation is
speci¬ed for all SAPIs that are not reserved, as indicated in Table 4.4. Both GPRS mobility
management and SMS messages use this mode for transfer.


4.6.3.2 Acknowledged mode
In the acknowledged mode, each sending entity is responsible for the organization of its
data ¬‚ow and for error recovery procedures. To enable this, the link needs to be ¬rst
established using the set asynchronous balanced mode (SABM) command. The frame
format used is the numbered information (I) frame and the frames are acknowledged at
the LLC layer. Procedures are speci¬ed for both retransmission of any frames that are

Table 4.4 SAPI identi¬ers
Value SAPI Service description SAP name Mode
0 0000 Reserved
1 0001 GPRS mobility management LLGMM Unack
2 0010 Tunnelling of messages 2 TOM2 Unack
3 0011 User data 3 LL3 Ack/Unack
4 0100 Reserved
5 0101 User data 5 LL5 Ack/Unack
6 0110 Reserved
7 0111 SMS LLSMS Unack
8 1000 Tunnelling of messages 8 TOM8 Unack
9 1001 User data 9 LL9 Ack/Unack
10 1010 Reserved
11 1011 User data 11 LL11 Ack/Unack
12 1100 Reserved
13 1101 Reserved
14 1110 Reserved
15 1111 Reserved
4.6 GPRS PROTOCOLS 103


unacknowledged as well as for ¬‚ow control. This mode of operation is referred to as
asynchronous balanced mode (ABM) and provides a reliable in-order delivery service.
This mode of operation is allowed for all SAPIs that are not reserved except for SAPIs
1, 2, 7 and 8 (see Table 4.4).


4.6.3.3 LLC frame formats and procedures

The LLC frames that are received will have different SAPIs to indicate what is being
transported. For example, SAPI 1 is reserved for mobility management as shown in
Table 4.4.
Figure 4.15 shows the format of the LLC header, and its ¬elds are now described.
The protocol discriminator (PD) bit in the frame address header should be set to a
logic 0 to indicate that this is an LLC frame; if it is set to 1 the frame will be treated as
an invalid frame.
The command/response (C/R) bit indicates whether this is a command or a response
to a command. The options are highlighted in Table 4.5.
The SAPI identi¬es the address of the higher layer services, to which this frame should
be sent. There are 4 bits set aside for SAPI addresses and thus there can be a maximum of
16 SAPIs. A number of these are reserved and Table 4.4, correlates the addresses to the
speci¬c SAPI entities. The service access point (SAP) name identi¬es the actual service
that is associated with the particular logical link frame.
It can be seen that there are four separate SAPs for user data. Each one of these can be
assigned a different QoS. There are also two SAPs for tunnelling of messages. These give
high and low priority to the messages being transferred. The tunnelling of messages is
an optional procedure which uses the LLC unacknowledged mode of operation to tunnel
non-GSM messages such as EIA/TIA-136 messages.
There are four types of control ¬eld:

• Supervisory (S frame) frames are used to perform LLC functions. They can acknowledge
I frames using the sequence number of the received frame, N(R), and also temporarily
suspend I frame transmission. The acknowledge request bit (A) is set to logic 1 by the
sender if an acknowledgement is required, and to 0 if no acknowledgement is required.
The S frame is sent if there is no information ¬eld data that needs to be transferred.
• Con¬rmed information transfer (I frame) where there is a sequence number for both
the sent frames, N(S), and the received frames, N(R). Each I frame also contains a
supervisory (S frame) and is sometimes referred to as an I + S frame.

Table 4.5 C/R values
Type Direction C/R
Command SGSN to UE 1

<<

. 22
( 132 .)



>>