<<

. 25
( 132 .)



>>

then the mobility management procedure will be used.
• If the purpose of the packet access procedure is to send a measurement report or a
packet pause message then the single block without TBF establishment will be used.


4.6.4.3 Contention resolution
Contention resolution is an important part of the RLC/MAC operation since a single
channel can be used for the transfer of a number of LLC frames, and thus two mobile
devices may perceive that a channel is allocated to both of them. It applies to both
dynamic as well as ¬xed allocation methods of operation. Since there are two basic
access possibilities, one-phase and two-phase, they are dealt with separately. The two-
phase access is inherently immune from contention since the second access phase, packet
resource request, addresses the mobile device by its TLLI. Since the same TLLI is included
in the downlink packet uplink/downlink assignment message, no mistake can be made.
The one-phase access method, however, is more insecure in its action and an effective
contention resolution mechanism needs to be introduced. The ¬rst part of the solution
requires identi¬cation of the mobile device. This is already necessary to establish a TBF
on the network side and also to take into consideration the multislot capability of the
device. By including the TLLI in the uplink ACK/NACK messages, the network is noti¬ed
of to whom the allocation belongs. This message needs to be sent early (even before the
receive window for RLC/MAC is full) as contention is resolved after the ¬rst occurrence
of this ACK/NACK message.
While contention resolution is ongoing, the mobile device will use its TLLI to uniquely
identify itself within every RLC data block that is sent within the TBF. The TLLI is
32 bits long and as such introduces signi¬cant overhead. However, to alleviate this, once
the contention resolution has completed, the TLLI need not be transmitted within the RLC
data block. The network will reply with a packet uplink ACK/NACK message, which will
include the same TLLI value that the mobile device has used.
114 GENERAL PACKET RADIO SERVICE


For one-phase access, contention resolution on the network side is assumed to be
successfully completed once the network receives an RLC data block which contains
both the TLLI identifying the mobile device and the TFI value that has been associated
with the TBF. The mobile device assumes contention resolution is successfully completed
when it receives a packet uplink ACK/NACK message which includes the same TLLI value
that the mobile device has sent in the initial RLC block and the TFI associated with the
uplink TBF.
For two-phase access the contention resolution is assumed to be complete when the
network receives a TLLI value identifying the mobile device as part of the contention
resolution procedure. The mobile device assumes contention resolution is successfully
completed when it receives a packet uplink assignment message which includes the same
TLLI value that the mobile device has sent included in the packet resource request and
its additional MS capabilities messages.


4.6.4.4 RLC/MAC frame format
Figures 4.24 and Figure 4.25, show the frame format for RLC/MAC data and control
frames. The ¬elds of each are explained below.

Data ¬elds

• Payload type (PT): this 2-bit ¬eld indicates whether this is a data (00) or a control (01)
block. A value of 10 in the downlink indicates a control block with the inclusion of
the optional header. All other values are reserved.

Payload Countdown
SI R MAC
Type value
X PI TFI TI byte 1
Payload
RRBP S/P USF MAC BSN E byte 2
Type
FB byte 1
PR TFI M E byte 3
Length Indicator
I
...




BSN E byte 2
byte M
Length Indicator M E
byte 3 (optional)
Length Indicator M E
(optional)
byte M+1
(optional)
TLLI (32 bits)
...




byte M byte M+5
Length Indicator M E E
PFI
(optional) (optional)
byte M+1 byte M+6
RLC DATA RLC DATA
byte N byte N

Downlink Uplink

Figure 4.24 RLC/MAC data block
4.6 GPRS PROTOCOLS 115


Payload
MAC
RRBP S/P USF
Type
RB
RTI FS AC byte 1
SN
Payload MAC
Spare R
Type
PR TFI D byte 2
byte 1
byte M
Control Message Contents
Control Message Contents
byte 22
byte 22
Downlink Uplink

Figure 4.25 RLC/MAC control block


• Relative reserved block period (RRBP): this 2-bit ¬eld speci¬es a reserved block that
the mobile device may use for a packet control acknowledgement message or a PACCH
block.
• Supplementary/polling (S/P): a 0 in this single-bit ¬eld indicates that the RRBP ¬eld
is not valid and a 1 indicates that it is.
• Uplink status ¬‚ag (USF): the USF consists of 3 bits and is sent in all downlink RLC
blocks to indicate the owner of the next uplink radio block on the same time slot.
• Power reduction (PR): this 2-bit ¬eld indicates the power level reduction of the current
RLC block as compared to the power of the BCCH. A value of 0 indicates 0“2 dB, 1
indicates 4“6 dB and 2 indicates 8“10 dB less than the BCCH. A value of 3 is unused.
• Temporary ¬‚ow identity (TFI): this 5-bit ¬eld identi¬es the TBF within which this
block belongs.
• Final block indicator (FBI): this single-bit ¬eld indicates the last downlink RLC data
block. A 0 indicates that there are more blocks to come whereas a 1 indicates that this
is the last block in this TBF.
• Block sequence number (BSN): this 7-bit ¬eld carries the sequence number of the RLC
block (mod 128) within the TBF.
• Extension (E): this single-bit ¬eld indicates the presence of the optional byte in the
data block header. A 0 indicates that an extension byte follows.
• Length indicator (LI): this 6-bit ¬eld is used to delimit LLC PDUs within a single RLC
data block by identifying the last byte of the LLC PDU.
• More (M): this single bit, along with the E bit and the LI, is used to delimit LLC PDUs
within a TBF. It identi¬es whether or not another LLC PDU follows the current one
within a single RLC data block.
• Countdown value (CV): this 4-bit ¬eld is sent by the mobile device to allow the network
to calculate the number of RLC blocks remaining in the current uplink TBF.
• Stall indicator (SI): this single-bit ¬eld indicates whether the mobile station™s RLC
transmit window can advance or not. A 0 indicates that the window is not stalled.
• PFI indicator (PI): this single-bit ¬eld indicates the presence of the optional PFI ¬eld.
A 0 indicates that it is not present.
116 GENERAL PACKET RADIO SERVICE


• TLLI indicator (TI): this bit indicates whether the TLLI ¬eld is present or not. A 0
indicates that the TLLI is not present.
• Temporary logical link identi¬er (TLLI): this 32-bit ¬eld is optional and is used while
contention resolution is required.
• Packet ¬‚ow identi¬er (PFI): this 7-bit ¬eld is assigned by the SGSN and used to identify
a particular ¬‚ow and QoS value. Legitimate identi¬ers can be: best effort, signalling,
SMS or dynamically assigned.
• RLC data: this ¬eld contains the LLC PDU or part of it if it has been segmented. The
amount of data transferred depends on whether there are any optional RLC headers
in place and also on the coding scheme used. Table 4.7 indicates the number of bytes
each coding scheme can carry.

Control ¬elds

• Reduced block sequence number (RBSN): used to indicate the sequence number of the
downlink RLC control blocks.
• Radio transaction identi¬er (RTI): this 5-bit ¬eld is used to group downlink control
blocks which make up a single message.
• Final segment (FS): this single-bit ¬eld is used in downlink control blocks to indicate
the ¬nal segment of a control message. A 0 indicates that this is not the ¬nal segment.
• Address control (AC): this single bit indicates the presence of the optional PR/TFI/D
byte in the downlink control block. A 0 indicates that this byte is not present.
• Direction (D): this single-bit ¬eld indicates whether the TBF identi¬ed in the downlink
control block TFI ¬eld is for an uplink (0) or downlink (1) TBF.
• Retry (R): this single-bit ¬eld indicates whether the mobile station has sent the channel
packet request message more than once. A 0 indicates that it was sent once and a 1
indicates that it was sent multiple times.


4.6.4.5 Summary of roles of SNDCP, LLC and RLC/MAC
The SNDCP is used to transfer data packets between the mobile device and the SGSN. It
is capable of multiplexing a number of channels onto the underlying LLC. It also provides
for compression of both the header and data.

Table 4.7 Number of bytes each coding
scheme can carry
Coding scheme Bytes of LLC data
CS-1 20
CS-2 30
CS-3 36
CS-4 50
4.6 GPRS PROTOCOLS 117


The datalink between the mobile device and the network is split into two separate
sublayers, the LLC between the mobile device and the SGSN and the RLC/MAC between
the mobile device and the BSS. The LLC provides both acknowledged and unacknowl-
edged modes of operation between the mobile device and the SGSN. It includes ¬‚ow con-
trol, error detection/correction through ARQ retransmissions and encryption of the data.
The RLC/MAC layer uses the services of the physical layer for information transfer.
It handles the segmentation and reassembly of LLC PDUs between the mobile device
and the BSC. Its functions include backward error correction through the use of selective
retransmissions and arbitration of resources between multiple mobile devices across the
shared medium. The MAC enables a single mobile device to use several physical chan-
nels in parallel. The RLC/MAC provides two methods of operation, acknowledged and
unacknowledged modes.


4.6.5 GPRS radio protocol
Since the air interface is particularly unreliable, extra error checking and correction bits
are added to the data. However, since this plus the data needs to ¬t into a transfer size
of 456 bits, the amount of coding reduces the space remaining for data, and hence the
throughput. In Table 4.8, the radio block (DATA) indicates the amount of subscriber data
transferred. As can be seen from the table, when a subscriber is using CS-1, there are
181 bits of user data being transferred in the 456-bit block. This user data is data at
the RLC/MAC layer and therefore includes their associated headers. The BCS bits are a
block check sequence which checks for errors, and the size of this ¬eld depends on the
coding scheme used.
CS-1, CS-2, and CS-3 all use 1/2 rate convolution coding to increase the reliability of
the data transfer and are therefore multiplied by 2; CS-4 does not use convolution coding,
but merely error checking using a CRC ¬eld. The error checking and correction for CS-2
and CS-3 introduce too many bits for the RLC frame, therefore puncturing is required.
Puncturing simply reduces the number of bits to 456 so that the frame will ¬t into the
four bursts. It does this by removal of non-critical error correction bits. The code rate
gives an indication of the amount of subscriber data within the frame; for example, for
CS-1, two bits of information are required at this layer to transfer one bit of subscriber
data. It is therefore 50% ef¬cient. For CS-4 we can see that the ef¬ciency has risen to
100% at this particular layer. However, there is a lack of error checking/correction and
in cells with high interference, using CS-4 will most likely reduce overall throughput.

Table 4.8 Coding scheme bit details
Coding Code USF Pre-code Radio block BCS Tail Coded bits Punctured Data rate
scheme rate USF (DATA) bits (kbps)
1
CS-1 3 3 181 40 4 456 0 9.05
2
≈2
CS-2 3 6 268 16 4 588 132 13.4
3
≈3
CS-3 3 6 312 16 4 676 220 15.6
4
CS-4 1 3 12 428 16 “ 456 0 21.4
118 GENERAL PACKET RADIO SERVICE


Table 4.9 Physical layer interaction with coding schemes
Coding Layer
scheme
Information Block coding Convolution code

40 + 0 + 4 = 228
CS-1 184 456
16 + 3 + 4 = 294
CS-2 271 588
16 + 3 + 4 = 338
CS-3 315 676
16 + 9 + 0 = 456
CS-4 431 456




Table 4.9 shows the information bits (including the RLC/MAC and USF) and how
extra bits are added at the various entities within Layer 1. As can be seen, the block

<<

. 25
( 132 .)



>>