Signalling in GPRS/EGPRS

677 views

Published on

“Signalling in GSM BSS” course focuses on signalling between GSM nodes within Base Station
System (BSS). During the course all protocols and signalling procedures on all interfaces within BSS
are presented in details. The organisation of channels of air interface and cell parameters is also
widely covered in the course. The course also describes parts of the Signalling System No. 7 that are
relevant for BSS and presents co-operation between Core Network and BSS during procedures like
call set-up and location update.

Published in: Technology
  • Be the first to comment

Signalling in GPRS/EGPRS

  1. 1. 3 Um interface – user plane 51 Chapter 3Chapter 3Chapter 3Chapter 3 Um interfaceUm interfaceUm interfaceUm interface –––– user planeuser planeuser planeuser plane TopicTopicTopicTopic PagePagePagePage PDP .................................................................................................................. 53 SNDCP............................................................................................................. 54 LLC.................................................................................................................. 60 RLC/MAC........................................................................................................ 78 GSM RF – Physical Layer ............................................................................. 112
  2. 2. Signalling in GPRS/EGPRS 52 This page is intentionally left blank
  3. 3. 3 Um interface – user plane 53 PDPPDPPDPPDP 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. App. GGSNSGSNBSSMS Physical Network Service BSSGP LLC SNDCP N E T IP UDP/TCP GTP --Gn------Gb---PhysicalGSM RF---Um--GSM RF N E T Network Service RLC MAC RLC MAC IPBSSGP UDP/TCPLLC GTPSNDCP PDPPDP App. GGSNSGSNBSSMS Physical Network Service BSSGP LLC SNDCP N E T IP UDP/TCP GTP --Gn------Gb---PhysicalGSM RF---Um--GSM RF N E T Network Service RLC MAC RLC MAC IPBSSGP UDP/TCPLLC GTPSNDCP PDPPDP Figure 3-1 Packet Data Protocol (PDP) IPIPIPIP 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. PPPPPPPPPPPP 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).
  4. 4. Signalling in GPRS/EGPRS 54 SNDCPSNDCPSNDCPSNDCP 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. SNDCP Packet Data Protocol NSAPI N-PDU SAPI SN-PDU Packet Data Protocol Packet Data Protocol . . . 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.
  5. 5. 3 Um interface – user plane 55 ServicesServicesServicesServices 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 variable- length 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. SubfunctionsSubfunctionsSubfunctionsSubfunctions 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.
  6. 6. Signalling in GPRS/EGPRS 56 segmentationsegmentation control compressor SN-UNITDATA.request LLCLL-DATA.request LL-UNITDATA.request SN-DATA PDU SN-UNITDATA PDU SN-DATA.request header dataN-PDU Network Layer SNDCP data compressor compare header to previous differencebig small headerheaderheader header delta M=0 M=1 M=1 Segmented N-PDU #1 control compressor data compressor M=0 M=1 M=1 Segmented N-PDU #2 M=0 M=1 Segmented N-PDU #1 #3 #2 #1 #2 #1 LLC header LLC header segmentationsegmentation control compressor SN-UNITDATA.request LLCLL-DATA.request LL-UNITDATA.request SN-DATA PDU SN-UNITDATA PDU SN-DATA.request header dataN-PDU headerheader datadataN-PDU Network Layer SNDCP data compressor compare header to previous differencebig small headerheaderheader header delta compare header to previous differencebig small headerheaderheader headerheaderheaderheaderheaderheader headerheader deltadelta M=0 M=1 M=1 Segmented N-PDU #1 M=0 M=1 M=1 M=0M=0 M=1M=1 M=1 Segmented N-PDU #1 control compressor data compressor M=0 M=1 M=1 Segmented N-PDU #2 M=0 M=1 Segmented N-PDU #1 #3 #2 #1 #2 #1 M=0 M=1 M=1 M=0 M=1 M=1 Segmented N-PDU #2 M=0 M=1 M=0 M=1 Segmented N-PDU #1 #3 #2 #1 #3 #2 #1 #2 #1 #2 #1 LLC header LLC header LLC header LLC header Figure 3-3 SNDCP model SNSNSNSN----PDU formatsPDU formatsPDU formatsPDU 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. N Data segment … N-PDU number - acknowledged mode3 PCOMPDCOMP2 NSAPIMTFXOct 1 12345678Bit N Data segment … N-PDU number - acknowledged mode3 PCOMPDCOMP2 NSAPIMTFXOct 1 12345678Bit Figure 3-4 SN-Data PDU format N Data segment … N-PDU number - unacknowledged mode (continued)4 Segment number3 PCOMPDCOMP2 NSAPIMTFXOct 1 12345678Bit N-PDU number unacknowledged mode N Data segment … N-PDU number - unacknowledged mode (continued)4 Segment number3 PCOMPDCOMP2 NSAPIMTFXOct 1 12345678Bit N-PDU number unacknowledged mode Figure 3-5 SN-Unitdata PDU format
  7. 7. 3 Um interface – user plane 57 Spare bit (X):Spare bit (X):Spare bit (X):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):First segment indicator bit (F):First segment indicator bit (F):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 SN- Unitdata PDU format. Also the octet for N-PDU number for acknowledged mode is not included in the SN-Data PDU format. 1 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. SNSNSNSN----PDU Type (T):PDU Type (T):PDU Type (T):PDU Type (T): 0 SN-DATA PDU. 1 SN-UNITDATA PDU. More bit (M):More bit (M):More bit (M):More bit (M): 0 Last segment of N-PDU. 1 Not the last segment of N-PDU, more segments to follow. NSAPI:NSAPI:NSAPI:NSAPI: 0 Escape mechanism for future extensions. 1 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. Data coData coData coData compression coding (DCOMP):mpression coding (DCOMP):mpression coding (DCOMP):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.
  8. 8. Signalling in GPRS/EGPRS 58 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. Protocol contrProtocol contrProtocol contrProtocol control information compression coding (PCOMP):ol information compression coding (PCOMP):ol information compression coding (PCOMP):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:Segment number:Segment number:Segment number: 0-15 Sequence number for segments carrying an N-PDU. NNNN----PDU numberPDU numberPDU numberPDU number ---- acknowledged mode:acknowledged mode:acknowledged mode:acknowledged mode: 0-255 N-PDU number of the N-PDU. NNNN----PDU numberPDU numberPDU numberPDU number ---- unacknowledged mode:unacknowledged mode:unacknowledged mode:unacknowledged mode: 0-4095 N-PDU number of the N-PDU. Data transfeData transfeData transfeData transferrrr Acknowledged modeAcknowledged modeAcknowledged modeAcknowledged 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.
  9. 9. 3 Um interface – user plane 59 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 LL- DATA.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 LL- DATA.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 N- PDU 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 Acknowledgement LL-DATA.req LL-DATA.ind LL-DATA.cnf SNDCP user SN-DATA.req SN-DATA.ind SNDCP LLC LLC SNDCP SNDCP user ReceiverOriginator Acknowledgement LL-DATA.req LL-DATA.ind LL-DATA.cnf SNDCP user SN-DATA.req SN-DATA.ind SNDCP LLC LLC SNDCP SNDCP user Receiver Figure 3-6 SNDCP acknowledged data transfer Unacknowledged modeUnacknowledged modeUnacknowledged modeUnacknowledged 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
  10. 10. Signalling in GPRS/EGPRS 60 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 LL- UNITDATA.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 LL- UNITDATA.req LL- UNITDATA.ind SNDCP user SN- UNITDATA.req SN- UNITDATA.ind SNDCP LLC LLC SNDCP SNDCP user Receiver Figure 3-7 SNDCP unacknowledged data transfer LLCLLCLLCLLC 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.
  11. 11. 3 Um interface – user plane 61 SGSNMSRLC/MAC L3 LLC BSSGP Signalling Signalling and data transfer Logical Link Management Entity LLGMM LLGMM LL3 LL5 LL9 LL11 TOM2 TOM8 LLSMS Multiplex Procedure Logical Link Entity SAPI=7 Logical Link Entity SAPI=8 Logical Link Entity SAPI=2 Logical Link Entity SAPI=11 Logical Link Entity SAPI=9 Logical Link Entity SAPI=5 Logical Link Entity SAPI=3 Logical Link Entity SAPI=1 LLC GRR BSSGP RLC/MAC BSSGP GPRS Mobility Management SNDCP TOM SMS SGSNMSRLC/MAC L3 LLC BSSGP Signalling Signalling and data transfer Logical Link Management Entity LLGMM LLGMM LL3 LL5 LL9 LL11 TOM2 TOM8 LLSMS Multiplex Procedure Logical Link Entity SAPI=7 Logical Link Entity SAPI=8 Logical Link Entity SAPI=2 Logical Link Entity SAPI=11 Logical Link Entity SAPI=9 Logical Link Entity SAPI=5 Logical Link Entity SAPI=3 Logical Link Entity SAPI=1 Logical Link Entity SAPI=7 Logical Link Entity SAPI=8 Logical Link Entity SAPI=2 Logical Link Entity SAPI=11 Logical Link Entity SAPI=9 Logical Link Entity SAPI=5 Logical Link Entity SAPI=3 Logical Link Entity SAPI=1 LLC GRR BSSGP RLC/MAC BSSGP GPRS Mobility Management SNDCP TOM SMS Figure 3-8 Functional model of the LLC layer Logical Link EntityLogical Link EntityLogical Link EntityLogical 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 procedureMultiplex procedureMultiplex procedureMultiplex 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.
  12. 12. Signalling in GPRS/EGPRS 62 Logical Link ManagementLogical Link ManagementLogical Link ManagementLogical 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 ManagementGPRS Mobility ManagementGPRS Mobility ManagementGPRS 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 ServiceShort Message ServiceShort Message ServiceShort 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 MessagesTunnelling Of MessagesTunnelling Of MessagesTunnelling 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 ModesLLC Transmission ModesLLC Transmission ModesLLC 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 LL- PDUs. Signalling and SMS are transferred in unacknowledged mode.
  13. 13. 3 Um interface – user plane 63 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. acknowledged mode unacknowledged mode protected unprotected LLC transmission modes Figure 3-9 LLC transmission modes NSAPI and TLLINSAPI and TLLINSAPI and TLLINSAPI 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.
  14. 14. Signalling in GPRS/EGPRS 64 IP address A SAP IP address B SAP NSAPI-1 NSAPI-2 TLLI SGSN GGSN associated with IP address A GGSN associated with IP address B IP IP Gi Gi 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 P- TMSI. 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 TLLIStructure of TLLIStructure of TLLIStructure 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.
  15. 15. 3 Um interface – user plane 65 Random G-RNTIRR1000 Part of the assigned G-RNTIGG0000 ReservedXXX010 ReservedXX0110 Auxiliary TLLIA01110 Random TLLIR11110 Foreign TLLITTTT01 Local TLLITTTT11 Type of TLLI 26 to 02728293031 bit number Random G-RNTIRR1000 Part of the assigned G-RNTIGG0000 ReservedXXX010 ReservedXX0110 Auxiliary TLLIA01110 Random TLLIR11110 Foreign TLLITTTT01 Local TLLITTTT11 Type of TLLI 26 to 02728293031 bit number bits in reserved rangesX bits derived from the assigned G-RNTIG bits in reserved rangesX bits in reserved rangesX bits derived from the assigned G-RNTIG bits derived from the assigned G-RNTIG bits chosen by the SGSNA bits chosen randomlyR bits derived from a P-TMSIT bits chosen by the SGSNA bits chosen by the SGSNA bits chosen randomlyR bits chosen randomlyR bits derived from a P-TMSIT bits derived from a P-TMSIT 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. SAPISAPISAPISAPI 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.
  16. 16. Signalling in GPRS/EGPRS 66 -Reserved1111 -Reserved1110 -Reserved1101 -Reserved1100 LL11User data 111011 -Reserved1010 LL9User data 91001 TOM8Tunnelling of messages 81000 LLSMSSMS0111 -Reserved0110 LL5User data 50101 -Reserved0100 LL3User data 30011 TOM2Tunnelling of messages 20010 LLGMMGPRS Mobility Management0001 -Reserved0000 SAP nameRelated serviceSAPI Figure 3-12 Allocation of SAPI values Frame structureFrame structureFrame structureFrame structure All LLC layer peer-to-peer entities exchanges frames conforming to the format shown in Fig. 3-13. (3 octets) Frame Check Sequence Field (variable length, max. N201 octets) Information Field (1-36 octets) Control Field Address Field (1 octet) 12345678 (3 octets) Frame Check Sequence Field (variable length, max. N201 octets) Information Field (1-36 octets) Control Field Address Field (1 octet) 12345678 Figure 3-13 LLC frame format
  17. 17. 3 Um interface – user plane 67 Address fieldAddress fieldAddress fieldAddress 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 fieldControl fieldControl fieldControl 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 fieldInformation fieldInformation fieldInformation 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) fieldFrame Check Sequence (FCS) fieldFrame Check Sequence (FCS) fieldFrame 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.
  18. 18. Signalling in GPRS/EGPRS 68 Control fieldControl fieldControl fieldControl field functionsfunctionsfunctionsfunctions The main function of the control field is discrimination between various frame types. The following frame types are defined: -NULL XIDXID FRMR- -SABM UA- Unnumbered -DISC DM- SACKSACK RNRRNR ACKACK Information + Supervisory RRRR ResponsesCommandsFormat UI - Figure 3-14 LLC frame types Unnumbered (U) framesUnnumbered (U) framesUnnumbered (U) framesUnnumbered (U) frames Set Asynchronous Balanced Mode (SABM) commandSet Asynchronous Balanced Mode (SABM) commandSet Asynchronous Balanced Mode (SABM) commandSet 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.) UA (optionally XID par.) ackmode ackmode Figure 3-15 ABM setup
  19. 19. 3 Um interface – user plane 69 Disconnect (DISC) commandDisconnect (DISC) commandDisconnect (DISC) commandDisconnect (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 DISC UA / DM ackmode ackmode Figure 3-16 ABM termination Unnumbered Acknowledgement (UA)Unnumbered Acknowledgement (UA)Unnumbered Acknowledgement (UA)Unnumbered Acknowledgement (UA) responseresponseresponseresponse 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) responseDisconnected Mode (DM) responseDisconnected Mode (DM) responseDisconnected 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.
  20. 20. Signalling in GPRS/EGPRS 70 SGSN DM ackmode ackmode Command #$?? SABM UA ackmode Figure 3-17 DM frame usage Frame Reject (FRMR) responseFrame Reject (FRMR) responseFrame Reject (FRMR) responseFrame 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 (#$??) ackmode ackmode Figure 3-18 FRMR frame usage
  21. 21. 3 Um interface – user plane 71 Exchange Identification (XID) command/responseExchange Identification (XID) command/responseExchange Identification (XID) command/responseExchange 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
  22. 22. Signalling in GPRS/EGPRS 72 NULL commandNULL commandNULL commandNULL 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. SGSN NULL BSS BSSGP + cell, TLLI SGSN NULL BSS BSSGP + cell, TLLI Figure 3-20 NULL frame usage Unconfirmed InformatioUnconfirmed InformatioUnconfirmed InformatioUnconfirmed Information (UI) framen (UI) framen (UI) framen (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 UI (L3 info) UI (L3 info) UI (L3 info) UI (L3 info) UI (L3 info) N(U)=0 N(U)=1 N(U)=0 N(U)=1 N(U)=2 unackmode Figure 3-21 UI frame usage Combined Information (I) and Supervisory (S) frameCombined Information (I) and Supervisory (S) frameCombined Information (I) and Supervisory (S) frameCombined Information (I) and Supervisory (S) framessss 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.
  23. 23. 3 Um interface – user plane 73 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) commandReceive Ready (RR) commandReceive Ready (RR) commandReceive Ready (RR) command / response/ response/ response/ 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 I+RR (L3 info) I+RR (L3 info) I+RR (L3 info) I+RR (L3 info) RR N(S)=0 N(S)=1 N(S)=3 ackmode I+RR (L3 info) N(R)=1 N(R)=1 I+RR (L3 info) RR N(S)=2 N(S)=4 N(R)=3 N(R)=5 N(R)=0 N(S)=0 N(R)=1 N(R)=1 N(R)=1 SABM UA Figure 3-22 RR frame usage Acknowledgement (ACK) commandAcknowledgement (ACK) commandAcknowledgement (ACK) commandAcknowledgement (ACK) command / response/ response/ response/ 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.
  24. 24. Signalling in GPRS/EGPRS 74 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. I+RR (L3 info) N(R)=0 I+RR (L3 info) I+RR (L3 info) I+RR (L3 info) N(S)=0 N(S)=1 ackmode I+RR (L3 info) N(S)=2 N(R)=0 SABM UA N(R)=0 N(R)=0 ACK N(R)=1 N(S)=1 N(R)=0 N(S)=3 SGSN Figure 3-23 ACK frame usage Selective Acknowledgement (SACK) commandSelective Acknowledgement (SACK) commandSelective Acknowledgement (SACK) commandSelective Acknowledgement (SACK) command / response/ response/ response/ 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 I+RR (L3 info) I+RR (L3 info) I+RR (L3 info) N(S)=0 N(S)=1 ackmode I+RR (L3 info) N(S)=2 N(R)=0 SABM UA N(R)=0 N(R)=0 SACK (0,1,0,...,n) N(R)=0 N(S)=5 N(R)=0N(S)=3 N(S)=4 N(R)=0 N(R)=0 I+RR (L3 info) I+RR (L3 info) N(R)=2 I+RR (L3 info) I+RR (L3 info) N(S)=2 N(S)=4 N(R)=0 Figure 3-24 SACK frame usage
  25. 25. 3 Um interface – user plane 75 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) commandReceive Not Ready (RNR) commandReceive Not Ready (RNR) commandReceive Not Ready (RNR) command / response/ response/ response/ 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 I+RR (L3 info)N(S)=0 N(S)=1 N(S)=2 N(R)=0 UA N(R)=0 N(R)=0 RNR N(S)=3 N(R)=4 RR N(R)=0 RR N(R)=0 RR N(R)=4 I+RR N(R)=0 I+RR (L3 info) I+RR (L3 info) ackmode SABM N(R)=0I+RR (L3 info)N(S)=3 Figure 3-25 RNR frame usage Other command field functionsOther command field functionsOther command field functionsOther command field functions Poll/Final bit (P/F)Poll/Final bit (P/F)Poll/Final bit (P/F)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.
  26. 26. Signalling in GPRS/EGPRS 76 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)Acknowledgement request bit (A)Acknowledgement request bit (A)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 CipheringCipheringCipheringCiphering This section describes how LLC interfaces with the GPRS ciphering algorithm. Ciphering algorithm interfaceCiphering algorithm interfaceCiphering algorithm interfaceCiphering 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.
  27. 27. 3 Um interface – user plane 77 Ciphering Algorithm Kc Input Output Direction Unciphered Frame Unciphered Frame Deciphered Frame Ciphered Frame MS or SGSN SGSN or MS Ciphering Algorithm Kc Input Output Direction Figure 3-28 GPRS ciphering environment Generation of InputGeneration of InputGeneration of InputGeneration 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.
  28. 28. Signalling in GPRS/EGPRS 78 RLC/MACRLC/MACRLC/MACRLC/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. address a data block to/from a certain MS control the access to the channel(s) shared by a number of MSs 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) MAC Medium Access Control RLC Radio Link Control address a data block to/from a certain MS control the access to the channel(s) shared by a number of MSs 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) MAC Medium Access Control RLC Radio Link Control Figure 3-29 RLC/MAC functions
  29. 29. 3 Um interface – user plane 79 MAC modesMAC modesMAC modesMAC modes Packet idle modePacket idle modePacket idle modePacket 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 modePacket transfer modePacket transfer modePacket 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 modeDual transfer modeDual transfer modeDual 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.
  30. 30. Signalling in GPRS/EGPRS 80 Packet Idle Mode Packet Transfer Mode Dual Transfer Mode no Temporary Block Flow (TBF) exists MS monitors the relevant paging subchannels on (P)CCCH 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 MS is allocated RR on a dedicated TCH MS is allocated TBFs on one or more PDCHs Packet Idle Mode Packet Transfer Mode Dual Transfer Mode no Temporary Block Flow (TBF) exists MS monitors the relevant paging subchannels on (P)CCCH 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 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 messagesRLC/MAC control messagesRLC/MAC control messagesRLC/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 Paging message: Packet Paging Request 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 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 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 TBFTBFTBFTBF 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.
  31. 31. 3 Um interface – user plane 81 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. TFITFITFITFI 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. 76543210TS -> MS 1 TFI = 1 MS 2 TFI = 2 MS 3 TFI = 3 MS 4 TFI = 1 GSM CS BPC GPRS PS PDCH 76543210TS -> MS 1 TFI = 1 MS 2 TFI = 2 MS 3 TFI = 3 MS 4 TFI = 1 GSM CS BPC GPRS PS PDCH 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.
  32. 32. Signalling in GPRS/EGPRS 82 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. USFUSFUSFUSF in dynamic allocation modein dynamic allocation modein dynamic allocation modein 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. 76543210TS -> MS4MS2MS2MS1UL TDMA GSM CS BPC GPRS PS PDCH 432USF 654TS 1 6 111USF 754TS 532USF 765TS 2USF 7TS 76543210TS -> USF=2USF=4USF=3USF=1DL TDMA MS 1 MS 2 MS 3 MS 4 76543210TS -> MS4MS2MS2MS1UL TDMA GSM CS BPC GPRS PS PDCH 432USF 654TS 1 6 111USF 754TS 532USF 765TS 2USF 7TS 76543210TS -> USF=2USF=4USF=3USF=1DL TDMA MS 1 MS 2 MS 3 MS 4 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
  33. 33. 3 Um interface – user plane 83 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 allocatiUSF in the extended dynamic allocatiUSF in the extended dynamic allocatiUSF in the extended dynamic allocationononon 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. 76543210TS -> MS2MS1UL TDMA 6 4 121USF 532TS 76543210TS -> USF=3DL TDMA MS 1 MS1MS1 MS1 MS2 USF=1 432USF 765TS MS 2 USF=0 USF=0 USF=0 USF=0 Figure 3-34 Usage of USF (Extended Dynamic Allocation) Multiplexing of GPRS and EGPRS TBFsMultiplexing of GPRS and EGPRS TBFsMultiplexing of GPRS and EGPRS TBFsMultiplexing 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.
  34. 34. Signalling in GPRS/EGPRS 84 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. SegmentationSegmentationSegmentationSegmentation Data block segmentationData block segmentationData block segmentationData 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=1, E=0, LIM=1, E=1, LIM=1, E=1, LIM=0, E=1, LI Figure 3-35 Data block segmentation
  35. 35. 3 Um interface – user plane 85 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 2 3 4 5 1 2 3 4 5 1 2 3 4 5 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 2 3 4 5 1 2 3 4 5 1 2 3 4 5 000...000 Figure 3-37 BSN - Block Sequence Number (unack mode)
  36. 36. Signalling in GPRS/EGPRS 86 Control message segmentationControl message segmentationControl message segmentationControl 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. BSS 1 RLC/MACcontrolmessages RTI=0 RBSN=0 FS=0 RTI=1 RBSN=0 FS=0 RTI=0 RBSN=1 FS=1 RTI=1 RBSN=1 FS=1 0 max 31 BSS 1 RLC/MACcontrolmessages RTI=0 RBSNe=0 FSe=0 RTI=0 RBSNe=1 FSe=0 RTI=0 RBSNe=2 FSe=0 0 max 31 RTI=0 RBSNe=n FSe=1 RTI=1 RBSN=1 FS=0 Figure 3-38 Control message segmentation AcknowledgeAcknowledgeAcknowledgeAcknowledgementsmentsmentsments Acknowledgement for control messageAcknowledgement for control messageAcknowledgement for control messageAcknowledgement 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.
  37. 37. 3 Um interface – user plane 87 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 DL UL RRBP Figure 3-39 Acknowledgement for control message Acknowledgement for data blocksAcknowledgement for data blocksAcknowledgement for data blocksAcknowledgement 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.
  38. 38. Signalling in GPRS/EGPRS 88 AcknowledgedAcknowledgedAcknowledgedAcknowledged GPRS TBFGPRS TBFGPRS TBFGPRS TBF modemodemodemode 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 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 retransmission Figure 3-40 Acknowledged GPRS UL TBF mode BSS Data Block BSN=20 Data Block BSN=21 Data Block BSN=22, RRBP=n Packet Downlink Ack/Nack SSN=20, RBB=(0,1) Data Block BSN=21 Data Block BSN=23 retransmission DL UL RRBP DL UL RRBP Figure 3-41 Acknowledged GPRS DL TBF mode
  39. 39. 3 Um interface – user plane 89 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. 3 4 5 1 2 CS-4 3 4 5 1 2 CS-4 4 5 CS-4 6 7 8 CS-2 4 5 CS-4 6 7 8 CS-2 Packet Downlink Ack/Nack (retransmit blocks 4 & 5) Packet Downlink Ack/Nack (retransmit blocks 4 & 5) BSS BSS BSS 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 AAAAcknowledged EGPRScknowledged EGPRScknowledged EGPRScknowledged EGPRS TBF mTBF mTBF mTBF modeodeodeode 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.
  40. 40. Signalling in GPRS/EGPRS 90 BSS Data Block BSN=20 Data Block BSN=21 Data Block BSN=22 EGPRS Packet Downlink Ack/Nack Data Block BSN=21 Data Block BSN=23 retransmission 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 MCS- 1, 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. 3 4 5 1 2 MCS-9 3 4 5 1 2 MCS-9 Packet Downlink Ack/Nack (retransmit blocks 4 & 5) Packet Downlink Ack/Nack (retransmit blocks 4 & 5) BSS BSS BSS In EGPRS TBF mode, for the retransmissions, the same or another MCS from the same family of MCSs may be selected 4 5 MCS-3 6 4 5 MCS-3 6 Figure 3-44 Retransmissions in EGPRS RLC/MAC Window Size (WS) is from 64 to 1024.
  41. 41. 3 Um interface – user plane 91 Unacknowledged mode operationUnacknowledged mode operationUnacknowledged mode operationUnacknowledged 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 TBFEstablishment of downlink TBFEstablishment of downlink TBFEstablishment of downlink TBF MS in Standby stateMS in Standby stateMS in Standby stateMS in Standby state The downlink TBF establishment procedure is illustrated in Fig. 3-45. Each step is explained in the list below. (Packet) Paging Request (P)PCH Packet Downlink Assignment (P)AGCH PACCH PACCH Packet Control Acknowledgement PDTCH PACCH BSS Cell Update 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
  42. 42. Signalling in GPRS/EGPRS 92 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 stateMS in Ready stateMS in Ready stateMS 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. Packet Downlink Assignment (P)AGCH PACCH PACCH Packet Control Acknowledgement PDTCH PACCH BSS 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.
  43. 43. 3 Um interface – user plane 93 Packet Downlink Assignment PACCH PACCH PACCH Packet Control Ack PDTCH PACCH BSS 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 TBFEstablishment of uplink TBFEstablishment of uplink TBFEstablishment 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.
  44. 44. Signalling in GPRS/EGPRS 94 (Packet) (EGPRS) Channel Request (P)RACH Packet Uplink Assignment (P)AGCH PACCH PACCH Packet Control Acknowledgement PDTCH PACCH BSS 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. (Packet) (EGPRS) Channel Request (P)RACH Packet Uplink Assignment (P)AGCH PACCH PACCH Packet Control Acknowledgement PDTCH PACCH BSS Packet Resource Request PACCH Packet Uplink Assignment PACCH Figure 3-49 UL TBF establishment – two-step setup
  45. 45. 3 Um interface – user plane 95 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. Packet Resource Request PACCH PACCH PACCH Packet Uplink Assignment PDTCH PACCH BSS Packet Control Ack PACCH Figure 3-50 UL TBF establishment in Packet Transfer Mode
  46. 46. Signalling in GPRS/EGPRS 96 Release of downlink TBFRelease of downlink TBFRelease of downlink TBFRelease 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 Packet Downlink Ack/Nack T3192 T3192 Figure 3-51 Release of downlink TBF Delayed release of downlink TBFDelayed release of downlink TBFDelayed release of downlink TBFDelayed 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
  47. 47. 3 Um interface – user plane 97 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 Data Block FBI=0, RRBP=k Packet Downlink Ack/Nack T3192 T3192 LLC UI Dummy commands FBI=0, RRBP=l Packet Downlink Ack/Nack LLC UI Dummy commands FBI=0, RRBP=m Packet Downlink Ack/Nack LLC UI Dummy commands FBI=1, RRBP=n T3190 Packet Downlink Ack/Nack T3190 T3190 BSS Data Block FBI=0, RRBP=k Packet Downlink Ack/Nack T3192T3192 T3192T3192 LLC UI Dummy commands FBI=0, RRBP=l Packet Downlink Ack/Nack LLC UI Dummy commands FBI=0, RRBP=m Packet Downlink Ack/Nack LLC UI Dummy commands FBI=1, RRBP=n T3190 Packet Downlink Ack/Nack T3190 T3190 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 TBFRelease of uplink TBFRelease of uplink TBFRelease of uplink TBF Countdown procedureCountdown procedureCountdown procedureCountdown 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.
  48. 48. Signalling in GPRS/EGPRS 98 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 Packet Control Ack Packet Uplink Ack, FAI=1, RRBP=n Data Block CV=15 Data Block CV=15 Data Block CV=14 Data Block CV=13 Data Block CV=1 Data Block CV=0 BSS Data Block CV=15 Packet Control Ack Packet Uplink Ack, FAI=1, RRBP=n Data Block CV=15 Data Block CV=15 Data Block CV=14 Data Block CV=13 Data Block CV=1 Data Block CV=0 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.
  49. 49. 3 Um interface – user plane 99 Countdown procedure (nCountdown procedure (nCountdown procedure (nCountdown procedure (nonononon----extendedextendedextendedextended ULULULUL TBF modeTBF modeTBF modeTBF 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 Data Block CV=15 Packet Resource Request Packet Uplink Ack, FAI=1, RRBP=n Data Block CV=15 Data Block CV=15 Data Block CV=14 Data Block CV=13 Data Block CV=1 Data Block CV=0 new LLC Figure 3-54 Countdown in non-extended uplink TBF mode Countdown procedure (extended UL TBF mode)Countdown procedure (extended UL TBF mode)Countdown procedure (extended UL 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.
  50. 50. Signalling in GPRS/EGPRS 100 BSS Data Block CV=15 Packet Control Acknowledgement Packet Uplink Ack, FAI=1, RRBP=n Data Block CV=15 Data Block CV=15 Data Block CV=14 Data Block CV=15 Data Block CV=1 Data Block CV=0 new LLC Data Block CV=14 Figure 3-55 Countdown in extended uplink TBF mode Extended uplink TBF modeExtended uplink TBF modeExtended uplink TBF modeExtended 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.
  51. 51. 3 Um interface – user plane 101 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 Packet Control Acknowledgement Packet Uplink Ack/Nack FAI=0 Data Block CV=0 USF Packet UL Dummy Block Packet Uplink Ack/Nack FAI=0 Packet Uplink Ack/Nack FAI=1, RRBP=n T3184 Figure 3-56 Extended uplink TBF mode GPRSGPRSGPRSGPRS RLC/MAC block structureRLC/MAC block structureRLC/MAC block structureRLC/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.
  52. 52. Signalling in GPRS/EGPRS 102 MAC header RLC header RLC data unit RLC data block RLC/MAC block MAC header RLC/MAC control block 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. 52CS-4 38CS-3 32CS-2 22CS-1 RLC data block size Channel Coding Scheme 52CS-4 38CS-3 32CS-2 22CS-1 RLC data block size Channel Coding Scheme Figure 3-58 RLC data block size Downlink RLC data blockDownlink RLC data blockDownlink RLC data blockDownlink RLC data block The Downlink RLC data block together with its MAC header is formatted as shown in Fig. 3-59. Octet N2 spare Octet M+1 Octet M (optional)EMLength indicator Octet 3 (optional)EMLength indicator Octet 2EBSN Octet 1FBITFIPR MAC headerUSFS/PRRBPPayload Type 12345678 RLC data Figure 3-59 Downlink RLC data block with MAC header
  53. 53. 3 Um interface – user plane 103 Payload TypePayload TypePayload TypePayload Type The Payload Type field indicates the type of data contained in remainder of the RLC/MAC block: 0 0 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. 1 1 Reserved. RRBPRRBPRRBPRRBP 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/PS/PS/PS/P The Supplementary/Polling (S/P) bit is used to indicate whether the RRBP field is valid or not valid. USFUSFUSFUSF 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.
  54. 54. Signalling in GPRS/EGPRS 104 PRPRPRPR 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. TFITFITFITFI 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. FBFBFBFBIIII The Final Block Indicator (FBI) bit indicates that the downlink RLC data block is the last RLC data block of the downlink TBF. BSNBSNBSNBSN The Block Sequence Number (BSN) field carries the sequence number of each RLC data block within the TBF. EEEE 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). LLLLengthengthengthength IIIIndicatorndicatorndicatorndicator 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.
  55. 55. 3 Um interface – user plane 105 MMMM 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 dataRLC dataRLC dataRLC 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 blockUplink RLC data blockUplink RLC data blockUplink RLC data block The Uplink RLC data block together with its MAC header is formatted as shown in Fig. 3-60. Octet N RLC data optional Octet M+1 Octet M (optional)EMLength indicator Octet 3 (optional)EMLength indicator Octet 2EBSN Octet 1TITFIspare MAC headerSICountdown ValuePayload Type 12345678 TLLI R PI Octet M+2 Octet M+3 Octet M+4 Octet M+5 Octet M+6 EPFI spare Octet N RLC data optional Octet M+1 Octet M (optional)EMLength indicator Octet 3 (optional)EMLength indicator Octet 2EBSN Octet 1TITFIspare MAC headerSICountdown ValuePayload Type 12345678 TLLI R PI Octet M+2 Octet M+3 Octet M+4 Octet M+5 Octet M+6 EPFI spare Figure 3-60 Uplink RLC data block with MAC header
  56. 56. Signalling in GPRS/EGPRS 106 Countdown ValueCountdown ValueCountdown ValueCountdown 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. SISISISI 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). RRRR 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. PIPIPIPI The PFI Indicator (PI) indicates the presence of the optional PFI field. TITITITI The TLLI Indicator (TI) bit indicates the presence of an optional TLLI field within the RLC data block. TLLITLLITLLITLLI The TLLI field contains a Temporary Logical Link Identifier (TLLI). PFIPFIPFIPFI The PFI field contains a Packet Flow Identifier (PFI). RLC/MAC cRLC/MAC cRLC/MAC cRLC/MAC control blocksontrol blocksontrol blocksontrol 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 blockDownlink RLC/MAC control blockDownlink RLC/MAC control blockDownlink RLC/MAC control block The Downlink RLC/MAC control block together with its MAC header is formatted as shown in Fig. 3-61.
  57. 57. 3 Um interface – user plane 107 Control Message Contents Octet 21 Octet M Octet 2/3 (optional)spare FS TFI Octet 2 (optional)DPR Octet 1 (optional)AC RBSNe RBSN MAC headerS/PRRBPPayload Type 12345678 USF RTI Octet 22 FSe Control Message Contents Octet 21 Octet M Octet 2/3 (optional)spare FS TFI Octet 2 (optional)DPR Octet 1 (optional)AC RBSNe RBSN MAC headerS/PRRBPPayload Type 12345678 USF RTI Octet 22 FSe Figure 3-61 DL RLC/MAC control block together with its MAC header RBSNRBSNRBSNRBSN 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. RTIRTIRTIRTI 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. FSFSFSFS 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. ACACACAC 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. DDDD 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). RBSNeRBSNeRBSNeRBSNe 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
  58. 58. Signalling in GPRS/EGPRS 108 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. FSeFSeFSeFSe 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 contentsControl message contentsControl message contentsControl message contents The Control message contents field contains exactly one segment from one RLC/MAC control message field (i.e. RLC/MAC control block). UUUUplink RLC/MACplink RLC/MACplink RLC/MACplink RLC/MAC control blockcontrol blockcontrol blockcontrol block The Uplink RLC/MAC control block together with its MAC header is formatted as shown in Fig. 3-62. Control Message Contents Octet 21 Octet 3 Octet 2 Octet 1 MAC headersparePayload Type 12345678 R Octet 22 Figure 3-62 Uplink RLC/MAC control block together with its MAC header EGPRS RLC/MAC block structureEGPRS RLC/MAC block structureEGPRS RLC/MAC block structureEGPRS 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 header RLC data block 1 RLC/MAC block RLC data block 2 MCS-7, MCS-8 and MCS-9 only Figure 3-63 EGPRS RLC/MAC block structure
  59. 59. 3 Um interface – user plane 109 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 headersEGPRS RLC data blocks and RLC/MAC headersEGPRS RLC data blocks and RLC/MAC headersEGPRS 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. The three families of EGPRS RLC data blocks based on a common size basis (22, 28 and 37 octets) enable link adaptation retransmission. A2*74MCS-9 A2*68MCS-8 B2*56MCS-7 A74MCS-6 B56MCS-5 C44MCS-4 A37MCS-3 B28MCS-2 C22MCS-1 FamilyEGPRS RLC data unit sizeChannel Coding Scheme The three families of EGPRS RLC data blocks based on a common size basis (22, 28 and 37 octets) enable link adaptation retransmission. A2*74MCS-9 A2*68MCS-8 B2*56MCS-7 A74MCS-6 B56MCS-5 C44MCS-4 A37MCS-3 B28MCS-2 C22MCS-1 FamilyEGPRS RLC data unit sizeChannel Coding Scheme Figure 3-64 EGPRS RLC data unit size EGPRS downlink RLC data blockEGPRS downlink RLC data blockEGPRS downlink RLC data blockEGPRS downlink RLC data block The EGPRS downlink RLC data blocks are formatted according to Fig. 3-65. Octet N Octet M+1 ELength indicator Octet M (optional) ELength indicator E Octet 1 (optional) FBI 12345678 RLC data Figure 3-65 EGPRS downlink RLC data block
  60. 60. Signalling in GPRS/EGPRS 110 Length IndicatorLength IndicatorLength IndicatorLength 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 blockEGPRS Uplink RLC data blockEGPRS Uplink RLC data blockEGPRS Uplink RLC data block The EGPRS uplink RLC data block is formatted according to Fig. 3-66.
  61. 61. 3 Um interface – user plane 111 Octet N Octet M+1 ELength indicator Octet M (optional) ELength indicator E Octet 1 (optional) TI 12345678 RLC data TLLI Octet M+2 Octet M+3 Octet M+4 Octet M+6EPFI optional Octet N Octet M+1 ELength indicator Octet M (optional) ELength indicator E Octet 1 (optional) TI 12345678 RLC data TLLI Octet M+2 Octet M+3 Octet M+4 Octet M+6EPFI optional Figure 3-66 Uplink EGPRS RLC data block EGPRS Downlink RLC/MAC headerEGPRS Downlink RLC/MAC headerEGPRS Downlink RLC/MAC headerEGPRS 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. Octet 4 Octet 3 TFI Octet 2 BSN1 Octet 1 BSN1 ES/PRRBPTFI 12345678 USF Octet 5 PR BSN2 BSN1 BSN2CPS Figure 3-67 EGPRS downlink RLC/MAC header (MCS-7 – MCS-9) EGPRS Supplementary/Polling (ES/P) FieldEGPRS Supplementary/Polling (ES/P) FieldEGPRS Supplementary/Polling (ES/P) FieldEGPRS 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. CPSCPSCPSCPS 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. EGPRS Uplink RLCEGPRS Uplink RLCEGPRS Uplink RLCEGPRS Uplink RLC/MAC header/MAC header/MAC header/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.

×