"Signalling in GPRS/EGPRS" - Chapter 03 Um interface – user plane (sample) by Leliwa

3 Um interface – user plane

Chapter 3 Um interface – user plane Topic

Page

PDP .................................................................................................................. 53 SNDCP ............................................................................................................. 54 LLC .................................................................................................................. 60 RLC/MAC........................................................................................................ 78 GSM RF – Physical Layer ............................................................................. 112

Signalling in GPRS/EGPRS

This page is intentionally left blank

3 Um interface – user plane

PDP Packet Data Protocol (PDP) is any protocol which transmits user data as discrete units known as packets, e.g., IP. Currently only IPv4, IPv6 and PPP protocols could be used as PDP in GPRS network. MS

BSS

SGSN

GGSN

App. PDP

PDP SNDCP

SNDCP

GTP

LLC

UDP/TCP

BSSGP

Network Service

N E T

RLC MAC

GSM RF

RLC MAC

---Um--

GSM RF

Physical

---Gb---

Physical

--Gn---

Figure 3-1 Packet Data Protocol (PDP)

IP The Internet Protocol (IP) is nowadays widely used for information exchange between computer networks. It was designed to be media independent and insensitive to network failures. GPRS networks supports both IPv4 and IPv6.

PPP The PPP protocol is specified in RFC 1661. The user plane for the PDP type PPP consists of a PPP protocol stack above SNDCP above GTP in the GGSN. The GGSN either terminates the PPP protocol and access the packet data network at the IP level, or further tunnels PPP PDUs via e.g. L2TP. The PDP type PPP allows subscriber to use different network layer protocols than IP on top of PPP layer (e.g. IPX or AppleTalk).

Signalling in GPRS/EGPRS

SNDCP Network layer protocols are intended to be capable of operating over services derived from a wide variety of subnetworks and data links. GPRS supports several network layer protocols providing protocol transparency for the users of the services. Introduction of new network layer protocols to be transferred over GPRS is possible without any changes to GPRS. Therefore, all functions related to transfer of Network layer Protocol Data Units (N-PDUs) are carried out in a transparent way by the GPRS network entities. This is one of the requirements for GPRS SNDCP. The Subnetwork Dependent Convergence (SNDC) protocol is situated below the network layer and above the Logical Link Control layer in the MS and the SGSN. A variety of network layers are supported, e.g., IPv4, IPv6 and X.25. The network-layer packet data protocols share the same SNDCP that then performs multiplexing of data coming from the different sources to be sent across LLC. This is illustrated in Fig. 3-2. Packet Data Protocol

Packet Data Protocol

N-PDU NSAPI

...

SNDCP SN-PDU SAPI

LLC

Figure 3-2 Multiplexing of network protocols The Subnetwork Dependent Convergence function is defined in terms of offered services and sub-functions. The set of protocol entities above SNDCP consists of commonly used network protocols. They all use the same SNDCP entity, which then performs multiplexing of data coming from different sources to be sent using the service provided by the LLC layer. The Network Service Access Point Identifier (NSAPI) is and index to the PDP context of the PDP that is using the service provided by SNDCP. One PDP may have several PDP contexts and NSAPIs. However, it is possible that each allocated NSAPI is used by separate PDP. Each active NSAPI uses the services provided by the Service Access Point Identifier (SAPI) in the LLC layer. Several NSAPIs may be associated with the same SAPI.

3 Um interface – user plane

Services The SNDC function provides the following services to the network layer: •

Transmission and reception of N-PDUs in acknowledged and unacknowledged LLC mode. In acknowledged mode, the receipt of data is confirmed at the LLC layer, and the data is transmitted and received in order per NSAPI. In unacknowledged mode, the receipt of data is not confirmed at the SNDCP layer or at the LLC layer.

•

Transmission and reception between the MS and SGSN of variablelength N-PDUs.

•

Transmission and reception of N-PDUs between the SGSN and MS according to the negotiated QoS profile.

•

Transfer of the minimum amount of data possible between the SGSN and MS through compression techniques.

The SNDC function requires the following services from the LLC layer: •

Acknowledged and unacknowledged data transfer.

•

Ciphered transmission of SN-PDUs.

•

In-order delivery of SN-PDUs per LLC SAPI.

•

Support for variable-length SN-PDUs.

Subfunctions SNDCP performs the following subfunctions: •

Multiplexing of N-PDUs from one or several NSAPIs onto one LLC SAPI. NSAPIs that are multiplexed onto the same SAPI use the same QoS profile.

•

Compression of redundant protocol control information and user data. This may include e.g., TCP/IP header compression and V.42 bis data compression. Compression may be performed independently for each QoS profile. If several network layers use the same QoS delay and traffic handling priority, then one common compressor may be used for these network layers. Compression parameters are negotiated between the MS and the SGSN. Compression is an optional SNDC function.

•

Segmentation and reassembly. The output of the compression subfunctions are segmented to maximum length LLC frames.

Signalling in GPRS/EGPRS

header

N-PDU

data

SN-DATA.request

Network Layer

SN-UNITDATA.request

SNDCP

compare header to previous header header header big difference small header

Segmented N-PDU #1

delta

M=0 M=1

control compressor

data compressor

segmentation

#3 #2 #1

M=0 M=1 M=1

Segmented N-PDU #2

#2 #1

M=0 M=1

Segmented N-PDU #1

segmentation

M=1

SN-DATA PDU

SN-UNITDATA PDU

LL-DATA.request

LL-UNITDATA.request

LLC header

LLC

LLC header

Figure 3-3 SNDCP model

SNSN-PDU formats Each Subnetwork Packet Data Unit SN-PDU contains an integral number of octets, and comprises a header part and a data part. An SN-PDU contains data from a single N-PDU only. Two different SN-PDU formats are defined. The SN-DATA PDU is used for acknowledged data transfer and SN-UNITDATA PDU for unacknowledged data transfer. Bit

Oct 1

NSAPI

DCOMP

N-PDU number - acknowledged mode

PCOMP

… Data segment N

Figure 3-4 SN-Data PDU format Bit

Oct 1

2 3 4

DCOMP

PCOMP

Segment number

N-PDU number unacknowledged mode

N-PDU number - unacknowledged mode (continued)

… Data segment N

Figure 3-5 SN-Unitdata PDU format 56

NSAPI

3 Um interface – user plane

Spare bit (X): X bit is set to 0. If SN-PDU is received with the Spare bit set to 1, the field is ignored without error notification.

First segment indicator bit (F): 0

This SN-PDU is not the first segment of an N-PDU. The octet including DCOMP and PCOMP is not included in the SN-Data PDU or SNUnitdata PDU format. Also the octet for N-PDU number for acknowledged mode is not included in the SN-Data PDU format.

This SN-PDU is the first segment of an N-PDU. The octet for DCOMP and PCOMP is included in the SN-Data PDU or SN-Unitdata PDU format. Also the octet for N-PDU number for acknowledged mode is included in the SN-Data PDU format.

SNSN-PDU Type (T): 0

SN-DATA PDU.

SN-UNITDATA PDU.

More bit (M): 0

Last segment of N-PDU.

Not the last segment of N-PDU, more segments to follow.

NSAPI: 0

Escape mechanism for future extensions.

Point-to-Multipoint Multicast (PTM-M) information.

2-4

Reserved for future use.

5-15 Dynamically allocated NSAPI value. SN-PDU with an unallocated NSAPI value is ignored by the receiving SNDCP entity without error notification.

compression Data co mpression coding (DCOMP): 0

No compression.

1-14 Points to the data compression identifier negotiated dynamically 15

Reserved for future extensions.

SN-PDU with an unallocated DCOMP value is ignored by the receiving SNDCP entity without error notification.

Signalling in GPRS/EGPRS

Data compression is an optional SNDCP feature. Data compression applies to both SN-DATA and SN-UNITDATA primitives. Data compression, if used, is performed on the entire N-PDU, including the possibly compressed protocol control information.

control Protocol contr ol information compression coding (PCOMP): 0

No compression.

1-14 Points to the protocol control information compression identifier negotiated dynamically. 15

Reserved for future extensions.

SN-PDU with an unallocated PCOMP is ignored by the receiving SNDCP entity without error notification.

Segment number: 0-15 Sequence number for segments carrying an N-PDU.

N-PDU number - acknowledged mode: 0-255

N-PDU number of the N-PDU.

N-PDU number - unacknowledged mode: 0-4095

N-PDU number of the N-PDU.

Data transfer transfer Acknowledged mode The N-PDU number in acknowledged mode is a number assigned to each N-PDU received by SNDCP through an SN-DATA.request. N-PDU numbers for different NSAPIs are assigned independently. The N-PDU number is included in the SNDCP header of the first segment of an N-PDU. Two variables, the Send N-PDU number and the Receive N-PDU number, are maintained for each NSAPI using acknowledged peer-to-peer LLC operation. When an NSAPI using acknowledged peer-to-peer LLC operation is activated, the Send N-PDU number and the Receive N-PDU number are set to 0. Modulo 256 operation is applied to the Send N-PDU number and the Receive N-PDU number.

3 Um interface – user plane

Upon reception of an SN-DATA.request, the SNDCP entity assignees to the N-PDU received the current value of the Send N-PDU number as the N-PDU number, increment the Send N-PDU number by 1, perform the compression and segmentation functions, then forward the SN-PDU(s) in LLDATA.request to the LLC layer. The N-PDU is stored into a buffer in the SNDCP entity. The buffered N-PDU is deleted when the SN-DATA PDU carrying the last segment of the N-PDU is confirmed by an LLDATA.confirm primitive, or when the entire N-PDU is confirmed by an SNSM-SEQUENCE.indication primitive. During normal operation (i.e., not in the recovery state), when the peer SNDCP entity receives the SN-PDU(s) in an LL-DATA.indication primitive, the SNDCP entity reassembles and decompresses the SN-PDU(s) to obtain the N-PDU, increment the Receive N-PDU number by 1, and forward the NPDU to the SNDCP user with the SN-DATA.indication. The correct SNDCP user is identified by the NSAPI field in the SN-PDU(s). Originator SNDCP user

SNDCP

SN-DATA.req

Receiver LLC

LLC

SNDCP

SNDCP user

LL-DATA.req LL-DATA.ind LL-DATA.cnf

Acknowledgement

SN-DATA.ind

Figure 3-6 SNDCP acknowledged data transfer

Unacknowledged mode The N-PDU number in unacknowledged mode is a number assigned to each N-PDU received by SNDCP through an SN-UNITDATA.request. N-PDU numbers for different NSAPIs are assigned independently. The N-PDU number is included in the SNDCP header of every SN-UNITDATA PDU. A variable, the Send N-PDU number (unacknowledged), is maintained for each NSAPI using unacknowledged peer-to-peer LLC operation. When an NSAPI using unacknowledged peer-to-peer LLC operation is activated, the Send N-PDU number (unacknowledged) are set to 0. Modulo 4096 operation is applied to the Send N-PDU number (unacknowledged). Upon reception of an SN-UNITDATA.request, the SNDCP entity assigns the current value of the Send N-PDU number (unacknowledged) as the N-PDU number of the N-PDU received, increment Send N-PDU number (unacknowledged) by 1, compress and segment the information, then forward

Signalling in GPRS/EGPRS

the SN-PDU(s) in LL-UNITDATA.request to the LLC layer. The N-PDUs are deleted immediately after the data has been delivered to the LLC layer. When the peer SNDCP entity receives the SN-PDU(s) in the LLUNITDATA.indication primitive, the SNDCP entity reassembles and decompress the SN-PDU(s) to obtain the N-PDU, then forwards it to the SNDCP user with the SN-UNITDATA.indication. The correct SNDCP user is identified by the NSAPI field in the SN-PDU(s). The SNDCP entity detects lost SN-PDUs. The SNDCP entity discards duplicate SN-PDUs and re-order out-of-sequence SN-PDUs, if possible. Originator SNDCP user

SNDCP

SNUNITDATA.req

Receiver LLC

LLUNITDATA.req

LLC

SNDCP

LLUNITDATA.ind

SNDCP user

SNUNITDATA.ind

Figure 3-7 SNDCP unacknowledged data transfer

LLC LLC spans from the MS to the SGSN. LLC is used 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. The LLC procedures are modelled upon the concepts of HDLC as outlined in ISO 4335. Data sequence integrity between the data source and data sink is effected by means of a cyclic numbering scheme. The Logical Link Control (LLC) layer structure is shown in Fig. 3-8.

3 Um interface – user plane

GPRS Mobility Management L3

LLGMM

SNDCP LL3

LL5

LL9

TOM LL11

TOM2

TOM8

SMS LLSMS

LLC Logical Logical Logical Link EntityLink Entity SAPI=7 Logical Link Entity SAPI=8 Logical Logical Link EntityLink Entity SAPI=2 SAPI=11 Logical Logical Link EntityLink Entity SAPI=9 SAPI=5 Link Entity SAPI=3 SAPI=1

Logical Link Management Entity

Multiplex Procedure

LLC GRR

BSSGP

MS SGSN

RLC/MAC Signalling Signalling and data transfer

RLC/MAC

BSSGP

Figure 3-8 Functional model of the LLC layer

Logical Link Entity The logical link procedures consist of multiple Logical Link Entities (LLEs) that control the information flow of individual connections. There may be multiple LLEs per TLLI. Functions provided by each LLE are: •

unacknowledged information transfer,

•

acknowledged information transfer,

•

flow control,

•

frame error detection.

The LLE analyses the control field of the received frame and provides appropriate responses and layer-to-layer indications. In addition, LLE analyses the LLC layer service primitives and transmits the appropriate command and response frames. There is one logical link entity for each DLCI.

Multiplex procedure On frame transmission, the multiplex procedure generates and inserts the FCS, performs the frame ciphering function, and provides SAPI-based logical link control layer contention resolution between the various LLEs. On frame reception, the multiplex procedure performs the frame decipher function and checks the FCS. If the frame passes the FCS check, the multiplex procedure distributes the frame to the appropriate logical link entity based on the DLCI.

Signalling in GPRS/EGPRS

Logical Link Management The Logical Link Management Entity (LLME) manages the resources that have an impact on individual connections. There is one LLME per TLLI. Functions provided by the LLME are: •

parameter initialisation,

•

error processing,

•

connection flow control invocation.

GPRS Mobility Management GPRS Mobility Management (GMM) uses the services of the LLC layer to transfer messages between the MS and the SGSN. GMM includes functions such as attach and authentication, and transport of session management messages for functions such as PDP context activation and deactivation.

Short Message Service The Short Message Service (SMS) uses the services of the LLC layer to transfer short messages between the MS and the SGSN.

Tunnelling Of Messages TOM is a generic protocol layer used for the exchange of TOM Protocol Envelopes between the MS and the SGSN. TOM mechanism is used for interworking with TIA/EIA-136 TDMA/PCS systems.

LLC Transmission Modes Two modes of operation of the LLC layer are defined for information transfer; unacknowledged and acknowledged. The LLC layer supports both modes simultaneously: •

In acknowledged mode, the receipt of LL-PDUs is confirmed. The LLC layer retransmits LL-PDUs if confirmation has not been received within a timeout period.

•

In unacknowledged mode, there is no confirmation required for LLPDUs.

Signalling and SMS are transferred in unacknowledged mode.

3 Um interface – user plane

In unacknowledged mode, the LLC layer offers the following two options: •

transport of ‘protected’ information, such that errors within the LLC information field result in the frame being discarded; and

•

transport of ‘unprotected’ information, such that errors within the LLC information field do not result in the frame being discarded. LLC transmission modes acknowledged mode

unacknowledged mode protected unprotected

Figure 3-9 LLC transmission modes

NSAPI and TLLI The Network layer Service Access Point Identifier (NSAPI) and Temporary Logical Link Identity (TLLI) are used for network layer routeing. An NSAPI/TLLI pair is unambiguous within a routeing area. In the MS, NSAPI identifies the PDP-SAP. In the SGSN and GGSN, NSAPI identifies the PDP context associated with a PDP address. Between the MS and the SGSN, TLLI unambiguously identifies the logical link. When the MS requests the activation of a PDP context, the MS selects one of its unused NSAPIs. For example (see Fig. 3-10), the MS receives an IP packet from a connected TE at the IP address A SAP. The IP PDU is encapsulated and NSAPI is initialised to NSAPI-1. TLLI is set to the MS's TLLI before the encapsulated IP packet is passed to the SNDC function. After the IP PDU is received, the SGSN analyses TLLI and NSAPI-1 and determines that the IP PDU shall be sent to the GGSN associated with IP address A. Within a routeing area, there is a one-to-one correspondence between TLLI and IMSI that is only known in the MS and SGSN. If it is not clear from the context which routeing area a TLLI belongs to, then TLLI is used together with RAI.

Signalling in GPRS/EGPRS

IP address A SAP GGSN associated with IP address A

NSAPI-1 TLLI NSAPI-2

SGSN GGSN associated with IP address B

IP address B SAP

Figure 3-10 Use of NSAPI and TLLI The TLLI address range is divided into four ranges: Local, Foreign, Random, and Auxiliary. The TLLI structure allows the MS and SGSN to deduce the range that a TLLI belongs to. A Local TLLI is derived from the P-TMSI allocated by the SGSN, and is valid only in the RA associated with the PTMSI. A Foreign TLLI is derived from a P-TMSI allocated in another RA. A Random TLLI is selected randomly by the MS, and is used when the MS does not have a valid P-TMSI available. An Auxiliary TLLI is selected by the SGSN, but it is currently unused. If the MS has a valid P-TMSI associated with the RA where the MS is currently located, the MS uses a Local TLLI derived from its P-TMSI, unless the MS performs a GPRS attach. If the MS does not have a valid P-TMSI associated with the current RA, or if the MS performs a GPRS attach, it derives a Foreign TLLI from its P-TMSI, or allocate a Random TLLI if no valid P-TMSI is available. By default, the TLLI transmitted at the RLC/MAC and BSSGP layers is used to identify the MS.

Structure of TLLI A TLLI is built by the MS or by the SGSN either on the basis of the P-TMSI (local or foreign TLLI), or directly (random or auxiliary TLLI), according to the rules described in Fig. 3-11. Part of the TLLI codespace is re-used in GERAN to allow for the inclusion of the GERAN Radio Network Temporary Identifier (G-RNTI) in RLC/MAC messages. G-RNTI is used only in the Iu interface is used between SGSN and PCU.

3 Um interface – user plane

bit number

Type of TLLI

26 to 0

Local TLLI

Foreign TLLI

Random TLLI

Auxiliary TLLI

Reserved

Part of the assigned G-RNTI

Random G-RNTI

bits derived from a P-TMSI

R bits chosen randomly

G bits derived from the assigned G-RNTI X bits in reserved ranges

A bits chosen by the SGSN

Figure 3-11 Structure of TLLI 'T', 'R', 'A' and 'X' indicate bits which can take any value for the type of TLLI. More precisely, 'T' indicates bits derived from a P-TMSI, 'R' indicates bits chosen randomly, 'A' indicates bits chosen by the SGSN, 'G' indicates bits derived from the assigned G-RNTI and 'X' indicates bits in reserved ranges.

SAPI SAPI identifies a point at which LLC services are provided by an LLE to a layer-3 entity. Consequently, SAPI identifies an LLE that should process an LLC frame and also a layer-3 entity that is to receive information carried by the LLC frame. SAPI allows 16 service access points to be specified. The SAPI values are allocated as shown in Fig. 3-12.

Signalling in GPRS/EGPRS

SAPI

Related service

SAP name

0000

Reserved

0001

GPRS Mobility Management

LLGMM

0010

Tunnelling of messages 2

TOM2

0011

User data 3

LL3

0100

Reserved

0101

User data 5

LL5

0110

Reserved

0111

SMS

LLSMS

1000

Tunnelling of messages 8

TOM8

1001

User data 9

LL9

1010

Reserved

1011

User data 11

LL11

1100

Reserved

1101

Reserved

1110

Reserved

1111

Reserved

Figure 3-12 Allocation of SAPI values

Frame structure All LLC layer peer-to-peer entities exchanges frames conforming to the format shown in Fig. 3-13. 8

Address Field (1 octet)

Control Field (1-36 octets)

Information Field (variable length, max. N201 octets)

Frame Check Sequence Field (3 octets)

Figure 3-13 LLC frame format

3 Um interface – user plane

Address field The address field consists of a single octet. The address field contains the SAPI and identifies the LLC entity for which a downlink frame is intended and the LLC entity transmitting an uplink frame. Address field also includes Command/Response (C/R) field that is used to discriminate between command and response frames.

Control field The control field typically consists of between one and three octets. The SACK supervisory frame also includes a variable-length bitmap field of up to 32 octets.

Information field The information field of a frame, when present, follows the control field. The minimum length of the information field is 140 octets and the maximum length depends on SAPI value and transmission mode: •

SAPI=1 – GMM (unacknowledged mode – UI-frames) – 400 octets,

•

SAPI=2 and 8 – TOM (unacknowledged mode – UI-frames) – 270 octets,

•

SAPI=7 – SMS – SMS (unacknowledged mode – UI-frames) – 270 octets,

•

SAPI=3, 5, 9, 11 – user data (unacknowledged mode – UI-frames) - 500 octets,

•

SAPI=3, 5, 9, 11 – user data (acknowledged mode – I-frames) – 1503 octets,

Frame Check Sequence (FCS) field The FCS 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. The FCS field contains the value of a CRC calculation that is performed over the entire contents of the header and information field, except for UI frames transmitted in unprotected mode, in which case the FCS field contains the value of a CRC calculation that is performed over the frame header and the first 4 octets of the information field containing SNDCP SN-UNITDATA PDU header.

Signalling in GPRS/EGPRS

Control field functions The main function of the control field is discrimination between various frame types. The following frame types are defined: Format Information + Supervisory

Unnumbered

Commands

Responses

RR ACK RNR SACK UI DISC SABM XID NULL

RR ACK RNR SACK DM UA FRMR XID -

Figure 3-14 LLC frame types

Unnumbered (U) frames Set Asynchronous Balanced Mode (SABM) command The SABM unnumbered command is used to place the addressed MS or SGSN side into ABM acknowledged operation. An LLE confirms acceptance of a SABM command by the transmission at the first opportunity of a UA response. Upon acceptance of this command, the LLE's reset the N(S) and N(R) sequential counters. An information field is permitted with the SABM command. If included, the information field contains XID parameters. This allows the LLC peers to negotiate LLC layer parameters and layer-3 parameters with the SABM command and UA response.

SGSN SABM (optionally XID par.)

ack mode

UA (optionally XID par.)

Figure 3-15 ABM setup 68

3 Um interface – user plane

Disconnect (DISC) command The DISC unnumbered command is transmitted in order to terminate the ABM operation. No information field is permitted with the DISC command. Prior to executing the command, the LLE receiving the DISC command confirms the acceptance of a DISC command by the transmission of a UA response. The LLE sending the DISC command terminates the ABM operation when it receives the acknowledging UA or DM response.

SGSN ack mode

ack mode

DISC UA / DM Figure 3-16 ABM termination

Unnumbered Acknowledgement (UA) response The UA unnumbered response is used by an LLE to acknowledge the receipt and acceptance of the mode-setting commands (SABM or DISC). Received mode-setting commands are not actioned until the UA response is transmitted. An information field is only permitted when UA is the response to a SABM command. The UA response in this case contains XID parameters with negotiated XID values. Disconnected Mode (DM) response The DM unnumbered response is used by an LLE to report to its peer that the LLE is in a state such that ABM operation cannot be performed. An LLE transmits a DM response to any valid command received that it cannot action.

Signalling in GPRS/EGPRS

SGSN

Command

ack mode

#$??

DM SABM UA ack mode

Figure 3-17 DM frame usage Frame Reject (FRMR) response The FRMR unnumbered response may be received by an LLE as a report of a frame rejection condition not recoverable by retransmission of the identical frame (e.g. receipt of a command or response control field that is undefined or not implemented, receipt of a supervisory or unnumbered frame with incorrect length, receipt of an I frame with an information field that exceeds the maximum established length). An information field that immediately follows the control field and that consists of 10 octets is returned with this response to provide the reason for the FRMR response.

SGSN

FRMR (#$??) Figure 3-18 FRMR frame usage

ack mode

#$??

3 Um interface – user plane

Exchange Identification (XID) command/response This frame is used to negotiate and re-negotiate LLC layer parameters and layer-3 parameters. XID frames can be transmitted in ADM and ABM. The negotiation procedure is one-phase, i.e., one side starts the process by sending an XID command, offering a certain set of parameters from the applicable parameter repertoire the sending entity wants to negotiate, proposing values within the allowed range. In return, the other side sends an XID response, either confirming these parameter values by returning the requested values, or offering higher or lower ones in their place. During the exchange of XID frames the values of the following parameters are negotiated: •

LLC version number,

•

Ciphering input offset for UI frames (IOV-UI),

•

Ciphering input offset for I frames (IOV-I),

•

Retransmission time-out (T200),

•

Maximum number of retransmissions (N200),

•

Maximum information field length for U and UI frames (N201-U),

•

Maximum information field length for I frames (N201-I),

•

I frame buffer size in the downlink directory (mD),

•

I frame buffer size in the uplink directory (mU),

•

Window size in the downlink direction (kD),

•

Window size in the uplink direction (kU),

•

Layer-3 parameters (e.g. PCOMP and DCOMP values).

SGSN XID (parameters) XID (parameters)

LLC ver, IOV UI, IOV I, T200, N200, N201-U, N201-I, mD, mU, kD, kU, Layer-3 par. e.g. PCOMP and DCOMP

Figure 3-19 XID parameters and XID frame usage

Signalling in GPRS/EGPRS

NULL command The NULL unnumbered command is used by an MS LLE to indicate a cell update. No information field is permitted with the NULL command.

BSS

SGSN BSSGP

NULL

+ cell, TLLI

Figure 3-20 NULL frame usage

Information Unconfirmed Informatio n (UI) frame When a layer-3 entity requests unacknowledged information transfer, the UI command is used to send information to its peer. No verification of sequence numbers is performed for UI frames. Therefore, the UI frame may be lost without notification to the layer-3 entity if a logical link exception occurs during transmission of the command. UI frames contain N(U), the unconfirmed sequence number of transmitted UI frames.

SGSN N(U)=0

UI (L3 info)

N(U)=0

UI (L3 info)

N(U)=1

UI (L3 info) UI (L3 info)

N(U)=2

unack mode

N(U)=1

UI (L3 info)

Figure 3-21 UI frame usage

framess Combined Information (I) and Supervisory (S) frame The function of the information (I) frame is to transfer, across a logical link connection, sequentially-numbered frames containing information fields provided by layer 3. This frame is only used in the ABM operation. Each I frame also contains supervisory information, in effect ‘piggy-backing’ an S frame with each I frame, so that it may be considered to be an I+S frame. A separate S frame is sent when there is no information field to be transferred. Whether an I+S or S frame is transmitted as a command or as a response is insignificant in the ABM procedures. 72

3 Um interface – user plane

Send sequence number N(S) is a sequential number of the information and supervisory frames (I+S frames). The sequence numbers are calculated separately for each direction. Receive sequence number N(R), is included in I+S frames (I+S frames) and as well as in supervisory frames (S frames). N(R) is the expected send sequence number of the next I frame to be received. Receive Ready (RR) command / response The receive ready (RR) supervisory frame is used by an LLE to: •

indicate that it is ready to receive an I frame,

•

acknowledge previously received I frames numbered up to and including N(R) – 1.

In addition to indicate the status of an LLE, the RR frame with the A bit set to 1 may be used by the LLE to request an acknowledgement from its peer LLE. The transmission of an RR frame also indicates the clearance of any busy condition within the sending LLE that was reported by the earlier transmission of an RNR frame by the same LLE.

SGSN SABM UA I+RR (L3 info)

N(R)=0

N(S)=0

I+RR (L3 info)

N(R)=1

N(S)=1

I+RR (L3 info)

N(R)=1

N(S)=2

I+RR (L3 info)

N(R)=1

N(R)=3

N(S)=3

I+RR (L3 info)

N(R)=1

N(S)=4

I+RR (L3 info)

N(R)=1

N(R)=5

ack mode

N(S)=0

Figure 3-22 RR frame usage Acknowledgement (ACK) command / response The ACK supervisory frame is used by an LLE to acknowledge a single or multiple I frames. Frames up to and including N(R) - 1, and frame N(R) + 1, have been received correctly.

Signalling in GPRS/EGPRS

In addition to indicate the status of an LLE, the ACK frame with the A bit set to 1 may be used by the LLE to request an acknowledgement from its peer LLE. The transmission of an ACK frame also indicates the clearance of any busy condition within the sending LLE that was reported by the earlier transmission of an RNR frame by the same LLE.

SGSN SABM UA I+RR (L3 info)

N(R)=0

N(S)=1

I+RR (L3 info)

N(R)=0

N(S)=2

I+RR (L3 info)

N(R)=0

ACK

N(R)=1

N(S)=1

I+RR (L3 info)

N(R)=0

N(S)=3

I+RR (L3 info)

N(R)=0

ack mode

N(S)=0

Figure 3-23 ACK frame usage Selective Acknowledgement (SACK) command / response The SACK supervisory frame is used by an LLE to acknowledge a single or multiple I frames. Frames up to and including N(R) - 1, and frames indicated by the SACK bitmap, have been received correctly. SGSN SABM UA I+RR (L3 info)

N(R)=0

N(S)=1

I+RR (L3 info)

N(R)=0

N(S)=2

I+RR (L3 info)

N(R)=0

N(S)=3

I+RR (L3 info)

N(R)=0

N(S)=4

I+RR (L3 info)

N(R)=0

N(S)=5

I+RR (L3 info)

N(R)=0

N(S)=2 N(S)=4

SACK (0,1,0,...,n) N(R)=2 I+RR (L3 info) N(R)=0 I+RR (L3 info)

N(R)=0

Figure 3-24 SACK frame usage 74

ack mode

N(S)=0

3 Um interface – user plane

In addition to indicate the status of an LLE, the SACK frame with the A bit set to 1 may be used by the LLE to request an acknowledgement from its peer LLE. The transmission of a SACK frame also indicates the clearance of any busy condition within the sending LLE that was reported by the earlier transmission of an RNR frame by the same LLE. Receive Not Ready (RNR) command / response The receive not ready (RNR) supervisory frame is used by an LLE to indicate a busy condition; that is, a temporary inability to accept additional incoming I frames. The value of N(R) in the RNR frame acknowledges I frames numbered up to and including N(R) - 1. In addition to indicate the status of an LLE, the RNR frame with the A bit set to 1 may be used by the LLE to request an acknowledgement from its peer LLE.

SGSN

SABM UA I+RR (L3 info)

N(R)=0

N(S)=1

I+RR (L3 info)

N(R)=0

N(S)=2

I+RR (L3 info)

N(R)=0

N(S)=3

I+RR (L3 info)

N(R)=0

RNR

N(R)=4

N(R)=0

N(R)=4

I+RR

N(R)=0

N(S)=3

ack mode

N(S)=0

Figure 3-25 RNR frame usage

Other command field functions Poll/Final bit (P/F) All U frames contain the Poll/Final (P/F) bit. The P/F bit serves a function in both command frames and response frames. In command frames the P/F bit is referred to as the P bit. In response frames it is referred to as the F bit.

Signalling in GPRS/EGPRS

The P bit set to 1 is used by an LLE to solicit (poll) a response frame from the peer LLE. The F bit set to 1 is used by an LLE to indicate the response frame transmitted as a result of a soliciting (poll) command.

SGSN Command (P=1) Response (F=1) Figure 3-26 P/F bit usage Acknowledgement request bit (A) All I+S and S frames contain the Acknowledgement Request (A) bit. The A bit set to 1 is used by an LLE to solicit an acknowledgement (i.e., an I+S or S frame) from the peer LLE. The A bit set to 0 is used by an LLE to indicate that the peer LLE is not requested to send an acknowledgement.

SGSN I+S / S (A=1) I+S / S (ack) Figure 3-27 A bit usage

Ciphering This section describes how LLC interfaces with the GPRS ciphering algorithm.

Ciphering algorithm interface The ciphering algorithm has four input parameters: the 64-bits long ciphering key (Kc) received from GMM, the frame-dependent input (Input), the transfer direction (Direction), ciphering algorithm type received from GMM and one output parameter (Output). The relationship between the input and output parameters and the ciphering algorithm is illustrated in Fig. 3-28.

3 Um interface – user plane

Input Direction

Ciphering Algorithm

Output Unciphered Frame

Ciphering Algorithm Output Deciphered Frame

Ciphered Frame

MS or SGSN

SGSN or MS

Figure 3-28 GPRS ciphering environment

Generation of Input The Input parameter is generated according to the following algorithm if the frame is a UI frame: Input = ( ( IOV-UI ⊗ SX ) + LFN + OC ) modulo 232 The Input parameter is generated according to the following algorithm if the frame is an I frame: Input = ( IOV-I + LFN + OC ) modulo 232 where: •

IOV-UI is a 32 bit random value generated by the SGSN.

•

IOV-I is a 32 bit random value generated by the SGSN.

•

LFN is the LLC frame number in the LLC frame header. LFN is a binary value with a length of nine bits. For I frames, N(S) is used as the LFN. For UI frames, N(U) is used as the LFN.

•

OC is a binary overflow counter that is calculated and maintained independently at the sending and receiving sides. The length of OC is 32 bits. There are four OC counters associated with each SAPI; two for unacknowledged information transfer (one for each direction of transmission), and two for acknowledged information transfer (one for each direction of transmission). An OC for acknowledged operation is set to 0 whenever ABM operation is (re-)established for the corresponding SAPI. OC is incremented by 512 every time when the corresponding LFN rolls over, i.e., when LFN exhausts its modulo and restarts counting from 0, so that OC and LFN when added together in effect is a 32 bit modulo 232 counter.

•

SX is a 32 bit SAPI XOR mask calculated as follows: SX = 227 • SAPI + 231.

•

+ is the binary addition operation.

•

⊗ is the bitwise XOR operation. 77

Signalling in GPRS/EGPRS

RLC/MAC In order to address a data block to/from a certain MS and to control the access to the channel(s) shared by a number of MSs, Medium Access Control (MAC) protocol - is used. Another protocol, Radio Link Control (RLC) is used for segmentation and reassembly of LLC PDUs into RLC/MAC blocks and, in RLC acknowledged mode of operation, for the Backward Error Correction (BEC) procedures enabling the selective retransmission of unsuccessfully delivered RLC/MAC blocks. In RLC acknowledged mode of operation, the RLC function preserves the order of higher layer PDUs provided to it. The RLC function provides also link adaptation. In EGPRS in RLC acknowledged mode of operation, the RLC function may provide Incremental Redundancy (IR). The RLC and MAC protocols’ information shares the same data block structure. RLC/MAC block carries user information (traffic) or signalling messages as a payload.

MAC Medium Access Control address a data block to/from a certain MS control the access to the channel(s) shared by a number of MSs

RLC Radio Link Control segmentation and reassemble of LLC PDUs into RLC/MAC blocks retransmission of unsuccessfully delivered RLC/MAC blocks (ack mode) preserves the order of higher layer PDUs (ack mode) link adaptation IR - Incremental Redundancy (EGPRS ack mode)

Figure 3-29 RLC/MAC functions

3 Um interface – user plane

MAC modes Packet idle mode In packet idle mode: •

No temporary block flow (TBF) exists.

•

The MS monitors the relevant paging subchannels on PCCCH or CCCH.

•

Upper layers may require the transfer of an upper layer PDU, which implicitly triggers the establishment of a TBF and the transition to packet transfer mode.

•

Upper layers may require the establishment of a GSM RR connection. When the MS enters dedicated mode, it may leave the packet idle mode, if the MS limitations make it unable to handle the RR connection and the procedures in packet idle mode simultaneously.

Packet transfer mode In packet transfer mode, the MS is allocated radio resources providing a TBF for physical point-to-point connection on one or more PDCH for the transfer of upper layer PDUs between the network and the MS. When a transfer of upper layer PDUs terminates, in either downlink or uplink direction, the corresponding TBF is released. When all TBFs have been released, in downlink and uplink direction, the MS returns to packet idle mode. In packet transfer mode, upper layers may require the establishment of a GSM RR connection. When the MS enters GSM dedicated mode, it may abort all ongoing TBFs and leave the packet transfer mode, if the MS limitations make it unable to handle the RR connection and the procedures in packet transfer mode simultaneously.

Dual transfer mode In dual transfer mode, the MS is allocated radio resources providing an RR connection on a dedicated TCH channel and one or more TBFs on one or more PDCHs. The allocation of radio resources for the RR connection and the TBFs is co-ordinated by the network, in agreement with the capabilities of the MS in dual transfer mode.

Signalling in GPRS/EGPRS

Packet Idle Mode no Temporary Block Flow (TBF) exists MS monitors the relevant paging subchannels on (P)CCCH

Packet Transfer Mode MS is allocated radio resources providing a TBF for physical p-to-p connection on one or more PDCH for the transfer of upper layer PDUs

Dual Transfer Mode MS is allocated RR on a dedicated TCH MS is allocated TBFs on one or more PDCHs

Figure 3-30 MAC modes

RLC/MAC control messages Fig. 3-31 summarises the RLC/MAC control messages. Uplink TBF establishment messages: Packet Access Reject Packet Channel Request EGPRS Packet Channel Request Packet Queuing Notification Packet Resource Request Packet Uplink Assignment Additional MS Radio Access Capabilities Downlink TBF establishment messages: Packet Downlink Assignment TBF release messages: Packet TBF Release RLC messages: Packet Downlink Ack/Nack EGPRS Packet Downlink Ack/Nack Packet Uplink Ack/Nack

System information messages: Packet System Information Type 1 Packet System Information Type 2 Packet System Information Type 3 Packet System Information Type 3 bis Packet System Information Type 3 ter Packet System Information Type 3 quarter Packet System Information Type 4 Packet System Information Type 5 Packet System Information Type 6 Packet System Information Type 7 Packet System Information Type 8 Packet System Information Type 13 Packet System Information Type 14 Packet System Information Type 15 Paging message: Packet Paging Request

Miscellaneous messages: Packet Control Acknowledgement Packet Cell Change Failure Packet Cell Change Order Packet Downlink Dummy Control Block Packet Uplink Dummy Control Block Packet Measurement Report Packet Measurement Order Packet Mobile TBF Status Packet Enhanced Measurement Report Packet PDCH Release Packet Polling Request Packet Power Control/Timing Advance Packet PRACH Parameters Packet PSI Status Packet Pause Packet Timeslot Reconfigure

Figure 3-31 RLC/MAC control messages

TBF The transmission of RLC/MAC blocks (a physical connection) in downlink or uplink direction is called Temporary Block Flow (TBF). MS can have uplink TBF, downlink TBF, or two separate TBFs in both directions. TBF is assigned to the MS during the procedure of TBF establishment, which can be initiated by the MS or the network. The TBF is allocated radio resources on one or more PDCHs.

3 Um interface – user plane

A TBF is temporary and is maintained only for the duration of the data transfer i.e. until there are no more RLC/MAC blocks to be transmitted and, in RLC acknowledged mode, all of the transmitted RLC/MAC blocks have been successfully acknowledged by the receiving entity. A TBF may operate in either GPRS or EGPRS TBF mode.

TFI To distinguish between RLC/MAC blocks belonging to different TBFs (users) sharing the same PDCH, the Temporary Flow Identity (TFI) is used. The usage of TFI is shown in Fig. 3-32. In this example TSs from 3 up to 7 on a radio channel are allocated as PDCHs. These PDCHs are used by 4 MSs. MS 1 is using PDCHs on TSs: 3, 4 and 5, MS 2 on TSs: 4, 5 and 6, MS 3 on TSs: 6 and 7, and MS 4 on TS 7. GSM CS BPC

TS ->

GPRS PS PDCH

MS 1 TFI = 1 MS 2 TFI = 2

MS 3 TFI = 3 MS 4 TFI = 1

Figure 3-32 Usage of TFI The TFI value is unique among concurrent TBFs in the same direction (uplink or downlink) on all PDCHs used for the TBF. The same TFI value may be used concurrently for TBFs on other PDCHs in the same direction and for TBFs in the opposite direction. An RLC/MAC block associated with a certain TBF comprises a TFI. The TBF is identified by the TFI together with, in case of a RLC data block, the direction (uplink or downlink) in which the RLC data block is sent; and in case of a RLC/MAC control message, the direction in which the RLC/MAC control message is sent and the message type.

Signalling in GPRS/EGPRS

Global_TFI is used to unambiguously identify the MS in packet transfer mode state within an uplink or downlink RLC/MAC control message. If present, the Global TFI addresses the MS using either an uplink TFI or downlink TFI of the MS.

USF in dynamic allocation mode The header of each downlink data block contains an Uplink State Flag (USF), which notifies MSs with uplink TBF assigned and sharing the same PDCH, which MS is allowed to send the next block on uplink. The usage of USF is shown in Fig. 3-33. USF is unique only on one PDCH. The MS gets the list of allocated PDCHs during the TBF establishment procedure – they are identified by ARFCN and TSs together with USF values. GSM CS BPC

UL TDMA TS -> TS MS 1

4 5 6 7

USF 1 1 1 1

GPRS PS PDCH

MS1 4 TS

MS 2

MS2 5

5 6 7

USF 2 3 5

4 5 6

MS 3

USF 2 3 4 DL TDMA TS ->

MS2 6

MS4 7 MS 4

USF 2

USF=1

USF=3

USF=4

USF=2

Figure 3-33 Usage of USF (dynamic allocation) All MSs with uplink TBFs receive downlink control blocks on these PDCHs that are allocated to them on uplink. When the MS detects its USF on a certain PDCH (downlink) it can transmit the next data block on this PDCH (uplink). For example MS 1 is assigned PDCHs on TSs: 4, 5, 6 and 7; and on all these TSs it has USF equal to 1. It listens to data blocks sent on the downlink and only on TS 4 it detects its USF, so it is only allowed to transmit one uplink data block on TS 4. USF avoids collisions on uplink, as only one MS is allowed to transmit on each PDCH at a certain time. MS with only downlink TBF established, has also to send some control blocks on the uplink. These blocks are used to report received signal quality and to send acknowledgements for the correctly received data blocks on the

3 Um interface – user plane

downlink. The network can allow MS to transmit a single block on uplink by setting the Relative Reserved Block Period (RRBP) field in the RLC/MAC block header sent to this MS on downlink. The USF field is three bits in length and eight different USF values can be assigned, except on PCCCH, where the value ‘111’ (USF=FREE) indicates that the corresponding uplink radio block contains PRACH.

USF in the extended dynamic allocation allocation The Extended Dynamic Allocation (EDA) method extends the Dynamic Allocation to allow higher uplink throughput that is especially important for halfduplex MS with multislot classes above multislot class 10, that is for MS that are able to transmit on more slots then they are able to receive in some multislot configurations. Without Extended Dynamic Allocation it is not possible to fully utilise uplink transfer capabilities of these MSs. In EDA, the MS monitors its assigned PDCHs starting with the lowest numbered PDCH, then the next lowest numbered PDCH, etc. Whenever the MS detects an assigned USF value on an assigned PDCH, the MS transmits a single RLC/MAC block on the same PDCH and all higher numbered assigned PDCHs.

UL TDMA TS ->

0 MS 1

1 TS

MS1

2 3 4 5

MS 2

USF 1 2 6 1

DL TDMA TS ->

MS2 6

MS2 7

5 6 7

USF 2 3 4

USF=1

USF=0

USF=0 USF=0

USF=3

USF=0

Figure 3-34 Usage of USF (Extended Dynamic Allocation)

Multiplexing of GPRS and EGPRS TBFs GPRS and EGPRS TBF mode capable MSs can be multiplexed dynamically on the same PDCH. A MS in GPRS TBF mode has to be able to detect the USF that assigns the uplink to that MS. The network uses GMSK modulation, i.e. either CS-1 to CS-4 or MCS-1 to MCS-4, in those blocks. The other blocks may use 8PSK modulation.

Signalling in GPRS/EGPRS

In such situation there is a possibility to use USF_GRANULARITY parameter (present in the messages used for uplink TBF establishment) in order to decrease the number of radio blocks modulated with GMSK. USF_GRANULARITY parameter controls the number of blocks to be send after each reception of the assigned value of the USF (1 blocks or 4 consecutive blocks). The MS does not need to monitor the USF during the block periods in which the MS obtains permission to transmit, thus those block can be modulated with 8PSK. For mobile station synchronization reasons, if GPRS MSs are multiplexed on the PDCH, at least one downlink radio block every 360ms is transmitted to each MS with a coding scheme and a modulation that can be decoded by that MS.

Segmentation Data block segmentation Segmentation of upper layer PDUs allows for transport of upper layer PDUs larger than the data field of a single RLC data block. If the contents of an upper layer PDU do not fill an integer number of RLC data blocks, the beginning of the next upper layer PDU is placed within the final RLC data block of the first upper layer PDU, with no padding or spacing between the end of the first upper layer PDU and the beginning of the next. If the final upper layer PDU in the TBF does not fill an integer number of RLC data blocks, filler octets are used to fill the remainder of the RLC data block.

LLC RLC

M=0, E=1, LI

M=1, E=1, LI

Figure 3-35 Data block segmentation

M=1, E=0, LI

3 Um interface – user plane

A Block Sequence Number (BSN) is included in the header of each RLC data block to number the RLC data block. The RLC data blocks are numbered consecutively, modulo SNS - Sequence Number Space (128 in GPRS and 2048 in EGPRS), to allow re-assembly of the upper layer PDUs on the receiving side. During RLC acknowledged mode operation, received upper layer PDUs are delivered to the higher layer in the order in which they were originally transmitted.

BSS 1

Figure 3-36 BSN - Block Sequence Number (ack mode) During RLC unacknowledged mode operation, received upper layer PDUs are delivered to the higher layer in the order in which they are received. Fill bits having the value ‘0’ are substituted for RLC data units not received. However, in EGPRS TBF mode, for erroneous RLC data blocks for which the header is correctly received, the output from decoder is delivered to the higher layer.

BSS 1

000...000

Figure 3-37 BSN - Block Sequence Number (unack mode)

Signalling in GPRS/EGPRS

Control message segmentation The network may segment RLC/MAC control messages into one, two or up to nine RLC/MAC control blocks depending on the length of the RLC/MAC control message. Segmentation of an RLC/MAC control message into more than two RLC/MAC control blocks is referred to as extended RLC/MAC control message segmentation. Extended RLC/MAC control message segmentation is not used for an RLC/MAC control message that can be sent using one or two RLC/MAC control blocks. If the contents of a control message do not fit an integer number of control blocks, filler octets are used to fill the remainder of the RLC/MAC control block. The Final Segment (FS) bit of the RLC/MAC control block header is set according to whether the RLC/MAC control block contains the final segment of an RLC/MAC control message, except in case of extended RLC/MAC control message segmentation in which case the FS bit is always set to ‘0’. In case of extended RLC/MAC control message segmentation, the Final Segment extension (FSe) bit of the RLC/MAC control block header (included in the second RLC/MAC control block onwards) is set according to whether the RLC/MAC control block contains the final segment of an RLC/MAC control message.

RTI=0 RBSN=1 FS=1 RTI=1 RBSN=1 FS=1 max 31

RTI=0 RBSNe=1 FSe=0 0

RTI=1 RBSN=0 FS=0

RTI=0 RBSNe=0 FSe=0

RTI=0 RBSNe=2 FSe=0

RTI=0 RBSNe=n FSe=1 RTI=1 RBSN=1 FS=0 1

RTI=0 RBSN=0 FS=0

RLC/MAC control messages

BSS

RLC/MAC control messages

BSS

max 31

Figure 3-38 Control message segmentation

Acknowledgements Acknowledgements Acknowledgement for control message No general acknowledgement is made as part of the transfer of RLC/MAC control blocks or RLC/MAC control messages. The receiver is not allowed to acknowledge an RLC/MAC control block except when a valid RRBP field is present in the MAC header of the RLC/MAC control block. 86

3 Um interface – user plane

Each downlink RLC/MAC control block header, if present, contains a Radio Transaction Identifier (RTI) field that is 5 bits in length and performs in effect a modulo 32 count of the downlink RLC/MAC control messages sent on a PDCH. The RTI field is used to group the RLC/MAC control blocks that make up an RLC/MAC control message. The RTI field allows the transmitting and receiving entities to distinguish between up to 32 RLC/MAC control messages in a single transmit direction therefore allowing up to 32 parallel transactions per PDCH. All segments of a segmented control message are transmitted on the same PDCH.

BSS Control Message RTI=x RRBP=n Packet Control Acknowledgement RTI=x

RRBP

Figure 3-39 Acknowledgement for control message

Acknowledgement for data blocks The RLC Automatic Repeat reQuest (ARQ) functions support two modes of operation: RLC acknowledged mode and RLC unacknowledged mode. RLC acknowledged mode operation uses retransmission of RLC data blocks to achieve high reliability. RLC unacknowledged mode operation does not utilise retransmission of RLC data blocks. A TBF may operate in either RLC acknowledged mode or RLC unacknowledged mode. The MS sets the RLC mode of the uplink TBF by setting the RLC_MODE bit to either RLC acknowledged mode or RLC unacknowledged mode in the Packet Resource Request or the (EGPRS) Packet Downlink Ack/Nack message. When the establishment cause field in the Packet Channel Request message indicates ‘one phase access’, the RLC mode defaults to RLC acknowledged mode. The network sets the RLC mode of the downlink TBF by setting the RLC_MODE bit in the Packet Downlink Assignment message.

Signalling in GPRS/EGPRS

Acknowledged GPRS TBF mode The transfer of RLC data blocks in the RLC acknowledged mode uses retransmissions of RLC data blocks. The transmitting side numbers the RLC data blocks via the block sequence number (BSN). The BSN is used for retransmission and for reassembly. The receiving side sends Packet Ack/Nack messages in order to request retransmission of RLC data blocks. RLC/MAC Window Size (WS) in GPRS TBF mode is 64.

BSS Data Block BSN=20 retransmission

Data Block BSN=21 Data Block BSN=22 Packet Uplink Ack/Nack SSN=20, RBB=(0,1) Data Block BSN=21 Data Block BSN=23

Figure 3-40 Acknowledged GPRS UL TBF mode

BSS Data Block BSN=20 Data Block BSN=21

Packet Downlink Ack/Nack SSN=20, RBB=(0,1) Data Block BSN=21 Data Block BSN=23 DL

RRBP

Figure 3-41 Acknowledged GPRS DL TBF mode

retransmission

Data Block BSN=22, RRBP=n

3 Um interface – user plane

The Packet Downlink/Uplink Ack/Nack contains: •

Starting Sequence Number (SSN) specifying BSN of the last block in the sequence of correctly received data blocks.

•

Receive Block Bitmap (RBB) representing Block Sequence Numbers of the data block with BSN higher than SSN and indicating positive or negative acknowledgements for corresponding data blocks,

•

channel quality report.

In GPRS TBF mode, once an RLC data block has been transmitted over the physical link, should it be necessary to re-transmit the RLC data block, it must be re-transmitted using the same channel coding scheme, BSN, and CV as it had in the previous transmission.

-4 CS 3 2 1

BSS

5 4

ack k/N 5) c A & 4 link wn locks o D it b t cke sm Pa etran (r

-2 CS

BSS

BSS 8

-4 CS

6 5

In GPRS TBF mode, once an RLC data block has been transmitted, it must be re-transmitted using the same CS, BSN, and CV as it had in the previous transmission.

Figure 3-42 Retransmissions for GPRS

Acknowledged EGPRS TBF m mode ode In EGPRS TBF mode, the transfer of RLC Data Blocks in the acknowledged RLC/MAC mode may be controlled by a selective type I ARQ mechanism, or by type II hybrid ARQ (Incremental Redundancy: IR) mechanism, coupled with the numbering of the RLC Data Blocks within one Temporary Block Flow. In the type I ARQ mode, decoding of an RLC data block is solely based on the prevailing transmission (i.e. erroneous blocks are not stored). In the type II ARQ case, erroneous blocks are stored by the receiver and a joint decoding with new transmissions is done. If the memory for IR operation runs out in the MS, the MS indicates this by setting the MS_OUT_OF_MEMORY bit in the EGPRS Packet Downlink Ack/Nack message. For uplink TBFs, the network may implicitly set the type I mode by ordering the MS to use a specific MCS and setting the RESEGMENT bit or type II mode by ordering the MS to use a specific MCS and not setting the RESEGMENT bit.

Signalling in GPRS/EGPRS

BSS Data Block BSN=20 Data Block BSN=21 retransmission

Data Block BSN=22 EGPRS Packet Downlink Ack/Nack Data Block BSN=21 Data Block BSN=23

Figure 3-43 Type II ARQ modes in EGPRS In EGPRS TBF mode, once an RLC data block has been transmitted over the physical link, should it be necessary to re-transmit the RLC data block, it must be re-transmitted using the same BSN and the same calculated CV as were used in the previous transmission. The modulation and coding scheme may be changed. For the retransmissions, the same or another MCS from the same family of MCSs may be selected. E.g. if MCS-7 is selected for the first transmission of an RLC block, any MCS of the family B may be used for the retransmissions. Further, RLC data blocks initially transmitted with MCS-4, MCS-5, MCS-6, MCS-7, MCS-8 or MCS-9, may be retransmitted with MCS1, MCS-2 or MCS-3, by sending the different parts of the RLC data block in different radio blocks. In this case, the split block field in the header is set to indicate that the RLC data block is split, and the order of the two parts.

S-9 MC 3 2 1

BSS

5 4

ck Na ck/ 5) A & k nlin s 4 ow block D t it cke sm Pa retran (

BSS

S-3 MC

6 5

In EGPRS TBF mode, for the retransmissions, the same or another MCS from the same family of MCSs may be selected

Figure 3-44 Retransmissions in EGPRS RLC/MAC Window Size (WS) is from 64 to 1024.

3 Um interface – user plane

Unacknowledged mode operation The transfer of RLC data blocks in the RLC unacknowledged mode does not include any retransmissions, except during the release of an uplink TBF where the last transmitted uplink block may be retransmitted. The Block Sequence Number (BSN) in the RLC data block header is used to number the RLC data blocks for reassembly. The receiving side sends Packet Ack/Nack messages in order to convey the necessary other control signalling (e.g. monitoring of channel quality for downlink transfer or timing advance correction for uplink transfers).

Establishment of downlink TBF MS in Standby state The downlink TBF establishment procedure is illustrated in Fig. 3-45. Each step is explained in the list below.

BSS (Packet) Paging Request (P)PCH Cell Update Packet Downlink Assignment (P)AGCH Packet Control Acknowledgement PACCH PACCH PDTCH PACCH

Figure 3-45 DL TBF establishment in Standby state ‘Packet paging request’ (PPCH) or ‘Paging request’ (PCH) containing MS identity (P-TMSI) is sent to the MS within all cells belonging to the RA. When MS decodes its own identity in ‘(Packet) Paging request’ it performs cell update procedure (transfer of an LLC frame). The network assigns the downlink TBF in ‘Packet Downlink Assignment’ message sent on PAGCH or AGCH. This message contains description of

Signalling in GPRS/EGPRS

downlink radio resources that will be used by MS including Temporary Flow Identity (TFI) that will identify RLC/MAC blocks sent to the MS. The network, when assigning downlink radio resources, takes into account the MS’s multislot class specified by the MS during GPRS attach procedure. The network sends packets to the MS on PDTCH. MS acknowledges the receipt of data blocks on PACCH.

MS in Ready state When a GPRS MS is in Ready state its current cell is known so the paging is not necessary. MS in Ready state and in Packet Idle mode monitors relevant (P)CCCH blocks. This means that the assignment of downlink TBF on (P)AGCH is possible without prior paging. When in packet transfer mode (MS has already an uplink TBF assigned), MS receives the downlink TBF assignment on PACCH. Downlink TBF establishment in MS Ready state and Packet Idle mode is shown in Fig. 3-46.

BSS Packet Downlink Assignment (P)AGCH Packet Control Acknowledgement PACCH PACCH PDTCH PACCH

Figure 3-46 DL TBF establishment in Ready state and Packet Idle mode The network assigns the downlink TBF in ‘Packet Downlink Assignment’ message sent on (P)AGCH. The network sends packets to the MS on PDTCH. MS acknowledges the reception of data blocks on PACCH. Downlink TBF establishment in MS Ready state and in Packet Transfer mode is shown in Fig. 3-47.

3 Um interface – user plane

BSS

Packet Downlink Assignment PACCH Packet Control Ack PACCH PACCH PDTCH PACCH

Figure 3-47 DL TBF establishment in Ready state and Packet Transfer Mode MS transfers the packets to the network on PDTCH. Network sends the acknowledgements for the received data blocks to the MS on PACCH. MS receives the ‘Packet Downlink Assignment’ on PACCH. Packets and acknowledgements are sent in both directions.

Establishment of uplink TBF The uplink TBF establishment is more complicated than the downlink TBF establishment because the network has no idea about the amount of data the MS wants to send to the network. There are two types of uplink TBF establishment: •

one-phase, when MS does not specify precisely the amount of data it wants to send to the network; and the network can assign uplink radio resources only on one PDCH.

•

two-phase, when MS specifies precisely the amount of RLC/MAC data to be sent, together with RLC mode and some QoS parameters and the network can assign radio resources on a number of PDCHs trying to meet MS needs.

One-phase uplink TBF establishment procedure is shown in Fig. 3-48.

Signalling in GPRS/EGPRS

BSS (Packet) (EGPRS) Channel Request (P)RACH Packet Uplink Assignment (P)AGCH Packet Control Acknowledgement PACCH PACCH PDTCH PACCH

Figure 3-48 UL TBF establishment – one-phase setup MS sends ‘(Packet) Channel Request’ on (P)RACH. Inside the message MS indicates that it initiates one-phase uplink TBF establishment procedure. The network sends ‘Packet Uplink Assignment’ message on (P)AGCH containing the description of uplink radio resources (PDTCH): ARFCN (or ARFCN, HSN and MAIO in case of a hopping channel), TS, TFI, USF and coding scheme (CS), MS transfers the packets to the network on the assigned PDTCH. The network acknowledges the data blocks on PACCH. Two-steps uplink TBF establishment procedure is shown in Fig. 3-49.

BSS (Packet) (EGPRS) Channel Request (P)RACH Packet Uplink Assignment (P)AGCH Packet Resource Request PACCH Packet Uplink Assignment PACCH Packet Control Acknowledgement PACCH PACCH PDTCH PACCH

Figure 3-49 UL TBF establishment – two-step setup 94

3 Um interface – user plane

MS sends ‘(Packet) Channel Request’ on (P)RACH. Inside the message MS indicates that it initiates the two-phase uplink TBF establishment procedure. The network sends ‘Packet Uplink Assignment’ message on (P)AGCH allowing MS to transfer a single data block on a certain PDCH. MS sends a single data block containing the ‘Packet Resource Request’ message, which specifies the MS demand for uplink radio resources. The network allocates uplink radio resources for the MS according to MS needs and its multislot class. The ‘Packet Uplink Assignment’ message, among other parameters, contains: •

ARFCN (or ARFCNs, HSN and MAIO in case of a hopping channel),

•

TS numbers and corresponding values of USF,

•

TFI,

•

CS.

MS transfers the packets to the network on the specified PDTCH(s). The network acknowledges the receipt of data blocks on PACCH(s). When the MS is in Packet Transfer Mode (MS has a downlink TBF assigned) the establishment of uplink TBF can be done on PACCH, see Fig. 3-50.

BSS

Packet Resource Request PACCH Packet Uplink Assignment PACCH Packet Control Ack PACCH PACCH PDTCH PACCH

Figure 3-50 UL TBF establishment in Packet Transfer Mode

Signalling in GPRS/EGPRS

Release of downlink TBF The network initiates the release of a downlink TBF by sending an RLC data block with the FBI set to the value 1 and with a valid RRBP field. The MS transmits than a (EGPRS) Packet Downlink Ack/Nack message in the specified uplink block. If retransmissions are required, then the network stops TBF release procedure and retransmits necessary RLC data blocks before re-initiating the release of the downlink TBF. If no retransmission is required, the network and the MS release the TBF after timer T3192 expires (0 - 1.5s). If the network has received the Packet Control Acknowledgement message and has new data to transmit for the MS, while T3192 is still running, the network establishes a new downlink TBF for the MS by sending on PACCH the Packet Downlink Assignment message with the Control Ack bit set to '1'.

BSS Data Block Data Block Data Block FBI=1, RRBP=n T3192

T3192

Packet Downlink Ack/Nack

Figure 3-51 Release of downlink TBF

Delayed release of downlink TBF When the network exhausts its supply of downlink data for a downlink TBF, it may release the TBF. If a TBF is not instantly released, the network may continue the downlink TBF awaiting new data to be received from the upper layers for up to 5s. After a period of inactivity, the TBF is released at a point determined by the network. If the network continues a downlink TBF when the supply of downlink data is exhausted, the RLC entity on the network side inserts filler information into the RLC data blocks that are transmitted to the MS. This is achieved by the insertion of LLC UI Dummy commands into the TBF. The FBI bit in the RLC

3 Um interface – user plane

header is set to the value 0 unless the network releases the TBF, in which case the FBI bit is set to the value 1. If new data is received from the upper layers, the network stops sending filler information and resumes normal operation during RLC data block transfer. RLC data blocks are sent to the MS as required to prevent the expiry of timer T3190 for each TBF and as needed to poll the MS for the provision of PACCH uplink blocks.

BSS

T3190

Data Block FBI=0, RRBP=k Packet Downlink Ack/Nack LLC UI Dummy commands FBI=0, RRBP=l

T3190

Packet Downlink Ack/Nack LLC UI Dummy commands FBI=0, RRBP=m

T3190

Packet Downlink Ack/Nack

T3192

LLC UI Dummy commands FBI=1, RRBP=n

Figure 3-52 Delayed release of downlink TBF By delaying the release of a downlink TBF a TBF is kept alive longer, which reduces frequent TBF setups releases. With this, the throughput for bursty traffic such as web browsing and e-mails etc. is improved significantly.

Release of uplink TBF Countdown procedure The MS sends the Countdown Value (CV) in each uplink RLC data block to indicate the current number of remaining RLC data blocks for the uplink TBF. The countdown procedure starts when RLC data blocks include CV values lower than 15. When the MS transmits the last RLC data block currently in the send buffer for the TBF the RLC data block has CV set to the value 0.

Signalling in GPRS/EGPRS

When an EGPRS RLC/MAC block for data transfer consists of two RLC data blocks, a CV value is calculated for each block and the CV of the RLC/MAC header refers to the second RLC data block.

BSS Data Block CV=15 Data Block CV=15 Data Block CV=15 Data Block CV=14 Data Block CV=13 Data Block CV=1 Data Block CV=0 Packet Uplink Ack, FAI=1, RRBP=n Packet Control Ack

Figure 3-53 Countdown procedure The MS indicates the end of the TBF by sending the RLC data block with CV = 0. When the network detects the end of the TBF (i.e. when CV=0) it sends a Packet Uplink Ack/Nack message with the Final Ack Indicator (FAI) bit set to '1', includes a valid RRBP field in the RLC/MAC control block header. If the Packet Uplink Ack/Nack message has the FAI bit set to ‘1’ and the MS does not initiate the establishment of a new uplink TBF, the MS transmits the Packet Control Acknowledgement message and releases the TBF. If there are no other ongoing TBFs, the MS enters packet idle mode. If the Packet Uplink Ack/Nack message does not have the FAI bit set to '1', the MS repeats sending the last block with CV=0, until a Packet Uplink Ack/Nack message with FAI bit set to '1' is received for this TBF, however the block with CV=0 can not be retransmitted more than four times. If the network does not receive the Packet Control Acknowledgement message or the Packet Resource Request (establishment of a new uplink TBF) message for the TBF in the radio block indicated by the RRBP field, it retransmits the Packet Uplink Ack/Nack message for the TBF.

3 Um interface – user plane

(non onmode)) Countdown procedure (n on-extended UL TBF mode When the MS has started countdown procedure it is only allowed to transmit as many data block as declared in the CV field. When all blocks have been sent (and acknowledged in case of acknowledged TBF mode) the uplink TBF is released. If the RLC entity of the MS receives new data from upper layers after the countdown procedure was started it has to release the uplink TBF after the last ‘old’ data block has been sent. In order to send ‘new’ packets a new uplink TBF has to be established.

BSS

new LLC

Data Block CV=15 Data Block CV=15 Data Block CV=15 Data Block CV=14 Data Block CV=13 Data Block CV=1 Data Block CV=0 Packet Uplink Ack, FAI=1, RRBP=n Packet Resource Request

Figure 3-54 Countdown in non-extended uplink TBF mode

Countdown procedure (extended UL TBF mode) In an uplink TBF operating in extended uplink TBF mode, the CV indicate the current number of RLC data blocks that has not been transmitted in the uplink TBF. The MS recalculates the CV for any untransmitted RLC data block when the RLC entity of the MS receives new data from upper layers for transmission in the uplink TBF.

Signalling in GPRS/EGPRS

BSS Data Block CV=15 Data Block CV=15 Data Block CV=15 Data Block CV=14 Data Block CV=15 Data Block CV=14

new LLC

Data Block CV=1 Data Block CV=0 Packet Uplink Ack, FAI=1, RRBP=n Packet Control Acknowledgement

Figure 3-55 Countdown in extended uplink TBF mode

Extended uplink TBF mode Network support of the extended uplink TBF mode is indicated by the NW_EXT_UTBF parameter that is broadcast on either BCCH or PBCCH. The extended uplink TBF mode is a part of the GERAN Feature Package 1. A MS indicating support of GERAN Feature Package 1 in the MS Classmark 3 supports the extended uplink TBF mode. In extended uplink TBF mode, an uplink TBF may be maintained during temporary inactive periods, where the MS has no RLC information to send, for up to 5s. During the temporary inactive periods, the MS may stop sending RLC data block. The network continue allocating the MS uplink radio blocks during the inactivity period allowing the MS to continue the transfer of RLC data blocks, when a new RLC data block becomes available. When the MS is allocated an uplink radio block and there is no RLC data block ready to send for this TBF, the MS sends an RLC/MAC control block in each uplink radio block allocated by the network. The network may allow, via the EXT_UTBF_NODATA parameter broadcast in GPRS Cell Options, any MS during extended uplink TBF mode not to send any Packet Uplink Dummy Control Block message when there is no other RLC/MAC block ready to send for this TBF. During a period when the network does not receive any RLC data blocks from the MS, the network may periodically send a PACKET UPLINK ACK/NACK message to the MS to prevent timer T3184 from expiring. 100

3 Um interface – user plane

The network may initiate the release an uplink TBF by sending a Packet Uplink Ack/Nack message with the Final Ack Indicator set to ‘1’ and a valid RRBP field. Than the MS transmits the Packet Control Acknowledgement or Packet Resource Request message to establish a new uplink TBF and release the old TBF.

BSS Data Block CV=0 Packet Uplink Ack/Nack FAI=0

T3184

USF Packet UL Dummy Block Packet Uplink Ack/Nack FAI=0

Packet Uplink Ack/Nack FAI=1, RRBP=n Packet Control Acknowledgement

Figure 3-56 Extended uplink TBF mode

GPRS RLC/MAC block structure Different RLC/MAC block structures are defined for data transfers and for control message transfers. The RLC/MAC block structures for data transfers are different for GPRS and EGPRS, whereas the same RLC/MAC block structure is used for control message transfers. The RLC/MAC block for GPRS data transfer consists of a MAC header and an RLC data block. The RLC data block consists of an RLC header, an RLC data unit and spare bits. The RLC data unit contains octets from one or more upper layer PDUs. The RLC/MAC block for control message transfer consists of a MAC header and an RLC/MAC control block.

101

Signalling in GPRS/EGPRS

RLC/MAC block RLC data block

MAC header RLC header

RLC data unit RLC/MAC control block

MAC header

RLC/MAC control block

Figure 3-57 RLC/MAC block structure The RLC data block consists of an RLC header, an RLC data unit, and spare bits. An RLC/MAC block containing an RLC data block may be encoded using any of the available channel coding schemes CS-1, CS-2, CS-3, or CS-4. Channel Coding Scheme

RLC data block size

CS-1

CS-2

CS-3

CS-4

Figure 3-58 RLC data block size

Downlink RLC data block The Downlink RLC data block together with its MAC header is formatted as shown in Fig. 3-59. 8

Payload Type

RRBP

S/P

USF

TFI BSN

MAC header FBI

Octet 1

Octet 2

Length indicator

Octet 3 (optional)

Length indicator

Octet M (optional) Octet M+1

RLC data

Octet N2 spare

Figure 3-59 Downlink RLC data block with MAC header

102

3 Um interface – user plane

Payload Type The Payload Type field indicates the type of data contained in remainder of the RLC/MAC block: 00

RLC/MAC block contains an RLC data block.

0 1 RLC/MAC block contains an RLC/MAC control block that does not include the optional octets of the RLC/MAC control header. 1 0 In the downlink direction, the RLC/MAC block contains an RLC/MAC control block that includes the optional first octet of the RLC/MAC control header. In the uplink direction, this value is reserved. 11

Reserved.

RRBP The Relative Reserved Block Period (RRBP) value specifies a single uplink block in which the MS is allowed to transmit a single block in the uplink direction. If the RRBP field is received as part of an ‘RLC/MAC control block’, the MS transmits a Packet Control Acknowledgement message in the uplink radio block specified. If the RRBP field is received as part of an ‘RLC/MAC data block’, the MS transmit a PACCH block in the specified uplink radio block. RRBP value indicates the number of TDMA frames (13, 17 or 18, 21 or 22, 26), the MS has to wait before transmitting the uplink RLC/MAC block. The delay is relative to the TDMA frame of the downlink block containing the RRBP value.

S/P The Supplementary/Polling (S/P) bit is used to indicate whether the RRBP field is valid or not valid.

USF The Uplink State Flag (USF) field is sent in all downlink RLC/MAC blocks and indicates the owner or use of the next uplink radio block on the same timeslot. The USF field is three bits in length and eight different USF values can be assigned, except on PCCCH, where the value '111' (USF=FREE) indicates that the corresponding uplink radio block contains PRACH.

103

Signalling in GPRS/EGPRS

PR The Power Reduction (PR) field indicates the power level reduction of the current RLC block. If downlink power control is not used, the MS ignores the PR field.

TFI In RLC data blocks, the Temporary Flow Identity (TFI) identifies the Temporary Block Flow (TBF) to which the RLC data block belongs. For the downlink and the uplink TFI the TFI field is 5 bits in length and are encoded as a binary number with range 0 to 31. In downlink RLC/MAC control blocks, the TFI identifies the Temporary Block Flow (TBF) to which the RLC/MAC control message contained in the downlink RLC/MAC control block relates. If present, this field indicates the MS to which the control message is addressed. If this field is not present all MS interprets the contents of the control message.

FBI FBI The Final Block Indicator (FBI) bit indicates that the downlink RLC data block is the last RLC data block of the downlink TBF.

BSN The Block Sequence Number (BSN) field carries the sequence number of each RLC data block within the TBF.

E The Extension (E) bit is used to indicate the presence of an optional octet in the RLC data block header (extension octet follows immediately / no extension octet follows).

Length Indicator The Length Indicator (LI) is used to delimit upper layer PDUs within the RLC data block. The first LI indicates the number of octets of the RLC data field belonging to the first Upper Layer PDU, the second LI indicates the number of octets of the RLC data field belonging to the second upper layer PDU, etc. Only the last segment of any upper layer PDU of a TBF (either this segment carries the entire Upper Layer PDU or not) is identified with a LI within the corresponding RLC data block.

104

3 Um interface – user plane

M The More (M) bit, along with the E bit and the LI, are used to delimit LLC PDUs within a TBF. When the M bit is present it indicates whether or not another LLC PDU follows the current one within the RLC data block.

RLC data The RLC data field contains octets from one or more upper layer PDUs. The RLC data field may contain parts of one or two upper layer PDUs and all of an arbitrary number of Upper Layer PDUs. The E bit, the M bit, and the Length Indicator delimit the RLC data field into upper layer PDUs. If the last upper layer PDU of a downlink TBF or an uplink RLC data block with CV = 0 does not fill the entire RLC data field, an extension octet is used to indicate the number of valid RLC data octets. The remainder of the RLC data field is filled with filler octets with the value '00101011'. Only the last RLC data block of a downlink TBF or an uplink RLC data block with CV = 0 may contain filler octets. If an uplink TBF is continued after the RLC data block with CV = 0, the next upper layer PDU starts with the first octet of the RLC data field of the next in sequence RLC data block.

Uplink RLC data block The Uplink RLC data block together with its MAC header is formatted as shown in Fig. 3-60. 7

spare

Countdown Value

MAC header

Octet 1

Octet 2

TFI BSN Length indicator

Octet 3 (optional)

Length indicator

Octet M (optional) Octet M+1 Octet M+2

TLLI

Octet M+3 Octet M+4

PFI

optional

Payload Type

Octet M+5 Octet M+6

RLC data Octet N spare

Figure 3-60 Uplink RLC data block with MAC header

105

Signalling in GPRS/EGPRS

Countdown Value The Countdown Value (CV) field is sent by the MS to allow the network to calculate the number of RLC data blocks remaining for the current uplink RLC entity.

SI The Stall Indicator (SI) bit indicates whether the mobile's RLC transmit window can advance (i.e. is not stalled) or can not advance (i.e. is stalled).

R The Retry (R) bit indicates whether the MS transmitted the Channel Request message, Packet Channel Request message, or EGPRS Packet Channel Request message one time or more than one time during its most recent channel access.

PI The PFI Indicator (PI) indicates the presence of the optional PFI field.

TI The TLLI Indicator (TI) bit indicates the presence of an optional TLLI field within the RLC data block.

TLLI The TLLI field contains a Temporary Logical Link Identifier (TLLI).

PFI The PFI field contains a Packet Flow Identifier (PFI).

RLC/MAC control control blocks The RLC/MAC control block consists of a control message contents field and in the downlink direction an optional control header. An RLC/MAC control blocks is always encoded using the coding scheme CS-1.

Downlink RLC/MAC control block The Downlink RLC/MAC control block together with its MAC header is formatted as shown in Fig. 3-61.

106

3 Um interface – user plane

Payload Type RBSN

4 S/P

RRBP

2 USF

RTI

FS TFI

PR RBSNe

FSe

1 MAC header AC D

spare

Octet 1 (optional) Octet 2 (optional) Octet 2/3 (optional) Octet M

Control Message Contents Octet 21 Octet 22

Figure 3-61 DL RLC/MAC control block together with its MAC header

RBSN The Reduced Block Sequence Number (RBSN) bit carries the sequence number of the downlink RLC/MAC control blocks. The RBSN bit is encoded as a binary number with range 0 to 1.

RTI The Radio Transaction Identifier (RTI) field is used to group the downlink RLC/MAC control blocks that make up an RLC/MAC control message and identifies the segmented control message sequence with which the downlink RLC/MAC control block is associated. The RTI field is five bits in length with range 0 to 31.

FS The Final Segment (FS) bit indicates that the downlink RLC/MAC control block contains the final segment of an RLC/MAC control message except when it is sent using extended RLC/MAC control message segmentation.

AC The Address Control (AC) bit is used to indicate the presence of the optional TFI/D octet in the header of downlink RLC/MAC control blocks.

D The Direction (D) bit indicates the direction of the TBF identified by the TFI field in the downlink RLC/MAC control block header (uplink TBF, downlink TBF).

RBSNe The Reduced Block Sequence Number extension (RBSNe) field together with the RBSN bit indicate the sequence number of the downlink RLC/MAC control blocks of an RLC/MAC control message segmented using extended

107

Signalling in GPRS/EGPRS

RLC/MAC control message segmentation. The RBSNe field is encoded as a binary number with range 0 to 7. Along with the FS bit and the FSe bit, they allow for extended RLC/MAC control message segmentation.

FSe The Final Segment extension (FSe) bit indicates that the downlink RLC/MAC control block contains the final segment of an RLC/MAC control message segmented using extended RLC/MAC control message segmentation. The FSe bit is only present from the second RLC/MAC control block onwards.

Control message contents The Control message contents field contains exactly one segment from one RLC/MAC control message field (i.e. RLC/MAC control block).

Uplink RLC/MAC control block The Uplink RLC/MAC control block together with its MAC header is formatted as shown in Fig. 3-62. 8

Payload Type

4 spare

1 R

MAC header Octet 1 Octet 2 Octet 3

Control Message Contents

Octet 21 Octet 22

Figure 3-62 Uplink RLC/MAC control block together with its MAC header

EGPRS RLC/MAC block structure The RLC/MAC block for EGPRS data transfer consists of a combined RLC/MAC header and one or two RLC data blocks. Each RLC data blocks contain octets from one or more upper layer PDUs. RLC/MAC block

RLC/MAC header

RLC data block 1

RLC data block 2 MCS-7, MCS-8 and MCS-9 only

Figure 3-63 EGPRS RLC/MAC block structure

108

3 Um interface – user plane

In each transfer direction, uplink and downlink, three different header types are defined. Which header type that is used depends on the Modulation and Coding Scheme (MCS).

EGPRS RLC data blocks and RLC/MAC headers The EGPRS RLC data block consists of a FBI (downlink) or TI (uplink) field and an E field followed by an EGPRS RLC data unit The size of the EGPRS RLC data unit for each of the MCSs is shown in Fig. 3-64. Channel Coding Scheme

EGPRS RLC data unit size

Family

MCS-1

MCS-2

MCS-3

MCS-4

MCS-5

MCS-6

MCS-7

2*56

MCS-8

2*68

MCS-9

2*74

The three families of EGPRS RLC data blocks based on a common size basis (22, 28 and 37 octets) enable link adaptation retransmission.

Figure 3-64 EGPRS RLC data unit size

EGPRS downlink RLC data block The EGPRS downlink RLC data blocks are formatted according to Fig. 3-65. 8

FBI

Length indicator

Octet 1 (optional)

Octet M (optional) Octet M+1

RLC data Octet N

Figure 3-65 EGPRS downlink RLC data block

109

Signalling in GPRS/EGPRS

Length Indicator The Length Indicator (LI) is used to delimit Upper Layer PDUs within the RLC data block. The first Length Indicator indicates the number of octets of the RLC data field belonging to the first Upper Layer PDU, the second Length Indicator indicates the number of octets of the RLC data field belonging to the second Upper Layer PDU, etc. Only the last segment of any Upper Layer PDU, including those with only one segment, is identified with a Length Indicator. The length indicator is placed in the RLC data block corresponding to the last segment of the Upper Layer PDU, unless the Upper Layer PDU without the corresponding LI field fills the RLC data block precisely. In that case, the Length Indicator is placed as the first Length Indicator in the next in sequence RLC data block and take the value 0. If the Upper Layer PDU does not fill the current RLC data block, a Length Indicator with value 127 (111 1111) is included as the last Length Indicator of the current RLC data block, indicating that there is no following Upper Layer PDU in this RLC data block. If the Upper Layer PDU does not fill the RLC data block and there is only one octet left, then the Length Indicator corresponding to the Upper Layer PDU is the last Length Indicator field that is included in the RLC data block. In case an Upper Layer PDU cannot be transmitted completely in the current RLC data block and will not be continued in the next in-sequence RLC data block, the corresponding Length Indicator have the value 127. The final RLC data block of a TBF has a Length Indicator field corresponding to the final Upper Layer PDU unless the final Upper Layer PDU fills the RLC data block precisely. If the final Upper Layer PDU fills the final RLC data block precisely, the final Upper Layer PDU is sent without a corresponding Length Indicator field. The Length Indicator field is 7 bits in length and is encoded as a binary number. The valid values are the values ranging from 0 to 74 and the value 127. All other values are reserved.

EGPRS Uplink RLC data block The EGPRS uplink RLC data block is formatted according to Fig. 3-66.

110

3 Um interface – user plane

Length indicator

Octet 1 (optional)

Length indicator

Octet M (optional) Octet M+2

TLLI

Octet M+3

optional

Octet M+1

Octet M+4 PFI

Octet M+6

RLC data Octet N

Figure 3-66 Uplink EGPRS RLC data block

EGPRS Downlink RLC/MAC header The EGPRS combined downlink RLC/MAC header for MCS-7, MCS-8 and MCS-9 (header type 1) is shown in Fig. 3-67 as an example of the downlink EGPRS combined RLC/MAC header. 8

TFI

BSN1

USF

ES/P

RRBP

Octet 1

TFI

Octet 2

BSN1 BSN2 CPS

Octet 3 BSN1 BSN2

Octet 4 Octet 5

Figure 3-67 EGPRS downlink RLC/MAC header (MCS-7 – MCS-9) EGPRS Supplementary/Polling (ES/P) Field The ES/P field is used to indicate whether the RRBP field is valid or not valid, and what fields the next uplink control block contains. CPS In EGPRS header, the Coding and Puncturing Scheme indicator field (CPS) is used to indicate the kind of channel coding and puncturing used for data blocks.

RLC/MAC EGPRS Uplink RLC /MAC header The EGPRS combined uplink RLC/MAC header for MCS-7, MCS-8 and MCS-9 (header type 1) is shown in Fig. 3-68 as an example of the uplink EGPRS combined RLC/MAC header.

111

Signalling in GPRS/EGPRS

TFI

Countdown Value BSN1

TFI BSN1

BSN2 PI

Octet 2 Octet 3

BSN2 spare

Octet 1

Octet 4 CPS

RSB spare

Octet 5 Octet 6

Figure 3-68 EGPRS uplink RLC/MAC header (MCS-7 – MCS-9) RSB The Resent Block Bit (RSB) indicates whether any of the RLC data blocks contained within the EGPRS radio block have been sent previously.

GSM RF – Physical Layer The Physical Layer represents functions required to transfer the bits over the physical channels on the radio medium. The physical layer consists of functions like channel coding for error detection, error correction, interleaving, burst formatting, and modulation.

Channel Coding Four coding schemes, CS-1 to CS-4, are defined for the GPRS packet data traffic channels. For all other GPRS packet control channels than Packet Random Access Channel (PRACH) and Packet Timing Advance Control Channel on Uplink (PTCCH/U), coding scheme CS-1 is always used. For access bursts on PRACH, two coding schemes are specified. The lower coding schemes have a high amount of channel coding and give a low data rate. The higher coding schemes have less channel coding and give a higher data rate. The coding scheme that offers the best performance varies depending on the radio link quality. Fig. 3-69 below shows the performance (i.e. throughput) of the coding schemes as a function of the radio link quality (C/I). CS-1 offers the highest throughput when the radio link quality is poor while CS-4 offers the best performance in good radio conditions.

112

Throughput per channel kb/s

3 Um interface – user plane

CS-1 20

CS-2 CS-3 CS-4

15 C/I [dB]

Figure 3-69 GPRS CS performance Nine Modulation and Coding Schemes, MCS-1 to MCS-9, are defined for the EGPRS packet data traffic channels. For all EGPRS packet control channels the corresponding GPRS control channel coding is used. MSs supporting EGPRS supports MCS-1 to MCS-9 in downlink and MCS-1 to MCS-4 in uplink. In case an MS supporting EGPRS is 8-PSK capable in uplink, it also supports MCS-5 to MCS-9 in uplink. 60

MCS-9 MCS-8

Throughput per channel kb/s

50 MCS-7

MCS-6

MCS-5

MCS-4 MCS-3 MCS-2 MCS-1

0 5

40 C/I [dB]

Figure 3-70 EGPRS MCS performance

113

Signalling in GPRS/EGPRS

GPRS PDTCH Four different coding schemes, CS-1 to CS-4, are defined for the GPRS Radio Blocks carrying RLC data blocks. The block structures of the CS are shown in Fig. 3-71 and Fig. 3-72. Radio Block USF

RLC/MAC info

BCS

rate 1/2 convolutional coding

puncturing

456 bits

Figure 3-71 Radio Block structure for CS-1 to CS-3 Radio Block USF

RLC/MAC info

BCS

block code

456 bits

Figure 3-72 Radio Block structure for CS-4 The first step of the coding procedure is to add a Block Check Sequence (BCS) for error detection. For CS-1 - CS-3, the second step consists of pre-coding USF (except for CS-1), adding four tail bits and a half rate convolutional coding for error correction that is punctured to give the desired coding rate. For CS-4 there is no coding for error correction.

114

3 Um interface – user plane

Scheme

Code rate

USF

Pre-coded USF

Radio Block excl. USF & BCS

BCS

Tail

CS-1

1/2

181

456

9.05

CS-2

≈2/3

268

588

132

13.4

CS-3

≈3/4

312

676

220

15.6

CS-4

428

456

21.4

Coded Punctured Data rate bits bits kb/s

Figure 3-73 Coding parameters for GPRS coding schemes CS-1 is the same coding scheme as specified for SACCH. It consists of a half rate convolutional code for FEC and a 40 bit FIRE code for BCS (and optionally FEC). CS-2 and CS-3 are punctured versions of the same half rate convolutional code as CS-1 for FEC. CS-4 has no FEC. CS-2 to CS-4 uses the same 16 bit CRC for BCS. The CRC is calculated over the whole uncoded RLC Data Block including MAC Header. The USF has 8 states, which are represented by a binary 3 bit field in the MAC Header. For CS-1, the whole Radio Block is convolutionally coded and USF needs to be decoded as part of the data. All other coding schemes generate the same 12 bit code for USF. The USF can be decoded either as a block code or as part of the data. In order to simplify the decoding, the stealing bits of the block are used to indicate the actual coding scheme.

EGPRS PDTCH Nine different modulation and coding schemes, MCS-1 to MCS-9, are defined for the EGPRS Radio Blocks. The block structure of the MCS-6 is shown in Fig. 3-74, as an example. The MCSs are divided into different families A, B and C. Each family has a different basic unit of payload: 37 (and 34), 28 and 22 octets respectively. Different code rates within a family are achieved by transmitting a different number of payload units within one Radio Block. For families A and B, 1, 2 or 4 payload units are transmitted, for family C, only 1 or 2 payload units are transmitted. When 4 payload units are transmitted (MCS-7, MCS-8 and MCS-9), these are splitted into two separate RLC blocks (i.e. with separate sequence numbers and BCSs). These blocks in turn are interleaved over two bursts only, for 115

Signalling in GPRS/EGPRS

MCS-8 and MCS-9. For MCS-7, these blocks are interleaved over four bursts. All the other MCSs carry one RLC block which is interleaved over four bursts. When switching to MCS-3 or MCS-6 from MCS-8, 6 padding octets are added to the data octets. 37 octets

37 octets

Family C

Family A

37 octets MCS-3

MCS-6

22 octets MCS-1

MCS-4

37 octets

MCS-3 1st part

MCS-3 2nd part

6+31 octets

37 octets

28 octets

Family B

Family A padding

MCS-9

6+31 octets

22 octets

28 octets

MCS-2 MCS-5 MCS-7

MCS-6 34 octets

34 octets

MCS-8

Figure 3-74 General description of MCSs for EGPRS To ensure strong header protection, the header part of the Radio Block is independently coded from the data part of the Radio Block (8 bit CRC calculated over the header -excl. USF- for error detection, followed by rate 1/3 convolutional coding –and eventually puncturing- for error correction). 3 bits

USF

33 bits RLC/MAC header

612 bits

HCS E FBI

Data 592 bits (74 oct)

BCS

rate 1/3 convolutional coding

36 bits

99 bits

1836 bits

+1 bit

SB=8

36 bits

puncturing

100 bits

1248 bits 1392 bits

Figure 3-75 Coding and puncturing for MCS-6 The USF has 8 states, which are represented by a binary 3 bit field in the MAC header. The USF is encoded to 12 symbols similarly to GPRS, (i.e., 12 bits for GMSK modes and 36 bits for 8PSK modes). The FBI (Final Block Indicator) bit and the E (Extension) bit do not require extra protection: they are encoded along with the data part. 116

3 Um interface – user plane

The first step of the coding procedure is to add a Block Check Sequence (BCS) for error detection. The second step consists of adding six tail bits (TB) and a 1/3 rate convolutional coding for error correction that is punctured to give the desired coding rate. The bits indicating the MCS used are in the coded header. In both 8PSK and GMSK modes the stealing bits (SB) of the block are used to indicate the header formats. There are eight SB for 8PSK mode which allow indicating four header formats. There are twelve SB for GMSK mode which allow indicating two header formats: the first eight of the twelve SB indicate CS-4.

PACCH, PBCCH, PAGCH, PPCH and PTCCH The channel coding for the PACCH, PBCCH, PAGCH, PPCH and downlink PTCCH is the same as the coding scheme CS-1. The coding scheme used for uplink PTCCH is the same as for PRACH.

PRACH Two types of packet access burst may be transmitted on the PRACH: an 8 information bits access burst or an 11 information bits access burst called the extended packet access burst. The channel coding used for the burst carrying the 8 data bit packet access uplink message is identical to the coding of the access burst as defined for random access channel in GSM. The channel coding for 11 bit access burst is the punctured version of the same coding as used for 8 bit access burst.

Interleaving and burst burst formatting 456 bits (GMSK) / 1392 (8-PSK)

CS / MCS

Figure 3-76 Interleaving and burst formatting 117

Signalling in GPRS/EGPRS

In case when GMSK modulation is used channel coder provides 456 bits for every RLC/MAC block which are than interleaved over four normal bursts. In case when 8-PSK modulation is used channel coder provides 1392 bits for every RLC/MAC block which are interleaved over four 8-PSK bursts.

Modulation The modulation technique used in GSM and GPRS is called Gaussian Minimum Shift Keying (GMSK). This is a narrow-band, digital modulation technique, which is based on phase shift keying. This can be visualized in a so-called I/Q-diagram, see Fig. 3-77. Transmission of a bit that is equal to the previously transmitted bit ( d i = d i −1 ) corresponds to +½ π increment of the phase. Consequently, transmission of a bit that is not equal to the previously transmitted bit ( d i ≠ d i −1 ) corresponds to -½ π decrement of phase. Every symbol that is transmitted represents one bit. The symbol rate and the bit rate are here equal: 271 ks/s (kilo symbols per second) = 271 kb/s. To be able to have higher bit rates per time slot, it is needed to change the modulation type. 8-PSK is specified to reuse channel structure, channel width, channel coding and the already existing mechanisms and functionality for GPRS and HSCSD. 8-PSK has the same spectrum parameters as GMSK does. This makes it possible to integrate 8-PSK channels into an existing frequency plan and to assign new 8-PSK capable channels in the same way as standard GSM channels. 8-PSK can offer higher bit rates however at the same time it is more sensitive to transmission problems. In 8-PSK three consecutive bits are mapped onto one symbol in the I/Q-plain. With the same symbol rate as in GMSK of 271 ks/s, the bit rate now becomes 813 kbits/s.

(0,1,0)

(0,0,0)

(0,1,1)

d i = d i −1

I d i ≠ d i −1

I (0,0,1)

(1,1,1)

(1,0,1)

(1,1,0) (1,0,0)

GMSK

8-PSK

Figure 3-77 GMSK and 8-PSK modulation

118