Gprs Siemens

Information
Base Station System GPRS/EGPRS Global Description

A30808-X3247-L24-1-7618
GPRS/EGPRS Global Description
Information Base Station System
Important Notice on Product Safety

DANGER - RISK OF ELECTRICAL SHOCK OR DEATH - FOLLOW ALL INSTALLATION INSTRUCTIONS. The system complies with the standard EN 60950 / IEC 60950. All equipment connected to the system must comply with the applicable safety standards. Hazardous voltages are present at the AC power supply lines in this electrical equipment. Some components may also have high operating temperatures. Failure to observe and follow all installation and safety instructions can result in serious personal injury or property damage. Therefore, only trained and qualified personnel may install and maintain the system.
The same text in German: Wichtiger Hinweis zur Produktsicherheit LEBENSGEFAHR - BEACHTEN SIE ALLE INSTALLATIONSHINWEISE. Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Alle an das System angeschlossenen Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen. In diesen Anlagen stehen die Netzversorgungsleitungen unter gefhrlicher Spannung. Einige Komponenten knnen auch eine hohe Betriebstemperatur aufweisen. Nichtbeachtung der Installations- und Sicherheitshinweise kann zu schweren Krperverletzungen oder Sachschden fhren. Deshalb darf nur geschultes und qualifiziertes Personal das System installieren und warten.
Caution:
This equipment has been tested and found to comply with EN 301489. Its class of conformity is defined in table A30808-X3247-X910-*-7618, which is shipped with each product. This class also corresponds to the limits for a Class A digital device, pursuant to part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the relevant standards referenced in the manual Guide to Documentation, may cause harmful interference to radio communications. For system installations it is strictly required to choose all installation sites according to national and local requirements concerning construction rules and static load capacities of buildings and roofs. For all sites, in particular in residential areas it is mandatory to observe all respectively applicable electromagnetic field / force (EMF) limits. Otherwise harmful personal interference is possible.
Trademarks: All designations used in this document can be trademarks, the use of which by third parties for their own purposes could violate the rights of their owners.
Copyright (C) Siemens AG 2003.

Issued by the Information and Communication Mobile Group Hofmannstrae 51 D-81359 Mnchen Technical modifications possible. Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a written contract.
A30808-X3247-L24-1-7618
This document consists of a total of 273 Pages. All pages are issue 1.
Reason for Update

Chapter/Section All Reason for Update New Release BR7.0.
Issue History
Issue Number 1 Date of Issue 07/2003 Reason for Update First Edition for New Release BR7.0.
A30808-X3247-L24-1-7618
Contents
1 1.1 1.2 2 2.1 2.2 2.3 3 3.1 3.2 3.3 3.4 3.5 3.5.1 3.5.1.1 3.5.1.2 3.5.2 4 4.1 4.2 4.2.1 4.2.2 4.3 4.3.1 4.3.2 4.3.3 4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.5 4.5.1 4.5.2 4.5.3 4.6 4.6.1 4.6.2 4.7 4.7.1 4.7.2 4.7.3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Generality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Structure of the Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Siemens Features Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 BR5.5 Feature Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 BR6.0 Feature Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 BR7.0 Feature Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 GPRS/EGPRS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 GPRS and EGPRS Modulation Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 GPRS/EGPRS Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 MAC/RLC Block and Radio Block Structures. . . . . . . . . . . . . . . . . . . . . . . . 32 MAC/RLC and Radio Block Structures: Data Transfer . . . . . . . . . . . . . . . . 32 MAC/RLC Block and Radio Block Structures for GPRS Data Transfer . . . . 33 Radio Block Structure for EGPRS Data Transfer. . . . . . . . . . . . . . . . . . . . . 33 MAC/RLC Block Structure: Control Signalling . . . . . . . . . . . . . . . . . . . . . . . 34 Radio Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 GPRS/EGPRS Physical Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Channel coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 GPRS Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 EGPRS Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Temporary Block Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Multiplexing MSs on the same PDCH: Downlink Direction . . . . . . . . . . . . . 46 Multiplexing MSs on the same PDCH: Uplink Direction. . . . . . . . . . . . . . . . 47 Multiplexing MSs on the same PDCH: Configuration. . . . . . . . . . . . . . . . . . 49 GPRS/EGPRS Logical Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Packet Broadcast Control Channel (PBCCH) . . . . . . . . . . . . . . . . . . . . . . . 50 Packet Common Control Channel (PCCCH) . . . . . . . . . . . . . . . . . . . . . . . . 51 Packet Data Traffic Channel (PDTCH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Packet Dedicated Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Coding of GPRS/EGPRS Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . 54 Mapping of Logical Channels onto Physical Channels . . . . . . . . . . . . . . . . 54 PDCH without the Specific GPRS/EGPRS Signalling . . . . . . . . . . . . . . . . . 55 PDCH Carrying both PBCCH and PCCCH . . . . . . . . . . . . . . . . . . . . . . . . . 55 PDCH Carrying PCCCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Packet Timing Advance Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Initial Timing Advance Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Continuous Timing Advance Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Multislot Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Mobile Station Classes for Multislot Capabilities . . . . . . . . . . . . . . . . . . . . . 60 Mapping of Uplink Packet Traffic Logical Channels. . . . . . . . . . . . . . . . . . . 62 Mapping of Downlink Packet Traffic Logical Channels . . . . . . . . . . . . . . . . 62
A30808-X3247-L24-1-7618
5 5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.2 5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.4 6 6.1 6.1.1 6.1.2 6.1.3 6.2 6.3 6.3.1 6.3.2 6.3.2.1 6.3.2.2 6.3.2.3 6.3.2.4 6.3.2.5 6.3.3 6.3.3.1 6.3.3.2 6.3.4 6.3.4.1 6.3.4.2 6.3.5 6.3.6 6.3.6.1 6.3.6.2 6.3.6.3 7 7.1 7.2 7.2.1 7.2.1.1 7.2.1.2 7.2.1.3
Hardware and Software Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Supported BSC Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Standard BSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 High Capacity BSC with the Old Rack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 High Capacity BSC with the New Rack . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 PPCU and PPXU Redundancy and Configuration Rules . . . . . . . . . . . . . . 71 BTS Equipment Supporting GPRS and EGPRS. . . . . . . . . . . . . . . . . . . . . 72 PCU Frames and Dynamic Allocation on the Abis Interface. . . . . . . . . . . . 73 Concatenated PCU Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Hardware supporting Flexible Abis Allocation and Concatenated PCU Frames 79 Configuration of the Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Algorithms Regarding Flexible Abis Allocation . . . . . . . . . . . . . . . . . . . . . . 82 Packet Switched Services Supported on CCCH/PCCCH . . . . . . . . . . . . . . 84 Radio Resources Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Enabling Packet Switched Services in a Cell . . . . . . . . . . . . . . . . . . . . . . . 88 Enabling GPRS Service in the Cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Enabling EGPRS Service in the Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Aspects Related to Carrier Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Configuration of GPRS Channels in a Cell . . . . . . . . . . . . . . . . . . . . . . . . . 93 Management of Packet Data Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Generalities about Resource Assignments. . . . . . . . . . . . . . . . . . . . . . . . . 96 Horizontal/Vertical Allocation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Vertical Allocation Strategy (VA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Horizontal Allocation Strategy (HA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Switching between VA and HA According to Radio Conditions . . . . . . . . . 99 Switching between VA and HA according to Abis Interface Conditions . . 102 Allocation of Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Management of Incoming GPRS/EGPRS Requests . . . . . . . . . . . . . . . . 103 PCU Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 TDPC Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Upgrading Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Upgrade of Radio Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Upgrade of Abis Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Incoming CS Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Waiting Queue Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Pre-emption of PDCH Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Pre-emption of PDT Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Forced Intracell Handovers of Already Established CS Calls . . . . . . . . . . 123 Gb Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Service Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sub-Network Service: Frame Relay on Gb Interface . . . . . . . . . . . . . . . . Examples of Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frame Relay Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procedures for PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 125 130 130 132 137 140
A30808-X3247-L24-1-7618
7.2.2 7.2.2.1 7.2.2.2 7.3 7.3.1 7.3.1.1 7.3.2 7.3.3 8 8.1 8.1.1 8.1.2 8.1.3 8.1.4 8.1.5 8.2 9 9.1 9.2 9.3 9.3.1 9.3.1.1 9.3.1.2 9.3.1.3 9.3.2 9.3.2.1 9.3.2.2 9.4 9.4.1 9.4.2 9.5 9.6 9.6.1 9.6.2 9.7 9.7.1 9.7.2 9.8 9.8.1 9.8.2 9.8.2.1 9.8.2.2 9.8.2.3 9.8.2.4 9.8.2.5 9.8.2.6
Network Service Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Control Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 BSSGP Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 BSSGP Addressing: BSSGP Virtual Connections (BVCs). . . . . . . . . . . . . 144 BVC Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 SGSN-BSS Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Load Control for Packet Switched Services . . . . . . . . . . . . . . . . . . . . . . . . 151 Dynamic PTPPKF Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 System Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Creation of a PCU Object and Enabling a NSVC for It . . . . . . . . . . . . . . . 154 PCU Crash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 PCU Comes Back in Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Time Needed to Execute PTPPKF Reconfiguration . . . . . . . . . . . . . . . . . 160 PCU Overload Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 GPRS/EGPRS Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Mobile Stations for Packet Switched Services . . . . . . . . . . . . . . . . . . . . . . 162 Network Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Mobility Management Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Mobility Management States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 IDLE State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 STAND-BY State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 READY State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Mobility Management Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Attach Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Detach Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Radio Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Packet Idle State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Packet Transfer State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Correspondence between RR States and MM States . . . . . . . . . . . . . . . . 169 Packet Data Protocol Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 INACTIVE State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 ACTIVE State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Activation and Deactivation of a PDP Context . . . . . . . . . . . . . . . . . . . . . . 171 PDP Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 PDP Context Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Access to the Network (Establishment of a TBF). . . . . . . . . . . . . . . . . . . . 172 Medium Access Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 TBF Establishment Initiated by the MS on CCCH/PCCCH . . . . . . . . . . . . 173 8 Bits or 11 Bits Uplink Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Establishment using a One Phase Access . . . . . . . . . . . . . . . . . . . . . . . . 175 TBF Establishment using a Two Phases Access. . . . . . . . . . . . . . . . . . . . 176 TBF Establishment for EDGE Mobile Stations. . . . . . . . . . . . . . . . . . . . . . 177 Contention Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Uplink Access on PRACH (Access Persistence Control). . . . . . . . . . . . . . 180
A30808-X3247-L24-1-7618
9.8.3 9.8.3.1 9.8.3.2 9.8.4 9.8.5 9.8.6 9.9 9.9.1 9.9.1.1 9.9.1.2 9.9.2 9.9.3 9.9.3.1 9.9.3.2 9.9.3.3 9.9.3.4 9.9.4 9.9.4.1 9.9.4.2 9.9.5 9.9.6 9.9.7 9.9.7.1 9.9.7.2 10 10.1 10.1.1 10.1.2 10.1.2.1 10.1.2.2 10.1.2.3 10.1.3 10.1.4 10.1.4.1 10.1.4.2 10.1.4.3 10.1.4.4 10.1.5 10.2 10.2.1 10.2.2 10.2.3 10.3 10.3.1 10.3.1.1 10.3.1.2 10.3.2
TBF Establishment Initiated by the Network on CCCH/PCCCH . . . . . . . . Network Operation Modes for Paging. . . . . . . . . . . . . . . . . . . . . . . . . . . . Discontinuous Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relative Reserved Block Period Field (RRBP) . . . . . . . . . . . . . . . . . . . . . Packet Queuing Notification Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . Polling Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RLC Data Block Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledged Mode for RLC/MAC Operation . . . . . . . . . . . . . . . . . . . . . GPRS Acknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EGPRS Acknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unacknowledged Mode for RLC/MAC Operation . . . . . . . . . . . . . . . . . . . Operations on Uplink TBF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Uplink TBF Using the Acknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . Uplink TBF Using the Unacknowledged Mode . . . . . . . . . . . . . . . . . . . . . Anomalies During an Uplink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Release of an Uplink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operations on Downlink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledged and Unacknowledged Modes on Downlink TBFs . . . . . . . Release of a Downlink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notes About Concurrent TBFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suspend/Resume Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notes About GPRS/EGPRS TBF Scheduling. . . . . . . . . . . . . . . . . . . . . . Supported QoS Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduling Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GPRS/EGPRS Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell Selection and Re-selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Measurements for Cell Selection and Re-selection . . . . . . . . . . . . . . . . . Cell selection and Re-selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . GPRS/EGPRS Path Loss Criterion (C1 Criterion) . . . . . . . . . . . . . . . . . . C31 Criterion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C32 Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell Re-selection Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management of GPRS/EGPRS Neighboring Cells. . . . . . . . . . . . . . . . . . Handling of Neighboring Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GPRS/EGPRS Neighboring Cells and Involved Parameters . . . . . . . . . . Configuration of an Adjacent Cell with GSUP= TRUE . . . . . . . . . . . . . . . Configuration of an Adjacent Cell with GSUP= FALSE . . . . . . . . . . . . . . Abnormal Cell Re-selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell Re-selection from GSM/GPRS/EGPRS Network to UMTS Network . GSM-UMTS Re-selection Algorithm: Circuit Switched Case . . . . . . . . . . GSM-UMTS Re-selection Algorithm: Packet Switched Case . . . . . . . . . . Handling of UMTS Neighboring Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Controlled Cell Reselection and Traffic Control Management . . Network Controlled Cell Reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . Measurement Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio Link Network Controlled Cell Reselection Algorithm . . . . . . . . . . . GPRS/EGPRS Traffic Control Strategy . . . . . . . . . . . . . . . . . . . . . . . . . .
181 182 184 187 187 188 190 191 191 191 193 193 193 195 195 196 199 199 200 202 203 207 208 208 210 210 210 212 212 213 215 216 218 218 220 221 222 223 224 224 225 226 227 228 231 232 234
A30808-X3247-L24-1-7618
10.3.2.1 Network Controlled Cell Reselection Algorithm for Traffic Control Strategy . . 235 10.4 Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 10.4.1 Power Control Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 10.4.2 Measurement at the MS Side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 10.4.2.1 Packet Idle Mode: Measurements for Power Control. . . . . . . . . . . . . . . . . 237 10.4.2.2 Packet Transfer Mode: Measurements for Power Control . . . . . . . . . . . . . 238 10.4.2.3 Derivation of Channel Quality Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 10.4.3 BTS Output Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 10.5 Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 10.5.1 Link Adaptation for GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 10.5.1.1 GPRS: Switching Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 10.5.1.2 Quality Traps Disadvantage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 10.5.1.3 GPRS: Link Adaptation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 10.5.2 Link Adaptation for EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 10.5.2.1 EGPRS: Switching Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 10.5.2.2 EGPRS: Link Adaptation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10.5.3 Selection of the Candidate Initial Coding Scheme . . . . . . . . . . . . . . . . . . . 254 11 12 Database Parameters and Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
A30808-X3247-L24-1-7618
Illustrations
Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 Basic GMSK Constellation of Signal Vectors. . . . . . . . . . . . . . . . . . . . . 24 Basic 8 PSK Constellation of Signal Vectors . . . . . . . . . . . . . . . . . . . . . 24 GPRS/EGPRS Network Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Protocol Stack for Data Transmission in GPRS/EGPRS Network. . . . . 28 Data Flow across Protocol Layers in case of GPRS/ EGPRS(MSC1...MSC6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Data Flow across Protocol Layers in case of EGPRS(MSC7...MSC9) . 30 Data Flow from the SGSN to the MS. . . . . . . . . . . . . . . . . . . . . . . . . . . 32 GPRS: MAC/RLC Block for Data Transfer. . . . . . . . . . . . . . . . . . . . . . . 33 GPRS: Radio Block for Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . 33 EGPRS: MAC/RLC Block for Data Transfer (with one RCL Data field) . 33 EGPRS: MAC/RLC Block for Data Transfer (with two RCL Data fields) 34 EGPRS: Radio Block for Data Transfer (with only one RCL Data field) 34 EGPRS: Radio Block for Data Transfer (with two RCL Data fields) . . . 34 MAC/RLC Block for Control Messages (Signalling). . . . . . . . . . . . . . . . 35 Radio Block for Control Messages (Signalling).. . . . . . . . . . . . . . . . . . . 35 Packet Data Channel (PDCH). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Multiframe Structure for a PDCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 GPRS Coding Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Coding of the MAC/RLC Block using CS1 . . . . . . . . . . . . . . . . . . . . . . . 40 EGPRS Coding Schemes and Families. . . . . . . . . . . . . . . . . . . . . . . . . 42 Interleaving of MCS9 Coded Data into Two Consecutive Normal Bursts44 Interleaving of MCS6 Coded Data into Four Consecutive Normal Bursts . 45 Multiplexing MS on the same PDCH (Downlink) . . . . . . . . . . . . . . . . . . 47 Multiplexing MS on the same PDCH (Uplink) . . . . . . . . . . . . . . . . . . . . 48 Example of Mapping of the PBCCH Channel. . . . . . . . . . . . . . . . . . . . . 51 Packet Common Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Example of Mapping of the PCCCH Channel. . . . . . . . . . . . . . . . . . . . . 52 Example of Mapping of two PCCCH Channels.. . . . . . . . . . . . . . . . . . . 53 Example of Mapping of Logical Channels in the Physical Channel (Downlink Direction). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Example of Mapping of Logical Channels in the Physical Channel (Uplink Direction).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Example of Downlink Configuration with PBCCH and PCCCH Channels . 56 Example of Uplink Configuration with PRACH Channel. . . . . . . . . . . . . 57 Continuous Timing Advance Update Feature . . . . . . . . . . . . . . . . . . . . 59 Example of Multislot Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Hardware and Software Entities supporting GPRS/EGPRS in BTS and BSC.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 View of the BSC Rack with and without PPCU Boards. . . . . . . . . . . . . 65 View of the High Capacity BSC with the Traditional Rack. . . . . . . . . . 67
Fig. 4.15 Fig. 4.16 Fig. Fig. Fig. Fig. 4.17 4.18 4.19 5.1
Fig. 5.2 Fig. 5.3
A30808-X3247-L24-1-7618
Fig. Fig. Fig. Fig.
5.4 5.5 5.6 5.7
Fig. 5.8 Fig. 5.9 Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. 5.10 5.11 6.1 6.2 6.3 6.4 6.5 6.6 6.7 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10
Fig. 7.11 Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. 7.12 7.13 7.14 7.15 7.16 7.17 8.1 8.2
Fig. 8.3 Fig. 8.4 Fig. 8.5
High Capacity BSC with the New Rack . . . . . . . . . . . . . . . . . . . . . . . . . 71 Fundamental Principle of Concatenated PCU Frames . . . . . . . . . . . . . . 76 Abis Mapping for a DL MCS9 radio block requiring 5 Abis subslots . . . . 78 High Capacity BSC: Relationship between PCU Frames and Abis Allocation according to the BTSE Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Standard BSC: Relationship between PCU Frames and Abis Allocation according to the BTSE Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 BSC handling of BTS Equipment with Software Releases not supporting the Abis Dynamic Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Mapping of CCCH/PCCCH Channels on the Abis Interface. . . . . . . . . . 85 CCCH/PCCCH Message Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Example of TRXs enabled to support Packet Switched Services. . . . . . 89 Example of GPRS/EGPRS configuration.. . . . . . . . . . . . . . . . . . . . . . . . 95 Example of Vertical Allocation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 98 Example of Horizontal Allocation Algorithm . . . . . . . . . . . . . . . . . . . . . . 99 Example of a Cell Configured with Five TRXs. . . . . . . . . . . . . . . . . . . . 100 Allocation Algorithm followed by the PCU. . . . . . . . . . . . . . . . . . . . . . . 110 Allocation Algorithm followed by the TDPC . . . . . . . . . . . . . . . . . . . . . 115 Gb Interface: Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Different Connection Types between the BSC and the SGSN. . . . . . . 125 Example of Frame Relay Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Example of Frame Relay Link (GTS=3). . . . . . . . . . . . . . . . . . . . . . . . . 129 Example of Frame Relay Link (GTS=3&4&5&6). . . . . . . . . . . . . . . . . . 129 Example of Frame Relay Link (GTS=3&4&7&8). . . . . . . . . . . . . . . . . . 129 Network Service Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Gb Interface with a Frame Relay Network . . . . . . . . . . . . . . . . . . . . . . 131 Creation of a NSVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 BSC Configured with One PCU and Two FR Links (64 Kbit/sec each one). 134 BSC Configured with One PCU and Two FR Links (128 Kbit/sec each one). 135 BSC Configured with Two PCUs and Two FR Links each one. . . . . . . 136 Frame Relay Network Connecting two DTE Devices . . . . . . . . . . . . . . 138 Frame Relay Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Periodic Polling Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Distribution of Packet Switched Data Traffic among Different Cells . . . 146 Flow Control Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Example of PTPPKF Distribution During System Initialization . . . . . . . 154 Example of PTPPKF Distribution when a New PCU is Created - Step 1 . . 155 Example of PTPPKF Distribution when a New PCU is Created - Step 2 . . 156 Example of PTPPKF Distribution in Case of PCU Crash . . . . . . . . . . . 157 Example of PTPPKF Distribution when a PCU Comes Back in Service. . . 159
10
A30808-X3247-L24-1-7618
Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig.
9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 9.13 9.14 9.15 9.16 9.17 9.18 9.19 9.20 10.1 10.2 10.3 10.4 10.5 10.6
Network Structure: Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Mobility Management States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Radio Resource States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Packet Data Protocol States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Coding of the 11 Bit Access Burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 One Phase Access on PCCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Two Phases Access on CCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Packet Access Reject Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 TBF Establishment Initiated by the Network on PCCCH . . . . . . . . . . . 182 Packet Queuing Notification Procedure . . . . . . . . . . . . . . . . . . . . . . . . 188 Packet Polling Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Behavior of T3182 Timer and N3102 Counter . . . . . . . . . . . . . . . . . . . 195 Detection of Anomalies during an Uplink TBF on the Network Side . . 196 Release of an Uplink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Release of Resources on the Network Side during an Uplink TBF (in case of T3169 timer expiration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Control Procedure Executed by the Network during a Downlink TBF . 200 Release of a Downlink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Suspend Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Resume Procedure (The MS Has Remained in the Same Cell - Successful Resume) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Resume Procedure (The MS has changed the Routing Area) . . . . . . 207 Management of Adjacent Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Network Controlled Cell Reselection Procedure . . . . . . . . . . . . . . . . . 231 CS1 and CS2 Throughput Depending on C/I (dB). . . . . . . . . . . . . . . . 241 Gross Throughput Depending on CS and C/I (dB) . . . . . . . . . . . . . . . 242 BLER as Function of C/I (dB) for all GPRS Coding Schemes. . . . . . . 243 Simulation Results for Family A (+MCS1) without IR . . . . . . . . . . . . . 246
A30808-X3247-L24-1-7618
11
1 Introduction
1.1 Generality
Second generation systems, due to the digital transmission mode they use, offer not only pure speech transmission, but also low rate data transmission and several supplementary services. Nevertheless, since needs for mobile data transmission are rapidly increasing in the mobile working of tomorrow, growths in the area of data transmission are much higher than in the area of speech transmission. In principle, high data transmission rates in the GSM network can be achieved by the HSCSD feature (High Speed Circuit Switched Data). With HSCSD it is possible to match the ISDN transmission rate, by combining four timeslots of the TDMA frame. One disadvantage of HSCSD, however, is the circuit switched data transmission it uses; in fact when circuit switched connections are used: efcient resource management is impossible; additional costs arise for the user. For this reason HSCSD is essentially suited for application involving high, but constant, transmission rates (e.g. video telephony). To increase data rates, exceeding HSCSD limits, the General Packet Data Service (GPRS) has been developed. GPRS is intended to provide the possibility of transmitting large volumes of data in a very short time; on the other hand it ensures a better management of available resources, which will: increase the number of users; reduce the costs arising for individual users (volume-oriented fees). With GPRS it is possible to reach a maximum data throughput per user of about 150170 kbit/sec. Third generation mobile networks, however, require, for their forthcoming multimedia applications, much more bandwidth, e.g. mandatory 384 kbit/sec. The Enhanced General Packet Data Service (EGPRS) represents the GPRS upgrade and offers the opportunity to achieve those high data rates by preserving the most important GSM air interface features (e.g. 200 kHz channeling, TDMA access type, cell planning processes), by introducing a new modulation scheme only (8 PSK instead of GMSK). This means that EGPRS will rely completely on underlying GSM functionality. Due to its GSM/GPRS compatibility EGPRS is the optimal packet data feature for established GSM operators, which gives them a high protection for old investments and requires only small new investments. Looking at the fact, that only a limited number of operators per country has been assigned with UMTS licenses, EGPRS is also a good opportunity for those operators (so called UMTS-losers) to make an evolutionary step with their networks and gives them the opportunity to offer 3rd generation services. It is expected that both UMTS and GPRS/EGPRS networks will coexist in near future. UMTS will serve mainly hotspots with up to 2Mbps data services per subscriber and GPRS/EGPRS will be used to cover the rest of the area offering 384kbps data services.
12
A30808-X3247-L24-1-7618
1.2
Structure of the Manual

This manual is completely dedicated to GPRS/EGPRS features; its purpose is to allow the user to understand which are the main characteristics of packet switched data services. Besides the general description about GPRS and EGPRS, the Siemens implementation is discussed: when a subject is shown, it is also described which are the parameters involved in the subject. The manual is organized in the following way: when a topic introduces one or more database parameters, for each parameter a link to a specific table of the BSC:CML manual is executed; the table describes the parameter, providing: a brief description of the parameter; the range of the parameter; its default value; the commands to which the parameter belongs to. Besides, chapter 2 is completely dedicated to list all the Siemens Feature Sheets (or Change Requests) regarding GPRS/EGPRS; for each Feature Sheet (or Change Request) it is shown: its number and title; a brief description of the Feature Sheet (or Change Request); the release of the Feature Sheet (or Change Request). Finally, in the last chapter of the manual four different tables are inserted: in the rst table the user nds, in the alphabetical order, all the parameters, related to GPRS/EGPRS only, which are discussed in the manual. For each parameter he nds one or more links to the chapters of the manual where the parameter is described and also a link to the title of Feature Sheets (or Change Requests) that introduce or describe the parameter in Siemens technology; in this way a user, who wants to know the meaning of one parameter, can nd in the manual the location where the parameter is explained and also which are the other documents that describe it; in the second one the user nds, in the alphabetical order, the not specic GPRS/EGPRS parameters which are discussed in the manual since they are also related to packet switched services. For each parameter he nds one or more links to the chapters of the manual where the parameter is described; besides, starting from parameters of BR5.5 release onwards, a link to the features that describe the parameter is executed; in the third one the user nds, in the alphabetical order, all the database objects which are related to GPRS/EGPRS only. For each object he nds the link to the Feature Sheets (or Change Requests) that introduce or describe the object in Siemens technology; in the fourth one, the user nds, in the alphabetical order, all the not specic GPRS/EGPRS database objects which are involved in packet switched services too. For each object he nds the link to the chapters of the manual that describe it; besides, starting from objects of BR5.5 release onwards, a link to the features that describe the parameter is executed. The manual is subdivided in several chapters: Chapter 2 lists all the Siemens Features pertaining to GPRS/EGPRS; when a parameter is described in the manual, a link to the feature that concerns it is executed;
A30808-X3247-L24-1-7618
13
Chapter 3 comprises a general discussion about packet switched services, showing the new architecture, the protocol stack and the data ow across the several network entities; Chapter 4 describes the GPRS/EGPRS radio interface, i.e. new logical channels, their mapping on physical channels and the rules that allow: to share the same physical channel among several mobile stations; to assign more physical channels to the same mobile station; Chapter 5 describes the hardware and software entities related to the introduction of packet switched services; the Packet Control Unit and its main features are presented; Chapter 6 shows how the user can congure the resources of the cell, to allow him to manage both circuit switched and packet switched services; some examples are used to clarify how the resources can be handled; Chapter 7 is dedicated to the Gb interface, i.e. the interface that connects the BSC to the core network. The frame relay protocol, which characterizes the Gb interface, is described. In particular, the following topics are discussed: the physical layer; permanent virtual connections; examples of conguration; procedures regarding the Gb interface. Chapter 8 describes the load control mechanism, that is used to distribute in a right way the GPRS/EGPRS trafc among the resources of the BSC; Chapter 9 describes the main procedures regarding the packet switched services, such as: GPRS/EGPRS attach/detach; PDP context activation/deactivation procedures related to packet data transfer. Chapter 10 introduces the new GPRS/EGPRS algorithms regarding: cell selection/re-selection; trafc control management; power control; link adaptation; Chapter 11 contains tables that summarize objects and parameters discussed in the manual.
14
A30808-X3247-L24-1-7618
2 Siemens Features Description

This chapter lists all the Siemens Feature Sheets (or Change Requests) regarding GPRS; for each Feature Sheet (or Change Request) it is shown: its number and title; a brief description about it; the release of the Feature Sheet (or Change Request).
2.1
BR5.5 Feature Description

FSH0720 GPRS: HW and Basic SW for Packet Control Unit (PCU) Release BR5.5 This feature is the main one regarding GPRS; it describes objects, parameters and functionalities regarding the packet switched data service.
CR - F017 Packet Downlink Assignment Procedure on CCCH Release BR5.5 This Change Request introduces the Packet Downlink Assignment procedure, which is mandatory, on the CCCH channel.
CR - F135 GPRS Alignment to SMG 30, 30BIS, 31, 31BIS Release BR5.5 This Change Request aligns the system to the last version of ETSI standard for release 97.
CR - F187 GPRS: Non signalling Channels PDCH Static Allocation Release: BR5.5 This Change Request introduces the possibility to configure static GPRS channels (not PBCCH or PCCCH) to support data traffic only.
CR - F189 GPRS Improvements Step 1 Release: BR5.5 This Change Request introduces some improvements regarding the GPRS service, to increase customer acceptance and performance of GPRS.
A30808-X3247-L24-1-7618
15
CR - F190 Support of Non-DRX Mode after Change to Packet Idle Mode Release: BR5.5 This Change Request allows to reduce, of about 50%, the time that is needed to send data blocks from the Gb interface to the MS. The target is reached by accelerating the packet downlink assignment procedure.
CR - F191 Improve Robustness of GPRS Packet DL Assignments Release: BR5.5 This Change Request allows to reduce the delay that occurs between the transmission of downlink assignment messages and the beginning of packet downlink data transfers (in a first step, see CR - F190, the delay that characterized downlink assignment procedures has been reduced. However the delay can still be in average reduced by 50% with the realization of this CR).
CR - F205 GPRS Improvements Step 2 Release: BR5.5 This Change Request introduces some improvements regarding GPRS service, to increase customer acceptance and performance of GPRS.
CR - F287 Decrease Round Trip Delay Time and Improve Web Browsing Performances Release BR5.5 This Change Request allows to improve the overall performance in the interaction between many TCP/IP based applications and the GPRS network.
CR - X232 GPRS Improvements for BR5.5 Release: BR5.5 This Change Request allows to improve the GPRS network, by introducing the following features without O&M impacts: - GPRS channels on all the TRXs of a cell; - horizontal allocation.
16
A30808-X3247-L24-1-7618
CR - X366 Change Polling Strategy during Delay TBF Release Release: BR5.5 This Change Request allows to reduce the time needed by the MS to establish a concurrent uplink TBF, when the downlink TBF is kept open using the Delay TBF release procedure, introduced by CR - F287.
2.2

FSH0397 High Capacity BSC Release BR6.0 This feature introduces the High Capacity BSC, that exploit the rack already used in the previous releases.
FSH0457 Service Dependent Channel Allocation Strategy - Step1 Release BR6.0 This feature introduces new strategies to manage Circuit Switched, GPRS and HSCSD calls.
FSH0503 GPRS: Automatic Horizontal Allocation Release BR6.0 This feature introduces the horizontal allocation strategy, and the parameter used to handle it.
FSH0512 Packet Transfer on non BCCH TRXs without Downlink Power Control Release BR6.0 This feature introduces the possibility to configure the GPRS service on the TRXs chosen by the operator.
FSH0515 Improvement in GPRS scheduler Release BR6.0 This feature introduces a new mechanism to schedule data block to be send/received to/from the users.
A30808-X3247-L24-1-7618
17
FSH1928 Miscellaneous Impacts from Q3IG and DIG Release BR6.0 This feature introduces the new method to configure both intra-BSC and inter-BSC neighboring cells.
CR - F092 Implementation of FRS0457: Service Dependent Channel Allocation Strategy Step 1 Release: BR6.0 This Change Request allows to implement the Service Dependent Channel Allocation Strategy - Step 1, described in FSH0457, in BR6.0 release.
CR - F119 Update of FRS 1928 (Miscellaneous impacts from Q3IG and DIG) Release: BR6.0 This Change Request is an update of FSH1928.
CR - F208 Rework of default values for Power Control, Handover, Adjacent Cell and BTS Release: BR6.0 This Change Request introduces new default values for some parameters.
CR - X260 GSM-UMTS Cell Selection/Re-Selection Release: BR6.0 This Change Request allows GSM/UMTS users to perform a cell reselection from GSM cells to UMTS cells.
CR - X263 GPRS scheduler Modification Release: BR6.0 This Change Request is due to the decision to implement only a few parts of FSH0515.
18
A30808-X3247-L24-1-7618
CR - X411 Removal of limitation in the number of GPRS adjacent cells Release: BR6.0 This Change Request increases to 32 the maximum number of GSM adjacent cells supporting GPRS.
CR - X482 UMTS-GPRS Cell reselection Release: BR6.0 This Change Request allows GPRS users to perform a cell reselection from GSM cells to UMTS cells without loosing the service.
CR - X617 New Attribute Definition and Default Adjustment Release: BR6.0 This Change Request introduces the TIMEDTBFREL parameter and new default values for some GPRS parameters.
CR - X669 GPRS Resume Procedure Release: BR6.0 This Change Request allows to implement the GPRS resume procedure already foreseen for next releases.
CR - X685 New PTPPKF Object Management in Case of Unavailability of TRXs Supporting GPRS Release: BR6.0 This Change Request establishes that when all the TRXs supporting GPRS in a cell are excluded from the service, because LOCKED and/or disabled, the related PTPPKF object instance is excluded from service too (put into DISABLED state).
CR - X706 Reserved GPRS Channels Management Modification Release: BR6.0 This Change Request introduces the GMAPERTCHRES parameter and a new definition for the GDCH one.
A30808-X3247-L24-1-7618
19
CR - X912 Modification of Busy Traffic Channel Calculation Release: BR6.0 This Change Request establishes that GPRS non reserved channels must be taken into account in the calculation of BUSY TRAFFIC CHANNELS only if the setting of DGRSTRGY parameter does not allow GPRS downgrade.
2.3

FSH0418 GPRS: Network Controlled Cell Reselection Release BR7.0 These feature introduces new strategies to control both GPRS and EGPRS packet switched data traffic. Besides it introduces new parameter for packet switched cell reselection from GSM to UMTS.
FSH0419 Support of CS3, CS4 Release BR7.0 This feature introduces new GPRS coding schemes.
FSH0420 MAC Protocol Enhancements for EDGE Release BR7.0 This feature introduces the enhancements regarding MAC protocol that is needed to support EDGE functionality. The feature sheet comprises also enhancements regarding both RLC and BSSGP protocols. Besides, it introduces some EDGE parameters related to the previous protocols and new flags to enable and disable GPRS and EGPRS on a cell basis.
FSH0429 EDGE: Flexible Abis Allocation Strategy (FAAS) Release BR7.0 This feature introduces a new strategy to manage Abis resources. With this strategy it is possible to assign in a dynamic way more than one Abis subslot to a single air timeslot. New PCU frames are also defined.
20
A30808-X3247-L24-1-7618
FSH0444 Link Quality Control: link adaptation (LA) Release BR7.0 This feature introduces the link adaptation algorithms regarding both GPRS and EGPRS services.
FSH0514 Gb/MS flow control (GPRS Step 1 Completion) Release BR7.0 This feature implements the flow control procedure on the Gb interface.
FSH0516 GPRS Resource Management Release BR7.0 This feature introduces new algorithms to manage radio resources when packet switched services (GPRS/EGPRS) are enabled.
FSH0527 2nd Step of the High Capacity BSC Release BR7.0 This feature introduces the High Capacity BSC, based on new rack and boards.
FSH0550 EGPRS/GPRS Scheduler Enhancements Release BR7.0 This feature introduces enhancements in the process that manages the transmission/reception of GPRS/EGPRS radio block on the radio interface.
CR - X0158 Enable/Disable GPRS and/or EDGE Support on Call Basis Release: BR7.0 This Change Request introduces two new attributes, of the PTPPKF object, to enable GPRS and EGPRS services.
CR - X1150 Improvement of CS Channel Allocation Release: BR7.0 This Change Request introduces changes in PDCH pre-emption, when a CS calls must be served in a congested cell.
A30808-X3247-L24-1-7618
21
CR - X1152 Adaptation of FRS0514 to Current Implementation Release: BR7.0 This Change Request aligns the FRS 514 (MS/Gb flow control) to the current implementation.
CR - X1362 New O&M Attributes for Network Controlled Cell Reselection Release: BR7.0 This Change Request introduces new parameters to manage Network Controlled Cell Reselection, already implemented with FSH0418.
CR - X1454 Multiplexing of GPRS and EGPRS on the same Timeslot Release: BR7.0 This Change Request allows to multiplex GPRS and EGPRS mobile stations on the same PDCH dynamically.
CR - X1495 Uplink Balanced Assignment of E(GPRS) Resources Release: BR7.0 This Change Request introduces a new strategy to manage in a better way concurrent TBFs, for MSs able to use more than one timeslot in uplink direction.
22
A30808-X3247-L24-1-7618
3 GPRS/EGPRS Overview
The General Packet Radio Service (GPRS) and the Enhanced General Packet Radio Service (EGPRS) allow packet switched data transmission under the GSM network. The well known word EDGE (Enhanced Data Rates for the GSM evolution) applies both to circuit switched and to packet switched services. Note that EDGE is mainly a characteristic of Air Interface, including a new kind of modulation (8PSK, besides the already used GMSK modulation, see "3.1 GPRS and EGPRS Modulation Principles"). The word EGPRS (Enhanced GPRS) applies only to packet service. Whenever we use the word EGPRS we are talking of EDGE applied to packet service. That means, substantially, coding the radio blocks using a specific set of modulation and coding schemes (MCS1, .., MCS9), and using new specific RLC/MAC control messages or new specific information elements in GPRS RLC/MAC control messages. In the present release, EDGE is applied only to packet services. However, the generic term EDGE is used in O&M attributes that, in some future release, could be used to define the support of EDGE circuit switched service. In the following of this manual the world EDGE means EGPRS. When GPRS/EGPRS are not used, the GSM/DCS network works in circuit switched connection mode, i.e. it gives to the customer the exclusive use of a certain amount of bandwidth for the duration of the requirement. The connection is set up on demand and released when the caller breaks the connection. Circuit switched connections are what is provided by the GSM architecture for speech and data services. Data transmission with bandwidth larger than 9.6 kbit/s (or larger than 14.4 Kbit/s, if this higher data rate is enabled) is reached combining more radio channels to a given user, by the HSCSD feature. Nevertheless, when a circuit switched connection is established and the user has nothing to send, which is typical of data transmission, the resources are wasted because they are not available for other users. In other words it means that circuit switched connections do not provide an efficient way to support data traffic. In order to improve and optimize the use of both the network and radio resources, GPRS and EGPRS use a packet switched technique to transfer both data and signalling in an efficient manner. New GPRS/EGPRS radio channels are defined, and the allocation of these channels is flexible: from 1 to 8 radio interface timeslots can be allocated for TDMA frame, for each transceiver of the cell; timeslots are shared by the active users (i.e. the same timeslot can be assigned to different users at the same time, unlike what happens in GSM); radio interface resources can be shared dynamically between speech services (i.e. circuit switched services) and data services (i.e. packet switched services) as a function of service load and operator preferences; uplink and downlink resources are allocated separately. Applications that take advantage from GPRS/EGPRS services should exhibit one or more of the following characteristics: intermittent, non periodic (i.e. bursts) data transmission; frequent transmission of small volumes of data; infrequent transmission of large volumes of data.
A30808-X3247-L24-1-7618
23
3.1
GPRS and EGPRS Modulation Principles

GPRS is an evolution of the existing GSM and uses the same modulation scheme, called GMSK (Gaussian Minimum Shift Keying). The GMSK digital modulation format relies on shifting the carrier 180 in phase to produce a binary modulation scheme capable of delivering 1 bit/symbol (see Fig. 3.1).
Fig. 3.1
Basic GMSK Constellation of Signal Vectors
GPRS uses four different channel coding schemes (see "4.2.1 GPRS Channel Coding") to provide different levels of protection to the packets on the air interface. This modulation scheme, within 200 KHz bandwidth, provides good spectral performance and adequate data rates for GSM voice applications, however it cannot supply fast data services since it only transmits 1 bit/symbol. EDGE uses the same bandwidth allocated to GSM voice and GPRS data, but delivers a higher capacity and fast data services to wireless network by using a new modulation scheme called 8 PSK (8-level Phase Shift Keying). With 8PSK modulation, there are eight distinct phase changes that the decoder will look for in the binary data. Each phase represents a symbol and carries three bits of information (see Fig. 3.2).
Fig. 3.2
Basic 8 PSK Constellation of Signal Vectors
24
A30808-X3247-L24-1-7618
As a consequence EDGEs 8 level-shift keying modulation scheme allows a radio throughput increase of almost 3 times the radio throughput of GPRS with the same number of timeslots. In the following table the physical layer parameters comparison between GSM/GPRS and EDGE/EGPRS is depicted. GSM GMSK, 1bit/sym 270833 Kbit/sec 114 bit 22.8 kbit/sec EDGE 8 PSK, 3 bit/sym 270833 Kbit/sec 348 bit 69.6 kbit/sec
Modulation Symbol Rate Payload per Burst Gross Rate per Time Slot
With the classical 8 PSK modulation scheme, it is possible during symbol changes for the signal trajectory to pass through the origin (I/Q value 0,0), which causes both a very high Peak to Average Value (PTA) and a high dynamic range of the signal. To avoid this possibility, EDGE uses a 3pi/8-shifted 8PSK approach, by which with every phase transition, the symbols rotate by 3pi/8 causing a shift of the I/Q constellation relative to its previous starting position. Nine coding schemes (from MCS1 to MCS9, see "4.2.2 EGPRS Channel Coding") using both GMSK and 8PSK modulations are introduced and a link adaptation algorithm allows to automatically switch between coding schemes, based on the radio environment condition. Tab. 3.1 shows how which EDGE coding schemes are GMSK modulated and which are 8 PSK modulated. GMSK modulated MCS1 MCS2 MCS3 MCS4 8 PSK modulated MCS5 MCS6 MCS7 MCS8 MCS9 Tab. 3.1 EGPRS Coding Schemes and their Modulation
3.2
Network Architecture
Generally the packet data network establishes a logical connection between users but does not guarantee immediate access to the transmission network: when more users try to access transmission resource at the same time, the network has to schedule the access keeping some of them in wait queue. As shown in Fig. 3.3, the GPRS/EGPRS network works like an overlaid network on the existing one. In the network architecture speech and data transmission with circuit switched connections are still controlled by the MSC (through the A interface).
A30808-X3247-L24-1-7618
25
Fig. 3.3
GPRS/EGPRS Network Architecture. Packet switched services introduce two new network nodes in the GSM PLMN: Serving GPRS Support Node (SGSN): the SGSN, which is at the same hierarchical level as the MSC, keeps track of the individual MS location and performs security functions and access control. The SGSN can be connected to the base station system (BSS) via a Frame Relay network. It is also possible to connect the SGSN and the BSS via nailed-up connections (NUCs) or through point-to-point connections. The Gb interface species the interface between the SGSN and the BSC (see "7 Gb Interface"). It is an interface consisting of connections which carry both data and signalling simultaneously, using the Frame Relay protocol. The Gb interface is a standard one in order to guarantee multi-vendor capabilities. Gateway GPRS Support Node (GGSN): the GGSN provides: interworking with external packet switched networks; management of IP addresses. The GGSN could be connected to the SGSN via an IP-based GPRS/EGPRS backbone network, but these two entities can also reside on the same physical node. The HLR is upgraded with GPRS/EGPRS subscriber information, and optionally the MSC/VLR can be enhanced for more efficient coordination of GPRS and non-GPRS services and functionalities, e.g.: paging of circuit switched calls through the SGSN; combined GPRS and non-GPRS location updates. To allow co-ordination of activities between the MSC and the SGSN, the Gs interface must be supported (see Fig. 3.3). The functionalities that guarantee GPRS/EGPRS security are equivalent to those used by the GSM system: the SGSN performs authentication and cipher setting procedures
26
A30808-X3247-L24-1-7618
based on the same algorithms, keys, and criteria as in existing GSM; the only difference is that GPRS/EGPRS network uses a ciphering algorithm optimized for packet data transmission. In order to access packet switched services, a MS shall first make its presence known to the SGSN by performing a GPRS attach procedure (see 9.3.2.1). This operation establishes a logical link between the MS and the SGSN, and makes the MS available for: paging via SGSN; notication of incoming GPRS/EGPRS data. SMS over GPRS; So, when the GPRS attach procedure is executed, the SGSN establishes with the mobile station a mobility management context, containing information pertaining to, e.g., mobility and security. In order to send and receive packet switched data, the MS shall first activate the packet data address that it wants to use. This operation makes the MS known in the corresponding GGSN; then interworking with external data networks can begin. During this procedure, which is called PDP context activation (i.e. Packet Data Protocol context activation), the SGSN establishes a PDP context with the GGSN (see 9.7). This context is used for routing purposes when the user: will send data to the external data network; will receive data from the external data network. After having executed both the attach and the PDP context activation procedures, the MS can start sending or receiving data. To transfer data, the MS must establish a physical connection with the network; this physical connection is called Temporary Block Flow. The Temporary Block Flow allows unidirectional transfer of data through the allocated radio resources (see 4.1). User data is transferred transparently between the MS and the external data networks with a method known as encapsulation and tunnelling: data packets are equipped with GPRS/EGPRS-specific protocol information and transferred between the MS and the GGSN. This transparent transfer method lessens the requirement for the GPRS PLMN to interpret external data protocols, and it enables easy introduction of additional interworking protocols in the future. User data can be compressed and protected with retransmission protocols, to get an efficient and reliable data transmission.
A30808-X3247-L24-1-7618
27
3.3
GPRS/EGPRS Protocol Stack

Fig. 3.4 shows the protocol stack that is used for data transmission in the packet switched data network.
Fig. 3.4
Protocol Stack for Data Transmission in GPRS/EGPRS Network. The different layers carry out the following functions: GSM RF: the GSM RF is the physical radio channel used to transfer packet data; MAC: the Media Access Control layer provides the access to the physical radio resources. It is responsible for the physical allocation of packet data channels (PDCHs); RLC: the Radio Link Control layer provides a reliable link over the air interface that ts the block structure of the physical channel; therefore it segments and re-assembles the LLC frames transmitted between the BSS and the SGSN. Additionally, it performs: a sub-multiplexing to support more than one MS by one physical channel; the channel combining to provide up to eight physical channels to one MS. LLC: the Logical Link Control layer provides a logical connection between the MS and the SGSN even if no physical connection is established. The physical connection is set up by RLC/MAC layer when there is data to transmit; BSSGP: the BSSGP protocol is used to transfer LLC frames together with related information between the SGSN and the BSC. Such information are QoS (Quality of Service) and routing information; SNDCF: the Sub-Network Dependent Convergence Function performs the following tasks: encryption; compression; segmentation/re-assembling;
28
A30808-X3247-L24-1-7618
multiplexing/de-multiplexing of signalling information and data packets. The encryption function is used to support the privacy of the data, whereas the compression and segmentation are performed to limit the amount of data transferred by LLC layer. GTP: the main task of GPRS Tunnelling Protocol is the encapsulation/de-encapsulation function. The different kinds of data packets are encapsulated in IP packets since IP is the GPRS/EGPRS internal network protocol. The encapsulated data packets are transferred between GSN nodes. Network: the network layer represents the used network protocol which is transferred over the GPRS/EGPRS network. Depending on the supported network protocol (IP, X.25, CLNP) there are several kinds of network layers; Higher layer: the higher layers are outside the scope of GPRS/EGPRS, because they are independent from the underlying network.
3.4
Data Flow
This chapter mainly describes how data is transmitted from the fixed network to the MS, and vice versa. Fig. 3.5 and Fig. 3.6 illustrate how the different protocol layers handle the data flow: Fig. 3.5 represents data ow in case of GPRS, and EGPRS when coding schemes from MSC1 to MSC6 are used; Fig. 3.6 represents data ow in case of EGPRS when coding schemes from MSC7 to MSC9 are used (see description below);
Fig. 3.5
Data Flow across Protocol Layers in case of GPRS/ EGPRS(MSC1...MSC6)
A30808-X3247-L24-1-7618
29
Fig. 3.6
Data Flow across Protocol Layers in case of EGPRS(MSC7...MSC9)
Lets suppose that an IP data packet has to be sent from an external data network to a mobile subscriber.
It is implied that the MS has already executed the attach procedure and it has already activated the PDP context towards the involved data network. The following steps are performed: 1. the Internet Service provider sends the IP data packet unit to the GPRS/EGPRS network, using the IP address which has been assigned to the MS during the PDP context activation procedure; 2. the GGSN searches for the relevant PDP context and forwards the data unit towards the right SGSN. The original IP data unit is encapsulated in a new one (using the GTP protocol), and the new IP address is the IP address of the SGSN; 3. the SGSN decapsulates the IP data packet and (by means of the SNDCP protocol) it subdivides the data packet in a certain number of LLC frames (data is also encrypted and compressed). 4. when the SGSN knows the location of the MS (i.e. the cell where the MS is camped on), these LLC frames are sent to the right BSC, across the Gb interface. As in the GSM system, the paging procedure is used to localize the subscriber. 5. LLC frames have a variable length; since they have to be sent on the radio interface, which has a limited capacity, the LLC frames are segmented in a certain number of MAC/RLC blocks; these blocks have a well dened length (according to the used coding scheme);
30
A30808-X3247-L24-1-7618
6. MAC/RLC blocks are then sent, across the Abis interface, to the right BTS;
MAC/RLC blocks are sent across the Abis interface, by means of PCU frames. Two kinds of PCU frames exist: - standard PCU frames: they allow to transmit a restricted number of bits every 20 msec and so they support only CS1 and CS2 GPRS coding schemes; - concatenated PCU frames: they support not only CS1 and CS2 GPRS coding schemes, but also CS3 and CS4, and all the EGPRS coding schemes (MSC1..MSC9). To get more details, please see "5.3 PCU Frames and Dynamic Allocation on the Abis Interface". 7. the BTS executes the following operations for received MAC/RLC blocks: block coding; convolutional coding; puncturing; interleaving. Regarding these operations, it is important to make a distinction among different cases: when GPRS coding schemes are used, a single MAC/RLC block contains one Information Feld only; the BTS executes the described operations on it; after these operations each received MAC/RLC block reaches, independently from the applied coding scheme, a xed length of 456 bits; this new block is called Radio Block; when EGPRS GMSK coding schemes are used (i.e. from MCS1 to MCS4), a single contains one Information Feld only; the BTS executes the described operations on it; after these operations each received MAC/RLC block reaches, independently from the applied coding scheme, a xed length of 456 bits; this new block is called Radio Block; when EGPRS MCS5 and MCS6 coding schemes are used, a single MAC/RLC block contains one Information Feld only; the BTS executes the described operations on it; after these operations each received MAC/RLC block reaches, independently from the applied coding scheme, a xed length of 1392 bits; this new block is called Radio Block; when EGPRS MCS7, MCS8 and MCS9 coding schemes are used, a single MAC/RLC block contains two Information Felds; the BTS executes the described operations on the MAC/RLC block; after these operations the MAC/RLC block reaches, independently from the applied coding scheme, a xed length of 1392 bits; this new block is called Radio Block; 8. as it has been said, the block that is obtained after different coding procedures is called Radio Block; each Radio Block is then sent on the radio interface by means of 4 Normal Bursts, in fact each Normal Burst can transmit: up to 114 bits in case of GPRS; up to 114 bits in case of EGPRS when GMSK modulation is used; up to 348 bits in case of EGPRS when 8PSK modulation is used. Fig. 3.7 shows the data flow between the SGSN and the MS in downlink direction (in uplink direction the same operations are executed, but in the opposite order).
A30808-X3247-L24-1-7618
31
Fig. 3.7
Data Flow from the SGSN to the MS.
To avoid confusion it is important to underline some features regarding MAC/RLC blocks and Radio Blocks. In this manual the following definitions are used: MAC/RLC block: a MAC/RLC block is a block generated in the BSC (by MAC/RLC layer) starting from LLC-PDU; then this block is sent using PCU frames towards the BTS that will apply the right coding; Radio Block: a Radio Block is a MAC/RLC block that is obtained after the BTS has applied the block coding (i.e. it is a MAC/RLC block plus some coding bits).
After block coding, the BTS will apply the convolutional coding and both puncturing and interleaving procedures; after these operations that block will reach a fixed length of 456 or 1392 bits, and it is still called Radio Block.
3.5
MAC/RLC Block and Radio Block Structures

Different MAC/RLC block (and as a consequence different Radio Block) structures for data transfer and control message transfer purposes are defined. The MAC/RLC block structure for data transfer is different between GPRS and EGPRS, whereas the same MAC/RLC Block structure is used for control messages.
i
3.5.1
All the different MAC/RLC block types, after the coding, are always carried by four Normal Bursts on the radio interface.
MAC/RLC and Radio Block Structures: Data Transfer

As it has been described, two different MAC/RLC Block structures are defined for GPRS and EGPRS data transfer; in the following they are described.
32
A30808-X3247-L24-1-7618
3.5.1.1
MAC/RLC Block and Radio Block Structures for GPRS Data Transfer
For GPRS, a MAC/RLC block for data transfer consists of one MAC Header, one RLC header and one RLC Data Block (see Fig. 3.8): the MAC header contains control elds which are different for uplink and downlink directions; the MAC header has constant length (8 bits); the RLC header contains control elds which are different for uplink and downlink directions; the RLC header has a variable length; the RLC data eld contains octets from one or more LLC PDUs.
MAC Header RLC Header Fig. 3.8
RLC Data
GPRS: MAC/RLC Block for Data Transfer
As it has been said, the MAC/RLC block is sent to the BTS, that will apply a block coding for error detection, adding a Block Check Sequence (BSC) field and obtaining the Radio Block (see Fig. 3.9). This Radio Block after convolutional coding, puncturing and interleaving, will be transmitted on the air interface and carried by four Normal Bursts.
MAC Header RLC Header Fig. 3.9
RLC Data
BCS
GPRS: Radio Block for Data Transfer
3.5.1.2
Radio Block Structure for EGPRS Data Transfer

For EGPRS, a MAC/RLC block for data transfer consists of one RLC/MAC Header, and one or two RLC Data Blocks (see Fig. 3.10 and Fig. 3.11): the RLC/MAC header contains control elds which are different for uplink and downlink directions; the RLC/MAC header has a variable length; the RLC data eld contains octets from one or more LLC PDUs; EGPRS coding schemes from MCS1 to MCS6 use MAC/RLC block constituted by one RLC Data eld only (see Fig. 3.10), whereas MCS7, MCS8 and MCS9 coding schemes use a MAC/RLC block constituted by two RLC Data elds (see Fig. 3.11) to reach an higher data rate.
RLC/MAC Header Fig. 3.10
RLC Data
EGPRS: MAC/RLC Block for Data Transfer (with one RCL Data field)
A30808-X3247-L24-1-7618
33
RLC/MAC Header Fig. 3.11
RLC Data
RLC Data
EGPRS: MAC/RLC Block for Data Transfer (with two RCL Data fields)
As it has been said, the MAC/RLC block is sent to the BTS, that will apply a block coding for error detection, obtaining the Radio Block (see Fig. 3.12 and Fig. 3.13). Two different block coding are applied for error detection: the Block Check Sequence (BSC) is used for error detection of the data part; the Header Check Sequence (HSC) is used for error detection of the header part. The header part is independently coded from the data part and has its own check sequence. In case of MAC/RLC blocks constituted by two RLC Data fields (see Fig. 3.11), each RLC data field has its own block check sequence (see Fig. 3.13), whereas the header is common for both the data fields. Then the Radio Block, after convolutional coding, puncturing and interleaving, will be transmitted on the air interface and carried by four Normal Bursts.
RLC/MAC Header
HCS
RLC Data
BCS
Fig. 3.12
EGPRS: Radio Block for Data Transfer (with only one RCL Data field)
RLC/MAC Header
HCS
RLC Data
BCS
RLC Data
BCS
Fig. 3.13
EGPRS: Radio Block for Data Transfer (with two RCL Data fields)
3.5.2
MAC/RLC Block Structure: Control Signalling

For both GPRS and EGPRS, a MAC/RLC Block for control message transfer consists of one MAC header and one RLC/MAC Control Block (see Fig. 3.14). the MAC header contains control elds which are different for uplink and downlink directions; the MAC header has constant length (8 bits); the RLC/MAC Control message eld contains one RLC/MAC control message; It is always carried by four normal bursts.
34
A30808-X3247-L24-1-7618
MAC Header
RLC/MAC Control Message
Fig. 3.14
MAC/RLC Block for Control Messages (Signalling).
As it has been said, the MAC/RLC block, is sent to the BTS, that will apply a block coding for error detection, adding a Block Check Sequence (BSC) field and obtaining the Radio Block (see Fig. 3.15). This Radio Block after convolutional coding, puncturing and interleaving, will be transmitted on the air interface and carried by four Normal Bursts.
MAC Header
RLC/MAC Control Message
BCS
Fig. 3.15
Radio Block for Control Messages (Signalling).
Examples of control messages which are transmitted in downlink direction in a MAC/RLC signalling block are: Packet Paging Request: it is sent by the network to trigger channel access by up to four mobile stations for connection establishment; Packet Downlink Assignment: it is sent from the network to assign downlink resources to the MS; Packet Uplink Ack/Nack: it is sent from the network to the mobile station, to acknowledge data blocks sent in uplink direction; Packet Power Control/Timing Advance: it is sent by the network to the MS in order to update either the timing advance or power control parameters; Packet Access Reject: it is sent by the network to the mobile station to indicate that the network has rejected the MSs access request. Examples of control messages which are transmitted in uplink direction in a MAC/RLC signalling block are: Packet Downlink Ack/Nack: it is sent from the mobile station to the network, to acknowledge data blocks sent in downlink direction; Packet Control Acknowledgment: it is sent from the mobile station to the network, to acknowledge control blocks sent in downlink direction;
The Packet Control Acknowledgment message is not formatted as a single MAC/RLC block, but as four Access Bursts.
A30808-X3247-L24-1-7618
35
4 Radio Interface
To configure packet switched data services on a specific cell, the user must create the PTPPKF object (Point To Point Packet Function) related to the cell. In the Containment Tree, the PTPPKF object is hierarchically dependent to the BTS one For each BTS instance (i.e. for each configured cell) there is only one PTPPKF object instance subordinated to it. This instance is always equal to 0. When the PTPPKF object has been created, the cell can be configured to support packet switched data services, following the configuration settings given by the user (regarding the configuration of GPRS/EGPRS services, see "6 Radio Resources Management"). Functional object PTPPKF Tab. 4.1 PTPPKF Object. Meaning Configure packet switched services on a specific cell.
Once packet switched services has been enabled, the radio resources of the cell can be assigned to either GPRS/EGPRS or circuit switched services, according to the operators preferences. In the GPRS/EGPRS system, two types of radio channels are foreseen: 1. on-demand channels (also called dynamic channels): these channels are shared between packet switched services and circuit switched services according to current requests, but circuit switched services have an higher priority than GPRS/EGPRS; 2. dedicated channels (also called static channels): these channels are permanently assigned to packet switched services, and they cannot be used for circuit switched services (even if no GPRS/EGPRS users are exploiting these channels).
4.1
GPRS/EGPRS Physical Channels

The physical channel (i.e. the timeslot of the TDMA frame) assigned to packet data services (either statically or dynamically) is called a Packet Data Channel (PDCH).
TDMA frame
GPRS/ EGPRS
0 PDCH Fig. 4.1 Packet Data Channel (PDCH).
When a timeslot is used for GPRS/EGPRS (i.e. when the timeslot is a PDCH one) the multiframe structure for this PDCH consists of 52 TDMA frames divided into (see Fig. 4.2): 12 blocks (one block is composed by 4 frames); each block can convey a MAC/RLC Radio Block containing either data or signalling (see "3.5 MAC/RLC Block and Radio Block Structures");
36
A30808-X3247-L24-1-7618
2 idle frames (used to make measurements); 2 frames used for the continuous timing advance update procedure (see "4.6 Packet Timing Advance Estimation").
52 TDMA Frame - PDCH Multiframe B0 B1 B2 T

4 frames
B3
B4
B5
B6
B7
B8 T
B9
B10
B11 i
1 frame
- i = Idle frame - Bx = Radio Block - T = PTCCH
Fig. 4.2
Multiframe Structure for a PDCH.
4.2
Channel coding
Blocks sent on the radio interface, inside the PDCH multiframe, are coded differently depending on the used packet switched service, i.e. GPRS or EGPRS. In the following the differences between the two services are described from the coding process point of view.
4.2.1
GPRS Channel Coding

Four coding schemes, CS1, CS2, CS3 and CS4, are defined for GPRS MAC/RLC blocks for data transfer. Tab. 4.2 shows the main characteristics of each coding scheme, referring to the structure of the GPRS MAC/RLC block for data transfer depicted in Fig. 3.8.
Coding scheme
Bits of RLC Data Field (without spare bits) 160 240 288 400
Spare bits in RLC Data Field 0 7 3 7
Net Data Rate
Bits of MAC/RLC Header (including USF) 24 24 24 24
Total size of the MAC/RLC block (bits)
CS1 CS2 CS3 CS4 Tab. 4.2
8 kbit/sec (160 bit/20 msec) 12 kbit/sec (240 bit/20 msec) 14.4 kbit/sec (288 bit/20 msec) 20 kbit/sec (420 bit/20 msec)
184 271 315 431
GPRS Coding Schemes According to the used coding scheme, the message (MAC/RLC block), delivered by means of PCU frames to the encoder of the BTS, has a fixed size of (obviously the same thing is valid for the message delivered from the BTS to the BSC): 184 bits in case of CS1; 271 bits in case of CS2; 315 bits in case of CS3;
A30808-X3247-L24-1-7618
37
431 bits in case of CS4.
Then the BTS will execute the following operations (the coding process, for every coding scheme, is shown in Fig. 4.3): 1. the rst step of the coding procedure is to add a Block Check Sequence (BCS) for error detection; 2. the second step consists of USF pre-coding (except for CS1); 3. then four tail bits are added and a half rate convolutional coding for error correction is applied (for CS4 there is no coding for error correction); 4. nally to obtain the target coding rate, the puncturing operation is executed.
CS1 USF= 3 bit
Modulation Block code 40 bit + 4 tail bit 228 bit Convolutional code (R=1/2) 456 bit Interleaving
181 bit CS2 / CS3
184 bit
Mod. USF= 3 bit USF pre-coding Block code16 bit + 4 tail bit 294 bit 338 bit Convolutional code (R=1/2) Puncturing Interleaving
268 bit 312 bit
271 bit 315 bit
274 bit 318 bit
588 bit 676 bit
456 bit 456 bit
CS4 USF= 3 bit
Modulation USF pre-coding 440 bit Block code 16 bit 456 bit Interleaving
428 bit
431 bit
Fig. 4.3
GPRS Coding Process In the first implementation of GPRS, CS1 and CS2 coding schemes have been introduced. Standard PCU frames were designed to carry the necessary signalling and data information between the BSC and the BTS, and the GPRS capacity on the Abis was limited to 16 kbps. In fact, with standard PCU frames, only 271 bits of data can be transmitted, every 20 msec, in the PCU frame, on the Abis interface. Since CS3 and CS4 contain a number of data bits upper than 271 (CS3 uses 315 bits, whereas CS4 uses 431 bits), it was not possible to use them. To support CS3 and CS4 coding schemes, concatenated PCU frames are introduced in the system, and the Abis throughput per radio channel (PDCH) is increased to n X 16 kbit/sec, using the flexible Abis allocation strategy (see 5.3). So, regarding the Abis interface, the information is sent using two kinds of PCU frames: a) Concatenated PCU frames are used when support of CS3/CS4 is enabled both at BSC and at BTS level;
38
A30808-X3247-L24-1-7618
b)Standard PCU frames are used when support of CS3/CS4 is disabled at BSC or at BTS level.
To get more information About concatenated PCU frames and the flexible Abis allocation strategy refer to "5.3 PCU Frames and Dynamic Allocation on the Abis Interface". The PCU frame format (concatenated or standard) is chosen at the Initial Time Alignment phase, and cannot be changed dynamically during data transfer. Therefore, in order to be able to reach the higher coding schemes (CS3/CS4), when CS3/CS4 are supported by O&M configuration, the selected PCU frame format shall be Concatenated, even if the initial coding scheme could be supported by standard PCU frames. As default, CS1 and CS2 coding schemes are enabled in the BSS; the BSC capability to support CS3/CS4 coding schemes can be enabled/disabled by the operator. The CSCH3CSCH4SUP parameter of the BSC object allow the user to enable/disable CS3/CS4 coding schemes at BSC level. Then the operator can enable/disable the support of CS3/CS4 on cell basis, by the CSCH3CSCH4SUP parameter of the PTPPKF object. Besides, the user can also indicate, on a cell basis, which coding scheme has to be used as preferred for data transmission, when a new transmission is initiated (whereas signalling uses always CS1 coding scheme, see "4.4.5 Coding of GPRS/EGPRS Logical Channels"). The user can set the preferred initial coding scheme, for GPRS, using the INICSCH parameter.
The user, by the INICSCH parameter, suggests a value of coding scheme to be used when a data transmission starts. This suggested value will be used only when the system does not have any other information to choose the initial coding scheme (see "10.5.3 Selection of the Candidate Initial Coding Scheme"). Then the link adaptation algorithm (see "10.5 Link Adaptation"), if enabled, can change the coding scheme of the TBF according to radio conditions. If link adaptation is not enabled, the initial coding scheme will be the only one used for data transmission in the cell. As it is described in "5 Hardware and Software Features", in order to support GPRS TBFs with CS3 or CS4 coding schemes, hardware/software requirements are the following: only High Capacity BSCs support CS3/CS4 coding schemes; BTS+, e-microBTS, picoBTS, support GPRS CS3/CS4 coding schemes; BTS1 base stations can support GPRS CS3/CS4 coding schemes, only it they are equipped with BBSIG44 boards only. The coding process of a MAC/RLC block, using CS1, is shown in Fig. 4.4: the 456 bits obtained after BTS coding, are sent across four Normal Burst, carrying 57X2 bits of information each one. In order to simplify the decoding, the stealing bits of the block are used to indicate the actual coding scheme (see also "4.2.2 EGPRS Channel Coding").
A30808-X3247-L24-1-7618
39
PCU
MAC/RLC block USF TFI 3 bits Data bits 181 bits BCS 40 bits Tail 4 bits
R=1/2 Convolutional Code Encrypted RLC frame 456 bits 456 bits are split in 4 Normal bursts. Normal Burst Tail Encrypted bits 57 bits Training Sequence Encrypted bits 57 bits Tail Guard
period
Stealing bits Fig. 4.4 Coding of the MAC/RLC Block using CS1
4.2.2
EGPRS Channel Coding

As it has been described in "3.1 GPRS and EGPRS Modulation Principles", nine different modulation and coding schemes, MCS1 to MCS9, are defined for EGPRS MAC/RLC Blocks, partly GMSK and 8 PSK modulated. Tab. 4.3 shows the main characteristics of each coding scheme, referring to the structure of the EGPRS MAC/RLC block for data transfer (see Fig. 3.10 and Fig. 3.11).
Coding scheme
Bits of RLC Data Field (without spare bits) 176 224 296
Net Data Rate
Bits of MAC/RLC Header DL/UL (including USF) 31/31 31/31 31/31 2 2 2
FBI+E elds (bits)
Total size of the MAC/RLC block DL/UL (bits) 209 257 329
MCS1 MCS2 MCS3 Tab. 4.3
8,8 kbit/sec (176 bit/20 msec) 11,2 kbit/sec (224 bit/20 msec) 14.8 kbit/sec (296 bit/20 msec)
EGPRS Coding Schemes
40
A30808-X3247-L24-1-7618
Coding scheme
Bits of RLC Data Field (without spare bits) 352 448 592 448+448 544+544 592+592
Net Data Rate
Bits of MAC/RLC Header DL/UL (including USF) 31/31 28/37 28/37 40/46 2 2 2
FBI+E elds (bits)
Total size of the MAC/RLC block DL/UL (bits) 385 478/487 622/631 940/946 1132/1138 1228/1234
MCS4 MCS5 MCS6 MCS7 MCS8 MCS9 Tab. 4.3
17.6 kbit/sec (420 bit/20 msec) 22.4 kbit/sec (448 bit/20 msec) 29.6 kbit/sec (592 bit/20 msec) 44.8 kbit/sec (896 bit/20 msec)
2+2 2+2 2+2
54.4 kbit/sec (1088 bit/20 msec) 40/46 59.2 kbit/sec (1184 bit/20 msec) 40/46
EGPRS Coding Schemes According to the used coding scheme, the message (MAC/RLC block) delivered, by means of PCU frames, to the encoder of the BTS has a fixed size of (obviously the same thing is valid for the message delivered from the BTS to the BSC): 209 bits in case of MCS1; 257 bits in case of MCS2; 329 bits in case of MCS3; 385 bits in case of MCS4; 478 bits in case of MCS5 in downlink direction, and 487 bits in case of MCS5 in uplink direction; 622 bits in case of MCS6 in downlink direction, and 631 bits in case of MCS5 in uplink direction; 940 bits in case of MCS7 in downlink direction, and 946bits in case of MCS7 in uplink direction; 1132 bits in case of MCS8 in downlink direction, and 1138 bits in case of MCS8 in uplink direction; 1228 bits in case of MCS9 in downlink direction, and 1234 bits in case of MCS8 in uplink direction. The MCSs are divided into different families: A; Apadding; B; C. Each family has a different basic unit of payload: 37 (and 34), 28 and 22 octets respectively. Different code rates within a family are achieved by transmitting a different number of payload units within one Radio Block. For families A and B, one, two or four payload units are transmitted, for family C, only one or two payload units are transmitted. Tab. 4.2.4 shows the correspondence between families and coding schemes, whereas Fig. 4.5 shows the different relationships among families, coding schemes and possible units of payload.
A30808-X3247-L24-1-7618
41
FAMILY A A Padding B C
CODING SCHEMES MSC-3, MSC-6, MSC-9 MSC-3, MSC-6, MSC-8 MSC-2, MSC-5, MSC-7 MSC-1, MSC-4
Tab. 4.2.4EGPRS Coding Schemes and Families
Fig. 4.5
EGPRS Coding Schemes and Families
When 4 payload units are transmitted (MCS7, MCS8 and MCS9), these are split into two separate RLC data fields of the same MAC/RLC block (i.e. with separate sequence numbers and BCSs, see Fig. 3.11). This can be clearly seen by comparing Fig. 4.6 (family A, MCS9) and Fig. 4.7 (family A, MCS6).
42
A30808-X3247-L24-1-7618
After receiving a MAC/RLC block from the BSC, the BTS will execute the following operations:
To ensure strong header protection, the header part of the Radio Block (i.e. the RLC/MAC header) is independently coded from the data part of the Radio Block. 1. the rst step of the coding procedure of the data part of the MAC/RLC Block is to add a Block Check Sequence (BCS, 12bits) for error detection; 2. the second step consists of adding six tail bits (TB); 3. then a 1/3 rate convolutional coding with constraint length 7 for error correction is applied; 4. after that, to obtain the target coding rate, the puncturing operation is executed; the puncturing step takes advantage of different puncturing schemes Pi with i = 1, 2 or 3, which has impact on Incremental Redundancy as Link Quality Control method; the Pi for each MCS correspond to different puncturing schemes achieving the same coding rate; 5. nally the radio block is rectangular interleaved over 4 bursts (see Fig. 4.6 and Fig. 4.7). Hence the block length for each RLC block is: 4*114 = 456 bit in case of GMSK modulation; 4*348 = 1392 bit in case of 8 PSK modulation (including stealing symbols).
For MCS8 and MCS9 only the header is interleaved over 4 normal bursts. The data blocks are interleaved over 2 bursts only. MCS7 header and data are interleaved over 4 bursts. The coding and puncturing scheme of a MAC/RLC radio block is clearly outlined in the RLC/MAC header within the Coding and Puncturing Scheme indicator field (CPS). Depending on coding scheme three different header types are defined: Header type 1 is used with coding scheme MCS7, MCS8 and MCS9; Header type 2 is used with coding scheme MCS5 and MCS6; Header type 3 is used with coding scheme MCS1, MCS2, MCS3 and MCS4. The header type of an incoming EGPRS radio block is indicated with stealing bits of the Normal Bursts: 12 stealing bits are used in case of MCS1, MCS2, MCS3 and MCS4 coding schemes; 8 stealing bits are used in case of MCS5, MCS6, MCS7, MCS8 and MCS9 coding schemes. Besides, as it has been described in "4.2.1 GPRS Channel Coding", stealing bits (8 bits) are also used to indicate the used coding scheme in case of GPRS radio blocks. Stealing bits coding is shown in Tab. 4.2.5. Coding Scheme GPRS CS1 GPRS CS2 GPRS CS3 GPRS CS4 MSC1, MSC2, MSC3, MCS4 none 1,1,0,0,1,0,0,0 0,0,1,0,0,0,0,1 0,0,0,1,0,1,1,0 0,0,0,1,0,1,1,0,0,0,0,0 Stealing Bits
Tab. 4.2.5Coding of Stealing Bits for GPRS and EGPRS Radio Blocks
A30808-X3247-L24-1-7618
43
Coding Scheme MSC5, MSC6 MSC7, MSC8, MSC9
Stealing Bits 0,0,0,0,0,0,0,0 1,1,1,0,0,1,1,1
Tab. 4.2.5Coding of Stealing Bits for GPRS and EGPRS Radio Blocks There are eight stealing bits for 8PSK mode which allow to indicate four header formats. There are twelve stealing bits for GMSK mode which allow to indicate two header formats: the first eight of the twelve stealing bits indicate CS4 to allow GPRS-mobiles to decode the header type 3 and to read the USF field of the header (see "4.3 Temporary Block Flow" to get ore details about the meaning of the USF field). The USF field has 8 states, which are represented by a binary 3 bit field in the MAC Header. The USF is encoded to 12 symbols similarly to GPRS, (i.e., 12 bits for GMSK modes and 36 bits for 8PSK modes). The FBI (Final Block Indicator) bit and the E (Extension) bit do not require extra protection: they are encoded along with the data part.
Fig. 4.6
Interleaving of MCS9 Coded Data into Two Consecutive Normal Bursts
44
A30808-X3247-L24-1-7618
Fig. 4.7
Interleaving of MCS6 Coded Data into Four Consecutive Normal Bursts The user can also indicate, on a cell basis, which coding scheme has to be used as preferred for data transmission, when a new transmission is initiated (whereas signalling uses always CS1 coding scheme, see "4.4.5 Coding of GPRS/EGPRS Logical Channels"). The user can set the preferred initial coding scheme with the following parameters: in uplink direction, as it is described in "9.1 Mobile Stations for Packet Switched Services", not all the EDGE mobile stations support the 8PSK modulation, so: the IMCSULNIR8PSK attribute suggests the MCS to be used in uplink direction if the MS supports the 8 PSK modulation in this direction; the IMCSULNIRGMSK attribute suggests the MCS to be used in uplink direction if the MS supports only the GMSK modulation in this direction; in downlink direction all the EDGE MS are obliged to support the 8 PSK modulation, so the INIMCSDL attribute suggests the MCS to be used in downlink direction for all the EGPRS mobiles.
The user, by previous parameters, suggests a value of coding scheme to be used when a data transmission starts. This suggested value will be used only when the system does not have any other information to choose the initial coding scheme (see "10.5.3 Selection of the Candidate Initial Coding Scheme"). Then the link adaptation algorithm, if enabled, can change the coding scheme of the TBF according to radio conditions. If link adaptation is not enabled, the initial coding scheme will be the only one used for data transmission in the cell (to get more details about coding schemes management, see "10.5 Link Adaptation"). To support EGPRS coding schemes, concatenated PCU frames are used in the system, and the Abis throughput per radio channel (PDCH) is increased to n X 16 kbit/sec, using the flexible Abis allocation strategy (see 5.3).
A30808-X3247-L24-1-7618
45
4.3
Temporary Block Flow

The Temporary Block Flow (TBF) is the physical connection, between the MS and the network, used to support the unidirectional transfer of LLC PDUs on packet data physical channels (PDCHs). The TBF is characterized by a set of allocated radio resources on one or more PDCHs, and it comprises the transmission of a number of RLC/MAC blocks carrying one or more LLC PDUs. A TBF is temporary and is maintained only for the duration of the data transfer. The TBF is established: in uplink direction to transfer data (or signalling) from the MS to the network; in downlink direction to transfer data (or signalling) from the network to the MS. A TBF can operate in either GPRS or EGPRS mode; the network sets the TBF mode in the PACKET UPLINK ASSIGNMENT, PACKET DOWNLINK ASSIGNMENT or IMMEDIATE ASSIGNMENT message (see "9.8 Access to the Network (Establishment of a TBF)").
The EGPRS TBF mode is supported by EGPRS capable MSs only, see "9.1 Mobile Stations for Packet Switched Services". For each TBF, the network assigns a Temporary Flow Identity (TFI). The assigned TFI is unique among concurrent TBFs in the same direction, i.e.: TBFs belonging to the same direction of transmission must have different TFI values; TBFs belonging to different directions of transmission could have the same TFI value. The TFI is assigned to a MS in a resource assignment message that precedes the transfer of LLC frames (both in uplink and downlink directions) belonging to one TBF. The same TFI is included in every RLC header belonging to a particular TBF, as well as in the control messages associated to the LLC frame transfer (e.g. acknowledgements), in order to address the peer RLC entities. Each TBF is then identified by the TFI together with: the direction (UL or DL) in which the RLC data block is sent, in case of RLC data block; the direction (UL or DL) in which the RLC/MAC control message is sent and the message type, in case of RLC/MAC control message.
4.3.1
Multiplexing MSs on the same PDCH: Downlink Direction

A downlink TBF, associated to a single PDCH, is set up giving to the MS: a PDCH (i.e. a timeslot); a TFI (each mobile station has its own TFI value). Then all the mobile stations, which have a downlink TBF on the same PDCH, execute the following steps: 1. they read all the downlink blocks inside the multiframe, and decode the TFI value; 2. if the TFI is not the one assigned to the MS, the block is skipped; 3. if the TFI is the one assigned to the MS, this means that the block belongs to the MS and then data is taken. Fig. 4.8 shows the mobile station behavior.
46
A30808-X3247-L24-1-7618
Fig. 4.8
Multiplexing MS on the same PDCH (Downlink)
4.3.2
Multiplexing MSs on the same PDCH: Uplink Direction

An uplink TBF, associated to a single PDCH, is set up giving to the MS: a PDCH (i.e. a timeslot); a TFI (each mobile station has its own TFI value); an Uplink State Flag (USF); the Uplink State Flag (USF) is used (on a PDCH basis) to allow multiplexing of uplink Radio blocks, from a number of MSs, in the same PDCH. USF is used in Dynamic Access Modes (see "9.8.1 Medium Access Modes"), and comprises 3 bits at the beginning of each Radio Block, that is sent in downlink direction (the 3 bits belong to the MAC header, see "3.5 MAC/RLC Block and Radio Block Structures"). It enables the coding of 8 different USF states which are used to multiplex the uplink trafc. Then all the mobile stations, which have an uplink TBF on the same PDCH, execute the following steps: 1. they read all the downlink blocks inside the multiframe, and decode the USF value; 2. if the USF is the one assigned to the MS, then the MS sends its uplink data on the next uplink block, or on next four uplink blocks; 3. if the USF is not the one assigned to the MS, then the MS doesnt send its uplink data on the next uplink block, or on next four uplink blocks. Fig. 4.9 shows the mobile station behavior in case of uplink transmission on the next uplink block.
A30808-X3247-L24-1-7618
47
Fig. 4.9
Multiplexing MS on the same PDCH (Uplink)
On PDCHs (not carrying PCCCH, see "4.4.2 Packet Common Control Channel (PCCCH)"), eight USF values are used to reserve the uplink to different MSs, by means of the following rule: - 7 USF values are used for 7 MSs that have established an uplink TBF; - one USF value is used to allow, to those MSs that have established a downlink TBF, to transmit control blocks in uplink direction (e.g. to transmit the Packet Downlink Acknowledge message). So when the network wants to permit to one MS, that doesnt have an uplink TBF, to transmit in uplink direction, it sets the USF field to this reserved value. In this way the MSs that have an uplink TBF dont transmit in the next uplink block (since they dont found their USF value), while the network informs the MS with the downlink TBF, that it must transmit in the uplink block that the network has reserved to it. To inform the MS, the network uses the RRBP field which is contained in all the downlink blocks (it is contained in the MAC header of both data and control blocks, see "3.5 MAC/RLC Block and Radio Block Structures"); by this field the network informs the MS that they must send a control block in uplink direction (see also "9.8.4 Relative Reserved Block Period Field (RRBP)").
GPRS and EGPRS MSs can be multiplexed dynamically on the same PDCH by utilizing the USF. The only problem is that if 8PSK modulation is used in downlink blocks (because downlink blocks are related to a EDGE TBF), a GPRS mobile station multiplexed on the same channel is not able to decode the USF value. So, the network: shall use the GMSK modulation, i.e. either CS 1 to CS 4 or MCS 1 to MCS 4, in those blocks that assigns the next uplink radio block, or the next four uplink radio blocks, to a GPRS mobile station; may use the 8PSK modulation for the other blocks. Besides, if we are using 8PSK modulation on a PDCH, in order to remain as much as possible with that modulation on this downlink PDCH, it is better to use granularity 4 for the GPRS mobile, this allows it to read the USF value every four downlink blocks.
48
A30808-X3247-L24-1-7618
So, when uplink resources must be allocated to a GPRS mobile station the USF value must point to the sequence of four uplink Radio Blocks starting with the next uplink Radio Block. The dynamic allocation using USF granularity requires that a GPRS MS can read the USF in an EGPRS GMSK block. This is enabled by setting stealing bits in the EGPRS GMSK blocks to indicate CS4 (see "4.2.2 EGPRS Channel Coding"). The coding and interleaving of the USF is done as defined for CS4; this leads to: a standard GPRS MS will be able to detect the USF in EGPRS GMSK blocks. The risk that the rest of the block will be misinterpreted as valid information is assumed to be low; an EGPRS MS can not differentiate CS4 blocks and EGPRS GMSK blocks by only looking at the stealing bits. This is however not needed for USF detection, since the USF is signalled in the same way. Further, assuming that the EGPRS MS knows if it is in EGPRS or standard GPRS mode, it will only have to try to decode the remainder of the GMSK blocks in one way in order to determine if they were aimed for it. For MS synchronization reasons, if standard GPRS MSs are multiplexed on the PDCH, at least one Radio Block every 360 msec on the downlink direction must use GMSK (i.e. standard GPRS or MCS-1 to MCS-4); this because every MSs must receive a radio block at least every 360 msec.
4.3.3
Multiplexing MSs on the same PDCH: Conguration

As it has been described, more than one MS can be multiplexed, either in downlink or in uplink direction, on the same physical data channel (PDCH): in uplink direction up to 7 MSs can be multiplexed on the same physical data channel; in fact up to seven USF values can be used to multiplex MSs on the same PDCH in uplink direction; in downlink direction up to 16 MSs can be multiplexed on the same physical data channel; this number is imposed by the Timing Advance Index (TAI) used for the Timing Advance Update procedure (see "4.6 Packet Timing Advance Estimation"); in total (uplink plus downlink) up to 16 MSs can be multiplexed on the same physical channel; this number is imposed by the Timing Advance Index (TAI) used for the Timing Advance Update procedure (see "4.6 Packet Timing Advance Estimation"). If, for instance, 7 MSs are using a PDCH in uplink direction, at most 9 MSs can use the same PDCH in downlink direction. The GMANMSAL parameter allows the operator to dene the maximum number of users that can share the same timeslot (PDCH); it is composed by two elds: the rst indicates the maximum number of users in uplink direction; the second one species the maximum number of users in downlink direction.
4.4
GPRS/EGPRS Logical Channels

Regarding packet switched services, four types of Packet Data Logical Channels have been introduced: Packet Broadcast Control Channel (PBCCH); Packet Common Control Channel (PCCCH); Packet Data Trafc Channel (PDTCH); Packet dedicated control channels (PTCCH and PACCH).
A30808-X3247-L24-1-7618
49
These different packet data logical channels, which are specific for GPRS/EGPRS, can occur on the same physical channel (i.e. on the same PDCH), when the timeslot is assigned to GPRS/EGPRS users.
The sharing of the physical channel is based on blocks of 4 consecutive Normal Bursts, with the exception of PTCCH (uplink direction) and PRACH (see "4.4.4 Packet Dedicated Control Channels") where single Access Bursts are used.
4.4.1
Packet Broadcast Control Channel (PBCCH)

Within GSM network, system information messages are regularly broadcasted by the BCCH and busy TCHs. With the help of system information the MS is able to decide whether and how it may gain access to the network via the current cell. The PBCCH logical channel broadcasts Packet data specific System Information (PSI). In addition to this kind of information, the PBCCH reproduces the information transmitted on the BCCH, to allow circuit switched operation to MSs that support both the services. In this way, a MS in GPRS attached mode monitors the PBCCH only, when this last is configured. The presence of the PBCCH is not mandatory in a cell supporting packet data services; if PBCCH is not allocated, the packet data specific system information is broadcast on BCCH (in the system information 13 message). The following Packet System Information exists: PSI 1, PSI 2, PSI 3, PSI 13 (see GSM 04.60). For instance: PSI 1 message is sent by the network on either the PBCCH or PACCH channel, giving information for cell selection, for control of the PRACH, for description of control channels and optional power control parameters; PSI 2 message is sent by the network on PBCCH channel, giving information of reference frequency lists, mobile allocations and PCCCH channel descriptions applicable for packet access in the cell; PSI13 message is sent by the network on PACCH channel (when the PBCCH channel is not configured), providing the MS with GPRS/EGPRS cell specific access-related information (e.g. Page Mode, Routing Area Code, Network Control Order, Power Control Parameters). When a GPRS mobile station camps on a cell, it starts reading system information on the BCCH channel. From BCCH channel, the MS understands if the cell supports the GPRS service. If the cell supports the service, the MS starts reading the system information 13, that provides GPRS cell specific information. From system information 13 the MS understands also if the PBCCH channel is configured in the cell. If it is configured, the MS stops reading system information on BCCH and starts reading packet system information on PBCCH. When a EDGE mobile station camps on a cell it starts reading system information on the BCCH channel. From BCCH channel, the MS understands if the cell supports the GPRS service. If the cell supports the service, the MS starts reading the system information 13, that provides information regarding EDGE availability too. From system information 13 the MS understands also if the PBCCH channel is configured in the cell, then: a) if PBCCH is not supported, MS knows that EGPRS is available reading GPRS Cell Option IE in SI13 and nding the EGPRS Packet Channel Request support indication eld, that indicates if the EGPRS PACKET CHANNEL REQUEST message is
50
A30808-X3247-L24-1-7618
supported in the cell (see "9.8.2.4 TBF Establishment for EDGE Mobile Stations"). Also PSI 13 in PACCH will contain GPRS Cell Options updated for EGPRS. b) if PBCCH is supported, GPRS Cell Options, updated for EGPRS, will be present in PSI 1.
The PBCCH channel, when configured, is allocated on a PDCH physical channel (see Fig. 4.10). Only one PDCH can support the PBCCH channel, i.e. it is not possible to configure the packet system information in two different PDCHs (it is like the GSM system, where the BCCH channel resides always in the slot 0 of the BCCH TRx.
TDMA frame
BCCH PBCCH
0 PDCH Fig. 4.10 Example of Mapping of the PBCCH Channel.
When, for GPRS/EGPRS mobile stations, PBCCH is used instead of BCCH, more information and parameters regarding packet switched data services are transmitted; for example new cell re-selection criteria are implemented (see "10.1 Cell Selection and Re-selection").
4.4.2
Packet Common Control Channel (PCCCH)

The PCCCH channel comprises logical channels used for common control signalling, introduced to support packet data services. These common channels are (see Fig. 4.11): Packet Paging Channel (PPCH): it is used, in downlink direction only, to page a MS prior to downlink packet transfer. PPCH uses paging groups in order to allow usage of DRX mode; Packet Access Grant Channel (PAGCH): it is used, in downlink direction only, in the packet transfer establishment phase, to send resource assignments to MSs prior to packet transfer; Packet Random Access Channel (PRACH): it is used, in uplink direction only, by a MS to initiate uplink transfer for sending data or signalling information. Access Bursts are used on PRACH (see "4.2 Channel coding").
A30808-X3247-L24-1-7618
51
Packet Random Access Channel PRACH
- to initiate uplink transfer - to request allocation of new PDTCHs
Packet Common Control Channels PCCCH
Packet Paging Channel PPCH
- to page a MS prior of a downlink transfer
Packet Access Grant Channel PAGCH Fig. 4.11 Packet Common Control Channels
- to allocate resources
PCCCH channels dont have to be allocated permanently on the cell. Whenever the PCCCH channels are not allocated, the already configured CCCH channels (i.e. PCH, AGCH and RACH) are used to execute the described operations, in the same way and with the same functionalities of GSM. The existence and the location of the PCCCH (i.e. the existence and the location of the PDCH channel that support the PCCCH) are broadcast on the cell.
The first PCCCH channel is automatically allocated when the PBCCH channel is configured, and it resides in the same PDCH containing the PBCCH (see Fig. 4.12). If the user needs more packet common signalling resources, it can configure another PCCCH in another PDCH (see Fig. 4.13).
TDMA frame
BCCH PBCCH + PCCCH
0 PDCH Fig. 4.12 Example of Mapping of the PCCCH Channel.
52
A30808-X3247-L24-1-7618
TDMA frame
BCCH PBCCH + PCCCH PCCCH
0 PDCH Fig. 4.13 Example of Mapping of two PCCCH Channels.
4.4.3
Packet Data Traffic Channel (PDTCH)

The PDTCH is a channel allocated for data transfer. It is temporarily dedicated to one MS. In the multislot operation (see "4.7 Multislot Configuration"), one MS uses multiple PDTCHs in parallel for individual packet transfer (i.e. it uses a PDTCH on each assigned PDCH). All packet data traffic channels are uni-directional: uplink PDTCH (PDTCH/U), for a mobile originated packet transfer; downlink PDTCH (PDTCH/D) for a mobile terminated packet transfer. A PDTCH also includes its dedicated control channels (see "4.4.4 Packet Dedicated Control Channels"). Regarding the PDTCH assignment, according to the GMANMSAL attribute, the following restrictions must be satisfied (see also 4.3.3):
PDTCHUp<=7 PDTCHDown<=16 PDTCHUp + PDTCHDown <=16
4.4.4
Packet Dedicated Control Channels

Two types of packet dedicated control channels are supported by GPRS/EGPRS services: Packet Associated Control Channel (PACCH): PACCH channel conveys signalling information related to a given MS. The signalling information includes e.g. acknowledgements and power control information. PACCH carries also resource assignment and reassignment messages, comprising the assignment of resources for PDTCH(s) and for further occurrences of PACCH. The PACCH channel is always associated to PDTCH channels: the PDTCH channel allows to transmit data blocks, while the PACCH channel allows to transmit the related signalling blocks; so the PACCH channel shares with PDTCHs the resources that have been currently assigned to one MS. For instance, the following control messages can be carried by the PACCH channel, according to the direction of transmission: Uplink Packet Control Acknowledgment; Packet Downlink Ack/Nack.
A30808-X3247-L24-1-7618
53
Downlink Packet Uplink Ack/Nack; Packet Power Control/timing Advance. Packet Timing Advance Control Channel (PTCCH): this type of channel is used in the timing advance update procedure (see "4.6 Packet Timing Advance Estimation"). The PTCCH/U is used to transmit random access burst to allow the estimation of the timing advance for one MS in packet transfer mode; the PTCCH/D is used to transmit timing advance information updates to several MSs.
4.4.5
Coding of GPRS/EGPRS Logical Channels

Regarding the coding of packet switched logical channels, the following considerations can be done: packet data trafc channels (PDTCHs) uses: coding schemes from CS1 to CS4 in case of GPRS; coding schemes from MCS1 to MCS4 in case of EGPRS; for all packet control channels, with the exception of PRACH and PTCCH/U, CS1 coding scheme is always used; both PRACH and PTCCH/U uses access bursts; for access bursts two coding schemes are specied (8 bit coding and 11 bit coding, see 9.8.2.1). on PTCCH/D, four normal bursts comprising a radio block are used to send the TAmessage (see "4.6 Packet Timing Advance Estimation").
4.5
Mapping of Logical Channels onto Physical Channels

A physical channel allocated to carry packet logical channels is called a packet data channel (PDCH). A PDCH carries packet logical channels only. GPRS/EGPRS logical channels are mapped dynamically onto a 52-multiframe (see Fig. 4.2). The 52-multiframe consists of 12 blocks of 4 consecutive frames, 2 idle frames and 2 frames used for the PTCCH channel. A block allocated to a given logical channel comprises one radio block or, in uplink direction only, 4 random access bursts.
Sometimes to allow the estimation of the timing advance, instead of transmitting a radio block, four access bursts are sent (see "9.8.6 Polling Procedures"). Besides it must be noted that the PRACH channel, when it is used in uplink direction, its not composed by a single block of four frames, but it is composed by four access bursts. The type of channel may vary on a block by block basis. From the configuration point of view the 12 blocks are put in an ordered list, defined as: B0, B6, B3, B9, B1, B7, B4, B10, B2, B8, B5, B11. A single PDCH carries different logical channels, according to either the operators choices or the direction of transmission. The following configuration can be used for a single PDCH: a) the PDCH doesnt carry the specic GPRS/EGPRS signalling (i.e. PBCCH and PCCCH channels); b) the PDCH carries both PBCCH and PCCCH channels;
54
A30808-X3247-L24-1-7618
c) the PDCH carries GPRS/EGPRS common signalling (i.e. PCCCH) but not the PBCCH channel.
4.5.1
PDCH without the Specific GPRS/EGPRS Signalling

When the PDCH doesnt carry GPRS/EGPRS specific signalling, the following statements are meaningful: in downlink direction (see Fig. 4.14) all blocks can be used as PDTCH/D or PACCH/D: the logical channel type is indicated in the block header. The mobile owner of the PDTCH/D or PACCH/D is indicated by the TFI (Temporary Frame Identier); PDCH Multiframe (downlink direction)
PDTCH/D PACCH/D PACCH/D PDTCH/D PDTCH/D PDTCH/D
Fig. 4.14
Example of Mapping of Logical Channels in the Physical Channel (Downlink Direction).
in uplink direction (see Fig. 4.15) all blocks can be used as PDTCH/U or PACCH/U: the occurrence of the PDTCH/U (and/or the PACCH/U) at given block(s) Bx (where Bx = B0...B11) in the 52-multiframe structure for a given MS on a given PDCH is indicated by the value of the Uplink State Flag (USF). The USF is contained in the header of the preceding block, transmitted in the downlink of the same PDCH. The MS may transmit a PDTCH block or a PACCH block on any of the uplink blocks used by the MS. The occurrence of the PACCH/U associated to a PDTCH/D is indicated by the network by polling the MS to transmit the PACCH/U block (see 9.8.4). PDCH Multiframe (uplink direction)
PDTCH/U PDTCH/U PACCH/U PDTCH/U PACCH/U PDTCH/U
Fig. 4.15
Example of Mapping of Logical Channels in the Physical Channel (Uplink Direction).
4.5.2
PDCH Carrying both PBCCH and PCCCH

When the PDCH carries both the PBCCH and the PCCCH channels, the following statements are meaningful: a) DOWNLINK DIRECTION: the rst block (B0) of the multiframe (see Fig. 4.2) is reserved for the PBCCH channel; the operator can also congure up to 3 more blocks as additional PBCCH. To congure additional blocks as PBCCH blocks, the operator can use the BSPBBLK parameter: it allows to specify at most four blocks, following the order: B0, B6, B3, B9.
A30808-X3247-L24-1-7618
55
the next remaining blocks can be congured for PAGCH, PDTCH/D and PACCH/D. To congure additional blocks to carry PAGCH, PDTCH/D and PACCH/D, the operator can use the BPAGCHR parameter: it allows to specify at most 12 blocks, following the order: B6, B3, B9, B1, B7, B4, B10, B2, B8, B5, B11. the remaining blocks are used for PPCH, PAGCH, PDTCH/D and PACCH/D. Fig. 4.16 shows an example of one PDCH carrying both the PBCCH and the PCCCH channels, where 3 blocks are dedicated to the PBCCH channel by setting the BSPBBLK value to 2. It can be noted how the number of blocks assigned to the logical channels change according to the value of the BPAGCHR parameter. In this example, since three blocks are always dedicated to the PBCCH channel, at most 9 blocks can be dedicated to PAGCH channel by the BPAGCHR parameter. b) UPLINK DIRECTION: in uplink direction each block can be used as PRACH, PDTCH/U and PACCH/U; the BPRACHR parameter allows the operator to indicate how many blocks must be reserved in a xed way to the PRACH channel. The operator can reserve up to 12 blocks (i.e. all the multiframe) for the PRACH channel. Remember that in a PRACH block, always 4 random access bursts are sent. Fig. 4.17 shows an example of one PDCH carrying PRACH channel; it can be noted how the blocks assigned to the logical channels change according to the value given to BPRACHR.
BSPBBLK BPAGCHR 2 2 2 2 2 2 2 2 2 2 2 0 1 2 3 4 5 6 7 8 9 :
BO
B1
B2
B3
B4
B5
B6
B7
B8
B9
B10
B11
PBCCH PAGCH + PDTCH + PACCH PAGCH + PDTCH + PACCH + PPCH Fig. 4.16 Example of Downlink Configuration with PBCCH and PCCCH Channels
56
A30808-X3247-L24-1-7618
BPRACHR 0 1 2 3 4 5 6 7 8 9 10 11 12
BO
B1
B2
B3
B4
B5
B6
B7
B8
B9
B10
B11
PRACH PRACH + PDTCH + PACCH Fig. 4.17 Example of Uplink Configuration with PRACH Channel.
4.5.3
PDCH Carrying PCCCH

When the PDCH carries the PCCCH channel (without the PBCCH one), the following statements are meaningful: a) DOWNLINK DIRECTION: up to 12 blocks can be congured for PAGCH, PDTCH/D and PACCH/D; to congure blocks to carry PAGCH, PDTCH/D and PACCH/D, the operator can use the BPAGCHR parameter: it allows to specify at most 12 blocks, following the order: B0, B6, B3, B9, B1, B7, B4, B10, B2, B8, B5, B11. the remaining blocks are used for PPCH, PAGCH, PDTCH/D and PACCH/D. b) UPLINK DIRECTION: in uplink direction each block can be used as PRACH, PDTCH/U and PACCH/U; the BPRACHR parameter allows the operator to indicate how many blocks must be reserved in a xed way to the PRACH channel. The operator can reserve up to 12 blocks (i.e. all the multiframe) for the PRACH channel. Remember that in a PRACH block, always 4 random access bursts are sent.
A30808-X3247-L24-1-7618
57
4.6
Packet Timing Advance Estimation

The packet timing advance estimation procedure is used to derive the correct value for timing advance that the MS has to use for the uplink transmission of radio blocks. The timing advance procedure comprises two parts: initial timing advance estimation; continuous timing advance update.
4.6.1
Initial Timing Advance Estimation

The initial timing advance estimation is based on the single access burst carrying the Packet Channel Request. The Packet Uplink Assignment or Packet Downlink Assignment (see "9.8 Access to the Network (Establishment of a TBF)") then carries the estimated timing advance value to the MS. This value is used by the MS for uplink transmissions until the continuous timing advance update provides a new value (see "4.6.2 Continuous Timing Advance Update"). Two special cases exist: when Packet Queuing Notication is used (see "9.8.5 Packet Queuing Notication Procedure"), the initial estimated timing advance may become too old to be sent in the Packet Downlink (Uplink) Assignment; when Packet Downlink (Uplink) Assignment has to be sent without prior paging (i.e., when the MS in the Ready state, see "9.3.1 Mobility Management States"), no valid timing advance value may be available. When timing advance information is not provided in the assignment message, the mobile station is not allowed to send normal bursts on the uplink direction until it receives a valid timing advance value either in PACKET TIMING ADVANCE/POWER CONTROL message or through the continuous timing advance procedure.
4.6.2
Continuous Timing Advance Update

MSs in Packet transfer mode use the continuous timing advance update procedure. The continuous timing advance update procedure is carried on the PTCCH allocated to the MS, if fact: for uplink packet transfer within the Packet Uplink Assignment the network assigns to the MS (besides the USF and the TFI) a Timing Advance Index (TAI) and a PTCCH channel; for downlink packet transfer, within the Packet Downlink Assignment, the network assigns to the MS (besides the TFI) a Timing Advance Index (TAI) and a PTCCH channel. The TAI specifies the PTCCH channel that the MS shall use. On the uplink, the MS sends in the assigned PTCCH/U an access burst, which is used by the network to derive the timing advance value. The network analyses the received access bursts and determines a new timing advance value for all MSs performing the continuous timing advance update procedure on that PDCH. The new timing advance values is sent via a downlink signalling message (TAmessage) on PTCCH/D. Network can send timing advance information also in Packet Timing Advance/Power Control and Packet Uplink Ack/Nack messages on PACCH. Fig. 4.18 shows the mapping of both the uplink access bursts and the downlink TAmessages on groups of eight 52- multiframes:
58
A30808-X3247-L24-1-7618
the TAI value shows the position where a slot is reserved for a MS to send an access burst in uplink direction (e.g. TAI= 1 identies the multiframe number n and the idle frame number 2). The TAI value defines the used PTCCH/U sub-channel, e.g.: the MS with TAI= 1 sends its access burst every eight multiframes in the idle frame number 2; the MS with TAI= 5 sends its access burst every eight multiframes in the idle frame number 10; the TA-message is sent from the network to MSs and it is composed of a radio block sent over four frames. For example: the MSs that have sent their access bursts in idle frames number 0, 2, 4 and 6, will receive their TA-message (with information about the timing advance to be used) in the TA-message number 2. This TA-message is transmitted in the downlink direction in terms of a radio block, distributed on the frames number 8, 10, 12 and 14. the MSs that have sent their access bursts in idle frames number 8, 10, 12 and 14, will receive their TA-message (with information about the timing advance to be used) in the TA-message number 3. This TA-message is transmitted in the downlink direction in terms of a radio block, distributed on the frames number 16, 18, 20 and 22.
Fig. 4.18
Continuous Timing Advance Update Feature The continuous timing advance update procedure can create some delays between the packet downlink assignment message and the beginning of the data transfer in downlink direction. In order to reduce the time between a packet downlink assignment message and the effective beginning of downlink data transmission, a specific packet polling procedure is executed (see, "9.8.6 Polling Procedures").
A30808-X3247-L24-1-7618
59
4.7
Multislot Conguration
Multiple packet data traffic channels can be allocated to the same MS. This is referred to as multislot packet configuration. In the multislot operation, one MS may use multiple PDTCHs in parallel for individual packet transfer. The network may allocate to a MS: several PDTCH/Us for one mobile originated communication; several PDTCH/Ds for one mobile terminated communication. In this context allocation refers to the list of PDCHs that may dynamically carry the PDTCHs for that specific MS. The PACCH may be mapped onto any of the allocated PDCHs. When a multislot configuration is used, a certain number of timeslots (PDCHs) is allocated to the same MS, according to its multislot capability; the following rules must be satisfied when more than one timeslot is assigned: 1. timeslots must belong to the same frequency (i.e. to the same TRX); 2. timeslots must be adjacent (i.e. they must have neighboring timeslots numbers-TN); 3. timeslots must belong to the same frequency hopping law, i.e. they must have the same: Mobile Allocation (MA); Mobile Allocation Index Offset (MAIO); Hopping Sequence Number (HSN);
Regarding frequency hopping for GPRS/EGPRS services, both Base Band Frequency Hopping and Synthesizer Frequency Hopping are supported.
4. timeslots shall have the same training sequence code (TSC).
4.7.1
Mobile Station Classes for Multislot Capabilities

When a GPRS/EGPRS MS supports the use of multiple timeslots, it shall belong to a multislot class as defined in Tab. 4.6 (only the first 12 classes are shown): Multislot class 1 2 3 4 5 6 7 8 9 10 Tab. 4.6 1 2 2 3 2 3 3 4 3 4 Maximum number of slots Rx 1 1 2 1 2 2 3 1 2 2 Tx 2 3 3 4 4 4 4 5 5 5 Sum 2 2 2 1 1 1 1 1 1 1 Minimum number of slots Tt 4 3 3 3 3 3 3 2 2 2 Tr
MS Multislot Classes
60
A30808-X3247-L24-1-7618
Multislot class 11 12 Tab. 4.6 4 4
Maximum number of slots Rx 3 4 Tx 5 5 Sum 1 1
Minimum number of slots Tt 2 2 Tr
MS Multislot Classes
where: Rx describes the maximum number of timeslots that the MS can use per TDMA frame in downlink direction. The MS must be able to support all integer values of timeslots (from 0 to Rx) in downlink direction; Tx describes the maximum number of timeslots that the MS can use per TDMA frame in uplink direction. The MS must be able to support all the integer values of timeslots (from 0 to Tx) in uplink direction; Sum is the total number of uplink and downlink timeslots that can actually be used by the MS per TDMA frame (when the MS has established a TBF in both the directions). The MS must be able to support all combinations of integer values of Rx and Tx timeslots where 1 <= Rx + Tx <= Sum; Tt relates to the time needed for the MS to get ready to transmit, after it has monitored the assigned timeslots in downlink direction; Tr relates to the time needed for the MS to perform adjacent cell signal level measurement and get ready to receive, after it has transmitted in uplink direction. Fig. 4.19 shows an example regarding a MS with multislot class=8: the MS has established concurrent TBFs, and it has 4 timeslots in downlink direction and 1 timeslot in uplink direction (remember that between downlink and uplink TDMA frames there is a temporal offset of 3 timeslots). When the MS has monitored its last downlink timeslot, it must wait Tt timeslots (i.e. 1 timeslot) before transmitting; after having transmitted in uplink direction, it waits Tr timeslots (i.e. 2 timeslots) before starting to monitor on downlink direction. Mobile Class = 8 Rx = 4 Tx = 1 Sum = 5 Tt = 1 Tr = 2 0 d d TDMA frame - Downlink d d u 0 7 7 TDMA frame - Uplink Tt Fig. 4.19 Example of Multislot Configuration Tr 7 0 d d
A30808-X3247-L24-1-7618
61
4.7.2
Mapping of Uplink Packet Traffic Logical Channels

The PDCHs where the MS may expect occurrence of its PDTCH/U(s) or PACCH/U for a mobile originated transfer is indicated in resource allocation messages. PACCH/U is allocated respecting the resources allocated to the MS and the MS multislot class. For each PDCH allocated to the MS, an Uplink State Flag (R0... R7) is given to the MS. To establish a multislot uplink Temporary Block Flow, the following conditions shall be satisfied: one common uplink TFI is available in all timeslots (TFI is the same on all the PDCHs); one USF is available for each PDCH in the set; a TAI is available in one of the assigned timeslots.
4.7.3
Mapping of Downlink Packet Traffic Logical Channels

The PDCHs where the MS may expect occurrence of its PDTCH/D(s) or PACCH/D for a mobile terminated transfer is indicated in resource allocation messages. The logical channel type is indicated in the block header. The mobile owner of the PDTCH/D or PACCH/D is indicated by the TFI (Temporary Frame Identifier) To establish a multislot downlink Temporary Block Flow, the following conditions shall be satisfied: one common downlink TFI is available in all timeslots (TFI is the same on all the PDCHs); a TAI is available in one of the assigned timeslots.
62
A30808-X3247-L24-1-7618
5 Hardware and Software Features

In order to introduce packet switched services in SBS, the PCU (Packet Control Unit) is designed for the BSC, to support packet data interworking between the Gb interface and the Abis interface. The functionalities of the PCU are supported by Channel Codec Units CCUs, which are implemented in the BTSs (see Fig. 5.1). The CCU functionality is added to the BTS functionalities by software download.
Fig. 5.1
Hardware and Software Entities supporting GPRS/EGPRS in BTS and BSC. The PCU is responsible for: Channel Access Control functions, e.g. access requests and grants; PDCH scheduling functions for uplink and downlink data transfer; Radio Channel Management functions, e.g. power control, congestion control, broadcast control information, etc.; PDCH RLC ARQ functions, including buffering and re-transmission of RLC blocks; LLC layer PDU segmentation into RLC blocks for downlink transmission; RLC layer PDU re-assembly into LLC blocks for uplink transmission; management of protocols toward the Gb interface. The functions inside the CCU are: Channel coding functions, including FEC and interleaving; Radio channel measurement functions, including received quality level, received signal level and information related to timing advance; Continuous Timing Advance update. The PCU functional object represents the packet control unit designed to implement packet switched services in SBS (see Tab. 5.1). Functional object PCU Meaning Represents the Packet Control Unit designed to implement packet switched services. PCU Object
Tab. 5.1
In BR7.0 release, different BSC types are provided, so, different boards can be used to implement the PCU. In the following the different types of supported BSCs are described to put in evidence their differences from the GPRS/EGPRS point of view; besides, also differences in
A30808-X3247-L24-1-7618
63
terms of BTS equipment are described, because according to the BTS type a specific set of features is provided for what concerns GPRS and EGPRS.
5.1
Supported BSC Types

As it has been described, in the current release different types of BSC are supported; they are: 1. the BSC equipped with the SN16 switching matrix and with older peripheral processors (here called standard BSC, see 5.1.1); 2. the High capacity BSC based on the same rack of the standard one, but equipped with the SNAP switching matrix (here called High capacity BSC with the old rack, see 5.1.2), that provides better performances in terms of: connectivity (i.e. number of PCM lines); packet data handling capability; LAPD signalling. 3. the High capacity BSC based on a new rack (here called High capacity BSC with the new rack, see 5.1.3), that provides better capabilities with respect to the High capacity BSC with the old rack, thanks also to new LICD cards.
In next paragraphs different BSC types are described, taking into account also their capability in terms of GPRS and EGPRS resources. To avoid confusion it is important to make a distinction between the terms Packet Data Channel (PDCH) and Packet Data Terminal (PDT). The Packet Data Channel (PDCH), as it has been described in "4 Radio Interface", is the radio timeslot associated to packet switched services (i.e. when the timeslot is associated to packet switched services, it is called PDCH). The Packet Data Terminal represents a basic resource for packet switched services manageable by the PCU. The capacity of the PCU, from packet switched data services point of view, is given in terms of Packet Data Terminals, i.e. a PCU supports a certain number of Packet Data Terminals. This number of Packet Data Terminals corresponds to the number of Abis subslots (16 kbit/sec) manageable by the PCU. For example when a single PDCH is associated to a GPRS user using CS2 coding scheme, it is also associated a single Abis subslot, and so only one PDT is busy in the PCU that manages this PDCH (in this case there is a one to one relationship between PDCH and PDT); but when a single PDCH is associated to a EGPRS user using MCS9 coding scheme, five Abis subslots must be associated to this PDCH (see 5.3), and so five PDT are busy in the PCU that manages this PDCH (in this case there is a one to five relationship between PDCH and PDT).
5.1.1
Standard BSC
In the Standard BSC, to implement the PCU unit, PPCU processors are used; each PCU unit consists of two PPCU boards: one of them is in Providing Service state; the other one is in Cold Stand-by state, and it is used as a spare board. The PPCU boards are inserted in the BSC rack in place of some PPLDs, as it is shown in Fig. 5.2.
64
A30808-X3247-L24-1-7618
Fig. 5.2
View of the BSC Rack with and without PPCU Boards.
Two instances of the PCU object can be created: PCU:0; PCU:1. The creation of one PCU object implies the consequent creation of the two related PPCU boards (active and cold-standby): the creation of the PCU:0 involves the creation of both the PPCU:0 and the PPCU:1; the creation of the PCU:1 involves the creation of both the PPCU:2 and the PPCU:3. The system firstly creates the two PPCU objects, and then the PCU object. When the first card reaches the Providing Service state, then the PCU starts the configuration alignment. Since the PPCUs are inserted in the BSC rack in substitution of some PPLDs, when the user creates a PCU object instance, some PPLDs should not have been equipped. The rule is shown in Tab. 5.2.
A30808-X3247-L24-1-7618
65
PCU instance PCU:0
PPLDs to be removed PPLD:11 PPLD:12 PPLD:13 PPLD:14
PCU:1
PPLD:7 PPLD:8 PPLD:9 PPLD:10
Tab. 5.2
PPLD Boards to Be Removed according to the PCU Object Instance.
Each PPLD board can manage up to 8 LAPD channels; so, when 14 PPLD boards are used, 112 LAPD channels are available in the BSS. When some PPLD boards are removed to introduce PPCU boards, the number of LAPD channels decreases, reducing the signalling capability of the BSC. When only one PCU is created, the number of PPLD boards becomes 10, and the number of configurable LAPD channels is 80; when both the PCU instances are created, the number of PPLD boards decreases to 6, and the number of configurable LAPD channels is 48. Each Packet Control Unit is able to handle at most a data rate of 2 Mbit/sec. This data flow is divided in two data rates of 1 Mbit/sec each one: 1. a data rate of 1 Mbit/sec towards the Abis interface; this ow allows to manage on the Abis interface at most 64 GPRS channels (16 Kbit/sec each one), i.e. 64 PDTs; 2. a data rate of 1 Mbit/sec towards the Gb interface; this ow allows to manage on the Gb interface at most 16 Frame Relay Links (64 Kbit/sec each one, see "7 Gb Interface"). When the standard BSC is fully equipped with two PCUs, it can handle up to 128 GPRS channels (PDCHs).
EGPRS is not supported by the standard BSC due to its low capacity in terms of PDTs. Besides, for each BSC it is possible to configure up to 150 cells and, as a consequence, up to 150 PTPPKF object instances.
66
A30808-X3247-L24-1-7618
5.1.2
High Capacity BSC with the Old Rack

Using the same rack of the previous releases, it is possible to get a BSC with an higher capacity by changing some boards (see Fig. 5.3).
Fig. 5.3
View of the High Capacity BSC with the Traditional Rack.
In order to get a High Capacity BSC using the traditional rack, the following boards are used: a new switching matrix board, called SNAP; new peripheral processor boards i.e.: PPXL boards to manage both LAPD and SS7L signalling; PPXU boards to manage GPRS and EGPRS services.
It is important to underline that the hardware of both PPXLs and PPXUs is named PPXX; depending on the slot position inside the BSC rack, the same board (i.e. the PPXX one) acts, from the functionality point of view, as PPXU or PPXL. In comparison with the SN16 (i.e. the switching matrix of the standard BSC), the SNAP card allows to interface 48 lines at 8 Mb/sec coming from LICD and PPXX (double bandwidth in comparison with the SN16, which can interface 24 lines).
A30808-X3247-L24-1-7618
67
This doubled number of lines increases independently (i.e. without trade-off) both GPRS/EGPRS and LAPD channels. The new switching matrix is introduced in the system through the handling of the NTWCARD attribute; this attribute can assume the values: NTWSN16, when SN16 switching matrix is used (standard BSC); NTWSNAP, when the SNAP switching matrix is used (high capacity BSC with the old rack).
When the NTWCARD is set to NTWSN16, the BSC works with PPCC, PPLD and PPCU boards. When the attribute value is NTWSNAP, only the SNAP and the new PPXU and PPXL boards are allowed. Mixed configurations are not possible. In the high capacity BSC, to get more GPRS/EGPRS channels it has been necessary to increase the number of boards assigned to packet switched functionality and to increase also their capability. This is allowed by the SNAP switching matrix, which provides 8 lines at 8 Mbit/sec towards PPXXs. Two lines are used for handling LAPD and SS7 level 2 signalling protocols with the new PPXL boards; and the remaining six ones are used for PPXU boards (each PPXU board has its own 8 Mbit/sec line). The PPXUs are all placed in the extended rack (as it is for the PPCUs). To handle packet switched services, six instances of the PCU object can be created: PCU:0; PCU:1; PCU:2; PCU:3; PCU:4; PCU:5. The creation of one PCU object implies the consequent creation of one PPXU board: i.e the creation of the PCU:0 involves the creation of the PPXU:0, the creation of the PCU:1 involves the creation of the PPXU:1, and so on.
A PPXU card is automatically created when the PCU object with the same instance is created, if NTWCARD= NTWSNAP. Otherwise (if NTWCARD=NTWSN16), a couple of PPCU is created (PPCU 0,1 for PCU-0; PPCU 2,3 for PCU-1). Tab. 5.3 shows the correspondence between the boards of the standard BSC and those ones of the high capacity BSC from packet switched services point of view. Standard BSC (no GPRS) PPLD-3 PPLD-4 PPLD-5 PPLD-6 PPLD-7 PPLD-8 PPCU-2 PPXU-2 Standard BSC (full GPRS conguration) PPLD-3 PPLD-4 PPLD-5 PPLD-6 PPXU-1 PPXU-0 High capacity BSC
Tab. 5.3
Correspondence between the Boards of the Two Types of BSC
68
A30808-X3247-L24-1-7618
Standard BSC (no GPRS) PPLD-9 PPLD-10 PPLD-11 PPLD-12 PPLD-13 PPLD-14
Standard BSC (full GPRS conguration) PPCU-3
High capacity BSC PPXU-3
PPXU-4 PPCU-1 PPXU-5
PPCU-0 Tab. 5.3 Correspondence between the Boards of the Two Types of BSC Since each PPXU is connected to the SNAP matrix by a 8 Mbit/sec line, each PPXU board, and as a consequence each PCU, is able to handle at most a data rate of 8 Mbit/sec. This data rate of 8 Mbit/sec is split into 128 time slots at 64 Kbit/sec each one. Since one of these time slots is used to transmit the CRC related to the others, then 127 timeslots can be used effectively. This data flow is divided into two data rates: 1. a data rate constituted of 64 time slots of 64 Kbit/sec towards the Abis interface; this ow allows to manage on the Abis interface at most 64 X 4 = 256 GPRS/EGPRS channels (16 Kbit/sec each one), i.e. 256 PDTs
Please remember that, if either GPRS CS3 and CS4 coding schemes, or EGPRS coding schemes are used, 256 PDTs do not correspond to 256 PDCHs strictly.
2. a data rate constituted of 63 time slots of 64 Kbit/sec towards the Gb interface; this ow allows to manage on the Gb interface at most 63 Frame Relay Links (64 Kbit/sec each one, see "7 Gb Interface"). Each PPXU board and then each PCU can handle up to 256 PDTs; so to reach 1280 PDTs (that is the number of packet switched resources provided by the high capacity BSC), 5 boards (i.e. 1280/256 boards) have to be considered in service simultaneously; this means that 1+1 redundancy (used in the standard BSC) is no longer possible and a different redundancy schema is provided. The used redundancy schema is called load balancing: with this schema all the six boards are simultaneously in service and the packet switched traffic is distributed among all the six boards (see "8 Load Control for Packet Switched Services"); this implies that each board will normally work in relax (the required real time traffic can be spread over 6 boards instead of 5). When the BSC is fully equipped with six PCUs, it can handle up to 1280 PDTs and 378 Frame Relay Links (63 X 6). Besides, with the high capacity BSC it is possible to configure up to 250 cells and, as a consequence, up to 250 PTPPKF object instances.
A30808-X3247-L24-1-7618
69
5.1.3
High Capacity BSC with the New Rack

The current release foresees a new BSC rack to get a new BSC with high capacity. Fig. 5.4 shows the high capacity BSC with the new rack. How it can be seen, the new rack contains the SNAP matrix and new PPXU, PPXL boards already present in the high capacity BSC with the old rack; these boards have the same characteristics already described in "5.1.2 High Capacity BSC with the Old Rack". With respect to the old rack, the new BSC rack provides the following innovations: support to the new line interface card, the STLP, which is used in place of the QTLP in the new rack; this includes the increase from 9 to 10 of the LICD number, and from 4 to 6 of the circuit number of LICD on which a PCM line can be created; support of 12 PCUs and PPXUs; new rack conguration and back plane: this will allow doubling the number of used PPXU (PPXX supporting GPRS/EGPRS) from 6 to 12; it will also allow housing 10+2 STLP, i.e. one more card than QTLPs equipped in the old rack. new fan box for heat dissipation. In order to achieve these goals, the following additional changes are introduced: the 2 EPWR (power supply devices in the expansion module) are removed to make room for PPXU and STLP. For this reason, the PPXX and the STLP are provided with an internal power supply, directly fed by the 48 V; on the top of the BSC a box containing 6 fans has been introduced, powered by the 48 V, to cope the increased heat generated by the BSC; sense points in the new board CPEX for monitoring the fan alarms have been introduced. As it has been previously described (see "5.1.1 Standard BSC" and "5.1.2 High Capacity BSC with the Old Rack"), the NTWCARD attribute allows to specify the BSC type. In fact if NTWCARD is set to NTWSN16, the BSC is made by the old rack and it works with SN16, PPCC, PPLD and PPCU boards; if the attribute value is NTWSNAP, then the old rack is still used but in this case only the SNAP matrix and new PPXU and PPXL boards are allowed. If the user wants to use the new BSC rack, with new STLP boards (and obviously also with SNAP and PPXU/PPXL boards), he must set the NTWCARD attribute equal to the NTWSNAP_STLP value. Regarding PPXU boards, the redundancy schema is always the load balancing one: all the twelve boards are simultaneously in service and the packet switched traffic is distributed among all the twelve boards (see "8 Load Control for Packet Switched Services"); this implies that each board will normally work in relax (the required real time traffic can be spread over 12 boards instead of 11). When the BSC is fully equipped with twelve PCUs, it can handle up to 2816 GPRS/EGPRS PDTs and 756 Frame Relay Links (63 X 12).
Please remember that, if either GPRS CS3 and CS4 coding schemes, or EGPRS coding schemes are used, 756 PDTs do not correspond to 756 PDCHs strictly. Besides, with the high capacity BSC it is possible to configure up to 400 cells and, as a consequence, up to 400 PTPPKF object instances.
70
A30808-X3247-L24-1-7618
Fig. 5.4
High Capacity BSC with the New Rack
5.1.4
PPCU and PPXU Redundancy and Configuration Rules

As it has been previously described, with the standard BSC two boards are deputed to manage GPRS service: they are named PPCU. For safety reason both boards have a spare copy. No dynamic data is present on the spare board so the redundancy schema is defined, in BSC terminology, as cold standby. The creation of one PCU object implies the consequent creation of the two related PPCU boards (active and standby). When the high capacity BSCs are used, six or twelve boards are deputed to manage GPRS and EGPRS services: they are named PPXU. In this case the 1+1 redundancy is no longer possible and a different redundancy schema called load balancing is provided (see 5.1.2 and 5.1.3)
A30808-X3247-L24-1-7618
71
It has been described that: the standard BSC can manage up to 150 GPRS cells, so the user can congure only up to 150 PTPPKF object instances; the high capacity BSC with old rack can manage up to 250 GPRS/EGPRS cells, so the user can configure up to 250 PTPPKF object instances; the high capacity BSC with old rack can manage up to 400 GPRS/EGPRS cells, so the user can configure up to 400 PTPPKF object instances. An important thing to be underlined (for all the BSC types) is that when the user configures a cell to be used for packet switched services, i.e. when the user creates a PTPPKF object instance, he does not have to assign the GPRS (or EGPRS) cell to a specific PCU, but it is the system that assigns the cell dynamically to one of the available PCUs. This behavior, during PTPPKF creation, is a direct consequence of the load balancing redundancy of the PPXUs: when a new cell is created, the system assign it to a PCU (the less busy one); when a PCU becomes unavailable, the cells served by it are dynamically distributed among the other PCUs. This behavior regards also the PPCUs even if they use the cold stand-by redundancy. In fact, using the standard BSC: when a new cell is created, the system assigns it to one of the two PCUs (the less busy); when the active PPCU board fails, the stand-by one will replace the damaged one (according to stand-by redundancy); if a couple of PPCU boards fails (i.e. if a PCU becomes unavailable), all the GPRS/EGPRS traffic of the PCU will be managed by the other couple of PPCU boards (i.e. by the other PCU) according to the load balancing criteria (as it happens in the high capacity BSC). The algorithm, that is used to distribute and redistribute the GPRS/EGPRS cells of one BSC among the available PCUs, is described in "8 Load Control for Packet Switched Services" chapter.
5.2
BTS Equipment Supporting GPRS and EGPRS

Regarding BTS equipment different solution can be adopted according to the operators needs. In fact, speaking about GPRS and EGPRS services, different kind of features are provided according to the used equipment; the following solutions are available: 1. BTS equipment supporting EDGE and all GPRS coding schemes. 2. BTS equipment supporting CS1 and CS2 coding schemes only; 3. BTS equipment supporting GPRS CS3 and CS4 but not EDGE; EDGE support is limited to the BTSplus platform. To introduce EDGE into the network, existing BTSplus sites must be easily upgraded with EDGE capable carrier units (E-CU) featuring the new 8-PSK modulation technique. The E-CU hardware is able to handle: GSM, HSCSD and GPRS (with all its coding schemes) services; enhanced GPRS service (EGPRS). To implement EGPRS, some GSM-CUs can be replaced by E-CUs at any arbitrary CU rack position; mixed configurations with CUs and E-CUs as well as configurations with E-CUs only are possible, but, as it has been said, the upgrade is only supported for BTSE types belonging to the BTSplus generation. Regarding GPRS coding schemes the requirements are the following:
72
A30808-X3247-L24-1-7618
BTS1 can not support GPRS CS3/CS4 coding schemes, if it not equipped with BBSIG44 boards only. There exists a ag in the BSC software which allows the BSC to distinguish between a BTS1 which contains only BBSIG44 boards and a BTS1 which contains a mixture of BBSIG and BBSIG44 boards. This flag is called PUREBBSIG44CONF and the setting is as follow: BTS1 with mixed BBSIG-BBSIG44 boards: PUREBBSIG44CONF set to FALSE; BTS1 with only BBSIG44 boards: PUREBBSIG44CONF set to TRUE. BTS+, e-microBTS, picoBTS, support GPRS CS3/CS4 coding schemes (also if a mixed conguration of GSM-CU and EDGE-CU boards is present);
i 5.3
It has to be remarked that it is up to operator to ensure the consistency between software configuration and BTS hardware.
PCU Frames and Dynamic Allocation on the Abis Interface

This chapter regards the distribution of GPRS/EGPRS traffic channels on the Abis interface. The Flexible Abis allocation strategy (Dynamic Allocation) is a general strategy used to handle the Abis resources in a flexible way. A flexible Abis allocation strategy is necessary to support GPRS CS3-CS4 coding schemes, and all EDGE coding schemes requiring more than 16 kbit/s Abis throughput for specific radio channels. With the dynamic Abis allocation the number of Abis subslots that can be associated to a radio timeslot depends on the service type. From the hardware platforms point of view, the following equipment support the flexible Abis allocation strategy: all the possible BSC congurations (standard BSC and high capacity BSCs, see"5.1 Supported BSC Types"); the BTSplus mainline with GSM-CU and EDGE-CU; picoBTS and enhanced micro BTS; BTS1. The introduction of CS3 and CS4 coding schemes for GPRS, and the EDGE feature have big impacts also on existing Abis interface, which must be modified: the Abis conguration of standard PCU frames (used for GPRS CS1/CS2 coding schemes), which is based on a single 16 Kbit/s slot, is not sufcient and does not manage the transport of high data rates per air timeslot exploited by GPRS CS3/CS4 coding schemes and EGPRS. The EGPRS data is submitted via "concatenated PCU frames" (see 5.3.1), as well as the GPRS data, in case the higher coding schemes (CS3/CS4) are enabled. Hence the exible Abis allocation strategy gives the opportunity to assign to each air interface timeslot, from one to up to ve 16 kbit/s Abis subslots (16 kbit/s each one) in a exible way; the capacity of each air interface timeslot can vary during runtime; for GPRS CS3/CS4 or EGPRS, the exible Abis allocation strategy adapts the Abis capacity to the required air interface capacity (in case of Link Adaptation/new TBF establishments/old TBF releases). Note that exible Abis allocation strategy is a
A30808-X3247-L24-1-7618
73
slow process compared to GPRS/EGPRS Link Adaptation (see "10.5 Link Adaptation"), hence the two processes must be synchronized; the total Abis capacity per BTS increases with the introduction of higher data rates at Um interface. Then, the exible Abis allocation strategy must be coupled with the management of up to 4 Abis PCM lines per BTS. Tab. 5.4 shows how packet switched services can be mapped in 16 Kbit/s, or N*16 Kbit/s Abis resources (per radio timeslot). 16 Kbit/sec GPRS channels supporting CS1 and CS2 only N x 16 Kbit/sec EGPRS (up to 5x16 kbit/s) GPRS channels supporting CS3/CS4 (up to 2x16 kbit/s)
Tab. 5.4Mapping of Services onto Abis Resources Besides, the flexible Abis allocation strategy coupled with the concept of concatenated PCU frames gives the operator the following advantages: the Abis interface handling is more efcient: a common pool of Abis timeslots is associated to a BTSM; then these Abis resources will be shared between different timeslots, carriers and even between different cells of the same base station site; EGPRS and GPRS Link Adaptation can be performed during runtime without loss of service; unused capacity of an air interface timeslot can be released in the Abis interface and exploited by other air interface timeslots; it is possible to reach a data rate up to about 60 kbit/s per packet data channel (PDCH) on the Abis interface. Generally speaking, the flexible Abis allocation strategy is managed by two different processes: 1.the rst task is the conguration one: the operator can assign to every BTSM a pool of Abis timeslots. These timeslots will be used to transfer information between the BTSM and the BSC; 2.the second task relies on the exible allocation and release of resources taken from the Abis pool. The Abis allocation algorithm is able to: assign sufcient Abis bandwidth to an air interface timeslot during run time; release bandwidth in case of congestion, according to service priorities and QoS constraints.
The traditional Static Abis management is kept for backward compatibility with the previous releases, harmonizing the O&M management of flexible and static BTSM. It must be clear that: exible abis allocation means that the association between radio timeslots and Abis timeslots is performed by radio signalling procedures. There is not a xed one-to-one (1 x 16 kbit/s) or one-to-two (2 x 16 kbit/s) association from air interface timeslots to Abis subslots, in the BSC database; static abis allocation means that the association between radio timeslots and Abis timeslots is performed during O&M procedures, stored into BSC database and
74
A30808-X3247-L24-1-7618
signalled to BTSM by O&M signalling procedures. The association is xed during runtime and can only be changed via O&M reconguration. To simplify the configuration procedures, the operator commands, used to configure both flexible and static allocations for a BTSM, are the same. In case of static BTSM, the static allocation between radio and Abis channels is performed by the system (BSC) at configuration time. In the following the different topics related to this feature are discussed, considering: a discussion about concatenated PCU frames (see 5.3.1); hardware supporting exible Abis allocation and concatenated PCU frames (see 5.3.2); conguration of the Abis interface (see 5.3.3); algorithms regarding exible Abis allocation (see 5.3.4).
5.3.1
Concatenated PCU Frames

The PCU frame is used to transmit packet data traffic on the Abis interface, whereas to transmit voice traffic, the similar TRAU frames are used. Concatenated PCU can handle: EGPRS (MCS1,., MCS9) GPRS Step II (CS3/CS4 data rates) GPRS Step I (CS1/CS2 data rates) Concatenated PCU frames require partially more bandwidth (e.g. with 32kbps, 48kbps, 64kbps and even 80kbps) than the current 16kbps ones. This higher bandwidth is achieved by concatenating several 16kbps subframes (1 up to maximum 5 EDGE subframes). In total 5 subframes (instead of 4) are necessary for 60kbps MCS8/MCS9 because of the huge in band signaling overhead. A PDCH with multiplexed EDGE and GPRS TBFs requires an Abis allocation due to the highest used coding scheme. Hence at the moment a PDCH with a MCS9 TBF on it requires 16Kbit/s*5 = 80Kbit/s. The subframes contain an index ranging from 1 to 5 called Sub-Frame-Counter (SFC) plus several control parameters and spares, which can be used in future. The Sub-Frame-Counter (SFC) indicates the sub-frame number and provides the sequence order of the 16Kbit/s channels. The SFC is coded by 5 bits, which allow a maximum chain of up to 32 concatenated PCU subframes (see Fig. 5.5). Thus the receiving side (either PCU in uplink or BTS in downlink direction) is able to reassemble the subframes to achieve the original complete RLC/MAC block.
A30808-X3247-L24-1-7618
75
Fig. 5.5
Fundamental Principle of Concatenated PCU Frames Concatenated PCU frames transport, for each coding scheme of GPRS/EGPRS services, the following number of bits, in downlink and uplink direction respectively (that represents the size of the transmitted MAC/RLC Block, see Tab. 4.2 and Tab. 4.3): Coding scheme CS1 CS2 CS3 CS4 MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7 MCS8 MCS9 Tab. 5.5 The useful payload part of the concatenated PCU frames is filled as follows: GPRS: Block Header, Data; EGPRS MCS1,...,6: Block Header, E, FBI/TI, Data EGPRS MCS7,...,9: Block Header, E, FBI/TI, Data 1st part, E, FBI/TI, Data 2nd part Number of bits transmitted in DL/UL (corresponding to the total size of the MAC/RLC block) 184 271 315 431 209 257 329 385 478/487 622/631 940/946 1132/1138 1228/1234
76
A30808-X3247-L24-1-7618
Header Check Sequences (HCS), Block Check Sequences (BCS) and Tail Bits are added by the BTS coder. MSs using different coding schemes can be multiplexed on the same timeslots (PDCH) on the air interface. Multiplexing of GPRS and EGPRS mobile stations is also possible if concatenated PCU frames are used in both cases (i.e. on the same timeslot it is not possible to multiplex users which are exploiting new concatenated PCU frames and others working with the standard PCU frames). The BTS and the BSC shall know how many Abis subslot are allocated to an air interface channel and they both shall know, which PCU subframe with which SFC is mapped on each 16kbps Abis subslot. That means: in case of multiplexing several TBFs on the same PDCH, for this PDCH all TBFs have PCU frames with the same SFC on a specific Abis subslot. Hence due to the selected Coding Scheme, which is outlined in the control bits of the first subframe, the mapping of the radio block payload to the PCU frame data bits is given and it is also clear, which PCU frame data bits must be filled with the pattern and which (maybe) are idle. The n*16 Kbit/s subframes of an air interface timeslot shall be arbitrarily distributed over PCM 24/30 Abis lines: they shall not necessarily allocate a block of subsequent Abis subslots, which is of course possible. The subframes can be completely disordered on the PCM lines of the BTSM as long as they are within the defined pool of the BTSM. They do not have to guarantee any ordered sequence in ascending way due to increasing SFC. But, as it has been said, it must be guaranteed that for a given PDCH all allocated TBFs use the same Abis subslots for concatenated PCU frames with the same SFC. Although all subframes have an equal size of 40 Octets = 320 bit (16kbps bit rate) the shape of the first subframe and the other consecutive subframes is a little bit different Fig. 5.6 shows an example of the abis mapping for a DL MCS9 radio block requiring 5 Abis subslots; the first subframe in figure 3 has a payload of maximum 216 bit, all others can carry up to 272 bit. As soon as a selected coding scheme requires less than the full number of data bits, the rest in the last data subframe shall be filled with a predefined bit pattern, e.g. 11111111...... In case of a coding scheme, which requires less subframes than the PDCH has allocated, those completely unused subframes shall be idle subframes also filled with the bit pattern 111111.... . These idle subframes shall be based on the coding of the additional subframes.
A30808-X3247-L24-1-7618
77
Fig. 5.6
Abis Mapping for a DL MCS9 radio block requiring 5 Abis subslots Since users multiplexed on the same PDCH can not use a different number of PCU subframes on Abis, idle PCU subframes with filling patterns are used on the Abis subslots not carrying data payload, in order to extend all the concatenated PCU frames to the same MCS-j (j=1,..., 9) configuration. Let us consider an Abis channel that is allocated for a maximum bandwidth for a MS using MCS9; in this case MSs using MCSs lower than MCS9 have some idle PCU frames with a filling pattern (e.g. 1111111...), due to the requirement that all TBFs on a particular PDCH occupy the same Abis capacity, whether they need it or not. Another case in which idle PCU-sub-frames are used to fill up the allocated Abis capacity is when a Link Adaptation of a TBF to a lower data rates occurs (i.e. MCS9/MCS6, because of the impossibility of the air interface to maintain MCS9 with good quality). The unused Abis capacity is filled with idle PCU sub-frames with filling pattern, because to reduce signalling overhead, the release of allocated Abis capacity is not executed immediately.
Standard PCU frames can be still used even combined with the flexible Abis allocation strategy; in fact dynamic Abis allocation does not imply the usage of concatenated PCU frames. Standard PCU frames are used whenever the BTS does not support concatenated ones (see "5.3.2 Hardware supporting Flexible Abis Allocation and Concatenated PCU Frames").
78
A30808-X3247-L24-1-7618
5.3.2
Hardware supporting Flexible Abis Allocation and Concatenated PCU Frames

As it has been described, dynamic Abis allocation does not imply concatenated PCU frame usage in packet flows. Fig. 5.7 and Fig. 5.8 show the relationship among standard/concatenated PCU frames and flexible/static Abis allocation, depending on the BTSE type and on the BSC type (i.e. standard or high capacity BSC). High Capacity BSC Both standard and concatenated PCU frames are supported.
BTSplus, picoBTS, E-microBTS - Standard/Concatenated PCU frames supported

- CS1...CS4 supported - MCS1...MCS9 supported on EDGE carriers -Dynamic Abis allocation supported
Concatenated PCU frames
BTS1 with BBSIG44 - Standard/Concatenated PCU frames supported - CS1...CS4 supported - Dynamic Abis allocation supported Concatenated PCU frames Dynamic Abis allocation
BTS1 without BBSIG44 - Only Standard PCU frames supported

- Only CS1 and CS2 supported - Dynamic Abis allocation supported
Standard PCU frames
Fig. 5.7
High Capacity BSC: Relationship between PCU Frames and Abis Allocation according to the BTSE Type
A30808-X3247-L24-1-7618
79
BTSplus, picoBTS, E-microBTS - Standard/Concatenated PCU frames supported

- CS1...CS4 supported - MCS1...MCS9 supported on EDGE carriers -Dynamic Abis allocation supported
Standard BSC Only standard PCU frames are supported.
Standard PCU frames
BTS1 with BBSIG44 - Standard/Concatenated PCU frames supported - CS1...CS4 supported - Dynamic Abis allocation supported Standard PCU frames Dynamic Abis allocation
BTS1 without BBSIG44 - Only Standard PCU frames supported

- Only CS1 and CS2 supported - Dynamic Abis allocation supported
Standard PCU frames
Fig. 5.8
Standard BSC: Relationship between PCU Frames and Abis Allocation according to the BTSE Type The following considerations can be done: standard PCU frames are used whenever GPRS CS3/CS4 and EDGE are not supported; concatenated PCU frames are used whenever EDGE and/or CS3 and CS4 (more than 16 kbit/s per radio timeslot) are supported; in all the previous cases, the mapping between radio timeslots and Abis timeslots is dynamic (at channel activation); GPRS CS3/CS4 and EGPRS are not supported on standard BSC, due to its low GPRS capacity (max. 128 PDCHs, decreasing to 64 PDCHs in case of CS3/CS4); in this case GPRS CS3/CS4 and EGPRS are not supported, and standard PCU frames are always used. The BSC software is backward compatible and it is able to handle BTSs running with old software releases, supporting only static Abis allocation. Fig. 5.9 gives such an example, when BTSs with old software releases are connected to a BSC with a release supporting the flexible Abis allocation strategy. In this case only GPRS CS1/CS2 radio channels are supported (GPRS CS3/CS4 or EGPRS capabilities cannot be configured). There are not any problems to handle such kind of situations since: static allocation and standard PCU frame format are implemented on BSC; operator commands for a release supporting the exible Abis allocation strategy have a backward compatible meaning and management (Abis pool denition is internally handled in a static way for old BTS software releases); the BSC is able to reject operator commands not compatible with old BTS software releases.
80
A30808-X3247-L24-1-7618
BSC Hardware
Software Release supporting Dynamic Allocation All BTS Hardware with Static Abis Software Release - Only Standard PCU frames supported
- Only CS1 and CS2 supported - Only Static Abis allocation supported
Dynamic Abis allocation Standard PCU frames Static Abis allocation
Fig. 5.9
BSC handling of BTS Equipment with Software Releases not supporting the Abis Dynamic Allocation
5.3.3
Configuration of the Abis Interface

As it has been described, the procedures used to configure both flexible and static allocations for a BTSM, are the same. The only difference is that in case of static BTSM, the static allocation between radio and Abis channels is performed by the system (BSC) at configuration time. As a consequence, all the concepts explained below, are valid, unless differently stated, for both flexible and static Abis allocations. To manage the Abis allocations two concepts are introduced: the Abis Subpool and the Abis Pool. Referring to a specific BTSM, the Abis Subpool is a set of 16 kbit/s Abis subslots belonging to a single PCMB line, routed together with the LPDLM instance (previously associated to the BTSM) configured on the same PCMB line.
Remember that a BTSM can be connected to the BSC by, at most, four PCMB lines, and each line must contain at least one LPDLM related to the BTSM. This is an operator constraint, valid for all kind of BSS configuration (star, loop, multidrop with/without cross connections) and also for cross connectors external to the BSS network elements. The subpool concept is necessary for O&M purpose, to manage a correct fault propagation from LPDLM to Abis resources. So, the user to connect the BSC to a specific BTSM can create a certain number of subpools that will contain a specific number of timeslots of the Abis interface. To configure an Abis subpool the SUBTSLB object is used. The SUBTSLB object indicates one subslot of a PCMB line; when creating a SUBTSLB instance the user must specify the following attributes: NAME: it indicates the subslots of a PCMB line, specifying the PCMB instance, the slot [1..31] of the selected line, and the subslot number [0..3]; ASSLAPD (Associated Lapd): it indicates the LPDLM instance (and as a consequence the BTSM) that is related to this subslot.
A30808-X3247-L24-1-7618
81
So, to create on a PCMB line a subpool for a specific BTSM, the user must create more instances of the SUBTSLB object, linking them to the same LPDLM instance (i.e. to the same BTSM) by the ASSLAPD parameter. Referring to a BTSM, the Abis Pool is the amount of 16 kbit/s Abis subslots reserved to the BTSM for traffic services (i.e. it is the amount of SUBTSLB instances, configured on different PCMB lines and associated, through the ASSLAPD, to the LPDLMs related to the BTSM). One more time it must be noted that: in case of BTS supporting dynamic Abis allocation, Abis subslots are selected from the Abis pool and allocated to radio channels at channel activation. In case of GPRS and EGPRS, changes of the Abis resources assigned to an air interface timeslot are possible during TBF-operation via the channel modication command; in case of static Abis allocation, Abis subslots are selected from the Abis Pool and statically allocated to radio channels by O&M procedures; the relationship between radio channels and Abis subslots is notied to BTS by O&M Abis signalling (at radio channel creation). The number of Abis subslots to be statically associated to air timeslot is always 1 for BTS running with old SW releases. Abis pools and subpools have the following properties and features: different Abis subpools, belonging to the same or different Abis pools, can be dened on the same PCMB line; subpools can be distributed over all connected PCMB lines of a BTSM (at least one subpool per line); the Abis subslots allocated to a radio channel may be distributed over different subpools, over different PCM lines and it is not necessary at all to guarantee that the subslots are neighboring each other; overlaps between different pools and subpools are forbidden. So, the PCU subframes belonging to a specific PDCH (or air interface timeslot) can be distributed via all available Abis subpools, even if the subpools are located on different PCMB lines.
5.3.4
Algorithms Regarding Flexible Abis Allocation

Regarding packet switched services, the BSC call processing (TDPC) handles dynamically GPRS/EGPRS PDCHs which could require: 1 Abis subslot in case of CS1/CS2 and MCS1 coding schemes; 2 Abis subslots in case of CS3/CS4 and MCS2/MCS3/MCS4/MCS5 coding schemes; 3 Abis subslots in case of MCS6 coding scheme; 4 Abis subslots in case of MCS7 coding scheme; 5 Abis subslots in case of MCS8/MCS9 coding schemes. Dynamic Abis allocation consists of the selection, for each radio channel of a cell, of one or more idle and in service Abis subslots, belonging to the pool associated to the BTSM that contains the cell; this selection is executed by the BSC during channel activation procedure, then the BSC informs the BTS by the CHANNEL ACTIVATION message. Besides, changes of the Abis resources assigned to a PDCH are also possible during TBF operations by the MODIFY ABIS CHANNEL command.
In case of static Abis allocation, Abis subslots are selected from the pool and allocated to radio channels by O&M procedures; the radio channel/Abis subslot relationship is notified to the BTS by O&M Abis signalling.
82
A30808-X3247-L24-1-7618
The Abis pools are present on TDPC database, related to the list of BTS (cells) fed by the pool. Abis idle lists are built and updated according to the O&M operator commands issued on the SUBTSLB object. In case of GPRS/EGPRS services the number of Abis resources actually allocated at service setup depends on several factors: required peak throughput, default applicable coding scheme, Abis resources actual availability, PCU resources actual availability. The 16Kbit/s Abis subslots, which are assigned to a Radio Channel (PDCH), can be located arbitrarily at the Abis pool/subpools and must not obey any rules due to increasing or decreasing subframe counter (SFC). The Abis subslots allocated to the same radio channel may be distributed over different PCMB lines and it is not necessary at all to guarantee that the subslots are adjacent each other. By the way, as far as possible the Abis subslots for the same PDCH will be selected from the same PCMB. For each allocated Abis subslot one PDT will be allocated. But each Abis subslot of a Radio Channel is coupled with a specific SFC, such that in case of multiplexing several GPRS/EGPRS TBFs on the same PDCH, the data of each TBF will be transported in a fixed, predetermined way. All PCU frames with the same SFC must be transported with the same 16Kbit/s Abis subslot. In case of packet switched services, the initial Abis assignment can be changed dynamically during operation due to: radio propagation conditions of the channels (Link Adaptation, see 10.5); pre-emption of circuit switched services over packet switched services (see "6.3.6.2 Pre-emption of PDT Resources"). The pool is managed with a soft boundary policy, which guarantees a minimum percentage of Abis subslots for each cell. All the cells belonging to the same BTSM share the same Abis pool; each cell may pick up Abis resource from the pool as long as the guaranteed minimum is left at the other cells disposal. The operator can set the guaranteed minimum number of subslots per cell by the GUARMABIS parameter (BTS object). As it has been said, the BSC informs the BTS about the Air timeslots/Abis subslots relationship by two commands: the CHANNEL ACTIVATION command, when a new PDCH is set up; the MODIFY ABIS CHANNEL command, when for one or more already assigned PDCHs a different number of Abis subslots is needed. In the following the two case are discussed. CHANNEL ACTIVATION Command Both air interface (carrier, timeslot) and Abis resources (subslots from the Abis pool) are included in the CHANNEL ACTIVATION message sent from the BSC to the BTS. After having received the CHANNEL ACTIVATION message, the BTS connects the indicated Abis resources with the Air interface timeslot. The CHANNEL ACTIVATION command contains the following additional information: a list of 16Kbit/s Abis subslots assigned to the air interface timeslot; in case of multiple Abis subslots, information on the SFC numeration is given too; the PCU frame format type: it can be standard or concatenated. If the CHANNEL ACTIVATION command activates a GPRS or EGPRS PDCH, the BTS has to connect the concatenated PCU frames depending on their SFC with the particular Abis channel(s). If the activation is successful, the BTS sends CHANNEL ACTIVATION ACK to the BSC, else it sends the CHANNEL ACTIVATION NACK.
A30808-X3247-L24-1-7618
83
MODIFY ABIS CHANNEL Command If a GPRS/EGPRS channel changes its properties (e.g. according to link adaptation procedure, the used coding scheme must be changed), the following sequence must be respected in Abis Allocation and coding scheme change: a) if there is a downgrading capacity, rst the coding scheme of (all) TBFs on the PDCH have to be adapted by PCU RLC/MAC signalling messages, then the Abis capacity may be changed by the MODIFY ABIS CHANNEL command; however that superuous Abis resources are not immediately released; unused PCU/Abis resources are released after a given amount of time; b) if there is an upgrading capacity, rst the Abis capacity is changed by MODIFY ABIS CHANNEL command, then the Abis subslots are aligned and nally the coding scheme of the TBF(s) can be switched. This process is possible only if enough Abis capacity is free in the Abis pool and if enough PCU resources are available. The MODIFY ABIS CHANNEL command must submit - just like the CHANNEL ACTIVATION command - as a parameter the list of Abis subslots and their corresponding subframe counters (SFC). It must be guaranteed, that the lists within CHANNEL ACTIVATION and MODIFY ABIS CHANNEL are equal besides the changes, which are made. Furthermore it must be clear that a MODIFY ABIS CHANNEL deletes the subframes with the highest SFCs in case of downgrading and adds subframes with adjacent higher SFCs in case of upgrading. It is not allowed to modify SFC to an already allocated Abis subslot. So, the MODIFY ABIS CHANNEL command contains the following information: the involved timeslot (specifying carrier and timeslot numbers); the new list of 16Kbit/s Abis subslots assigned to the air interface timeslot.
5.4
Packet Switched Services Supported on CCCH/PCCCH

In the previous chapters (see 4.4.2) it has been described how it is possible to support GPRS/EGPRS common signalling either on already existing CCCHs (shared CCCHs) or on dedicated CCCHs (PCCCHs). To avoid packet switched signalling load on traditional CCCHs, it is convenient to use GPRS/EGPRS PCCCHs as soon as packet switched traffic increases beyond a certain threshold, so that packet switched signalling traffic has no influence on normal signalling, and the overall traffic capacity is improved. These logical channels are mapped on different physical resources (see Fig. 5.10): a) Dedicated CCCH: PCCCH is mapped in the multiframe of a Packet Data Channel (PDCH); in this case the common control signalling is carried in a logical channel dedicated to GPRS/EGPRS trafc. b) Shared CCCH: no dedicated control signalling channels exist for packet switched data services, so that GPRS/EGPRS common control signalling packets access a CCCH following its mapping rules. This mechanism is mandatory, whenever a dedicated CCCH is not allocated.
84
A30808-X3247-L24-1-7618
TDMA frame
CCCH PCCCH
PDCH
PCMB line
0 LAPD
31
Fig. 5.10
Mapping of CCCH/PCCCH Channels on the Abis Interface.
In both cases signalling messages are processed in the PCU, which is realized in BSC by means of PPCU/PPXU cards (Peripheral Processors for GPRS/EGPRS). In the following, a short description is given about the message handling which is implied by the described mechanisms (see Fig. 5.11): a) Dedicated CCCH: messages are carried in a PCU frame on the 16 kbit/s timeslot related to the physical PDCH, where the PCCCH is mapped. The timeslot is routed via switching matrix directly to the PPCU/PPXU where the channel is processed. b) Shared CCCH: messages are carried in the LAPD channel related to the BTSE. The channel is routed via switching matrix to a PPLD where the LAPD protocol is processed. The extracted messages are read by TDPC via Telephonic Bus from the PPLD Dual Port RAM. In the TDPC the messages are analyzed: GPRS/EGPRS related messages are written by TDPC via Telephonic Bus in the Dual Port RAM of the PPCU/PPXU, where they are processed.
A30808-X3247-L24-1-7618
85
Fig. 5.11
CCCH/PCCCH Message Handling. The advantages of the first method (dedicated CCCH) are straightforward: on the air interface CCCH performances for normal GSM trafc are not reduced because of the packet switched data messaging; on the Abis interface the capacity of the LAPD link is not shared between GSM and GPRS/EGPRS traffic; the TDPC does not waste real time to route packet switched data messages toward PPCUs/PPXUs and to multiplex in LAPDs the messages received from the PPCUs the Telephonic Bus is not loaded (twice) by the exchange of messages among PPLD, PPCU/PPXU and TDPC. On the other side shared CCCHs is supported in any case to provide the first access when no specific GPRS/EGPRS signalling channels are allocated. Besides, shared CCCHs are the only way to allow Class B MSs (see "9.1 Mobile Stations for Packet Switched Services") attached to GPRS/EGPRS to listen to their circuit switched paging channel on CCCH, when the optional Gs interface between the MSC and the SGSN is not implemented (see "9.8.3.1 Network Operation Modes for Paging").
86
A30808-X3247-L24-1-7618
6 Radio Resources Management

The PTPPKF functional object represents point to point packet data services in a cell. Point to point data services regard: GPRS service, i.e. packet switched data services using the traditional GMSK modulation; EGPRS service: EGPRS introduces the 8PSK modulation in the existing GSM network to increase up to 384kbps the data rate for data services. The creation of the PTPPKF object for a specific cell can be done only if: the BTS object has been already created for the cell; at least one PCU (see, "5 Hardware and Software Features") has been created; at least one permanent virtual connection (see "7 Gb Interface") has been configured for the PCU. Either during or after having enabled GPRS/EGPRS services in a cell, the operator can configure, according to his needs, the radio resources of the cell. A cell supporting GPRS/EGPRS may allocate resources on one or several physical channels in order to support the packet switched data traffic. The physical channels (i.e. PDCHs), shared by GPRS/EGPRS MSs, are taken from the common pool of physical channels available in the cell. The allocation of physical channels to circuit switched services and packet switched services is done according to the following two principles: Master-slave concept: at least one PDCH, acting as a master, accommodates: the packet broadcast channel (PBCCH); the packet common control channel (i.e. PCCCH); user data and dedicated signalling (i.e. PDTCH and PACCH). Other PDCHs, acting as slaves, are used for both user data transfer and dedicated signalling only (PACCH). Capacity on demand concept: GPRS/EGPRS do not require permanently allocated PDCHs. The allocation of capacity for these services can be based on the needs for actual packet transfers which is here referred to as the "capacity on demand" principle. The operator can, as well, decide to dedicate permanently or temporarily some physical resources (i.e. PDCHs) to the packet switched data trafc. When the PDCHs are congested due to the GPRS/EGPRS trafc load and more resources are available in the cell, the network can allocate more physical channels as PDCHs. However, the existence of PDCH(s) does not imply the existence of PBCCH/PCCCH.
When no PBCCH/PCCCH channels are allocated in a cell, all GPRS/EGPRS attached MSs camp on the BCCH/CCCH. When PCCCH is allocated in a cell, all GPRS/EGPRS attached MSs camp on it. PCCCH can be allocated either as the result of the increased demand for packet data transfers or whenever there are enough available physical channels in a cell (to increase the quality of service). When the PCCCH capacity is inadequate, it is possible to allocate additional PCCCH resources on one or several PDCHs (see "5.4 Packet Switched Services Supported on CCCH/PCCCH").
A30808-X3247-L24-1-7618
87
According to previous concepts the operator can use different strategies to configure packet switched data services in a cell; e.g. he can: a) reserve at least one static timeslot for GPRS/EGPRS specic signalling, and congure other dynamic timeslots (which will be shared with circuit switched services) for GPRS/EGPRS data; b) reserve at least one timeslot for GPRS/EGPRS specic signalling, and congure other static timeslots (which will not be shared with circuit switched services) for GPRS/EGPRS data; c) not reserve any timeslot for GPRS/EGPRS specic signalling, and congure some static timeslots for GPRS/EGPRS data; d) not reserve any timeslot for GPRS/EGPRS specic signalling, and congure some dynamic timeslots for GPRS/EGPRS data; e) not reserve any timeslot for GPRS/EGPRS specic signalling, and congure both some static and some dynamic timeslots.
6.1
Enabling Packet Switched Services in a Cell

When configuring GPRS/EGPRS services on a cell (i.e. when creating a PTPPKF object instance), the user shall specify some parameters (belonging to the PTPPKF object) that allow him to configure the two services according to his needs. Among the parameters of the PTPPKF object, two of them allow to make available or not packet data services in the referred cell. In fact, when a PTPPKF object instance is created, neither GPRS service nor EGPRS service are enabled as default. So the user to enable GPRS and EGPRS has to manage two specific parameters; they are: 1. the EGPRS ag (enable GPRS) allows to make available or not available the whole Packet Data services in the cell, i.e. both GPRS (based on CS1,.., CS4), and EGPRS (based on MCS1,.., MCS9). The EGPRS ag has the same functional behavior as the command lock/unlock on the PTPPKF object; the only difference is that, in case of EGPRS=FALSE, the operational state of PTPPKF is disabled. In this way for the operator is clear that the PTPPKF cannot provide service, even if it unlocked. The default value of the EGPRS ag is FALSE; this means that when creating the PTPPKF object instance, the cell is disabled to support, in general, both (GPRS and EGPRS) packet data services. But it must be noted that: before setting EGPRS=TRUE for a specic cell, the user shall specify, for this cell, at least one TRX that supports the GPRS service; i.e. he can choose, among the total number of TRXs configured for the cell, which of them will handle packet data services (see "6.1.1 Enabling GPRS Service in the Cell"). to enable EGPRS services in the cell is not sufcient to set EGPRS=TRUE but other parameter settings are required (see below); but setting EGPRS=TRUE is the rst step in the procedure that allows to congure the EGPRS service in the cell (see "6.1.2 Enabling EGPRS Service in the Cell"). 2. the EEDGE (enable EDGE) ag allows to make available or not available the EGPRS service in the cell, provided that the GPRS service is available and there are radio resources congured to support EDGE. It is not allowed to make the EGPRS service available (EEDGE=TRUE) if the GPRS service is not available (EGPRS=FALSE) or if no TRX in the cell has been congured to support EDGE. In fact to enable EGPRS services in the cell, is not sufcient to set EEDGE = TRUE but other parameter settings are required (see "6.1.2 Enabling EGPRS Service in the Cell"). The default value of the EEDGE ag is FALSE.
88
A30808-X3247-L24-1-7618
6.1.1
Enabling GPRS Service in the Cell

As it has been described in "6.1 Enabling Packet Switched Services in a Cell", when a PTPPKF object instance is created, the EGPRS parameter, that allows to make available or not available the whole Packet Data services in a cell (both GPRS and EGPRS), is set to FALSE as a default value. Before setting the EGPRS parameter to true, the user must enable the GPRS service on a TRX basis, i.e. the user must enable at least one TRX to support packet data services.
The GPRS service will not be enabled in a cell, it the user does not enable it on at least one TRX of the cell, after having created the PTPPKF object. To enable, in general packet switched data services on a specific TRX, the user must set to TRUE the GSUP attribute belonging to the TRX object. Setting GSUP=TRUE means that the TRX is enabled to support in general both packet data services, i.e. it is enabled to support both GPRS and EGPRS. Fig. 6.1 shows an example of one cell with five TRXs, where three of them (i.e. TRX0, TRX3 and TRX4) have been enabled to support the packet switched services.
TDMA frame TRX 0

BCCH 0 7
GSUP=TRUE
TDMA frame TRX 1

0
GSUP=FALSE
7
TDMA frame TRX 2

0 7
GSUP=FALSE
TDMA frame TRX 3

0
GSUP=TRUE
7
TDMA frame TRX 4

0
GSUP=TRUE
7
Fig. 6.1
Example of TRXs enabled to support Packet Switched Services.
BTSplus equipment can be equipped with two different types of carrier units (see 5.2): 1. GSM-CUs, i.e. carrier units able to support GSM and GPRS services;
A30808-X3247-L24-1-7618
89
2.E-CUs (EDGE carrier units), i.e. carrier units able to support GSM, GPRS and EGPRS services. So, the user, beside enabling the TRX to support packet data services (with GSUP parameter), can indicate if the TRX will be used for GSM/GPRS only, or if it will be used for EGPRS too. To indicate how the TRX has to be exploited, the TRXMD parameter is used; it can assume two values: GSM: it is the default value that means that the TRX can be used for GSM, and also for GPRS if GSUP=TRUE; EDGE: it means that the TRX can be used for GSM, and also for both GPRS and EGPRS if GSUP=TRUE.
i i
Regarding the detailed procedure to enable EGPRS, please refer to "6.1.2 Enabling EGPRS Service in the Cell". From the BTS equipment point of view, the TRXMD parameter is the criterion used to allocate a carrier unit type (GSM-CU or E-CU) to the transceiver. The association between a TRX and the boards (CU or E-CU) of a BTSplus is performed automatically by the BTS equipment, taking into account suggestion from operator (i.e. the TRXMD setting). After having enabled one or more TRXs to support GPRS, i.e. after having set for one or more TRXs: GSUP=TRUE TRXMD=GSM the user must set to TRUE the EGPRS parameter of the PTPPKF object, to definitely enable the GPRS service in the cell. It is possible to set GSUP=TRUE for whatever TRX of the cell, with the following exceptions: in case of Concentric Cells, the TRXs supporting GPRS must always belong to the complete cell area; in case of GSMDCS (common BCCH) cells all the TRXs that support GPRS must belong to the same band of the BCCH TRX (and this coincides with the band of the Complete Area). This is due to the fact that the two GSM and DCS bands have different propagation factors, thus it could be that on cell borders only the frequency of one band is received; one mobile that accessed the cell with one band could not work with the other one; in case of cells having SYSID=EXT900 only the TRXs with TRXFREQ belonging to BB900 band (that is, the same band of BCCH) can have GSUP = TRUE; In case SYSID=F2ONLY, if the BCCH belongs to BB900 band, all the TRXs for which the GSUP is set at TRUE must belong to the BB900 band; In case SYSID=F2ONLY, if the BCCH belongs to the extended band, all the TRXs for which the GSUP is set at TRUE must belong to the extended band; it is possible to set as rst GPRS TRX whatever TRX of the cell, that is, it is not mandatory to set this attribute to TRUE rst on the BCCH TRX; the setting of a TRX to GSUP = TRUE has to take into account the Multislot constraints for TSC and Frequency Hopping parameters;
90
A30808-X3247-L24-1-7618
the setting of a TRX to GSUP=TRUE must be executed only when all the TRXs channels are not available to the service (this situation can be reached by executing a shutdown for all these TCH: this is suggested to avoid impacts on CS calls.
Beside the TRXs of a cell on which the user wants to configure the packet switched data services, it is suggested to configure GSUP=TRUE also for the BCCH TRX. In this way the condition of no TRXs with GSUP=TRUE (condition that puts the PTPPKF object in DISABLE state) happens when there is also a BCCH outage. In this case the whole BTS is put Out of Service from both circuit switched and packet switched services point of view. Once one or more TRXs have been enabled to support the GPRS service, the user can configure, according to his needs, some static and dynamic GPRS channels on them (see "6.2 Configuration of GPRS Channels in a Cell").
6.1.2
Enabling EGPRS Service in the Cell

As it has been described in "6.1.1 Enabling GPRS Service in the Cell", to enable in general packet switched data services on a cell and TRX basis, the user must set: the GSUP parameter of the TRX object to TRUE (for each TRX he wants to enable to support packet data services); the EGPRS parameter of the PTPPKF object to TRUE; After that if the user wants to enable EDGE service in one or more cells of the BSC, he must execute a series of operations to enable it. The ESUP parameter of the BSC object allows the user to enable EGPRS services in the whole BSC. If the user does not set to TRUE the ESUP parameter, EGPRS service will not be allowed in the BSC. Since EGPRS can only be enabled on high capacity BSCs, the ESUP parameter can not be set to true if the NTWCARD parameter (BSC object) is not set to either SNAP or SNAP_STLP. After the user has enabled EDGE service on BSC basis, he has to enable it both on TRX basis and on cell basis. As it has be described in "6.1.1 Enabling GPRS Service in the Cell", to enable, in general, packet data services on a specific TRX, the user must set to true the GSUP attribute belonging to the TRX object. Setting GSUP=TRUE means that the TRX is enabled to support in general both packet data services, i.e. it is enabled to support both GPRS and EGPRS. To activate EDGE service on a specific TRX, beside enabling the TRX to support packet data services (with GSUP parameter), the user has to indicate that the TRX will be used for EGPRS too. To indicate how the TRX has to be exploited, the TRXMD parameter is used; it can assume two values: GSM: it is the default value that means that the TRX can be used for GSM and also for GPRS; EDGE: it means that the TRX can be used for GSM and also for both GPRS and EGPRS. So the user to enable EGPRS service on a TRX must set the TRXMD parameter to EDGE value. After having enabled EGPRS on a TRX basis, i.e. after having enabled at least one TRX to support EGPRS, the user can enable EGPRS on a cell basis by setting to TRUE the EEDGE parameter.
A30808-X3247-L24-1-7618
91
Once one or more TRXs have been enabled to support the EGPRS service, the user can configure, according to his needs, some static and dynamic channels on them, to be used for packet switched services (see "6.2 Configuration of GPRS Channels in a Cell").
6.1.3
Aspects Related to Carrier Configuration

As it has been described, by means of the TRXMD attribute, it is possible to specify whether a TRX supports: GSM services; EDGE services (the EDGE services value indicates the support of GSM, GPRS and EGPRS). On the other hand, the capability of a Carrier Unit is modelled with a read only attribute called TRX CAPABILTY. It reflects the real capabilities of the TRX independently of the TRXMD parameter setting. The attribute is available for the operator by GETINFO TRX and GETINFO BTS commands, and it can assume the following values: GSM: the TRX is associated to a carrier Unit without EDGE capability; EDGE: the TRX is associated to a carrier Unit with EDGE capability; UNKNOWN: the BSC has no knowledge about the carrier Unit associated to TRX. The following combinations of TRXMD and TRX CAPABILITY are possible (see Tab. 6.1): TRXMD GSM GSM GSM EDGE EDGE EDGE TRX CAPABILTITY GSM EDGE UNKNOWN GSM EDGE UNKNOWN Meaning The TRX is working with GSM functionality The TRX is working with GSM functionality No CU is related The TRX is working with GSM functionality since no E-CU is available The TRX is working with EDGE functionality No CU is related
Tab. 6.1
Combinations of TRXMD and TRX CAPABILITY Values The BTSE shall try to find an optimal allocation between the required TRX operation modes and the available carrier unit types according to the following rules: 1. 2. 3. 4. 5. Try to allocate the BCCH TRX to the appropriate CU type; Try to allocate all EDGE-TRX to E-CUs; Try to allocate all GSM-TRX to GSM-CUs; Try to allocate all remaining GSM-TRX to E-CUs; Try to allocate all remaining EDGE-TRX to GSM-CUs (the state of the TRX changes to enabled-degraded).
When transceivers are reconfigurated the BTSE checks if the allocation among TRXs and CUs is still optimal. If necessary an automatic reconfiguration according to the rules shown above is performed. A change of the functional configuration may be caused by: creation/deletion of a TRX; modication of the TRXMD attribute of a TRX;
92
A30808-X3247-L24-1-7618
breakdown of CU allocated to BCCH-TRX; breakdown of CU allocated to TRX belonging to the complete area, in case of concentric cells; commissioning of TRX after breakdown.
Please note that some changes of configuration may lead to a loss of traffic for one or two TRX. It is an operators task to avoid the loss of traffic by taking the right measures. In case of Baseband frequency hopping all TRXs involved in the same hopping law must be homogeneous, i.e. they must have the same TRXMD value. If a TRX with TRXMD = EDGE gets TRX_CAPABLITY = GSM (e.g. due to a reconfiguration) the hopping for the TRX related to this hopping law is stopped in the cell, and the operator is informed. Synthesizer frequency hopping is not affected. Configuration of the BCCH Transceiver for EGPRS The EGPRS PACKET CHANNEL REQUEST message, specific for EDGE mobile stations (see "4.4.1 Packet Broadcast Control Channel (PBCCH)" and "9.8.2.4 TBF Establishment for EDGE Mobile Stations"), is only supported by EDGE-CUs. Therefore the use of the EGPRS PACKET CHANNEL REQUEST message can be forced by configuring the BCCH-TRX in EDGE mode, which implies the allocation of a EDGE-CU to the TRX, using the TRXMD parameter. The BCCH carrier is continuously transmitted on all timeslots and without variation of RF level; however, the RF power level may be ramped down between timeslots to facilitate switching between RF transmitters. If 8PSK modulation is used for timeslots of the BCCH TRX, these timeslots may use a 8PSK mean power which is at most 4 dB lower than the power used for GMSK modulated timeslots. So, the use of the 8PSK modulation on the BCCH carrier is critical and the operator can enable/disable it. By means of the EBCCHTRX attribute the operator can decide whether the channels of the BCCH-TRX are available for EDGE 8PSK services or not. So, if the BCCH TRX is enabled to support EDGE, but EBCCHTRX is set to FALSE, it means that only GMSK modulated coding schemes of EDGE will be supported on the BCCH TRX (besides GPRS coding schemes). Even if the BCCH TRX is enabled to support 8PSK modulation, timeslots 0 and 7 are not allowed to use this modulation. This is necessary for compatibility with mobiles which do not support EDGE, in fact: timeslot 0 is used to transmit system information and signalling; and avoiding 8PSK modulation on timeslot 7 allows to prevent leakage of power into timeslot 0.
6.2
Conguration of GPRS Channels in a Cell

After having defined how many TRXs will support GPRS and EGPRS services (see 6.1), the user shall indicate how the slots belonging to these TRXs shall be managed; the following statements show how the user can configure the GPRS/EGPRS service on the TRXs where GSUP=TRUE: 1. the user can reserve, on a channel basis, some slots to packet switched services only; these slots will be statically allocated to GPRS/EGPRS signalling (PBCCH and PCCCH) and will not be used for circuit switched services. The user can dene
A30808-X3247-L24-1-7618
93
these only GPRS/EGPRS slots on a channel basis, by setting the GDCH attribute of the chosen CHAN object; The GDCH attribute can assume the following values: PBCCH: i.e. the related channel is reserved for packet switched services, and it supports GPRS/EGPRS system information, common signalling and data; PCCCH: i.e. the related channel is reserved for packet switched services, and it supports GPRS/EGPRS common signalling and data.
Only one physical channel can be configured to carry the PBCCH logical channel (i.e. only one channel can be configured as PBCCH); if the operator then needs more PCCCHs, it shall configure another channel as PCCCH.
2. then the user has the possibility to congure among the remaining timeslots, other static timeslots for PS services (i.e. not shared with CS services); the user can indicate this number of static GPRS/EGPRS slots using the GMANPRES attribute of the PTPPKF object. The difference with respect to the conguration of static slots using the GDCH attribute is that with GDCH the conguration is made on a channel basis and regards GPRS/EGPRS signalling channels only, whereas using GMANPRES the conguration is made without indicating the channel, but only a number of channels, and regards GPRS/EGPRS trafc channels only. If for example, the user denes 4 static slots for packet switched services, using GMANPRES, then 4 slots will be reserved by the system for GPRS/EGPRS trafc on the TRXs where GSUP=TRUE; 3. nally the user can choose among the remaining available slots (on TRXs where GPRS is supported) the maximum number of dynamic GPRS/EGPRS channels; these channels will be shared between PS and CS services, according to the actual request of resources. To congure this number of shared slots the user has to set the GPDPDTCHA attribute (PTPPKF object). It indicates a percentage; this percentage is applied to the total number of available slots (on TRXs where GPRS/EGPRS are supported) decreased by the number of both static GPRS/EGPRS slots and slots reserved for GSM signalling. The percentage indicates the maximum number of dynamic GPRS/EGPRS slots. To clarify the previous concepts, lets suppose that three TRXs of a cell are configured to support GPRS/EGPRS (according to what has been described in 6.1). The first TRX (TRX0) is the BCCH one and contains one SDCCH timeslot; the second and the third TRXs (TRX3 and TRX4) are completely dedicated to both circuit switched and packet switched services (see Fig. 6.2). Then, on TRXs where packet switched services are supported, the total number of available slots for PS and CS services is equal to 22, in fact: 6 slots are available on TRX0; 8 slots are available on TRX3; 8 slots are available on TRX4.
94
A30808-X3247-L24-1-7618
TDMA frame TRX 0

BCCH SDCCH 0
GDCH=PBCCH
GSUP=TRUE
7
TDMA frame TRX 1 SDCCH

0
GSUP=FALSE
7

0 7
GSUP=FALSE
TDMA frame TRX 3

0
GSUP=TRUE
7
TDMA frame TRX 4

0
GSUP=TRUE
7
Fig. 6.2
Example of GPRS/EGPRS configuration.
If the user sets: GPDPDTCHA= 50 (i.e. 50%); GDCH= PBCCH for one CHAN object (CHAN:6) of the BCCH TRX (see Fig. 6.2); GMANPRES=1 then, the maximum number (N) of GPRS/EGPRS channels shared with CS services is given by the following formula:
N= [Total number of available timeslots on TRXs with GSUP=TRUE - Number of GPRS/EGPRS static slots(defined by GDCH and GMANPRES)]* GPDPDTCHA/100 =
= ( 22 - 2 ) * 50/100 = 10 So, in this cell we will have (on TRXs where GSUP=TRUE): 2 slots statically allocated for packet switched services (one signalling slot dened on a channel basis using the GDCH attribute and the other one dened on a cell basis using GMANPRES) 10 slots shared between PS and CS services (according to the previous formula and the GPDPDTCHA setting); 10 slots reserved for CS services (i.e. the remaining slots on the TRXs where GSUP=TRUE).
A30808-X3247-L24-1-7618
95
Obviously both the TRX1 and the TRX2 will be used for circuit switched services only.
Timeslots configured for PS services can be used for GPRS or EGPRS according to the configuration of the TRXs. So, timeslots allocated on TRXs with GSUP=TRUE and TRXMD=GSM can be used only for GPRS, whereas timeslots allocated on TRXs with GSUP=TRUE and TRXMD=EDGE can be used for both GPRS and EGPRS. It must be underlined that previous example is only valid if HOPMODE=SYNHOP. As soon as HOPMODE=BBHOP (independently of frequency hopping is enabled or not), timeslots 0 of all non-BCCH TRX are not considered for the GPDPDTCHA calculation. Finally, to define how many users can be multiplexed in a PDCH, the GMANMSAL attribute (PTPPKF object) is used. It defines the maximum number of GPRS/EGPRS users that can share the same timeslot (PDCH); it is composed of two fields: the first indicates the maximum number of users in uplink direction, the second one specifies the maximum number of users in downlink direction.
6.3
6.3.1
Management of Packet Data Channels

Generalities about Resource Assignments
The radio resource assignment to a mobile station requiring an uplink or a downlink TBF establishment is performed under the BSC control, through co-operation between the PPCU/PPXU processors (involved in PDCH management and scheduling functions for UL and DL data transfer, see "5 Hardware and Software Features") and the TDPC processor (dedicated to resource management). When a new GPRS/EGPRS request arrives at the BSC, the PPCU/PPXU, starting from the MS multislot class and the required peak throughput, estimates the number of radio resources (i.e. the number of PDCHs) requested for TBF establishment. In fact, in order to give the best possible throughput for each user, the system considers the Peak Throughput Class to calculate the number of resources to be assigned to a new TBF. The resource allocation algorithm tries to assign to each TBF a number of timeslots that depends on the required Peak Throughput Class, i.e.: a) MS Multislot Class (it is sent from the MS to the network during the GPRS attach procedure, see "9.3.2.1 Attach Function"); b) Peak Throughput: in case of uplink TBF is derived from the Channel Request description inside the Packet Resource Request or Packet DL Ack/Nack; in case of downlink TBF is derived from the Qos Prole IE of the DL-UNITDATA; c) Coding Scheme to apply, given in throughput per timeslot.
Trying to maximize the throughput is the most important criteria in radio resource search. The PCU, after calculating the number of requested resources, checks if the actual used strategy is the vertical one or the horizontal one (see "6.3.2 Horizontal/Vertical Allocation Strategies"). Then, according to the used strategy and to the needed resources, it sends the right request to the TDPC. According to the requests received by PPCU/PPXU, the TDPC is responsible for: 1. the assignment of the proper radio resources on the air interface (PDCHs); 2. the assignment of the Abis interface subslots related to these PDCHs.
96
A30808-X3247-L24-1-7618
When the PCU request arrives at the TDPC, the TDPC tries to satisfy the request. If required channels are found, the TDPC sends the ACK message to the PCU, otherwise other actions have to be executed (see "6.3.3.2 TDPC Algorithm"). Note that, on a cell basis, the PPCU/PPXU knows: 1. the number of PDCHs in use at a given time; i.e. it knows: the timeslots (PDCHs) with at least one TBF assigned; PDCHs waiting for the next TBF, before the PDCH timer (Empty Channel Timer) expires. In fact, when the last MS associated to a PDCH is released, the virtual assignment persists for the duration of the Empty Channel Timer. The value of this timer is set, by means of the TEMPCH parameter, to avoid continuous requests (in case of high GPRS/EGPRS traffic) from the PPCU to the TDPC. When the timer is still active, the allocated PDCH(s) for the released TBF are still seen as allocated even if they are no more active. 2. the number of PTDs (equal to the number of Abis subslots) related to the PDCHs still in use. From this point it could happen that (according to what has been described in "5.3.1 Concatenated PCU Frames") for a PDCH one or more corresponding PDTs are useless, i.e. they are lled with idle PCU frames, due to downgrade to a coding scheme needing less PDTs than the initial ones. When a PDT is lled with idle PCU frames, the PCU before releasing it waits until a timer dened by the TEMPPDT parameter expires. The timer is used to avoid continuous requests of Abis resources from the PPCU to the TDPC; in fact to every PDT corresponds an Abis 16 Kbit/sec subslots that the PCU must require to the TDPC, since it is the TDPC that manages Abis resources.
6.3.2
Horizontal/Vertical Allocation Strategies

When a new request of GPRS/EGPRS resources arrives at the BSC, two different strategies are provided to assign packet switched data channels; they are: the VERTICAL ALLOCATION (VA) strategy: before assigning a new slot to GPRS/EGPRS service, the already used slots must be lled as much as it is possible, according to the chosen GMANMSAL value (see 6.3.2.1); the HORIZONTAL ALLOCATION (HA) strategy: it is introduced in the system to allow higher bit data rates, when the cell is not congested. This strategy is intended to distribute the incoming GPRS/EGPRS calls on all the available PDCHs. In this way not too many users are multiplexed on the same PDCH, increasing the data transfer throughput for all the involved mobiles (see 6.3.2.2). The user can manage the allocation strategy according to his needs, by means of specific parameter settings. It is important to underline how the chosen strategy depends both from radio resources availability and Abis resources availability. Chapter 6.3.2.3 describes how the radio interface situation triggers the switching from HA to VA and vice versa, according to parameter settings; whereas chapter 6.3.2.4 describes the analogous topics taking into account the Abis interface. Finally the complete algorithm is summarized in chapter 6.3.2.5.
A30808-X3247-L24-1-7618
97
6.3.2.1
Vertical Allocation Strategy (VA)

When GPRS/EGPRS channels are handled using the Vertical Allocation (VA) algorithm, the criterion is to multiplex the maximum number of mobiles on each channel, before assigning a new PDCH. This is obtained by filling an already used PDCH, as much as it is possible, compatibly with: network settings of GMANPRES, GPDPDTCHA and GMANMSAL attributes; MS multislot capability. If, for example, 2 mobile stations perform 3DL+1UL GPRS/EGPRS calls, the BSC e.g. will assign them the timeslots number 2, 3 and 4. In this way timeslots from 5 to 7 remain free because the BSC multiplexes the 2 mobiles on the same 3 PDCHs, as drawn in Fig. 6.3.
TS0 BCCH TRX
TS1
TS2
TS3
TS4
TS5
TS6
TS7
bcch sdcch
MS1DL MS1DL MS1DL MS1UL MS2DL MS2DL MS2DL MS2UL
Fig. 6.3
Example of Vertical Allocation Algorithm
Besides, when the vertical allocation strategy is used, the BSC tries to multiplex in a fair way the mobile requests, using the so called flat distribution. With the flat distribution, if the BSC is in VA condition and over each radio timeslot is multiplexed only one mobile station, if three GPRS/EGPRS mobile requests (single slot) arrive to BSC, the BSC will multiplex the 3 mobiles over 3 different radio channels trying to distribute uniformly the resources. If the flat distribution was not used, all the 3 mobiles would be multiplexed in the same timeslot (compatibly with GMANMSAL setting).
6.3.2.2
Horizontal Allocation Strategy (HA)

The Horizontal Allocation (HA) strategy is intended to distribute the incoming GPRS/EGPRS calls on all the available PDCHs. In this way not too many MSs are multiplexed on the same PDCH, increasing the data transfer throughput for all the involved mobiles. When a new request of PDCH channels arrives at the BSC and there are still available radio channels for GPRS service, the BSC will assign new radio channels to the GPRS/EGPRS mobiles, instead of increasing the number of mobiles multiplexed on the already busy channels. If, for example, 2 mobiles perform 3DL+1UL GPRS/EGPRS calls, the BSC will assign timeslots number 2, 3 and 4 to the first call, then timeslots number 5, 6 and 7 to the second call.
98
A30808-X3247-L24-1-7618
In this way each timeslot is used for a lower number of calls and the throughput is better than that for the vertical allocation strategy, as drawn in Fig. 6.4.
TS0 BCCH TRX
TS1
TS2
TS3
TS4
TS5
TS6
TS7
bcch sdcch
MS1DL MS1DL MS1DL MS2DL MS2DL MS2DL MS1UL MS2UL
Fig. 6.4
Example of Horizontal Allocation Algorithm
6.3.2.3
Switching between VA and HA According to Radio Conditions

Taking into account the radio interface, the BSC switches autonomously from VA to HA (and vice versa) in relation to the traffic load in the cell (i.e. in relation to the number of busy air timeslots). The aim of this feature is to use the horizontal allocation when the cell is not loaded; otherwise the adopted strategy will be the vertical one. To avoid frequent changes between HA and VA strategies, two thresholds are defined: one threshold (ThresholdIdleChannelHV) represents the transaction from the horizontal allocation to the vertical one; the other threshold (ThresholdIdleChannelVH) represents the transaction from the vertical allocation to the horizontal one. These thresholds, used to activate horizontal/vertical allocation, are managed by the GASTRTH attribute (PTPPKF object).
The GASTRTH contains a third field, called ThresholdIdleChanEU; this field represents a threshold that is used in the radio resource upgrade strategy ("6.3.4.1 Upgrade of Radio Resources"). The threshold, that causes the transaction from one allocation algorithm to the other one, represents the percentage of idle slots in the whole cell. The percentage is calculated as the number of idle channels in the cell with respect to the number of available channels in the cell (TCHs or PDCHs; do not consider slots containing GSM signalling, such as BCCH or SDCCHs slots, and also slots statically reserved to GPRS/EGPRS). The number of available channels in the cell is calculated as:
Available Channels = Total number of configured channels - Number of OUT OF SERVICE channels - Number of GPRS/EGPRS static channels (defined by both GDCH and GMANPRES) - Number of GSM signalling channels
Obviously the number of Idle Channels is the number of not busy channels inside the pool of all the available channels of the cell. Then the percentage of idle channels in the cell (to be compared with the thresholds of the GASTRTH parameter) is given by:
A30808-X3247-L24-1-7618
99
Percentage of Idle Channels in the cell = Idle Channels / Available Channels
It is important to highlight that the evaluated value, that represents the percentage of idle channels in the cell, is truncated, so decimals are not taken into account in the comparison with thresholds. E.g. if the internal evaluation estimates that the percentage of idle channels in the cell is 10.9%, then the real value that is compared to the thresholds is 10% and not 11%).
Lets consider a cell with five configured TRXs, three of them supporting GPRS/EGPRS (see Fig. 6.5) where: TRX0 contains BCCH and SDCCH logical channels; TRX1 and TRX2 do not support GPRS/EGPRS; TRX3 supports the GPRS/EGPRS service, but it is out of service. the timeslots of the TRXs (with the exception of the BCCH and the SDCCH ones) are dened as TCHF_HLF; then each timeslot represents, from the circuit switched services point of view, two available channels.
TDMA frame TRX 0

BCCH SDCCH 0 7
GSUP=TRUE

0
GSUP=FALSE
7

0 7
GSUP=FALSE
TDMA frame TRX 3

0
GSUP=TRUE
7
TDMA frame TRX 4

0
GSUP=TRUE
7
Fig. 6.5
Example of a Cell Configured with Five TRXs.
100
A30808-X3247-L24-1-7618
In this case: total number of congured trafc channels = (6 + 7 + 7 + 8 + 8 ) * 2 = 72;
BCCH and SDCCH signalling channels are not considered, only traffic channels are taken into account.
number of OUT OF SERVICE channels = (8 * 2) = 16; if we set GMANPRES= 3 (without setting the GDCH value for any channel), then the Number of static GPRS/EGPRS channels to be considered in the previous formula is equal to 6 (since each timeslot reserved to packet switched services represents, from the circuit switched services point of view, two available channels).
Then, according to the above formula (without considering GSM signalling channels): Available channels = 72 - 16 - 6 = 50. If, for instance, the GASTRTH parameter has been set with the following values: ThresholdIdleChannelHV=30%, for the transaction from HA ---> VA; ThresholdIdleChannelVH=40%, for the transaction from VA ---> HA. when the percentage of idle slots is upper than 40%, the horizontal allocation is used. In this case: (100 * Idle channels) / Available channels > 40 ----> Idle channels = 21. So, when in the cell the number of idle channels is equal to 21, the Horizontal Allocation strategy is used. If the percentage of idle slots falls under 30%, the vertical allocation is used; in this case: (100 * Idle channels) / Available channels < 30 ----> Idle channels = 14. So, when in the cell the number of idle channels reaches the value 14, the vertical Allocation strategy is used. If the percentage exceeds again the 40% threshold, then the horizontal allocation algorithm is restored
The difference between the two thresholds of the GASTRTH parameter should not be too much high, but the thresholds have to be set to reasonable values (also taking into account the number of configured TCHs in the cell). Otherwise it could happen that, when the VERTICAL allocation is used, a return back to the HORIZONTAL one is applied only when the cell is completely idle, and this is not a real hysteresis behavior. It should be noted that when the horizontal allocation is used to assign GPRS/EGPRS resources, two conditions, related to radio interface, can determine the transition to the vertical one: the first condition occurs when in the cell the number of idle channels falls below the threshold set by the GASTRTH parameter; the second one occurs when the number of channels assigned to GPRS/EGPRS users reaches the maximum number of channels configured for PS services by means of GMANPRES, GDCH and GPDPDTCHA parameters.
A30808-X3247-L24-1-7618
101
6.3.2.4
Switching between VA and HA according to Abis Interface Conditions

Taking into account the Abis interface, the BSC switches autonomously from VA to HA (and vice versa) in relation to the number of exploited Abis resources (i.e. in relation to the number of busy Abis subslots). In fact, according to the flexible Abis allocation strategy (see 5.3), the number of used Abis resources of a BTSM depends on which services are currently running on the cells managed by the BTSM. Then it is very important to check, besides the radio interface situation, also the level of congestion of the Abis interface, to take the right countermeasures. So the switching from vertical allocation to horizontal allocation and vice versa is influenced from the Abis interface too. To manage the resource allocation process, a set of thresholds regarding Abis allocation usage is introduced. The user can set these thresholds by the GASTRABISTH parameter (gprsAllocationStrategyAbisThresholds) of the BTSM object. GASTRABISTH is composed of four fields, two of them allow to manage the vertical/horizontal allocation strategy and are here described; the remaining two regard the upgrade of Abis resources and are discussed in "6.3.4.2 Upgrade of Abis Resources": the rst threshold (thresholdIdleAbisHV) denes the percentage of idle Abis subslots of the BTSM (over the available Abis subslots of the BTSM) under which the Vertical allocation strategy for Abis scarcity is activated on the radio interface (for all the cell of the BTSM). To activate the vertical allocation in case of Abis scarcity is useful to re-use in multiplexing the already allocated Abis subslots, slowing down the allocation of new Abis resources; the second one (thresholdIdleAbisVH) denes the percentage of idle Abis subslots of the BTSM (over the available Abis subslots of the BTSM) over which the Horizontal allocation can be activated again on the radio interface, if also the thresholds on radio resources (on a cell basis) allow that. Constraints on these two Abis thresholds are: thresholdIdleAbisHV < thresholdIdleAbisVH
6.3.2.5
Allocation of Resources
Besides the situations described in 6.3.2.3 and 6.3.2.4, in BR7.0 release the switching to vertical/horizontal allocation is also driven by the availability/unavailability of PDTs on PCU (remember that with the high capacity BSC, see "5.1 Supported BSC Types", the maximum number of GPRS channels manageable by the single PCU, i.e. the maximum number of PDT manageable by the single PCU, is fixed to 256). Then according to the availability/unavailability of PDTs on PCU side: when the percentage of busy PDTs on a PCU is 100%, then vertical allocation is applied; when the percentage of busy PDTs on a PCU is less than100%, then horizontal allocation is applied (provided that thresholds of GASTRTH and GASTRABISTH parameters do not lead to vertical allocation). In summary, in cells belonging to BTSM with dynamic Abis management, the following situations are possible during the allocation of radio resources, according to different contexts:
102
A30808-X3247-L24-1-7618
a) the horizontal allocation in a cell is used if at the same time these three conditions are satisfied: there is not radio scarcity in the cell, i.e. the percentage of idle air timeslots in the cell is bigger than the ThresholdIdleChannelHV field of the GASTRTH parameter; there is not Abis resources scarcity, i.e. the percentage of idle Abis subslots of the BTSM managing the cell is bigger than the thresholdIdleAbisHV eld of the GASTRABISTH parameter; there is not PDT exhaustion for the PCU that manages the cell. b) starting from horizontal allocation, if there is radio scarcity, i.e. the percentage of idle air timeslots in the cell becomes lower than the ThresholdIdleChannelHV field of the GASTRTH parameter, than vertical allocation is triggered. c) starting from horizontal allocation, if there is Abis scarcity, i.e. the percentage of idle Abis subslots in the BTSM becomes lower than the ThresholdIdleAbisHV field of the GASTRABISTH parameter, than vertical allocation is triggered; the PCUs that are handling cells belonging to the impacted BTSM are informed. d) starting from horizontal allocation, if there is PDT exhaustion in the PCU, than vertical allocation is triggered. e) if the vertical allocation of the cell is due to radio scarcity only, and the percentage of idle air timeslots in the cell becomes bigger than the ThresholdIdleChannelVH field of the GASTRTH parameter, than horizontal allocation is triggered. f) if the vertical allocation of the cell is due to Abis scarcity only, and the percentage of idle Abis subslots in the BTSM becomes bigger than the ThresholdIdleAbisVH field of the GASTRABISTH parameter, than horizontal allocation is triggered; besides the PCUs that are assigned cells belonging to the impacted BTSM are informed. The used allocation strategy is managed and implemented in the TDPC. The TDPC informs the PCU about the used strategy using the allocation flag (HA/VA). This flag is updated each time the TDPC replies to PCU requests for resources. To avoid possible misalignment between TDPC and PCU, as regards the allocation flag, a mechanism is foreseen for which an audit, running every 10 seconds for each equipped and in service PCU, is sent to communicate to the PCU the current allocation strategy used on the TDPC side.
6.3.3
Management of Incoming GPRS/EGPRS Requests

With the introduction of packet switched data calls, a new clear and flexible strategy for channel allocation is required. Furthermore, the introduction of channel allocation strategies requires a mechanism to use/reuse the system resources, in order to better comply with the operators choices. In this sense it is very important to optimize the resource allocation in order to use each TRX in the best possible way, and to satisfy each new request according to the customers setting (both for Data and for Speech calls). Regarding the management of different services, the operator has the possibility to configure in the cell static and dynamic GPRS/EGPRS timeslots (see "6.2 Configuration of GPRS Channels in a Cell"). When a new GPRS/EGPRS request arrives at the BSC, it starts a process that is responsible for the management of all the incoming requests: the PCU, when it is needed, asks to the TDPC to set-up new channels for packet switched services. The aim of the task in PCU/TDPC is to allocate the requested resources according to the operator setting and to the Mobile Station preferences.
A30808-X3247-L24-1-7618
103
The radio resources allocation algorithm keeps into account the availability of EGPRS service, and the presence of EDGE capable mobiles and TRXs: in fact MSs that support EGPRS could be assigned either to TRX supporting EDGE (exploiting EGPRS coding schemes) or to TRX supporting GPRS (in this case only GPRS coding schemes can be used). To distinguish EDGE TRXs from non EDGE TRXs, both on TDPC and PCU, the Resource Manager looks at the TRX capability dynamic attribute of the TRX (see "6.1.3 Aspects Related to Carrier Configuration"): TRX with unknown TRX capability are not taken into account, since they are not available for service at all. Both on TDPC and on PCUC, the radio resource research algorithm will also take into account also the EBCCHTRX attribute, that specifies whether the 8PSK modulation is allowed on BCCH TRX (see " Configuration of the BCCH Transceiver for EGPRS"). The aim of the algorithm is: maximize the throughput in the limits of specified peak throughput (if specified), minimizing the number of allocated radio resources. Therefore, in principle EDGE TRXs are preferable for EDGE-capable mobiles, because higher data rates are possible with a lower number of radio resources, and even when data rates are comparable, or GPRS data rates are slightly better (e.g. CS4 versus MCS4), we can expect better performances from a TBF operating in EGPRS mode (instead of GPRS mode), due to specific retransmissions rules and incremental redundancy (see "9.9.1.2 EGPRS Acknowledged Mode"). But, for an EGPRS TBF, when the multislot capability of a mobile is high, and if radio resources are insufficient on EDGE TRXs and available on non EDGE TRXs, a non EDGE TRX could be preferable. In fact, as it has been said, trying to maximize the throughput is the most important criteria in radio resource research. Let us consider an example; a request to establish a TBF with the following requirements arrives at the BSC: Peak throughput = 80 Kbit/sec Multi-slot capability = 4 timeslots According to the request, the BSC finds two solutions; the first using NE timeslots on an EDGE TRX, the second using NG timeslots on a non EDGE TRX, where: NE = 2 (with MCS9) NG = 4 (with CS4) The best solution is to allocate 2 radio timeslot on EDGE TRX, because the peak throughput is sustained with the minimum number of radio resources. But if only 1 radio resource (NE) is available on an EDGE TRX, the sustainable throughput is only 59.2 Kbit/s. In this case 3 radio resources (62.4 Kbit/s), or 4 radio resources (83,2 Kbit/s), on a non EDGE TRX allow to sustain the peak throughput, and should be considered better solutions. From the configuration point of view, to allow, both for the voice and data calls, an higher flexibility for different operators strategies, a parameter is provided. This parameter, called CPOLICY, allows the operator to indicate on which TRX (BCCH or not BCCH) a certain type of call (voice or data) shall be preferably allocated. In this way a clear usage policy for the BCCH TRX channel allocation is guaranteed. The PCU and the TDPC take
104
A30808-X3247-L24-1-7618
care of this setting when they have to assign resources to GPRS users (see "6.3.3.1 PCU Algorithm" and "6.3.3.2 TDPC Algorithm"). So, taking account GPRS and EGPRS mobiles, TRXs supporting EGPRS or GPRS only, and the CPOLICY parameter, the research algorithm follows these rules basically: in case of EDGE capable mobiles, TRXs are sorted giving priority to the EDGE TRXs; this criterion is more important than the call policy. That is: if the CPOLICY parameter is set to DATA_CALL_ON_BCCH and the BCCH TRX is a non EDGE TRX, the BCCH TRX is checked AFTER all the EDGE TRXs and before all the other non EDGE TRXs. When the EDGE BCCH TRX doesnt support 8PSK (EBCCHTRX=FALSE), the Call Policy is disregarded: BCCH TRX will be considered after all the other EDGE TRXs even if the CPOLICY parameter is set to DATA_CALL_ON_BCCH. If the operator wants to give more priority to the BCCH TRX, according to the Call Policy, the EBCCHTRX attribute should be set to TRUE; in case of non EDGE capable mobiles, TRXs are sorted giving priority to the non EDGE TRXs; this criterion is more important than the call policy. That is: if the CPOLICY parameter is set to DATA_CALL_ON_BCCH and the BCCH TRX is a EDGE TRX, the BCCH TRX is checked AFTER all the non EDGE TRXs and before all the other EDGE TRXs. The Horizontal/Vertical allocation algorithm on TDPC receives as input a PDCH_Request message from the PCU containing, among other information, a list of suggestions for channels to be granted by TDPC. The already busy for GPRS/EGPRS channels can be assigned only by the PCU, while idle channels can be assigned only by the TDPC. If the incoming GPRS request cannot be satisfied (because some timeslots have to be free for the GPRS multislot calls, or because the cell is congested), the request is inserted in a waiting queue (i.e. a stand by queue), and it will be served as soon as the proper actions have been performed (see "6.3.6 Waiting Queue Management").
!
The
The waiting queue where the not served GPRS requests are inserted, is different from the queue related to the Queuing feature. In fact the Queuing feature is related to circuit switched calls only, and the related queue is called queuing list. As it has been described, the algorithm used to assign GPRS resources is split in two parts: one is performed on the PCU and the other one on the TDPC; in the following the parts are described.
6.3.3.1
PCU Algorithm
When a new request of GPRS resources arrives at the BSC, the first actions are taken by the PCU that handles the cell from which the request is arrived.
This chapter describes the PCU algorithm in case of new GPRS/EGPRS calls. The upgrading procedure in case new resources are asked for already established calls are discussed in "6.3.4 Upgrading Strategies". When a new request comes at PCU, the following information is provided: Mobile capability (GPRS or EGPRS); required Peak throughput; Multislot class; Candidate Initial Coding Scheme (CS/MCS); as it has been described in "4.2 Channel coding", the user can set the preferred initial coding scheme, for both
A30808-X3247-L24-1-7618
105
GPRS and EGPRS services, to be used when a new TBF starts. The O&M congured initial coding schemes will be used only if no information about a MS in a cell is available when a new TBF starts. In fact the PCU holds into memory, for each mobile station, the last coding scheme (either CS or MCS) used in Uplink/downlink directions for TBFs associated to the MS; neverthless the PCU maintains this information only for a specific period of time. So the Candidate Initial Coding Scheme will be: the coding scheme memorized in the PCU memory, if this information is still available; the O&M congured value otherwise.
To get more detailed information about initial coding scheme handling, please refer to "10.5.3 Selection of the Candidate Initial Coding Scheme".
The aim of the search on PCU side is to find a number of adjacent PDCHs in order to maximize the throughput of the TBF. The PCU, before starting to search radio resources on the TRXs, calculates the optimal number (N) of radio resources that allow to maximize the initial target throughput of the data transmission. The general formula to calculate the number of optimal number of radio resources (N) is the following: Peak Throughput Available N Min(ceil ( PT / (T_I_CS x (1-BLER) ), Multislot Class) Peak Throughput NOT Available Multislot Class
where: ceil = round up to the upper integer PT = required Peak Throughput T_I_CS =throughput (maximum data rate) of Candidate initial coding scheme BLER = it is the initial BLER value. The BLER value is defined as the number of radio blocks to be repeated (not acknowledged blocks) versus the number of transmitted radio blocks in total (i.e. the sum of the acknowledged blocks and the not acknowledged one, see "9.9 RLC Data Block Transfer"): BLER= NACK_Blocks/(ACK_Blocks+NACK_Blocks) The user can define the initial BLER value, used in the resource assignment process, by the INIBLER parameter. The O&M configured initial BLER will be used only if no information about a MS in a cell is available when a new TBF starts. In fact the PCU holds into memory, for each mobile station, besides the last coding scheme, the last measured BLER value (historical BLER) associated to the MS; neverthless the PCU maintains this information only for a specific period of time. So the Initial BLER corresponds to the INIBLER value if no historical BLER information is available; otherwise the historical BLER is used. The optimal number of radio resources that the PCU calculates depends on: the availability of the Peak Throughput in the request; the mobile station capability, i.e. if the MS is EGPRS capable or not. The different possibilities are described in the following:
106
A30808-X3247-L24-1-7618
a) In case of mobiles with EGPRS capability and in case the peak throughput is available, two calculations must be performed, for a pure UL or DL TBF setup (no concurrent TBF in progress): calculation for the optimal number NE of radio resources for EDGE TRX (based on the candidate initial MCS); calculation for the optimal number NG of radio resources for non EDGE TRX (based on the candidate initial CS); in case a concurrent TBF is in progress with TBF mode EDGE, only NE will be calculated; in case a concurrent TBF is in progress with TBF mode GPRS, only NG will be calculated; this is because, if a MS is assigned concurrent TBFs, these shall be in the same TBF mode. b) In case of mobiles without EGPRS capability and in case the peak throughput is available, only the calculation for NG is performed; c) In case the peak throughput is not available, the multislot class is taken into account. Then, different solutions (i.e. different radio timeslot configurations) are compared in terms of initial target throughput instead of number of timeslot; the basic formula to calculate the initial target throughput per timeslot is: Initial target throughput per timeslot = throughput (maximum data rate) of the candidate initial CS/MCS This value is multiplied by the number (NG or NE) of radio resources to get the better solution; the better solution is those providing the highest Initial Target Throughput.
When the initial target throughput per PDCH on GPRS TRXs is slightly better than initial target throughput per PDCH on EDGE TRXs, solutions allocating N radio resources on EDGE TRXs are preferred to solutions allocating N radio resources on GPRS TRXs, because better performances are expected from EGPRS specific retransmission rules and incremental redundancy (see "9.9.1.2 EGPRS Acknowledged Mode"). This situation can occur for example when the MCS and CS used to calculate the initial target throughput are homologous (e.g. CS4/MCS4). E.g. 3 radio timeslot in EGPRS TBF mode are preferable to 3 radio timeslots in GPRS mode, in case the initial MCS in the cell is MCS4 (data rate 17,6) and the initial GPRS CS in the cell is CS4 (data rate 20,8). The Initial target throughput is just an indicator, used to compare different radio timeslot configurations; there is no guarantee that the initial target throughput is really achieved, because the actual throughput depends on several factors: radio conditions, C/I, Link Adaptation, multiplexing factor, availability of Abis and PDT resources, etc. In particular, in case of Abis/PDT resources scarcity it is not guaranteed that the resource assignment will result in the best solution in terms of throughput (see "6.3.3.2 TDPC Algorithm"). When the PCU has calculated the optimal number of radio resources, it starts executing a pre-search of radio resources on available TRXs; a different process is applied according to the allocation strategy currently in use (the PCU algorithm is shown in Fig. 6.6). In case of Horizontal Allocation strategy the PCU starts a search on all the TRXs usable for GPRS or EGPRS according to the kind of request. The criteria used to find resources are the following (in order of priority): 1. prefer EGPRS on EDGE TRXs and GPRS on non EDGE TRXs; 2. maximize the Initial target throughput;
A30808-X3247-L24-1-7618
107
3. maximize the number of empty channels (i.e. the channels already allocated in packet transfer mode, but without assigned TBF; these channels are seen by the PCU as allocated until TEMPCH timer expires); 4. minimize the overall weight on the affected PDCHs;
The following QoS parameters are taken into account in resource allocation process on PCU side: - Radio Priority in uplink direction; - Service Precedence in downlink direction. Internally, UL radio priority and DL service precedence are mapped into a unique internal priority so that UL and DL TBFs are comparable. Internal priority here mentioned coincides with the scheduling priority used by the scheduler process (see "9.9.7 Notes About GPRS/EGPRS TBF Scheduling" to know how Qos attributes are mapped to scheduling priority). According to its priority, each TBF is assigned a weight; as it is described in 9.9.7, the association between priorities and weights is performed by the following O&M attributes: SCHWEIPRI1, SCHWEIPRI2, SCHWEIPRI3, SCHWEIPRI4. So, each PDCH(i) is assigned a total weight W(i) given by: W(i) = Sum of W(k) where W(k) is the weight of all the TBF(k) multiplexed on the PDCH(i). On PCU, the algorithm for radio resources presearch, in addition to the other criteria, tries then to minimize the total weight of the suggestions to be sent to TDPC.
5. maximize the number of adjacent timeslots with respect to the ones already in packet transfer mode; 6. choose the preferred TRXs according to the CPOLICY parameter. The output of this algorithm is a possible configuration on one TRX. Two cases exist: 1. if all the chosen timeslots are already available at PCU side, i.e. the PCU does not need to ask new idle PDCH channels to the TDPC, the timeslots are assigned by PCU immediately (i.e. no PDCH_Request message is sent to TDPC). But in this case, according to flexible Abis allocation strategy, it could happen that, even if no new PDCH has to be allocated, new PDT/Abis allocation is necessary to support the new TBF; these because e.g. the current Abis allocation is not enough to support the candidate initial coding scheme. In this case the PCU will request to TDPC additional Abis resources using the PDCH_Abis_Upgrade message (to have more details about upgrade of Abis resources, see "6.3.4.2 Upgrade of Abis Resources"). It must be noted that when the horizontal allocation is used, timeslots already available at PCU side are the empty channels, i.e. free PDCHs for which the TEMPCH timer is running (these channels are also called pre-allocated) 2. in case some timeslots are not immediately available, i.e. when new idle channels are necessary at PCU side, a PDCH_request message is sent to TDPC indicating this configuration as a suggestion (the request notifies also the TDPC the Initial Target Throughput per timeslot). Obviously the request contains also the number of Abis resources needed to support the TBF. In order to handle parallel requests the TRX belonging to this suggestion is set as frozen and excluded from subsequent searches until either TDPC answers (positively or not) or a protection timer expires. In case of Vertical Allocation strategy the idea is trying to reduce the number of new timeslots to ask to TDPC for the incoming request.
108
A30808-X3247-L24-1-7618
First of all when the Vertical Allocation strategy allocation is used the layering method is the following (flat distribution): instead of multiplexing continuously on the same timeslot (until the GMANMSAL value is reached), the TBFs are spread on all the already assigned timeslots, on all the TRXs. This leads to better system performances in terms of TBF throughput. This is done multiplexing the new TBF on the timeslots already in packet mode that are not in busy state (busy state is set when the number of TBFs multiplexed on a PDCH reaches the GMANMSAL value). The criteria used to find resources are the following (in order of priority): 1. 2. 3. 4. 5. prefer EGPRS on EDGE TRXs and GPRS on non EDGE TRXs; maximize the initial target throughput; maximize the number of empty channels; minimize the overall weight on the affected PDCHs; choose the preferred TRXs according to the CPOLICY parameter.
The output of this algorithm is a possible configuration on one TRX. If all the chosen timeslots are already available at PCU side they are assigned immediately. It must be noted, that when the vertical allocation is used, timeslots already available at PCU side are: timeslots already assigned to GPRS users, containing active TBFs; empty channels, i.e. free PDCHs for which the TEMPCH timer is running (these channels are also called pre-allocated). In this case no new PDCH has to be allocated, but it could happen that the current PDT/Abis allocation is not enough, so the PCU could request to TDPC additional Abis resources by the PDCH_Abis_Upgrade message (to have more details about upgrade of Abis resources, see "6.3.4.2 Upgrade of Abis Resources"). In case some timeslots are not immediately available, a PDCH_request message is sent to TDPC indicating the suggestion to be preferred in the search. Also in this case, in order to handle parallel requests, the TRX belonging to the suggestions is set as frozen and excluded from subsequent searches until either TDPC answers (positively or not) or a protection timer expires.
A30808-X3247-L24-1-7618
109
MS/SGSN request
Calculate the number of requested PDCHs according to: - Multislot Class - Peak Throughput -Mobile Station Capability -Candidate Initial Coding Scheme
Horizontal
Allocation type?
Vertical
Find channels according to HA criteria
Find channels according to VA criteria
NO
PCU needs new PDCH channels?
YES
NO
PCU needs new PDCH channels?
YES
Send PDCH_Request to TDPC
Send PDCH_Request to TDPC
PCU needs new PDT?
YES
PCU needs new PDT?
YES
NO
NO
Assign channels already in Packet Mode
Send PDCH_Abis_Upgrade to TDPC
Assign channels already in Packet Mode
Send PDCH_Abis_Upgrade to TDPC
Fig. 6.6
Allocation Algorithm followed by the PCU
110
A30808-X3247-L24-1-7618
6.3.3.2
TDPC Algorithm
As it has been described (see 6.3.3.1) the PCU can send to the TDPC two kinds of message: a) the PDCH_Request message, when new PDCHs on the air interface have to be assigned; this message species also the number of Abis resources needed to support the TBF; b) a PDCH_Abis_Upgrade message, when new PDCHs on the air interface have not to be assigned, but new Abis resources are needed. The second case is considered as an upgrade of already assigned resources, and it is discussed in "6.3.4.1 Upgrade of Radio Resources". The first case is here described. When the PCU needs new PDCH channels to be assigned to the incoming GPRS/EGPRS call, it sends to the TDPC a PDCH_Request message. The PDCH_Request message received from the PCU contains the following information: Number of timeslots; Suggestion; the suggestion contains the following information: relative number of TRX; bit map containing 1 for each timeslot selected by the PCU in the suggested configuration (there is 1 for both pre-allocated and idle channels in the configuration); bit map containing 1 for each timeslot pre-allocated by the PCU in the suggested configuration;
Pre-allocated channels are the channels already in packet transfer mode, but without assigned TBF; i.e. they are the channels for which the TEMPCH timer is still running (see "6.3.3.1 PCU Algorithm").
the HA/VA indicator. This indicator is used to say in which allocation type (HA/VA) the PCU has sent the message to the TDPC; number of needed Abis subslots for each PDCH.
As a general rule, the TDPC will try first to satisfy the suggestion sent by the PCU. Only if it is not possible to exactly satisfy the suggestion, it tries to satisfy the request using as many pre-allocated channels as it can. If again the request is not satisfied, TDPC goes on to search through all the TRXs, in order to find out the best configuration that matches the requirement fixed further. It is important to underline the following feature: the Abis/PDT scarcity does not affect the radio resource assignment algorithm of TDPC. The only mandatory check (on TDPC) concerns the availability of one Abis/PDT per new PDCHs in the selected radio timeslot configuration. No attempt is done to search radio resources minimizing the number of new allocated Abis/PDT resources. Hence, in case of Abis/PDT resources scarcity it is not guaranteed that the initial coding scheme can be supported; and the initial target throughput is based on the number of radio timeslots that can be actually activated. Then the TDPC will answer to the PCU with: a PDCH_Setup message when at least one idle channel has been assigned; in this case, no matter of the value of the thresholdIdleAbisStopUpgrade eld of the GASTRABISTH parameter (see "6.3.4.2 Upgrade of Abis Resources"), the TDPC
A30808-X3247-L24-1-7618
111
will allocate new PDCHs trying to assign them the requested number of Abis/PDTs per PDCH and, if necessary and possible (see "6.3.4.2 Upgrade of Abis Resources"), upgrade up to the requested number of PDTs per PDCH the already allocated PDCHs in the conguration. In case Abis/PDT resources are not enough to satisfy completely the request (activation of new PDCHs and possible upgrade of already allocated PDCHs), the number of PDTs per PDCH specied in the request is downgraded. a PDCH_KO message, if no idle channels have been assigned (even if some preallocated channels were present in the PCU request); also in this case if necessary and possible (see "6.3.4.2 Upgrade of Abis Resources"), upgrade up to the requested number of PDTs per PDCH the already allocated PDCHs in the conguration.
More in detail, the TDPC algorithm is described in the following (see Fig. 6.7). When the involved BTS is congested, if the incoming GPRS/EGPRS request is for more than one timeslot, the TDPC distinguishes between upgrade requests and new requests: an upgrade request is detected each time the PCU requires for additional timeslots for GPRS/EGPRS service. This means that some timeslots are currently allocated for PS data transmission, and the request is for additional resources. In this case, when the BTS is congested, the request from the PCU is rejected and the TDPC sends a PDCH_KO message to the PCU. a different situation occurs when an incoming request arrives at the TDPC from the PCU and no channels are currently allocated for PS services. In this case, when the BTS is congested, the incoming multislot request is downgraded to a single timeslot request. At this time if the request cannot be served immediately, it will be included in the waiting queue.
This mechanism is not applied to timeslots reserved for exclusive use of the GPRS/EGPRS services. So if the incoming request can be satisfied using the timeslots reserved exclusively for PS services (xed by the operator using the GMANPRES attribute) no downgrade or reject is performed on the incoming request. If the BTS is not congested, the TDPC verifies if there are some pending requests, first in the queuing list and then in the waiting queue. If any pending request exists then the TDPC puts the incoming GPRS/EGPRS request in the waiting queue because it is necessary to serve the old calls before. So, when resources are available and either the queuing list or the waiting queue is filled with some pending request, the new request will not be served immediately, even if there is no congestion from a BTS point of view. This is done in order to optimize the usage of resources and it can produce a short delay in serving the new requests. In case both the queues are empty, the TDPC has to check if the incoming request can be completely satisfied by available system resources. The algorithm on TDPC will search idle channels following these criteria: 1. prefer EGPRS on EDGE TRXs and GPRS on non EDGE TRXs; 2. maximizing the initial target throughput; 3. using as many pre allocated channels, if any, as it can (resulting from PCU suggestions); 4. minimizing the number of forced intracell handovers of circuit switched calls; 5. choosing the preferred TRXs according to the CPOLICY parameter.
112
A30808-X3247-L24-1-7618
If the request is completely satisfied by the available resources, without the need to execute forced intracell handovers, the request is served immediately; so the TDPC will answer to the PCUC with a PDCH_Setup message. The PDCH_Setup message contains always the current allocation value (VA/HA) on TDPC. If one or more intracell handovers have to be executed, the request is put in waiting queue and the management is delegated to the waiting queue manager process (see "6.3.6 Waiting Queue Management").
Note that for the previous algorithm the search including forced intracell handovers is applied only if forced intracell handovers have been enabled by the operator (see "6.3.6.3 Forced Intracell Handovers of Already Established CS Calls"). If no new idle channels are assigned, the TDPC will answer to the PCU with a PDCH_KO message; this message hasa field as a bit map containing the HA/VA indicator. The HA/VA indicator is set to horizontal allocation or vertical allocation depending on the situation of radio interface and Abis interface, how described in "6.3.2 Horizontal/Vertical Allocation Strategies". The following considerations can also be done: each time more than one solution is found to satisfy a request, it is chosen that for which, when new channels are assigned, the number of adjacent busy channels for GPRS/EGPRS is higher. This is done to reduce holes in the configuration and to facilitate the assignment for new incoming GPRS/EGPRS calls when the VA is active; it should be noted as the priority related to the preferred TRX is the lowest one; so if the request can be satisfied, according to the other criteria, on not preferred TRXs, the resources will be assigned on a not preferred TRX; in case more than one allocation with the same number of timeslots is possible on different TRXs, the allocation is performed according to the order of priority listed above. For instance if the system is handling a request for three timeslots, and both TRX0 (BCCH) and TRX1 (non BCCH) have three available timeslots, but only TRX0 has one empty channel, whereas TRX1 has not empty channels, then the allocation is performed on TRX0 even if TRX1 may have more than the required timeslots free; for PDCH allocation in multislot congurations, the allocated PDCHs must have (see also "4.7 Multislot Configuration"): same frequency hopping law; same training sequence code (TSC); same MAIO; adjacent time slot numbers; The rst three rules have to be followed during the conguration phase, that means that all timeslots (defined as TCH) must have the same hopping law and the same training sequence code. The fourth law is dynamically followed by TDPC, when it selects timeslots to be allocated to GPRS/EGPRS users. if TDPC answers with PDCH_KO to the PCU because no GPRS/EGPRS channels are available anymore or because no idle channels are assigned and there are not pre allocated ones, TDPC will force the VA. In this way the PCU will try to layer the call on already busy for GPRS/EGPRS channels; the subsequent deallocation of the allocated PDCH occurs when all the TBFs present on it have been released, and the TEMPCH timer is expired.
A30808-X3247-L24-1-7618
113
If what assigned by TDPC does not fit what required by the PCU, this last tries to expand the proposed configuration using timeslots already available and adjacent to the new ones. For instance when the HA is used, if the PCU has to assign to a GPRS/EGPRS user three channels, the PCU requires three idle channels to the TDPC (let us suppose that the PCU does not indicate any pre allocated channel in the suggestion). If the TDPC can assign only two channels, because either the maximum number of PS channels or the Vertical allocation threshold has been reached, it assigns this two channels setting also the VA/HA flag to VA. Then the PCU uses the two channels assigned by TDPC, plus another channel already available at PCU side where another TBF is running (since there are not any pre allocated channels).
114
A30808-X3247-L24-1-7618
Reception of PDCH_Request from PCU
YES
Is the Cell congested?
NO
Are queues empty? NO Put the call in Waiting Queue NO
YES
Upgrade New call or Upgrade?
New call
Are there available resources immediately?
YES
Downgrade the (E)GPRS call to 1 timeslot NO Send PDCH_KO to PCU (if necessary set VA)
Assign the resources Is it possible to free resources using Intracell Handover?
Put the downgraded call in Waiting Queue
Calculate HA/VA threshold
YES
Put the multislot call in Waiting Queue
YES
Threshold overcome?
NO
YES
Were there pre-allocated channels in the PCU request?
NO
Set VA
Assign pre-allocated PDCHs
Calculate HA/VA threshold Send PDCH_KO to PCU (Set VA) YES Threshold overcome? NO Send PDCH_Setup to PCU
Set VA
Send PDCH_KO to PCU
Fig. 6.7
Allocation Algorithm followed by the TDPC
A30808-X3247-L24-1-7618
115
6.3.4
Upgrading Strategies
Two kinds of upgrading strategies are defined according to different situations: 1. upgrading of radio resources: additional radio resources could become necessary to sustain the peak throughput; 2. upgrading of Abis/PDT resources: it can be required by Link Adaptation (see 10.5) when the conditions gets better, or by the PCU when in the same PDCH has to ll a TBF with an higher coding scheme with respect to those already substained. As it can be seen, the upgrading of radio resources is different from the upgrading of Abis/PDTs, that occurs under completely different conditions. So, these upgrading strategies are discussed separately.
6.3.4.1
Upgrade of Radio Resources

After the first allocation of radio resources, additional radio resources could become necessary to sustain the peak throughput. Therefore a radio resource upgrading strategy is necessary. The events triggering the radio resource upgrading (upgrading conditions) are: increasing of the peak throughput requirement; decreasing of the maximum sustainable throughput, due to the worsening of radio conditions; loss of radio resources due to pre-emption or O&M commands. In general, once detected the upgrading condition, several additional radio resources could be necessary to fill the gap to the required number of radio resources. However, in the present release, for effort reasons the upgrading of radio resources is performed one step a time; it means that radio resources are added one at a time, each time one of the upgrading conditions is detected. The additional radio resource must belong to the same TRX and must be adjacent to the radio resources already assigned to the TBF. The choice between the radio resource on the left or on the right of the current allocation is performed using the same criteria used in the first allocation of radio resources (see 6.3.3.1). Note that in case the worsening of radio conditions would lead simultaneously to a step of Link Adaptation (downgrading the CS/MCS and possibly the Abis/PDTs, see "10.5 Link Adaptation") and to upgrading of radio resources, the downgrading of CS/MCS is managed before the upgrading of radio resources. It is a general rule on PCU that procedures cannot be nested: hence the upgrading of radio resources will be started, if necessary, only when the downgrading of CS/MCS procedure is completed. The radio resources upgrade is attempted if the already allocated resources are less than what can be supported by the MS multislot class. Depending on the position of the TBF on the TRX, the best additional PDCH could be already allocated to GPRS/EGPRS, or it could be necessary to request it to TDPC. As long as vertical allocation is in progress, PCU is not allowed to request new PDCHs to TDPC for upgrading reasons. The additional PDCH can be requested only if both the following conditions are satisfied: 1. the horizontal allocation is in progress;
116
A30808-X3247-L24-1-7618
2. the number of idle radio timeslots in the cell is higher than the thresholdIdleChanEnableUpgrade field of the GASTRTH attribute.
The number of idle timeslot is calculated in the same manner as described in "6.3.2.3 Switching between VA and HA According to Radio Conditions". The check is performed on TDPC. The PCU is informed by a flag (enableRadioUpgradingFlag) added in all the messages containing the allocation status flag. At system initialisation by default the enableRadioUpgradingFlag is DISABLED both on PCU and TDPC sides, and is set to ENABLED at the first check detecting the horizontal allocation condition, unless the thresholdIdleChanEnableUpgrade value is 100 (this value means: new PDCHs cannot be allocated to GPRS for upgrading reasons). The thresholdIdleChanEnableUpgrade does not enable the upgrading strategy. It enables the possibility to allocate new PDCHs to GPRS/EGPRS for upgrading reasons. But PDCHs already allocated to GPRS/EGPRS can be assigned to a TBF for upgrading reasons no matter of the thresholdIdleChanEnableUpgrade value. Besides, the thresholdIdleChanEnableUpgrade threshold does not affect the assignment of resources for new incoming TBFs. In the following the upgrading conditions are discussed. 1) Change in Peak Throughput Requirement While an uplink TBF is in progress, the mobile can request a variation in peak throughput submitting a PACKET_RESOURCE_REQUEST message and specifying a different value of peak throughput in the Channel Request Description information element. While a downlink TBF is in progress, the SGSN can request a variation in peak throughput specifying a different value of throughput in the QoS Profile information element of the DL-UNITDATA. In both cases (DL/UL), the variation of peak throughput is taken into account only if a peak throughput value higher than the currently managed value (in the same UL or DL direction) is specified. An extension to the number of allocated timeslots is tried if the number of currently allocated timeslots is lower than the number of required timeslots; the number of required timeslots is defined as: Number of required TSs = min (ceil ( new PT / (T_A_CS x (1-BLER)), Multislot Class). where: ceil = round up to the upper integer new PT = new required Peak Throughput T_A_CS =throughput of the Actual Coding Scheme BLER = it is the actual BLER. The extension is tried by adding one adjacent TS to the actual configuration; so the PCU will send to TPDC a PDCH_Upgrade_Reqeust message, but only if the conditions regarding horizontal allocation and the percentage of idle timeslots are verified. In case radio resources are missing and the upgrading is not possible, the upgrading request is let drop. The upgrading will be attempted again if a decreasing of maximum sustainable throughput is detected, as specified in 2) Change in Maximum Sustainable Throughput.
A30808-X3247-L24-1-7618
117
2) Change in Maximum Sustainable Throughput During a TBF lifetime, due to variations in radio conditions, either the BLER or the used CS/MCS coding scheme can change, leading to a change in Maximum sustainable Throughput. The Maximum sustainable throughput is defined as the maximum throughput that would be achieved by a given TBF if it was alone on the multislot configuration, that is: Maximum sustainable throughput = T_A_CS x (1-BLER) x #TS where: T_A_CS =throughput of the Actual Coding Scheme BLER = it is the actual BLER #TS = number of allocated timeslots to the TBF A check on the maximum sustainable throughput is performed periodically, with a period defined by the UPGRFREQ attribute. As a general rule, only the decreasing in maximum sustainable throughput is taken into account (increasing, hence the downgrading of radio resources is not managed). Moreover, since the variations in Maximum sustainable throughput can be very frequent, only the decreasing below a given threshold will be managed. An extension to the number of allocated TSs is tried if: T_A_CS x (1-BLER) x Currently allocated #TS < (1- ACCEPTGDEGR) x PT where: T_A_CS = throughput of the Actual Coding Scheme BLER = it is the actual BLER PT = Peak Throughput ACCEPTGDEGR= it is an O&M parameter So, when the max sustainable throughput becomes lower than the maximum tolerable degradation of the peak throughput, the upgrading is performed.
As long as the one radio resource a time algorithm is implemented, the ACCEPTGDEGR attribute is suggested to be set to 0 (no degradation allowed, radio resource upgrading always attempted as soon as the upgrading condition is detected), in order to reach the required radio resource allocation in several steps. The extension is tried by adding one adjacent timeslot to the actual configuration; so the PCU will send to TPDC a PDCH_Upgrade_Reqeust message, but only if the conditions regarding horizontal allocation and the percentage of idle timeslots are verified.
6.3.4.2
Upgrade of Abis Resources

According to flexible Abis allocation strategy, for already assigned radio channels, new Abis resources could become necessary, e.g.: it can be required by Link Adaptation when the radio conditions gets better (see "10.5 Link Adaptation"); it can be required by the PCU when in the same PDCH has to set up a TBF with an higher coding scheme with respect to those already multiplexed on the PDCH (see "6.3.3 Management of Incoming GPRS/EGPRS Requests").
118
A30808-X3247-L24-1-7618
The user can manage the upgrade strategy of Abis resources by two fields of the GASTRABISTH parameter. The two fields are: thresholdIdleAbisStopUpgrade eld: it denes the percentage of idle Abis subslots of a BTSM (over the available Abis subslots managed by the BTSM) under which the PCU must disable the Abis upgrading requests to TDPC for all the cells managed by the PCU and belonging to the involved BTSM. When this threshold is overcome, the first allocation of Abis resources to a TBF is performed with the same criteria used under normal conditions (looking at the candidate initial coding scheme), but further upgrading of Abis resources is forbidden. Moreover, in case of runtime Abis release (due to worsening of radio conditions, CS pre-emption or O&M commands), the released Abis is not allowed to be allocated again to running TBFs. The main aim of this threshold is to avoid useless signalling between PCU and TDPC in case of nearly complete Abis congestion, therefore, the default value of the threshold is 0, meaning that the Abis upgrading is disabled only in case of complete Abis congestion. The secondary aim of this threshold is to avoid the allocation of additional Abis resources to running packet services in case of Abis scarcity, so that the residual Abis resources in the pool can be by preference available to set up new CS services (this will be the trend in case of vertical allocation) or even to new PS services (in case horizontal allocation is still active). Note that moving this threshold from the default value, a reduction in PS throughput is expected; thresholdIdleAbisRestoreUpgrade eld: it denes the percentage of idle Abis subslots of a BTSM (over the available Abis subslots managed by the BTSM) over which the Abis upgrade requests to TDPC are restored for all the cells managed by the PCU and belonging to the involved BTSM. Constraints on the Abis thresholds are: thresholdIdleAbisStopUpgrade < thresholdIdleAbisRestoreUpgrade There is no constraint between the Abis threshold to switch to vertical allocation (see "6.3.2.4 Switching between VA and HA according to Abis Interface Conditions") and the Abis threshold to disable the Abis upgrade requests; the operator is free to set the one lowest than the other, and vice versa. As a general configuration rule, in BTSMs where the Abis resources/radio resources ratio is quite high, in order to obtain the highest benefit from Link Adaptation, the Abis upgrading should be disabled only in case of complete Abis congestion or at least after the switch to vertical allocation. Instead, in BTSMs where the Abis resources/radio resources ratio is quite low, for some operators it could be preferable to disable the Abis upgrading before the switch to vertical allocation. In any case the choice will depend from the relative preference given from the operator to circuit switched calls versus packet switched TBFs, and to running TBFs versus incoming TBFs.
6.3.5
Incoming CS Calls
When a circuit switched call (deriving from either a normal assignment or an external incoming handover) comes into the cell with no free radio channels, the following algorithm is applied:
A30808-X3247-L24-1-7618
119
1. if the incoming CS call nds the cell in a congested state, the rst attempted thing is to preempt one vulnerable CS call; 2. if preemption cannot be started for whatever reason (e.g. the feature is not enabled), the Directed Retry procedure is started; 3. if also the Directed Retry cannot be started (e.g. the feature is not enabled or the feature is enabled but the Handover Condition Indication message does not contain any cell) the queueing procedure is started, if enabled;
The queuing procedure puts the CS call in the Queueing List that is different from the Waiting Queue.
4. if the queueing procedure is not enabled, the CS call is put in the Waiting Queue. To free resources for the CS call put in waiting queue, a packet data transfer may be downgraded, in case of a multislot call, or released in the worst case. In any case the static GPRS/EGPRS channels can not be pre-empted by CS calls (see "6.3.6 Waiting Queue Management"). Besides, according to the flexible Abis allocation strategy (see 5.3), it could happen also that when the CS calls has to be served, no Abis resources are available to serve the incoming call. Even in this case, the call is put in the waiting queue in order to find the required resources.
6.3.6
Waiting Queue Management

As it has been described in "6.3.3.2 TDPC Algorithm", there are some cases for which the TDPC inserts the incoming requests in the waiting queue; then the TDPC must analyze in a second time this pending requests to serve them. The task is activated by a timer. To summarize, the following GPRS/EGPRS calls are put in waiting queue: a) GPRS/EGPRS requests that arrive when the cell is congested and no GPRS calls are present in the cell; these calls are downgraded to 1 timeslot before being inserted in the waiting queue; b) GPRS requests that arrive when other calls are present in the waiting queue or in the queuing list; c) GPRS requests that must wait for intracell handovers; in these case the multislot call is inserted in the waiting queue. Besides, in the waiting queue could also be put CS calls that arrive: a) when no radio resources are available in the BTS; in fact, if both the pre-emption and the directed retry fail or have not been enabled, these calls are put in the queuing list (if the Queuing feature has been enabled). Otherwise, if the Queuing feature is not enabled the CS calls are put in the waiting queue (see "6.3.5 Incoming CS Calls") b) when no Abis resources are available in the BTSM that manages the BTS. The TDPC, before checking the waiting queue, analyses the queueing list. If the queueing list contains some pending request (i.e. some CS calls), the TDPC shall immediately manage resources of the queueing list.
120
A30808-X3247-L24-1-7618
After this procedure, or if the queueing list is empty, the process shall analyze the waiting queue.
Note, once more, that the resources that are released, are used first by the Queueing process and only later on by the Waiting Queue process. So the classic Queueing procedure already implemented has always an higher priority than the waiting queue management. Three types of action can be performed by the process to serve pending requests on the waiting queue: 1. Use resources just released by the TDPC: in case the system had released any system resources, these have been included in the Idle List structure. Then the system nds the released resources which are available for the specic cell. If the resources are not enough to serve all the entries present in the waiting queue, the following Downgrading mechanisms are activated; 2. Downgrading of already active HSCSD multislot calls: the downgrade of already active HSCSD calls, is performed in two situations only: to serve GPRS/EGPRS pending requests in the waiting queue; to serve incoming CS requests in the waiting queue (see "6.3.5 Incoming CS Calls"); The downgrade of an already active HSCSD call is executed only if the number of used timeslots is greater than one (i.e. at least one timeslot must remain allocated for the HSCSD call) 3. Downgrading of already active PS multislot calls: the GPRS/EGPRS downgrade process, consists in a decrease of the number of timeslots already assigned to PS services. When the downgrade of PS calls is performed, one of the GPRS/EGPRS channels is preempted and the channel is released. In the case in which a PS data transmission uses only one timeslot for GPRS/EGPRS, and the timeslot is preempted for downgrading, the transmission is interrupted (to avoid GPRS/EGPRS downgrading, the operator can assign static GPRS/EGPRS timeslots as explained in "6.2 Conguration of GPRS Channels in a Cell"). The downgrade of already active PS multislot calls is performed in two situations only: to serve GPRS/EGPRS pending requests in the waiting queue; to serve incoming CS requests in the waiting queue (see "6.3.5 Incoming CS Calls").
GPRS/EGPRS calls can be in waiting queue for two reasons: with a multislot request if the BTS is not congested, or downgraded to 1 timeslot if the BTS is congested. No active GPRS/EGPRS multislot calls are downgraded to free resources for incoming GPRS/EGPRS multislot calls. Regarding the downgrade of already active GPRS/EGPRS and HSCSD multislot calls, the user can select the downgrade strategy. The user can choose the preferred downgrade strategy through the DownGradeStrategy parameter (DGRSTRGY). This attribute allows the user to choose among five different strategies: Downgrade of HSCSD calls rst Downgrade of GPRS/EGPRS calls rst Downgrade of HSCSD calls only Downgrade of GPRS/EGPRS calls only No Downgrade
A30808-X3247-L24-1-7618
121
6.3.6.1
Pre-emption of PDCH Channels

The TDPC can send to the PCU the order to release one or more PDCHs in a cell (PDCH_preemption_order), due to unavailability of radio resources in a cell. On PCU, PDCH pre-emption orders are managed with the aim to disturb a set of TBFs characterised by QoS requirements as low as possible. Therefore, the algorithm selects, in the order: 1. PDCHs with the PDCH empty timer still active (because this PDCH has a total Weight equal to 0; see "6.3.3.1 PCU Algorithm" to get information about the total weight of TBFs assigned to a PDCH); as it has been described the PDCH empty timer can be dened by the user by the TEMPCH parameter; 2. PDCHs with the lowest total weight, among the PDCHs with the highest timeslot position on the TRX. The preemption of some PDCHs can result in the reconfiguration of some TBFs (partially allocated also on residual PDCHs) and in the release of some other TBFs (completely allocated on the preempted PDCHs). It is important to underline that, if the preemtpion of a PDCH must be executed to serve an incoming CS call (see "6.3.5 Incoming CS Calls"), these two criteria are followed: a) before downgrading a PDCH on a TRX where CS calls are seen as preferred, a free channel on not preferred TRXs (not preferred for CS calls) is searched before (i.e. the CPOLICY parameter is negletted); b) independently on the value of the DGRSTRGY parameter, if the are some empty channels (i.e. PDCH channels for which the PDCH empty timer is running) they are used to serve the CS call; if no empty channels exists, than the rules dened by the DGRSTRGY parameter are followed to free resources for the CS call.
6.3.6.2
Pre-emption of PDT Resources

The TDPC can send to the PCU a PDT pre-emption order in case no PDT or Abis resources are available for PBCCH/PCCH activation, or in case no Abis resources are available to serve incoming CS requests put in waiting queue. Cells belonging to the exhausted BTSM are spread over several PCUs (see "8 Load Control for Packet Switched Services"), so, in case of unavailability of Abis resources in a BTSM pool, the TDPC selects the PCU with the highest number of PDTs allocated to the exhausted BTSM, and sends it a pre-emption order. In case of unavailability of Abis resources, the same pre-emption level used in case of radio resources unavailability is applied. E.g. In case of CS pre-emption due to unavailability of Abis resources, the pre-emption management shall not cause the release of PBCCHs and PCCHs (or the pre-emption of static GPRS/EGPRS channels). That is: only PDTs with SFC=1..4 can be removed from PBCCHs and PCCHs. On PCU, PDT pre-emption orders are managed with the aim to balance the distribution of PDTs among cells and to disturb as less as possible running TBFs. In each selected cell, the algorithm selects, in the order: 1. PDTs with PDT empty timer still active (as it has been described in "6.3.1 Generalities about Resource Assignments", the PDT empty timer can be dened by the user by the TEMPPDTparameter); 2. starting from the rst TRX and highest timeslot numer and removing one PDT per timeslot, then moving on the next TRX; this step is repeated until the required number of PDTs is found.
122
A30808-X3247-L24-1-7618
Since the PDT pre-emption management can result in the release of some PDCHs, it can result in the reconfiguration of some TBFs (partially allocated also on residual PDCHs) and in the release of some other TBFs (completely allocated on the preempted PDCHs). PDCHs can be released provided that the number of residual PDCHs allocated in the cell is higher or equal to the number of reserved PDCHs. In case the release of the PDTs does not cause the whole PDCH release, a forced downgrade of the coding scheme is performed for all the TBFs multiplexed on the involved PDTs. Otherwise (release of the whole PDCH), the same behaviour implemented in case of PDCH pre-emption (see 6.3.6.1) is ensured.
6.3.6.3
Forced Intracell Handovers of Already Established CS Calls

When from the PCU comes a request for a new PDCH, the TDPC tries to allocate it. It could happen that in the transceivers supporting GPRS/EGPRS there are not free and consecutive timeslots, e.g. because the already assigned PDCHs are full and the remaining timeslots are dedicated to circuit switched calls. In this case, if there is at least one free channel in the cell (and the maximum number of timeslots assigned to PS services has not been reached), a forced intracell handover starts to free timeslots for GPRS users. The forced intracell handover allows to move a CS call from one timeslot, to another one in the same cell.
The decision whether pre-emption may be made on circuit switched services is taken by the TDPC, causing a forced intracell handover for circuit switched calls. To enable forced intracell handover, the user must set the ENFOIAHO parameter (Enable Forced Intracell Handover) to TRUE.
A30808-X3247-L24-1-7618
123
7 Gb Interface
The Gb interface connects the BSC to the SGSN, transferring signalling information and user data. Several BSCs may be interfaced to one SGSN on the Gb interface. The main characteristics of the Gb interface are: a) resources are given to a user upon activity (when data is sent or received) and they are reallocated immediately thereafter; this is in contrast to the A interface, where a single user has the only use of a dedicated physical resource throughout the lifetime of a call, irrespective of activity; b) GPRS/EGPRS signalling and user data are sent in the same physical channel. No dedicated physical resources are required to be allocated for signalling purposes (like e.g. the A interface where SS7 links are used to transmit signalling between the BSC and the MSC). The protocol stack of the Gb interface is illustrated in Fig. 7.1.
Fig. 7.1
Gb Interface: Protocol Stack
The several layers realize the following functions: L1: it species the Layer 1 of the Gb interface. Frame Relay (FR) is used for GPRS/EGPRS in a rst phase. Network Service (NS): it performs transport of NS Service Data Units (SDU) between the SGSN and BSS. The Gb interface is based on Frame Relay (FR) as specied in GSM 08.16. FR supports high data rate transmission with low delay. Frames of different sizes may be transmitted. FR performs congestion control and error detection, however error correction is not supported. BSSGP: the primary functions of the Base Station Subsystem GPRS protocol (BSSGP) are: providing connection-less links between the SGSN and the BSS (layer 2 level); providing tools for bi-directional control of data ow; handling paging requests from the SGSN to the BSS.
124
A30808-X3247-L24-1-7618
LLC (Logical Link Control layer): provides logical links between a MS and the corresponding SGSN. The transport of both data and signalling is supported; SNDCP (SubNetwork Dependent Convergence Protocol): supports a direct peer to peer (i.e. point-to-point) communication between a MS and a SGSN. User data is transported from a network layer protocol, e.g. IP or X.25.
The NS layer of the Gb interface is split into a Network Service Control part and a Sub Network Service part. The Service Control part is independent from the physical realization of the network, whereas the Sub-Network Service entity is the Frame Relay protocol.
7.1
Physical Layer
Four types of configurations are possible to connect the BSC to the SGSN: 1. a direct line (e.g. PCM30) between the two entities (static and permanent physical point to point connections); 2. an intermediate frame relay network; 3. Nailed Up Connection (NUC) through the MSC via a frame relay network; 4. NUC through MSC, without using an intermediate frame relay network. The different configurations are illustrated in Fig. 7.2.
Fig. 7.2
Different Connection Types between the BSC and the SGSN. The Gb interface is realized by PCM lines: in case of direct connections between the BSC and the SGSN, PCM lines are called PCMG; in case of connections through the MSC (and TRAU), PCMA lines are used.
A30808-X3247-L24-1-7618
125
The PCMG object represents the PCM line used to connect the BSC and the SGSN, without passing through the MSC. Functional object PCMG Meaning Represents the direct physical connection between BSC and SGSN. PCMG Object
Tab. 7.1
On the PCMG line, 31 physical channels, of 64 kbit/sec each one, can be handled (slot 0 is always use for synchronization purposes). In case of standard BSC (see 5.1.1) up to two PCMG lines can be configured: PCMG:0; PCMG:1. In fact in this case two PCMG lines are enough to handle the 32 X 64 Kbit/sec channels (16 channels for each PCU) that can be equipped toward the Gb interface, providing also the possibility to have fault redundancy. When the high capacity BSC with the old rack is used (see 5.1.2), in order to exploit completely the bandwidth that the 6 PPXUs offer toward the Gb interface (in total 378 time slots at 64 Kbit/sec), an increase of the PCMG number is necessary. For E1 lines (31 time slots), 12 lines are enough, while for the T1 lines (PCM24 mode), 16 PCMG lines are necessary: so this is the number of PCMG that is possible to configure at mos with this kind of BSC. When the high capacity BSC with the new rack is used (see 5.1.3), in order to exploit completely the bandwidth that 12 PPXUs offer toward the Gb interface (in total 756 time slots at 64 Kbit/sec), an increase of the PCMG number is necessary. For E1 lines (31 time slots), 24 lines are enough, while for the T1 lines (PCM24 mode), 32 PCMG lines are necessary: so this is the number of PCMG that is possible to configure at most when the new BSC rack is used. As it has been described in "5 Hardware and Software Features", each PCU manages the packet switched data traffic of a specific number of cells; to transmit packet data (or signalling) related to these cells, each PCU can use all the PCMG lines configured for the BSC. In other words, the PCM line is not statically assigned to one PCU, but to the whole BSC. This line can be connected in one circuit of LICD without any restrictions. The LICD circuit using QTLP V2 can be programmed in transparent mode and in this way we can connect 2 PCM lines to 1 LICD circuit. The following attributes are involved in PCMG configuration: PCML: this attribute identies the LICD number (range 0 to 8), the CIRCUIT number (range 0 to 5 ) and the TRUNK (A or B) to which the PCM line is connected;
The range 0..5 of the CIRCUIT number is valid when STLP boards are used in the BSC (i.e. when the new BSC rack is used), otherwise tha admitted range is 0..3.
CRC: this attribute indicates if CRC-4 signal handling for PCM 30 line or CRC-6 signal handling for PCM 24 line is Enabled on PCMG line; CODE: this attribute selects the line transmission code to be provided on the line; NUA: this attribute enables or disables handling of not urgent alarms on PCMG line;
126
A30808-X3247-L24-1-7618
BER (Bit Error Rate): this attribute indicates the threshold that, if exceeded, the line must be put in Disabled state; BAF: this attribute defines frame alignment bits that can be set by operator; LOWBER (Lower Bit Error Rate): this attribute is relevant only for PCM24 lines; REMAL (Remote AlarmType): this attribute is relevant only for PCM24 lines.
The Gb interface physical layer is specified in GSM 08.14; it is called Frame Relay Link (FRL). The Frame Relay Link is a n X 64 Kbit/sec physical channel, created over a PCM line. These physical channels can be created grouping either neighboring or spaced time slots of the PCM line; more than one physical channel can be created over a single line (see Fig. 7.3).
FRL_1 PCM line
31
PCM line
0 FRL_2 Fig. 7.3 Example of Frame Relay Links FRL_3
31
In case of direct connections between the BSC and the SGSN, frame Relay links are created over PCMG lines, whereas in case of connections through the MSC, the FR links are created over PCMA lines. The FRL object represents the physical channel over the Gb interface between the BSC and the SGSN. Functional object FRL Meaning Represents the physical link connection on Gb interface. FRL Object
Tab. 7.2
In case of A interface connections the 64 kbit/s time slots are reserved on PCMS (and PCMA) lines and handled in TRAU as transparent channel. In case of direct Gb interface connections (i.e. connections built without passing through the MSC), PCMG lines are dedicated to SGSN connection, and the FRL occupies one or more 64 kbit/s timeslots. The choice between direct connections or A interface connections can be done in base
A30808-X3247-L24-1-7618
127
of the bandwidth required on Gb interface (in case of small number of FRL links is advantageous to use A interface connections). In case of A interface connections, with multislot links, the customer shall guarantee that the MSC is able to ensure the sequence. If the MSC is not able to guarantee this feature, only single timeslot frame relay links can be configured. When a standard BSC is used (see 5.1.1), up to 32 frame relay links can be created for each BSC (with range 0 to 31). In fact how it is described in "5 Hardware and Software Features", each PCU is able to handle 1 Mbit/sec data flow towards the Gb interface. This flow corresponds to a flow obtained by 16 slots (64 Kbit/sec each one) on a PCM line. This factor determines the maximum number of Frame Relay links that can be configured for each PCU, and the capacity in terms of bit/rate; in fact for each PCU: up to 16 FRLs of 64 kbit/sec each one can be congured; or only a single FRL with 1Mbit/sec can be congured. When the high capacity BSC with the old rack is used (see 5.1.2), up to 378 frame relay links can be created for each BSC (with range 0 to 377). In fact how it is described in "5 Hardware and Software Features", each PCU is able to handle a 4 Mbit/sec data flow towards the Gb interface. This flow corresponds to a flow obtained by 63 slots (64 Kbit/sec each one) on a PCM line. This factor determines the maximum number of Frame Relay links that can be configured for each PCU, and the capacity in terms of bit/rate; in fact for each PCU at most 63 FRLs of 64 kbit/sec each one can be configured. When the high capacity BSC with the new rack is used (see 5.1.3), up to 756 frame relay links can be created for each BSC (with range 0 to 755). In fact how it is described in "5 Hardware and Software Features", each PCU is able to handle a 4 Mbit/sec data flow towards the Gb interface. This flow corresponds to a flow obtained by 63 slots (64 Kbit/sec each one) on a PCM line. This factor determines the maximum number of Frame Relay links that can be configured for each PCU, and the capacity in terms of bit/rate; in fact for each PCU at most 63 FRLs of 64 kbit/sec each one can be configured. When creating a Frame Relay Link the operator specifies which PCU it belongs to, using the PCUID attribute. This attribute indicates the pathname of the PCU managing the FRL. Besides, the operator indicates: 1. the PCM line on which the link is created, using the GLK attribute; 2. the number of slots that constitutes the FRL, using the GTS attribute. For example: setting GTS= 3, allows to congure a 64 kbit/sec Frame Relay link on the slot number 3 of the PCM line which is specied by the GLK attribute (see Fig. 7.4); setting GTS= 3&4&5&6, allows to congure a 256 kbit/sec Frame Relay link on slots number 3, 4, 5 and 6 of the PCM line which is specied by the GLK attribute (see Fig. 7.5); setting GTS= 3&4&7&8, allows to congure a 256 kbit/sec Frame Relay link on slots number 3, 4, 7 and 8 of the PCM line which is specied by the GLK attribute (see Fig. 7.6).
128
A30808-X3247-L24-1-7618
0 64 Kbit/sec Frame Relay Link Fig. 7.4 Example of Frame Relay Link (GTS=3).
31
0 256 Kbit/sec Frame Relay Link Fig. 7.5 Example of Frame Relay Link (GTS=3&4&5&6).
31
0 256 Kbit/sec Frame Relay Link Fig. 7.6 Example of Frame Relay Link (GTS=3&4&7&8).
31
The operator, by the FRSTD attribute, can optionally also indicate the frame relay standard to be used (regarding the frame relay structure see 7.2.1.2). Supposing to configure, for each PCU, 2 FRLs, these links can be distributed on the Gb interface in different manners, by setting the GTS attribute, e.g.: it is possible to put all the two links on the same PCMG line; it is possible to distribute them on two different PCMG lines (this situation is obviously better than the previous one, since the redundancy of the links is provided; in fact in case of fault of one PCMG line, the other one allows to maintain the connection between the BSC and the SGSN); it is possible to put one of them on one PCMG line, and the remaining one on one PCMA line; it is possible to put both the links over PCMA lines. When the links are created over different PCMA lines, and these lines belong to the same TRAU module (i.e. the lines correspond to the same PCMS line), the FR links must have different timeslot values for the GTS attribute.
A30808-X3247-L24-1-7618
129
Instead, if the lines belong to different TRAU module this problem does not exist. This last solution is obviously better than the previous one, since it provides the redundancy of FRLs.
Remember that the PCMG/PCMA lines are shared between the configured PCUs, whereas each Frame Relay Link is associated to a specific PCU according to the PCUID value.
7.2
Network Service Layer

The Network Service layer provides a reliable connection between the BSC and the SGSN; this reliable connection is realized: a) within the FR network, when such network exists between the two entities; b) with a direct link, in case of point-to-point connections. Error detection is performed, while error recovery is left to upper layers. The Network Service entity is composed of (see Fig. 7.7): 1. the Sub-Network Service (i.e. the Frame Relay protocol), which is an entity dependent on the intermediate Gb interface network; 2. the Network Service Control, i.e. a control entity independent from that network.
Fig. 7.7
Network Service Layer
7.2.1
Sub-Network Service: Frame Relay on Gb Interface

On the Gb interface, and specifically inside each Frame Relay physical link, only Permanent Virtual Circuits are implemented. A Permanent Virtual Circuit (PVC) is an end-to-end logical communication link between the BSS/PCU and the SGSN, irrespective of the exact configuration of the Gb interface. These PVCs are created inside the FR physical links, and each FRL can contain more than one PVC. For PVCs there is not call set-up or clearing: a connection to the frame relaying node must be in place from the configuration point of view. The NSVC (Network Service Virtual Connection) object represents the end-to-end permanent virtual connection between the BSC and the SGSN.
130
A30808-X3247-L24-1-7618
Functional object NSVC
Meaning Represents the end-to-end communication between BSS and SGSN.
Tab. 7.3
NSVC Object
Each NSVC is identified by the Network Service Virtual Connection Identifier (NSVCI). Up to 65536 NSVCIs can be created between a BSC and the SGSN. For each FRL (i.e. for each Frame Relay physical link) more than one NSVC can be created. Referring to Fig. 7.8 there is a set of principles that apply to the Gb FR network: the physical link is the Frame Relay bearer channel (allocated timeslots in a PCMG or a PCMA line); the NSVC is the FR PVC; the FR PVC (NSVC) provides an end-to-end connection through the FR network. The Network Service Virtual Link (NSVL) is the local link in one end of the FR PVC, i.e it is the link at the User Network Interface (UNI); the Data Link Connection (DLC) denes the entry point to the FR network. A DLC is identied by a DLC Identier (DLCI); the Network Service Virtual Link Identier (NSVLI) is the DLCI together with the bearer channel identier (FRL). A physical link supports one or more NSVLs; each one is identied by a NSVLI.
Frame Relay physical link
Fig. 7.8
Gb Interface with a Frame Relay Network
When creating a new PVC, i.e. when creating a new instance of the NSVC object, the user must so specify:
A30808-X3247-L24-1-7618
131
1. the Network Service Virtual Connection Identier (NSVCI) of the NSVC, i.e. the common and absolute identication of the virtual connection between the SGSN and the BSS; to specify this value he uses the NSVCI parameter; 2. the Network Service Virtual Link Identier (NSVLI) to identify the NSVC on the local (BSS) side. To specify this value he uses the NSVLI parameter; this parameter is composed of two elds: the rst one (FRLN) indicates the Frame Relay physical link on which the permanent virtual circuit is created; the second one (DLCIN) indicates the DLCI number; this identier (that is the address of Frame Relay packets, see "7.2.1.2 Frame Relay Structure") allows to distinguish between different NSVCs that belong to the same physical Frame Relay link. The mapping of the DLCI parameter is as follows: DLCI value 0 1-15 16-511 512-991 Mapping In band signalling Reserved Available for user information Available for user information
Since Frame Relay Physical links are statically associated to a single PCU, even the NSVCs created inside this FRL are handled by a single PCU. The PCU will then share its traffic among all its NSVCs. So, each PCU can manage: - a set of frame relay physical links (FRLs); - a set of NSVCs, for each FRL. - NSVCs belonging to different FRLs are distinguished by the FRLN attribute; - NSVCs belonging to the same FRL are distinguished by the DLCIN attribute. All the NSVCs configured for a PCU, constitute the so called NSVC group; this group is identified by the Network Service Entity Identifier (NSEI). The NSEI is the logical entity of the SGSN that manages a single PCU; as a consequence it identifies, besides the PCU, all the NSVCs configured for the Packet Control Unit. The NSEI value, that identifies the PCU and its NSVCs is configured by the NSEI parameter. If a direct end-to-end PCMG line connection is used between the BSC and the SGSN (i.e. if a Frame Relay Network is not used), the two values related to one NSVC are the same; i.e. the NSVLI value at the BSS side is equal to the NSVLI value at the SGSN side. When an intermediate FR network is used in connecting the BSS and the SGSN, the NSVLI values, of the same NSVC, can have a different value at the SGSN side and at the BSS side.
7.2.1.1
Examples of Addressing
In order to provide end-to-end communication between the SGSN and the BSS irrespective of the exact configuration of the Gb interface, the concept of Network Service
132
A30808-X3247-L24-1-7618
Virtual Connection (NSVC) is used. At each side of the Gb interface there is a one-toone correspondence between NSVCs and NSVLs. The creation of a NSVC may be as follows (see Fig. 7.9): Database object instance: NSVC-3 Defining the end-to-end connection between the SGSN and the BSC/PCU. Internal identifier of the FR network connecting each side of the network. FRL object 0, DLCI 111. Local connection at BSC/PCU side. Similarly a NSVLI value must be defined at the SGSN side.
Parameters for NSVC-3:
NSVCI=5
NSVLI=0-111
Fig. 7.9
Creation of a NSVC
To well understand previous concepts, some examples regarding the configuration of both Frame Relay Links and Permanent Virtual Connections (NSVCs) are described. Lets consider a BSC that is connected to the SGSN by two direct PCMG lines (PCMG0 and PCMG-1). EXAMPLE 1: BSC Configured with One PCU and Two Frame Relay Links of 64 Kbit/sec each one. Two frame relay links of 64 kbit/sec each one have been created for a BSC configured with a single PCU. The PCU has been congured with a NSEI value equal to 2354 (see Fig. 7.10). The PCU sees a total bandwidth of 128 Kbit/sec (64 Kbit/sec + 64 Kbit/sec).
A30808-X3247-L24-1-7618
133
FRL:0 NSEI = 2354 PCUID:PCU-0 GLK:PCMG-0 GTS:2
PCU- 0
PCMG-0 0 31
PCMG-1 0 FRL:1 PCUID:PCU-0 GLK:PCMG-1 GTS:5 Fig. 7.10 BSC Configured with One PCU and Two FR Links (64 Kbit/sec each one). 31
Supposing now to create a PVC for each FRL; Tab. 7.4 shows possible values that can be used to create the two virtual connections. As it can be seen, DLCI values of the two created NSVCs can be equal, since the two NSVCs belong to two different FRLs.
NSVC belonging to FRL:0 NSVCI NSVLI FRLN DLCI 494 0 100
NSVC belonging to FRL:1 NSVC NSVLI FRLN DLCI 512 1 100
Tab. 7.4
Example of Setting of NSVC Values.
EXAMPLE 2: BSC Configured with One PCU and Two Frame Relay Links of 128 Kbit/sec each one. Two frame relay links of 128 kbit/sec each one have been created for a BSC configured with a single PCU. The PCU has been congured with a NSEI value equal to 2354 (see Fig. 7.11). The PCU sees a total bandwidth of 256 Kbit/sec (128 Kbit/sec + 128 Kbit/sec).
134
A30808-X3247-L24-1-7618
FRL:0 NSEI = 2354 PCUID:PCU-0 GLK:PCMG-0 GTS:2&3
PCU- 0
PCMG-0 0 31
PCMG-1 0 FRL:1 PCUID:PCU-0 GLK:PCMG-1 GTS:5&8 Fig. 7.11 BSC Configured with One PCU and Two FR Links (128 Kbit/sec each one). 31
Supposing now to create a PVC for each FRL; Tab. 7.4 shows possible values that can be used to create the two virtual connections. It can be seen, that from the NSVC configuration point of view, there isnt any difference with respect to the previous example, even if the FRL:1 has been created using two not adjacent timeslots. Obviously the network must be enable to support one FRL created with two not neighboring slots. EXAMPLE 3: BSC Configured with Two PCUs and Two Frame Relay Links of 128 Kbit/sec each one. In this case the BSC contains two PCUs. The PCU-0 has been configured with a NSEI value equal to 2354, while the PCU-1 is identied by the NSEI= 7564 (see Fig. 7.12). For each PCU two frame relay links of 128 kbit/sec each one have been created; the PCU sees a total bandwidth of 256 Kbit/sec (128 Kbit/sec + 128 Kbit/sec).
A30808-X3247-L24-1-7618
135
FRL:0 NSEI = 2354 PCUID:PCU-0 GLK:PCMG-0 GTS:2&3
FRL:2 PCUID:PCU-1 GLK:PCMG-0 GTS:8&9
PCU- 0 PCU- 1
PCMG-0 0 31
PCMG-1 0 FRL:1 NSEI = 7564 PCUID:PCU-0 GLK:PCMG-1 GTS:5&7 FRL:3 PCUID:PCU-1 GLK:PCMG-1 GTS:10&11 31
Fig. 7.12
BSC Configured with Two PCUs and Two FR Links each one.
Supposing now to create a PVC for each FRL; Tab. 7.5 shows possible values that can be used to create the two virtual connections for the PCU-0, and possible values that can be used to create the two virtual connections for the PCU-1. The NSEI identifier of the PCU-0, not only identifies the PCU, but also used NSVCs to support the traffic of the PCU-0; in the same way the NSEI identifier of the PCU-1, not only identifies the PCU-1, but also used NSVCs to support its traffic. NSVC belonging to FRL:0 NSVCI NSVLI FRLN DLCI 480 0 163
Tab. 7.5
Example of Setting of NSVC Values for both PCU-0 and PCU-1
136
A30808-X3247-L24-1-7618
Tab. 7.5
Example of Setting of NSVC Values for both PCU-0 and PCU-1
7.2.1.2
Frame Relay Structure

Core functions of the NS Sub Network Service provide necessary data link functions to permit routing and relaying, but exclude those associated with sequencing, most forms of error detection, error recovery and flow control. Referring to the Frame Relay frame format (see Fig. 7.14), the Sub Network Service functionality provides for: a) Delimiting, alignment and transparency using the Flag eld. b) Multiplexing/De-multiplexing using the Address eld. This function permits one or more core connections to exist across a single physical connection. c) Error detection using the FCS eld (no Error Recovery). Frame Relay uses a common error-checking mechanism known as the cyclic redundancy check (CRC). The CRC compares two calculated values to determine whether errors occurred during the transmission from source to destination. Frame Relay reduces network overhead by implementing error checking rather than error correction. Frame Relay typically is implemented on reliable network media, so data integrity is not sacriced because error correction can be left to higher-layer protocols running on top of Frame Relay. d) Congestion control using the FECN, BECN, and DE elds. This function permits core entities to detect congestion, to optionally notify peer entities of congestion conditions, and to discard data units in response to congestion. Frame Relay implements two congestion-notication mechanisms: Forward-explicit congestion notication (FECN); Backward-explicit congestion notication (BECN) FECN and BECN features are controlled by a single bit contained in the Frame Relay frame header. The Frame Relay frame header also contains a Discard Eligibility (DE) bit, which is used to identify less important trafc that can be dropped during periods of congestion. The FECN mechanism is initiated when a DTE device (e.g. in our case the SGSN) sends Frame Relay frames into the network (see Fig. 7.13).
A30808-X3247-L24-1-7618
137
Fig. 7.13
Frame Relay Network Connecting two DTE Devices
If the network is congested, DCE devices (switches) set the value of the frames FECN bit to 1. When the frames reach the destination DTE device, the Address eld (with the FECN bit set) indicates that the frame experienced congestion in the path from source to destination. The DTE device can relay this information to a higherlayer protocol for processing. Depending on the implementation, ow-control may be initiated, or the indication may be ignored. DCE devices set the value of the BECN bit to 1 in frames travelling in the opposite direction of frames with their FECN bit set. This informs the receiving DTE device that a particular path through the network is congested. The DTE device then can relay this information to a higher-layer protocol for processing. Depending on the implementation, ow-control may be initiated, or the indication may be ignored. The Discard Eligibility (DE) bit is used to indicate that a frame has lower importance than other frames. DTE devices can set the value of the DE bit of a frame to 1 to indicate that the frame has lower importance than other frames. When the network becomes congested, DCE devices will discard frames with the DE bit set, before discarding those that do not. This reduces the likelihood of critical data being dropped by Frame Relay DCE devices during periods of congestion. Two parameters are involved in the congestion control procedure: TCONG: this parameter allows the user to congure the width of the observation window used for congestion detection. The congestion detection regards the path from the SGSN to the BSC (i.e. it regards the frame relay frames sent by the SGSN to the BSS). If, during the time dened by TCONG, the number of frames indicating congestion is equal or greater than the number of frames indicating no congestion, the congestion state is notified to upper layers; TCONOFF: after a congestion notication to upper layers, no other notications are foreseen for a length of time defined by TCONOFF. This timer is needed to provide a hysteresis time in order to ensure that the traffic reduction at mobile station can be effective.
138
A30808-X3247-L24-1-7618
All data link peer to peer communications use frames conforming to the format shown in Fig. 7.14.
Fig. 7.14
Frame Relay Frame Structure
The basic Frame Relay fields are the following: Flags: delimits the beginning and end of the frame. The value of this eld is always the same and is represented either as the hexadecimal number 7E or the binary number 01111110. Address: contains the following information: DLCI: the 10-bit DLCI is the essence of the Frame Relay header. This value represents the virtual connection between the DTE device and the switch. Each virtual connection that is multiplexed onto the physical channel will be represented by a unique DLCI. The DLCI values have local signicance only, which means that they are unique only to the physical channel on which they reside. Therefore, devices at opposite ends of a connection can use different DLCI values to refer to the same virtual connection. Since there is neither D-channel nor layer 2 management functionality, the available DLCI values usable for user information are almost the whole DLCI range but DLCI 0, which is reserved for layer 3 message transfer (STATUS and STATUS_ENQUIRY, see "7.2.1.3 Procedures for PVCs"); Extended Address (EA): it is used to indicate whether the byte in which the EA value is 1 is the last addressing eld. If the value is 1, then the current byte is determined to be the last DLCI octet. Although current Frame Relay implementations use a two-octet DLCI, this capability allows for longer DLCIs to be used in the future. The eighth bit of each byte of the Address eld is used to indicate the EA. C/R: it is the bit that follows the most signicant DLCI byte in the Address eld. The C/R bit is not currently dened. Congestion Control: it consists of the three bits that control the Frame Relay
A30808-X3247-L24-1-7618
139
congestion-notication mechanisms. These are the FECN, BECN, and DE bits, which are the last three bits in the Address eld. Data: contains encapsulated upper-layer data. Each frame in this variable-length eld includes a user data or payload eld that will vary in length up to 16,000 octets. This eld serves to transport higher-layer protocol packets (PDUs) through a Frame Relay network. Frame Check Sequence: ensures the integrity of transmitted data. This value is computed by the source device and veried by the receiver to ensure integrity of transmission.
7.2.1.3
Procedures for PVCs

For each group of PVCs belonging to a FRL, a periodic polling procedure is used in acquiring general status about the connection between the BSC and the SGSN. The polling interval is defined by the T391 timer. Every T391 seconds the PCU sends a STATUS ENQUIRY message to the network to retrieve some information (optionally the network may initiate the polling procedure). The information regards: a) notication of the addition of a PVC: used to notify users of newly added permanent virtual circuits; b) detection of the deletion of a PVC: used to notify users of deleted permanent virtual circuits; c) notication of the availability (active) or unavailability (inactive) state of a congured PVC: used to determine changes in status of congured PVCs; d) link integrity verication: used in determining the in-channel signalling link DLCI-0. Establishing and releasing a logical connection is accomplished by exchanging messages via DLCI-0. The Link Integrity verication procedure is required since DLCI-0 contains unnumbered information (UI) frames at Level 2. The periodic polling procedure allows the PCU to retrieve the previous information; the procedure is shown in Fig. 7.15.: 1. every T391 seconds the PCU sends a STATUS_ENQUIRY message to the network; 2. the network answers with a STATUS message; two types of STATUS messages can be used: if no PVCs have been added to or deleted from the FRL, or if the state of congured PVCs is not changed, the network answers with a normal STATUS message; it is used only to verify the link integrity (this message doesnt contain the state of the congured PVCs because nothing is changed); if one (or more) PVC has been added to or deleted from the FRL, or if the state of any congured PVCs is changed, the network answers with a FULL STATUS message, reporting the status of ALL the PVCs (this message is also used to verify the link integrity); 3. after N391 polling cycles (i.e. after N391 expirations of the T391 timer), the PCU sends to the network a STATUS_ENQUIRY message requiring a FULL STATUS answer; 4. every time the PCU doesnt receive an answer from the SGSN, an error counter is incremented;
140
A30808-X3247-L24-1-7618
5. if the error counter reaches the N392 value during the error observation window dened by: N393 * T391 the Frame Relay link is put into Disable state, and all the contained PVCs are, as a consequence, put in Disable state; 6. if the N392 threshold is not reached during the error observation window, the error counter is restarted.
PCU
Expiration of T391 STATUS_ENQUIRY
SGSN
STATUS Reset and restart T392 Expiration of T391 STATUS_ENQUIRY
STATUS Expiration of T391 N391 polling cycles reached STATUS_ENQUIRY Reset and restart T392
FULL_STATUS
Fig. 7.15
Periodic Polling Procedure
i
7.2.2
The value of the T391 timer set on the BSC side must be lower than the value of the T392 timer set on the SGSN side.
Network Service Control

The Network Service Control entity is responsible for the following functions: NS SDU transmission: the NS SDUs are transmitted on the congured NSVCs. The NS SDUs are encapsulated into Network Service Control PDUs which in turn are encapsulated into Sub- Network Service PDUs. On each NSVC data is transferred in order; Load sharing: the load sharing function distributes the NS SDU trafc among the available (i.e. unblocked) NSVCs. NSVC management: a blocking procedure is used by a NS entity to inform a NS peer entity when a NSVC becomes unavailable for NS user trafc; an unblocking procedure is used for the reverse operation;
A30808-X3247-L24-1-7618
141
a reset procedure is used between peer NS entities in order to set a NSVC to a determined state, after events resulting in possibly inconsistent states of the NSVC at both sides of the Gb interface; a test procedure is used to check that a NSVC is properly operating between peer NS entities.
7.2.2.1
Load Sharing
All NS SDUs to be transmitted over the Gb interface are passed to the load sharing function. The load sharing function is used by NS entities to select among unblocked NSVCs of the addressed BVC, where to send NS SDUs.
Each BVC represents a GPRS/EGPRS cell in the PCU (see "7.3 BSSGP Protocol"); so the load sharing function allows to transmit the NS SDUs related to a cell among the available NSVCs. The mapping between NS SDUs and NSVCs is based on an implementation dependent function that meets the following requirements: for each BVC (i.e. for each cell), the load sharing function chooses the NSVC over which the current NS SDU must be transmitted; thus, the load sharing function guarantees that, for each BVC, the order of all NS SDUs is preserved; load sharing functions at the BSS and the SGSN are independent. Therefore, uplink and downlink NS SDUs for a subscriber may be transferred over different NSVCs; a change in the number of available NSVCs for NS user trafc (i.e. one or more NSVCs become blocked or unblocked) results in a re-organization of the NS SDU trafc amongst the unblocked NSVCs; for a BVC, when there arent unblocked NSVCs between a BSS and a SGSN, the corresponding trafc is discarded by the NS at the sending side.
Load sharing applies only to NS SDUs, not to NS signalling, such as NSVC management PDUs (e.g. NS_BLOCK_PDU used in the NSVC block/unblock procedures, see "7.2.2.2 Control Procedures").
7.2.2.2
Control Procedures
The procedures concerning the management of NSVCs are: block/unblock of NSVCs by the operator reset and test the status of NSVCs. The Block Procedure inhibits a NSVC to carry traffic. For instance, the BSC may block a NSVC because of: Operation and Maintenance intervention at the Gb interface, making the NSVC unavailable for NS user traffic; equipment or link failure at the BSS or at the SGSN side; failure in the transit network. The Load Sharing function is then informed and the result is the redistribution of NS SDU to other unblocked NSVCs; the NS entity is informed via NS_STATUS_INDICATION primitive for each affected BVC, while the remote peer is notified via NS_BLOCK_PDU. The reception of the NS_BLOCK_ACK primitive from the SGSN closes the procedure at BSS side. When the PCU has sent a NS_BLOCK_PDU, it waits TNSVCBLK seconds for acknowledgement from the SGSN. The NNSVCBLKR parameter specifies the maximum
142
A30808-X3247-L24-1-7618
number of performed retries by the PCU in the NSVC block procedure; i.e. if the SGSN does not answer to the block procedure, the PCU retries the procedure at most NNSVCBLKR times. The Unblock Procedure allows to return a previously blocked NSVC back to service again. The procedure is analogue to the BLOCK one. When the PCU has sent the NS_UNBLOCK_PDU, it waits TNSVCBLK seconds for acknowledgement from the SGSN. The NNSVCUBLR parameter specifies the maximum number of performed retries in the NSVC unblock procedure; i.e. if the SGSN does not answer to the unblock procedure, the procedure is retried NNSVCUBLR times. The Reset Procedure is used: when a new NSVC is set up between a BSS and the SGSN; after processor restart; after failure recovery or any local event restoring an existing NSVC which was in dead state; when the state of a NSVC is undetermined between remote NS entities. Upon completion of the reset procedure, the successfully reset NSVC is marked as blocked and alive at both sides of the Gb interface. The BSS (or the SGSN) sends the NS_RESET_PDU to its peer entity indicating the NSVCI. The NS_RESET_PDU is sent on the NSVC being reset. When the PCU has sent the NS_RESET_PDU, it waits TNSVCR seconds for acknowledgement. The NNSVCRR parameter specifies the maximum number of performed retries in the NSVC reset procedure, before generating any alarm; i.e. if the SGSN does not answer to the reset procedure, the procedure is retried infinitely times, but after NNSVCRR times an O&M alarm is notified. The Test Procedure is performed via NS_ALIVE_ACK_PDU and it is used when a BSS (or SGSN) wishes to check that end-to-end communication with its peer entity exists on a NSVC. Both sides of the Gb interface must initiate this procedure independently from each other. This procedure is initiated upon successful completion of the reset procedure (as specified in sub-clause "Reset procedure") and shall then be periodically repeated. After unsuccessful attempts, the procedure is stopped, the NSVC is marked as dead and blocked, the O&M system and the load sharing function are informed. A blocking procedure is initiated using an alive NSVC, if any. The test procedure is executed according to the following features: the periodicity of the procedure is given by the TNSVCTST timer; i.e. when a NSVC is available the test message is sent to the SGSN every TNSVCTST seconds; if after TNSVCPTST seconds no answer to the test is received from the SGSN, the procedure is retried; after NNSVCTSTR repetitions, without any answer, the link is declared as not available.
7.3
BSSGP Protocol
The Gb interface allows many users to be multiplexed over a common physical resource. Both GPRS/EGPRS signalling and user data may be sent on the same physical resource. The primary functions of the BSSGP protocol include:
A30808-X3247-L24-1-7618
143
transmit LLC frames from the SGSN to the BSS, with radio related information (such as Quality of Service and routing information) which is used by the RLC/MAC function; transmit LLC frames from the BSS to the SGSN, with radio related information (such as Quality of Service and routing information) which is derived from the RLC/MAC function; provide functionalities to enable both the SGSN and the BSS to perform management control functions (e.g. SGSN-BSS flow control).
7.3.1
BSSGP Addressing: BSSGP Virtual Connections (BVCs)

The BSSGP protocol establishes the connection between the SGSN and the PCU in terms of BSSGP virtual connections (BVCs). Each BVC is used in transporting BSSGP PDUs, between PTP (point to point) functional entities; a PTP functional entity is constituted by a cell. The following concepts are meaningful: each BVC is identied by a BVCI (Virtual Connection Identier); each BVCI identies univocally a GPRS/EGPRS cell in the PCU; each PCU is identied by the Network Service Entity Identier (NSEI) in the SGSN; the couple BVCI and NSEI identies univocally a GPRS/EGPRS cell in the SGSN; In GSM 08.18 for point to point packet transfer its specified that a cell is identified by a BVCI, so there is a relation one to one between a cell and a BVCI. In Siemens implementation the PTPPKF object represents the presence of packet switched data services in a specific cell and the state of this object allows or not the service in the cell. The dependency from the BTS object is one to one, then all state changes on BTS objects are reflected on PTPPKF objects. The NSVC-BVCI hierarchy is not one to one but one PTPPKF can be reached from different NSVCs, which are connected to the same PCU; in fact the NSEI identifies the NSVC group, i.e. the group of all the NSVCs that provide service for a PCU: to one PCU corresponds only one NSVC group and vice versa. Then, the PTPPKF state can be affected by: BTS state changes; specic commands executed on the object; state changes on subordinated NSVC objects. The PTPPKF state transition, due to NSVC state change, is handled by the system that puts the PTPPKF object in disabled state when the associated BVCI is no more accessible. All state transitions for PTPPKF objects are notified to remote end via BVCI Block/Unblock procedure (see 7.3.1.1). The PCU restart or the BSS initialisation are handled making a reset procedure with SGSN. Needed timers for handling Block/Unblock and Reset procedures are defined in the PCU object (see "7.3.1.1 BVC Procedures"). The PTPPKF object is always created with the instance equal to 0 since it is subordinate to the BTSM and BTS object following this path: BTSM:m/BTS:n/PTPPKF:0 The BVCI number associated to a PTPPKF object instance is fixed, and the relation is:
144
A30808-X3247-L24-1-7618
BVCI number = (number of creation of the PTPPKF in the database) + 2 The 0 and 1 values are reserved respectively for signalling and PTM links.
When an upgrade from the BR5.5 release to the BR7.0 one is executed, some changes in the SGSN database must be executed. This is due to the fact that, according to the load balancing schema that is used for the PCUs (see "5.1 Supported BSC Types"), the PTPPKFs (i.e. the BVCIs) are no more statically assigned to a single NSEI (i.e. to a single PCU) but they can be moved from one PCU to another one following the PTPPKF distribution algorithm (see "8 Load Control for Packet Switched Services"); so in the SGSN the BVCIs of one BSC have to be configured on all the NSEIs (PCUs) related to the BSC. To summarize the previous concepts, let us consider a SGSN that manages four PCUs: PCU:0, PCU:1 and PCU:2 congured on BSC:1; PCU:0 congured on BSC:2. Watching at Fig. 7.16, it can be seen that: a) each PCU is identied in the SGSN by the NSEI attribute: the PCU:0 of the BSC:1 is identied by the NSEI_A value; the PCU:1 of the BSC:1 is identied by the NSEI_B value; the PCU:2 of the BSC:1 is identied by the NSEI_C value; the PCU:0 of the BSC:2 is identied by the NSEI_D value; b) the NSEI attribute identies also all the congured NSVCs for each PCU: the NSEI_A value identies NSVC:0, NSVC:1 and NSVC:2 connections (related to PCU:0 of BSC:1); the NSEI_B value identies NSVC:3 and NSVC:4 connections (related to PCU:1 of BSC:1); the NSEI_C value identies NSVC:5, NSVC:6 and NSVC:7 connections (related to PCU:2 of BSC:1); the NSEI_D value identies NSVC:0, NSVC:1 and NSVC:2 connections (related to PCU:0 of BSC:2);
Obviously the NSVCI values, related to the different NSVCs created for the four PCUs, must be different each other.
c) each cell is identied in the PCU, by the BVCI value; d) each cell is identied in the SGSN, by the couple BVCI and NSEI; e) the trafc of all the cells (BVCIs) congured for a PCU is distributed among all the NSVCs congured for the PCU.
A30808-X3247-L24-1-7618
145
NSVC group identified by NSEI_A GPRS Cell BVCI= 2 NSVC:0 GPRS Cell BVCI= 6 BSC:1\PCU:0 NSEI_A NSVC:1 NSVC:2 BVCI=2 BVCI=6 NSEI_A FRL:0
FRL:1 NSVC group identified by NSEI_B FRL:2 BSC:1\PCU:1 NSEI_B GPRS Cell BVCI= 4 FRL:3 NSVC:3 NSVC:4 BVCI=4 BVCI=5 NSEI_B
GPRS Cell BVCI= 5
NSVC group identified by NSEI_C GPRS Cell BVCI= 3 BSC:1\PCU:2 GPRS Cell BVCI= 7 NSEI_C NSVC:5 NSVC:6 FRL:4
SGSN
BVCI=3 BVCI=7 NSEI_C
NSVC:7
FRL:5 NSVC group identified by NSEI_D FRL:0 NSVC:0
GPRS Cell BVCI= 3
BVCI=2 BVCI=3 BVCI=4 FRL:1 NSEI_D
GPRS Cell BVCI= 2 GPRS Cell BVCI= 4
BSC:2\PCU:0 NSEI_D
NSVC:1 NSVC:2
Fig. 7.16
Distribution of Packet Switched Data Traffic among Different Cells
146
A30808-X3247-L24-1-7618
7.3.1.1
BVC Procedures
For BVCs associated to PTPPKF objects the following procedures, with remote end, are implemented: BLOCK; UNBLOCK; RESET. The BLOCK Procedure inhibits a BVCI to carry traffic. Its performed when the PTPPKF object is locked by the operator or when it reaches a disable-dependency state. All PDTCHs of the cell are released and system information, reporting GPRS/EGPRS service not allowed in the cell, are sent in BCCH or PBCCH. If, after a Block Procedure attempt, the PCU doesnt receive any answer from the SGSN, it retries the procedure. The waiting time for the block procedure is defined by the T1 parameter: after sending a BVCI block message, the PCU waits T1 seconds for acknowledgement. After NBVCBR consecutive repetitions, without any answer from the SGSN, an O&M alarm is sent. The UNBLOCK Procedure allows the traffic back on the previous blocked BVCI. The PTPPKF is put in enabled state. System information, reporting GPRS/EGPRS service allowed in the cell, are sent in BCCH or PBCCH. If, after an Unblock Procedure attempt, the PCU doesnt receive any answer from the SGSN, it retries the procedure. The waiting time for the unblock procedure is defined by the TF1 parameter: after sending a BVCI unblock message, the PCU waits T1 seconds for acknowledgement. After NBVCUR consecutive repetitions, without any answer from the SGSN, an O&M alarm is sent. The RESET Procedure is used when a new BVCI is set up between the SGSN and the BSS, or after each event (processor restart, failure recovery, etc.) that needs to clear and to synchronize BVCI status on both sides. Both sides must initiate the procedure independently. If, after a Reset Procedure attempt, the PCU doesnt receive any answer from the SGSN, it retries the procedure. The waiting time for the reset procedure is defined by the T2 parameter: after sending a BVCI reset message, the PCU waits T2 seconds for acknowledgement. After NBVCRR consecutive repetitions, without any answer from the SGSN, an O&M alarm is sent.
7.3.2
Quality of Service (QoS)

For an uplink data transfer, the QoS profile is communicated by the MS as a priority information in the PACKET_CHANNEL_REQUEST message. For a downlink data transfer, the BSSGP protocol provides the means to transfer the full QoS profile together with each downlink LLC PDU. In this latter case the following QoS parameters are included in each LLC-PDU transferred to the BSS: precedence class; peak throughput; LLC-PDU lifetime. The PCU, taking into account the available radio resources and the multislot capabilities of the MS, decides if and how the requested QoS may be satisfied. This means that the core algorithm of the PCU would try to satisfy the requested QoS by acting on many factors.
A30808-X3247-L24-1-7618
147
Regarding the QoS, as it has been described in "6.3 Management of Packet Data Channels", the resource allocation algorithm allows to take into consideration the required peak throughput class. No QoS related to BSSGP flow control ("7.3.3 SGSN-BSS Flow Control") is now implemented.
7.3.3
SGSN-BSS Flow Control

The BSSGP flow control mechanism concerns only downlink message transfer. This is due to the fact that the SGSN transmits downlink LLC PDUs but it has no knowledge about the GPRS/EGPRS radio capacity in the BSS. For the uplink transmission this problem does not exist since it is the BSS itself which schedules the MSs accesses, according to its own radio capacity. For packet transfer from the SGSN to the BSS, the BSSGP protocol uses an address which is composed of three parts: cell Identity; QoS prole; MS identication (e.g. TLLI).
The Temporary Logical Link Identity (TLLI) identifies univocally a GPRS/EGPRS user, who is engaged in data transfer, inside a cell (see also "9.8.2.5 Contention Resolution"). These three parts are then used to dynamically queues and contexts in both the SGSN and the BSS. The flow control mechanism is then based on these queues and contexts. The principle of flow control is based on the following: a) in the SGSN, queues are provided per MS. The SGSN sends PDUs to the LLC layer as a function of the requested service type (e.g., PTP or PTM) and the Mobility Management state (see "9.3.1 Mobility Management States"); b) in the BSS, queues per cell (BVCI) and per MS (TLLI) are provided at the BSSGP level; c) signalling has its own queue. The BSS controls the flow of packet data units (PDUs) to its BVC buffer for an individual MS, by indicating to the SGSN the maximum allowed throughput for a certain TLLI. The BSS controls the flow of packet data units to its BVC buffers, by indicating to the SGSN the maximum allowed throughput for each BVC. The amount of buffered packet data units for a given TLLI or BVC has to be optimized to efficiently use the available radio resources. The packet data units have to be transferred across the Um interface before the PDU lifetime expires; in this case the PDU is deleted from the BSS and the deletion is signalled to the SGSN by the LLCDISCARDED PDU message (see Fig. 7.17).
148
A30808-X3247-L24-1-7618
Fig. 7.17
Flow Control Principle
The principle of BSSGP flow control procedure is that the BSS sends to the SGSN flow control parameters which will allow the SGSN to locally control its transmission output in downlink direction. The SGSN performs flow control on each BVC and on each MS. The flow control is performed on each LLC PDU, first by the MS flow control mechanism and then by a BVC flow control mechanism. Based on the flow control parameters sent by the BSS, the SGSN calculates the Estimated Throughput and modifies its downlink transmission within 100 msec. The rate at which the BSS is allowed to send flow control messages for a given BVC or MS is limited and defined by the following rule: the BSS may send a new Flow Control PDU every TF1 seconds, where TF1 is a value which is predefined and common to the BSS and the SGSN. If the BSS detects a missing FLOW-CONTROL-ACK from the SGSN and the condition which causes the sending of a FLOW-CONTROL PDU still remains, the FLOW-CONTROL PDU may be retransmitted immediately. In this case the BSS may violate the repetition rate defined by the TF1 value. In case redundant NSVC links are created on the Gb-interface, the following rule must be obeyed to avoid unnecessary GPRS/EGPRS blocking for certain cells (see "7.2.1.3 Procedures for PVCs"): if NS-ALIVE-ACK is not received because of link problems, the respective NSVC is put into disabled state after a maximum time defined by:
Time_1= TNSVCTST+ TNSVCPTST * NNSVCTSTR
The PTPPKF object is put into disabled state if FLOW-CONTROL-ACK is not received during the time defined by:
A30808-X3247-L24-1-7618
149
Time_2 = TF1* Number of Flow Control Retries
In case of link problems it could therefore happen that the PTPPKF object is disabled while the NSVC is still enabled. To avoid this situation the following rule has to be followed:
Time_2 > Time_1
The default value of "Number of Flow Control Retries" is fixed to the value 15. The rule is therefore fulfilled with the database default values for the following parameters: TNSVCTST; TNSVCPTST; NNSVCTSTR; TF1.
150
A30808-X3247-L24-1-7618
8 Load Control for Packet Switched Services

As it has been described in "5.1.4 PPCU and PPXU Redundancy and Configuration Rules", when the user configures a GPRS/EGPRS cell, i.e. when the user creates a PTPPKF object instance, he does not have to assign the cell to a specific PCU, but it is the system that assigns the cell to one of the PCUs dynamically. This is a direct consequence of the load balancing redundancy. Besides, when one PCU fails (e.g. when a PPXU fails in case of high capacity BSCs, or when couple of PPCUs fail in case of standard BSCs), the system redistributes the PS traffic among the remaining PCUs. In the BSC, there is a load control system that manages the PTPPKFs distribution among the PCUs available in the system. This kind of calculation is established taking into account the number of created and available PCUs, and the number of PTPPKF already associated to each PCU. In case one PCU becomes unavailable for any reason, all PTPPKFs belonging to that PCU are moved to other PCUs; the algorithm shall evaluate new PTPPKFs distribution considering the number of PTPPKF already present on each PCU and the number of resources reserved to packet switched services for each PTPPKF (see "8.1 Dynamic PTPPKF Reconfiguration"). In case one PCU becomes available the first time (i.e. after its creation) a new computation is started in order to distribute PTPPKFs configured in the system on all PCUs. Besides, the PTPPKF distribution process implements a mechanism based on a Guard timer, in order to avoid oscillation in case of fast PCU state changes (see "8.1.5 Time Needed to Execute PTPPKF Reconfiguration").
i 8.1
In order to make possible to move one PTPPKF from one PCU to another one, all PCUs shall contain the same database as far is concerned the PTPPKF configuration.
Dynamic PTPPKF Reconguration

The PTPPKFs distribution/redistribution algorithm is performed by the GPRS/EGPRS load control process implemented on TDPC board. The PTPPKFs reconfiguration is performed in the following cases: when the boards related to the PCU become unavailable; this situation could happen when: a PPXU board fails, in case of high capacity BSCs; a couple of PPCU boards fail (the couple PPCU:0/1 or the PPCU2/3), in case of standard BSC; the PPXU or the couple of PPCUs is locked. the connection of the PCU towards the SGSN falls down, that means that the last NSVC connection from the PCU to the SGSN is no more available; this situation could happen when: the PCMG line containing the last available FRL (if the last available FRL is created on it) is locked or goes down (as a consequence the last NSVC becomes unavailable); the PCMA line containing the last available FRL (if the last available FRL is created on it) is locked or goes down (as a consequence the last NSVC becomes unavailable);
A30808-X3247-L24-1-7618
151
the last FRL is locked or goes down, and as a consequence the last NSVC is disabled; the last NSVC is locked or goes down; the PCU is locked; the connection of the PCU towards the SGSN comes back, that means that the last NSVC connection from the PCU to the SGSN is now available.
In general the PTPPKFs reconfiguration is triggered from all the operations that generate a PCU/Gb down-restart. So the previous causes can be summarized with these sentences: any time the Gb interface related to any PCU is no more available, the reallocation is triggered or when a PCU <<can not see>> the SGSN, the PTPPKF allocated to that PCU should be moved to another PCU that can <<see>> the SGSN.
a PTPPKF is deleted, but only if this operation causes an unbalanced distribution of PTPPKFs among the PCUs.
It must be noted that: 1. the PTPPKF creation is not included as a trigger for PTPPKFs reconguration (when a PTPPKF is created, it is assigned to the less loaded PCU); 2. the PCU creation itself does not trigger the PTPPKFs reconguration, but the reconguration starts when the rst NSVC is created and enabled for this PCU (i.e. when the connection on the Gb interface is available); 3. the PCU overload (see "8.2 PCU Overload Management") does not trigger the PTPPKF reconguration, since also in this case no PCU/Gb down-restart is executed. The system, to handle the distribution/redistribution algorithm make use of the following information: dynamic information: state of PCUs congured in the BSC; state of PTPPKFs congured in the BSC; static information: number of PCUs and PTPPKFs congured in the BSC; total number of radio channels congured for PS services for each PTPPKF (packet control channels + reserved packet channels + dynamic packet channels); Routing Area of the PTPPKF (only at init time); total number of timeslots congured for each PCU on the Gb interface (see "7 Gb Interface"). If we define: PCU_TS_Gb PTPPKF_load(i) Number of timeslots of 64 Kbit/sec related to the FR links associated to a specific PCU Number of GPRS/EGPRS channels (static and dynamic) configured for a specific PTPPKF(i)
Then the load of a single PCU can be considered as the sum of the PTPPKF_load of all the PTPPKF associated to the PCU divided by the PCU_TS_Gb of the PCU (that is how the FR links associated to the PCU can manage all the radio channels associated to the PCU); so:
152
A30808-X3247-L24-1-7618
PCU_load = (Sum PTPPKF_load(i) [i=1..n]) / PCU_TS_Gb where n is the number of PTPPKFs associated to the PCU Then the algorithm tries to distribute the packet switched traffic among the configured and available PCUs, so as all the PCUs have the same PCU_load. Moving one PTPPKF from one PCU to another one causes a release of all the TBFs associated to that PTPPKF. To avoid as much as possible this situation, the set of PTPPKF is divided in 3 sub sets (the three sets are considered by the general algorithm that calculates and moves PTPPKFs from one PCU to another one): PTPPKF_DIED: this set contains PTPPKFs belonging to PCUs without the Gb in service, that have to be moved to PCUs in service; this set is taken into account as soon as the algorithm runs after the PCU/Gb fault; PTPPKF_KO: it includes PTPPKFs that are not doing trafc because they are disabled or have been locked; this set is the first analyzed for a possible moving of PTPPKFs, when a new PCU goes into service. PTPPKF_ENABLE: it includes all the other PTPPKFs, that are considered for a possible moving; this set is the second analyzed for a possible moving of PTPPKFs, when a new PCU goes into service. The set is considered after the previous set (i.e.PTPPKF_KO) has become void. According to different situations, different handling is provided even if the general rule is always to redistribute the traffic in the better way. The following examples are shown: System initialization (Bring-Up and Full Init), see 8.1.1; Creation of a new PCU object (new PPXU board, or new PPCU couple of boards), see 8.1.2; PCU crash (see 8.1.3); PCU comes back in service (see 8.1.4).
8.1.1
System Initialization
When the system is initialized, the BVCI synchronization is performed, between the BSC and the SGSN, using the BVC RESET procedure (see "7.3.1.1 BVC Procedures"). Then the distribution algorithm (see Fig. 8.1) distributes the configured PTPPKFs among the configured and available PCUs; the algorithm takes into account, besides the PCU loads, also the Routing Area of the PTPPKFs (regarding routing areas, see "9.2 Network Structure").
The algorithm considers the Routing Areas only at init time. In fact, to reduce the paging load, (if the SGSN is cleaver enough) the algorithm tries, if possible, to associate a Routing area to just one PCU. These constraints could collide with the balancing of the PCU loads. In this case the constraint related to the loads of the PCUs has an higher priority.
A30808-X3247-L24-1-7618
153
PCU:0 NSEI:0 PCU_load=9/3=3
PTPPKF RA=2 1 PDCH BVC=4
PCU_TS_Gb= 3
SGSN
PTPPKF RA=3 1 PDCH BVC=77 PTPPKF RA=5 2 PDCH BVC=35
PCU_TS_Gb= 1
Fig. 8.1
Example of PTPPKF Distribution During System Initialization
8.1.2
Creation of a PCU Object and Enabling a NSVC for It

When a new PCU is created and the first NSVC is created and enabled, the algorithm redistributes the already configured PTPPKFs among the available PCUs, taking into account the new one. On the Gb interface, the BVC BLOCK procedure (see 7.3.1.1) is performed on the PTPPKFs to be moved, before moving them (see Fig. 8.2). Then, when the cells are shifted to the new PCU, the BVC RESET and UNBLOCK procedures (see 7.3.1.1) are performed for the same cells (see Fig. 8.3). In Siemens-BSS implementation both the Cell Identifier and the BVCI of the moved cells do not change.
154
A30808-X3247-L24-1-7618
PCU:0 NSEI:0 old_PCU_load=9/3=3 new_PCU_load=6/3=2
BSSGP:BVC_BLOCK_34 PTPPKF RA=1 3 PDCH BVC=23 BSSGP:BVC_BLOCK_ACK_34
PCU_TS_Gb= 3
PCU_TS_Gb= 2
SGSN
New PCU is created
BSSGP:BVC_BLOCK_77 BSSGP:BVC_BLOCK_ACK_77 PCU_TS_Gb= 1
Fig. 8.2
Example of PTPPKF Distribution when a New PCU is Created - Step 1
A30808-X3247-L24-1-7618
155
PCU_TS_Gb= 3
BSSGP:BVC_RESET_34:Cell Identifier PTPPKF RA=1 3 PDCH BVC=34 BSSGP:BVC_RESET_ACK_34 BSSGP:BVC_UNBLOCK_34 BSSGP:BVC_UNBLOCK_ACK_34
SGSN
PCU_TS_Gb= 2 BSSGP:BVC_RESET_77:Cell Identifier BSSGP:BVC_RESET_ACK_77 BSSGP:BVC_UNBLOCK_77 BSSGP:BVC_UNBLOCK_ACK_77
PCU_TS_Gb= 1 PTPPKF RA=5 2 PDCH BVC=35
Fig. 8.3
Example of PTPPKF Distribution when a New PCU is Created - Step 2
156
A30808-X3247-L24-1-7618
8.1.3
PCU Crash
When a PCU crashes, the algorithm redistributes the configured PTPPKFs among the remaining PCUs. Since the PCU is crashed, it is not possible to perform the BVC BLOCK procedure on the damaged PCU (in any case the SGSN can detects this anomaly because the L2 layer is not working anymore). The PTPPKFs are moved on healthy PCUs, and then a BVC RESET procedure is started for each shifted PTPPKF object (see Fig. 8.4). The routing area information is not considered by the algorithm, to save the time of the elaboration.
BSSGP:BVC_RESET_34:Cell Identifier BSSGP:BVC_RESET_ACK_34 PCU_TS_Gb= 3 BSSGP:BVC_UNBLOCK_34 BSSGP:BVC_UNBLOCK_ACK_34
PCU:2 NSEI:2 FAILED
NO block procedures on Gb interface. The PCU fails suddenly PCU_TS_Gb= 2
SGSN
BSSGP:BVC_RESET_77:Cell Identifier PTPPKF RA=3 1 PDCH BVC=77 PTPPKF RA=5 2 PDCH BVC=35 BSSGP:BVC_RESET_ACK_77 PCU_TS_Gb= 1 BSSGP:BVC_UNBLOCK_77 BSSGP:BVC_UNBLOCK_ACK_77
Fig. 8.4
Example of PTPPKF Distribution in Case of PCU Crash
A30808-X3247-L24-1-7618
157
8.1.4
PCU Comes Back in Service

When the PCU comes back in service, the PTPPKFs related to this PCU, before the fault, are put back on it (see Fig. 8.5). This process is not considered as a PTPPKF reconfiguration, in fact in order to minimize the TBFs release, the reallocation algorithm is not performed when a PCU comes back in service after a fault, but the PTPPKFs belonged to this PCU will be put back on it. Eventually, also the PTPPKFs belonged to other faulty PCUs will be involved in this reallocation procedure. There are two exceptions for this case: 1. if a PCU comes back in service, but before another PCU has come in service for the first time (i.e. it was created), then the algorithm performs a total reconfiguration; 2. if some modications regarding the FRLs allocation of the PCU has been done during the period of time the PCU/Gb was down, then the algorithm performs a total reconfiguration. In fact there is a difference between putting back PTPPKFs to the PCU they belonged before and a total redistribution itself. In the first case the previously moved cells are returned back without a new load calculation; the reason for not doing in this case a new recalculation is simply due to the need of managing short downs of Gb or PCU: it makes no sense to redistribute everything again and again simply because, for example, a PCM line (containing the last FRL of a PCU) is not stable.
158
A30808-X3247-L24-1-7618
BSSGP:BVC_BLOCK_34 PTPPKF RA=1 3 PDCH BVC=23 BSSGP:BVC_BLOCK_ACK_34
PCU_TS_Gb= 3
PCU:2 NSEI:2 IN-SERVICE
BSSGP:BVC_RESET_34:Cell Identifier PTPPKF RA=1 3 PDCH BVC=34 BSSGP:BVC_RESET_ACK_34 BSSGP:BVC_UNBLOCK_34 BSSGP:BVC_UNBLOCK_ACK_34
SGSN
PCU_TS_Gb= 2 BSSGP:BVC_RESET_77:Cell Identifier BSSGP:BVC_RESET_ACK_77 BSSGP:BVC_UNBLOCK_77 BSSGP:BVC_UNBLOCK_ACK_77
BSSGP:BVC_BLOCK_77 BSSGP:BVC_BLOCK_ACK_77
Fig. 8.5
Example of PTPPKF Distribution when a PCU Comes Back in Service
A30808-X3247-L24-1-7618
159
8.1.5
Time Needed to Execute PTPPKF Reconfiguration

For what concern the PTPPKFs distribution/redistribution algorithm, to avoid oscillation in case of fast PCU changes, a mechanism based on a Guard Timer is provided. This timer lasts 5 seconds and it starts each time there is a modification in Gb/PCU status. When the timer runs no calculations are executed to redistribute GPRS/EGPRS cells (even if there are some changes in Gb/PCU status). Obviously, this timer does not regard new created PTPPKFs, because in this case there is not a balancing procedure, but the created PTPPKF is simply put on the less loaded PCU available in that moment. In any case, the calculation algorithm is always executed in few milliseconds, apart some calculations taking into account routing area considerations. Calculations taking into account routing area considerations lasts some tens of milliseconds, so they cannot be done during normal TDPC working. Thus they are done only at init phase (see "8.1.1 System Initialization"). The redistribution procedure takes, in general, some seconds. The worst case concerns the moving of a PTPPKF from one PCU to another one: the PTPPKF needs to be blocked and internally deleted on the old PCU, then created and unblocked on the new one. This process takes about 7 seconds in total. This time, added to the 5 seconds of the guard timer, makes a total of 12 seconds, that are needed to redistributes PTPPKFs to a PCU going into service. This time is more or less independent from the number of involved PTPPKFs, being done in burst parallel on the various PTPPKFs. Besides, there are also no significative differences between PPCU and PPXU boards handling.
8.2
PCU Overload Management

For what concern the PTPPKFs distribution/redistribution algorithm, no reconfiguration is foreseen due to Overload reasons, since as it has been described in 8.1, the only triggers are Down/Restart of PCU/Gb. Overload prevention mechanism present since old releases is based on the real time of the card, and it is described here below. PCU overload management alarm is started when PCU processor real time exceeds a threshold. The operating system measures the PCU processor real time. A PCU cyclic task checks whether the percentage of the real time is greater than an upper, not configurable, threshold; if this is true, the cyclic task sends a message, indicating that the machine is overloaded, to the GPRS/EGPRS overload handler process. The cyclic task stops the overload message sending to the GPRS/EGPRS overload handler when the percentage of the real time is smaller than a lower, not configurable, threshold. The GPRS/EGPRS overload handler acts structurally as the already existing BSC and BTS overload ones. At the very first signal of PCU Overload, an alarm is emitted towards LMT/RC. The overload process is controlled by BSCT17 and BSCT18 timers and it is based upon the progressive application of protection actions, if the overload situation persists. If the overload situation disappears these protection actions are progressively removed. The protection action, used by GPRS/EGPRS overload handler to reduce the PS service traffic, is based upon the sending of System Information indicating that
160
A30808-X3247-L24-1-7618
GPRS/EGPRS services are not present in the cell. This is done for a progressively increasing number of cells (at steps of 10 cells) allocated on the involved PCU, if the overload situation persists. On the contrary, if the overload finishes, System Information indicating that GPRS/EGPRS service are present again are sent; this is done in step of 5 cells that were formerly "GPRS/EGPRS barred". When all the cell are in the original situation, the PCU overload alarm is ceased.
A30808-X3247-L24-1-7618
161
9 GPRS/EGPRS Procedures
9.1 Mobile Stations for Packet Switched Services
A GPRS/EGPRS MS can operate in one of three modes of operation. The mode of operation depends on: the services that the MS is attached to, i.e., only PS services or both PS and CS services; the MS's capabilities to operate GPRS/EGPRS and other GSM services simultaneously. The three modes of operation are: Class-A mode of operation: the MS is attached to both GPRS/EGPRS and other GSM services, and the MS supports simultaneous operation of GPRS/EGPRS and other GSM services; Class-B mode of operation: the MS is attached to both GPRS/EGPRS and other GSM services, but the MS can only operate one set of services at a time. In network operation mode III (see "9.8.3.1 Network Operation Modes for Paging"), a MS that is capable of monitoring only one paging channel at a time cannot operate in class B mode of operation. In this case, such a MS shall revert to class-C mode of operation. Class-C mode of operation: the MS is exclusively attached to GPRS/EGPRS services. Besides, for what concerns EGPRS mobiles only, a supplementary distinction exists. Two mobile classes are foreseen: the rst class of mobiles, which allows a cost efcient and fast implementation, supports the 8PSK modulation in downlink direction and the GMSK modulation in uplink direction; the second class of mobiles has more advanced capability, supporting the 8PSK modulation in both uplink and downlink directions.
9.2
Network Structure
On the air interface the network organization structure remains the same as in the GSM implementation. An additional identifier is introduced to group cells that support packet switched services in the Location Area (LA). This identifier is named Routing Area (RA) and it is a sub entity of the Location Area. The Routing Area is a more precise description of the current position of the GPRS/EGPRS mobile station; one LA can include up to 256 RAs. Routing Area numbering is not unique in the network, but it is unique in the Location Area domain; to identify a Routing Area two parameters have been introduced: the Routing Area Code (RACODE): it identies univocally the routing area inside the location area; the Routing Area Color (RACOL): it allows the Mobile Station to distinguish between two routing areas that have the same Routing Area Code, but belong to two different Location Areas. Fig. 9.1 shows an example of network structure.
162
A30808-X3247-L24-1-7618
Location Area
Routing Area
Fig. 9.1
Network Structure: Example
9.3
9.3.1
Mobility Management Functionalities

Mobility Management States
The Mobility Management (MM) activities related to a GPRS/EGPRS subscriber are characterized by one of three different MM states (see Fig. 9.2). Each state describes a certain level of functionality and allocated information. The information, which is held at both MS and SGSN sides, is denoted MM context.
A30808-X3247-L24-1-7618
163
Fig. 9.2
Mobility Management States
9.3.1.1
IDLE State
In GPRS IDLE state the subscriber is not attached to the GPRS/EGPRS mobility management. Both the MS and the SGSN contexts hold no valid location or routing information for the subscriber. The subscriber-related mobility management procedures are not performed. PLMN selection and GPRS/EGPRS cell selection and re-selection processes (see 10.1) are performed by the MS. In order to establish MM contexts in the MS and in the SGSN, the MS shall perform the GPRS Attach procedure (see "9.3.2.1 Attach Function"). When the GPRS attach procedure has been executed, the MM state moves from IDLE to READY: the MS requests access and a logical link to an SGSN is established.
9.3.1.2
STAND-BY State
In STANDBY state the subscriber is attached to GPRS/EGPRS mobility management. The MS and the SGSN have established MM contexts for the subscriber. Pages for PTP data transfers or signalling information transfers may be received. It is also possible to receive pages for CS services via the SGSN (only if the Gs interface between the MSC and the SGSN is implemented). PTP data reception and transmission is not possible in stand-by state. The MS performs Routing Area updates and GPRS/EGPRS cell selection and re-selection locally. The MS executes mobility management procedures to inform the SGSN when it has entered a new RA. The MS does not inform the SGSN on a change of cell
164
A30808-X3247-L24-1-7618
in the same RA. Therefore, for MSs in STANDBY state, the location information in the SGSN MM context contains only the routing area identity (RAI).
The Routing Area Identity is defined as: RAI = MCC + MNC + LAC + RAC where: - MCC = mobile country code; - MNC = mobile network code; - LAC = location area code; - RAC = routing area code. The MS may initiate activation or deactivation of PDP contexts while it is in STANDBY state. A PDP context shall be activated before data can be transmitted or received for this PDP context. The SGSN may have to send data or signalling information to a MS in STANDBY state; in this case the SGSN sends a Paging Request in the routing area where the MS is located. The MM state in the MS changes to READY when the MS responds to the page, and in the SGSN when the response to paging is received. Also, the MM state in the MS changes to READY when data or signalling information is sent from the MS and, accordingly, the MM state in the SGSN changes to READY when data or signalling information is received from the MS. The MS or the network may initiate the GPRS Detach procedure to move to the IDLE state. After expiry of the mobile reachable timer, the SGSN may perform an implicit detach in order to return the MM contexts in the SGSN to IDLE state. The MM and PDP contexts may then be deleted. In particular, the following procedures cause the transition from the standby state to the other MM states: moving from STANDBY to IDLE: Implicit Detach: the MM and PDP contexts in the SGSN return to IDLE and INACTIVE state; Cancel Location: the SGSN receives a Cancel Location message from the HLR, and removes the MM and PDP contexts; moving from STANDBY to READY: PDU transmission: the MS sends a LLC PDU to the SGSN, possibly in response to a page; PDU reception: the SGSN receives a LLC PDU from the MS.
9.3.1.3
READY State
In READY state the MM context corresponds to the STANDBY MM context extended by location information for the subscriber on cell level. The MS performs mobility management procedures to provide the network with the actual selected cell. GPRS/EGPRS cell selection and re-selection is done locally by the MS, or may optionally be controlled by the network (see "10.3 Network Controlled Cell Reselection and Traffic Control Management"). The MS may send and receive PDP PDUs in this state. The network doesnt initiate PS pages for a MS in READY state; pages for other services may be done via the SGSN. The MS may activate or deactivate PDP contexts while in READY state. The READY state is supervised by a timer. A MM context moves from READY state to STANDBY state when the READY timer expires.
A30808-X3247-L24-1-7618
165
In order to move from READY state to IDLE state, the MS initiates the GPRS Detach procedure. In particular, the following procedures cause the transition from the ready state to the other MM states: moving from READY to STANDBY: READY timer expiry (see " READY TIMER"): the MS and the SGSN MM contexts return to STANDBY state; Force to STANDBY: the SGSN indicates an immediate return to STANDBY state before the READY timer expires; abnormal RLC condition: the SGSN MM context returns to STANDBY state in case of delivery problems on the radio interface; moving from READY to IDLE: GPRS Detach: the MS or the network request that the MM contexts return to IDLE state and that the PDP contexts return to INACTIVE state. The SGSN may delete the MM and PDP contexts. The PDP contexts in the GGSN is deleted. Cancel Location: the SGSN receives a Cancel Location message from the HLR, and removes the MM and PDP contexts. READY TIMER The READY timer controls the time a MS remains in READY state before going to the STANDY state. In the MS the READY timer is reset and begins running when a LLC PDU is transmitted; in the SGSN the timer begins running when a LLC PDU is correctly received. When the READY timer expires, both the MS and SGSN MM contexts return to STANDBY state. The length of the READY timer shall be the same in the MS and in the SGSN. If the READY timer length is set to zero, the MS is immediately forced into STANDBY state.
9.3.2
Mobility Management Procedures

MM procedures use the LLC and RLC/MAC protocols for message transmission across the Um interface. The MM procedures provide information to the underlying layers to enable reliable transmission of MM messages on the Um interface. User data can in general be transmitted during MM signalling procedures. User data transmitted during attach, authentication, and routing area update procedures may be lost and may therefore have to be retransmitted. In order to minimize the need for retransmission, the MS and the SGSN dont transmit user data during the attach, authentication, and routing area update procedures.
9.3.2.1
Attach Function
The GPRS(EGPRS) attach procedure is executed by the MS. In the attach procedure, the MS provides its identity and an indication of which type of attach it wants to execute. Two different types of attach are foreseen (both of them executed towards the SGSN): the GPRS attach; the combined GPRS/IMSI attach. The combined attach allows the MS to register itself both in the SGSN and in the MSC, but this procedure can be executed only when the network works in a co-ordinate way,
166
A30808-X3247-L24-1-7618
i.e. only when the Gs interface between the MSC and the SGSN is configured (see also "9.8.3.1 Network Operation Modes for Paging").
If the network operates in mode I (see "9.8.3.1 Network Operation Modes for Paging"), then a MS that is both GPRS/EGPRS-attached and IMSI-attached performs the combined RA/LA update procedure. If the network operates in mode II or III, then a GPRS/EGPRS-attached MS, that has the capability to be simultaneously GPRS/EGPRS attached and IMSI-attached, performs the (not-combined) Routing Area Update procedure, and it accesses the CCCH channel for CS operation. After having executed the GPRS attach procedure, the MS is in READY state and MM contexts are established in both the MS and the SGSN. The MS may then activate PDP contexts as described in "9.7 Activation and Deactivation of a PDP Context". An IMSI-attached MS that can only operate in class-C mode of operation shall follow the normal IMSI detach procedure before making a GPRS attach. A GPRS-attached MS in class-C mode of operation shall always perform a GPRS detach before making an IMSI attach. The steps of the Attach procedure are illustrated in the following list: 1. the MS initiates the attach procedure by the transmission of the Attach Request message to the SGSN. The message contains the following information: IMSI or P-TMSI: IMSI is included if the MS does not have a valid P-TMSI. If the MS has a valid P-TMSI, then P-TMSI and the old RAI associated with P-TMSI are included; Classmark: it contains the MS's multislot capabilities and supported ciphering algorithms for PS services; Attach Type: it indicates which type of attach that has to be performed, i.e., GPRS/EGPRS attach only, GPRS/EGPRS Attach while already IMSI attached, or combined (E)GPRS/IMSI attach; DRX Parameters: indicate when the MS is in a non-sleep mode and when it is able to receive paging requests and channel assignments (see "9.8.3.2 Discontinuous Reception"). 2. the SGSN sends the Attach Accept message to the MS; P-TMSI is included if the SGSN allocates a new P-TMSI; 3. if P-TMSI has been changed, the MS acknowledges the received P-TMSI by the Attach Complete message.
P-TMSI (packet temporary mobile subscriber identity) is optionally sent by the SGSN to the MS in Attach Accept and Routing Area Update Accept messages. If the P-TMSI signature has been sent by the SGSN to the MS because a new P-TMSI has been allocated by the SGSN, then the MS includes the received P-TMSI signature in the next Routing Area Update Request or in the next Attach Request for identification checking purposes. In both the Attach and Routing Area Update procedures, the SGSN compares the P-TMSI signature sent by the MS with the signature stored in the SGSN. If the values do not match, the SGSN should use the security functions to authenticate the MS. The P-TMSI signature parameter has only local significance in the SGSN that allocated the signature. P-TMSI is the analogous of the GSM T-IMSI (temporary IMSI). If the Attach Request cannot be accepted, the SGSN returns the Attach Reject message to the MS. The message contains the cause the has generated the rejection.
A30808-X3247-L24-1-7618
167
A GPRS/EGPRS-attached MS makes IMSI attach via the SGSN with the combined RA/LA update procedure if the network operation mode is I. In network operation modes II and III, or if the MS is not GPRS/EGPRS-attached, the MS makes IMSI attach as already defined in GSM.
9.3.2.2
Detach Function
The Detach function allows a MS to inform the network that it wants to make a GPRS/EGPRS and/or IMSI detach, and it allows the network to inform a MS that it has been GPRS/EGPRS-detached or IMSI-detached by the network. A GPRS/EGPRS-attached MS sends a Detach Request message to the SGSN, indicating a GPRS/EGPRS detach. In the Detach Request message there is an indication to tell if the detach is due to switch off or not. The indication is needed to know whether a Detach Accept message shall be returned or not.
9.4
Radio Resource Management

Radio Resource (RR) management procedures are characterized by two different RR operating modes (see Fig. 9.3). Each mode describes a certain amount of functionalities and information allocated.
Packet Idle State
- No RLC context in MS & SGSN
- Mobile originated call - Answer to paging
- Deactivation of RLC context
Packet Transfer State
- RLC context in MS & SGSN - Routing context between MS & SGSN
Fig. 9.3
Radio Resource States
9.4.1
Packet Idle State

In packet idle mode no Temporary Block Flows exist (see "4.3 Temporary Block Flow"). Upper layers can require the transfer of LLC PDUs which, implicitly, may trigger the establishment of a TBF and the transition to packet transfer mode (see Fig. 9.3). In packet idle mode the MS listens to the PBCCH and to the paging sub-channel for the paging group the MS belongs to. If PCCCH is not present in the cell, the mobile station listens to the BCCH and to the relevant paging sub-channels.
168
A30808-X3247-L24-1-7618
9.4.2
Packet Transfer State

In packet transfer mode, the mobile station uses the allocated radio resources to transmit radio blocks. Continuous transfer of one or more LLC PDUs is possible. Concurrent TBFs may be established in opposite directions. Transfer of LLC PDUs in either RLC acknowledged or RLC unacknowledged mode is provided. When selecting a new cell, a mobile station: 1. 2. 3. 4. 5. leaves the packet transfer mode; enters the packet idle mode; switches to the new cell; reads the system information of the new cell; resumes the packet transfer mode in the new cell.
While operating in packet transfer mode, a mobile station belonging to GPRS/EGPRS class A may simultaneously enter the CS dedicated (connected) mode. A mobile station belonging to GPRS/EGPRS class B leaves the packet transfer modes before entering the CS dedicated mode.
9.5
Correspondence between RR States and MM States

Tab. 9.1 provides the correspondence between Radio Resource states and Mobility Management states. MM States RR States Packet Transfer state READY Packet Idle state STAND-BY Packet Idle state
Tab. 9.1
Correspondence between MM States and RR States
9.6
Packet Data Protocol Functionalities

The subscription of a point to point PS service contains one or more PDP addresses. Each PDP address is described by an individual PDP context in the MS, in the SGSN, and in the GGSN. Every PDP context exists independently in one of two PDP states. The PDP state indicates whether the PDP address is activated for data transfer or not. Activation and deactivation procedures are described in 9.7. All PDP contexts of a subscriber are associated with the same MM context for the IMSI of that subscriber.
A30808-X3247-L24-1-7618
169
Fig. 9.4
Packet Data Protocol States
9.6.1
INACTIVE State
The INACTIVE state characterizes the data service for a certain PDP address of the subscriber as not activated. The PDP context contains no routing or mapping information to process PDUs related to that PDP address. No data can be transferred. A changing location of a subscriber causes no update for the PDP context in INACTIVE state even if the subscriber is attached to the PS MM. If the GGSN is allowed to initiate the activation of the PDP context for that PDP address, mobile-terminated PTP packets, received in INACTIVE state by the GGSN, may initiate the Network-Requested PDP Context Activation procedure. Otherwise, mobile-terminated PTP packets received in INACTIVE state invoke error procedures in the GGSN (for instance an IP packet is discarded). Other error procedures may be introduced on the application level, but this is outside the scope of the present document. The MS initiates the transition from the INACTIVE state to the ACTIVE state by initiating the PDP Context Activation procedure (see "9.7.1 PDP Context Activation").
9.6.2
ACTIVE State
In ACTIVE state, the PDP context for a specific PDP address is activated in the MS, in the SGSN and in the GGSN. The PDP context contains mapping and routing information for transferring PDUs (for that particular PDP address) between the MS and the GGSN. The ACTIVE PDP state is permitted only when the mobility management state of the subscriber is STANDBY or READY.
170
A30808-X3247-L24-1-7618
An active PDP context for a MS is moved to the INACTIVE state when the deactivation procedure is initiated. All active PDP contexts for a MS are moved to the INACTIVE state when the MM state changes to IDLE.
9.7
Activation and Deactivation of a PDP Context

These functions are only meaningful at the NSS level and in the MS, and do not directly involve the BSS. A MS in STANDBY or READY state can initiate these functions at any time to activate or deactivate a PDP context in the MS, in the SGSN, and in the GGSN. Upon receiving an Activate PDP Context Request message, the SGSN initiates procedures to set up PDP contexts. Upon receiving a Deactivate PDP Context Request message, the SGSN initiates procedures to deactivate PDP contexts.
9.7.1
PDP Context Activation

The PDP context activation procedure is used by the mobile station to obtain an IP address from the network, and to negotiate service parameters such as delay class (average and peak) and throughput (average and peak). Currently the network foresees the best effort quality of service only, giving to the MS the available resources, without taking into account any mobile request. In the following, the PDP Context Activation procedure is described: 1. in order to activate a PDP context the mobile station sends a CHANNEL REQUEST message to the network. The network, after having reserved a channel on the BTS, sends an IMMEDIATE ASSIGNMENT message carrying the PACKET UPLINK ASSIGNMENT information element. This message reserves an uplink resource (a time slot, with TFI and USF) to the mobile station, allowing it to transmit the ACTIVATE PDP CONTEXT REQUEST; 2. the MS sends the ACTIVATE PDP CONTEXT REQUEST message to the SGSN. The following main information are contained in the message: PDP Address: it is used by the MS to indicate whether it requires the use of a static PDP address or whether it requires the use of a dynamic PDP address; the MS shall leave PDP Address empty to request a dynamic PDP address; Access Point Name: it is a logical name referring to the external packet data network that the subscriber wishes to connect to; QoS: indicates the desired QoS prole; 3. security functions are executed by the SGSN; 4. the SGSN validates the ACTIVATE PDP CONTEXT REQUEST using PDP Type, PDP Address, and Access Point Name provided by the MS and the PDP context subscription records; 5. the SGSN sends a CREATE PDP CONTEXT REQUEST (PDP Type, PDP Address, Access Point Name, Negotiated QoS) message to the affected GGSN; 6. the GGSN uses the Access Point Name to nd an external network. The GGSN creates a new entry in its PDP context table and generates a Charging Id. The new entry allows the GGSN to route PDP PDUs between the SGSN and the external PDP network, and to start charging; 7. the GGSN then returns a CREATE PDP CONTEXT RESPONSE message to the SGSN. PDP Address is included if the GGSN has allocated a PDP address;
A30808-X3247-L24-1-7618
171
8. the SGSN selects the Radio Priority based on the Negotiated QoS, and returns the ACTIVATE PDP CONTEXT ACCEPT message to the MS.
The RLC/MAC layer supports four Radio Priority levels and an additional level for signalling messages as defined in GSM 04.60. Upon uplink access the MS can indicate one of the four priority levels, and whether the cause for the uplink access is user data or signalling message transmission. This information is used by the BSS to determine the radio access precedence (i.e. access priority) and the service precedence (i.e. transfer priority under congested situation). The Radio Priority concept is related to the QoS one, i.e. an higher Quality of Service corresponds to an higher Radio Priority. The Radio Priority is coded as follow: - 0: Radio Priority 1 (Highest priority, used also for signalling); - 1: Radio Priority 2; - 2: Radio Priority 3; - 3: Radio Priority 4 (Lower priority).
9.7.2
PDP Context Deactivation

The PDP Context Deactivation procedure is executed with the following steps: 1. the MS sends a DEACTIVATE PDP CONTEXT REQUEST message to the SGSN; 2. security functions are executed by the SGSN; 3. the SGSN sends a DELETE PDP CONTEXT REQUEST message to the GGSN. The GGSN removes the PDP context and returns a DELETE PDP CONTEXT RESPONSE message to the SGSN. If the MS was using a dynamic PDP address, then the GGSN releases this PDP address and makes it available for subsequent activations by other MSs; 4. the SGSN returns a DEACTIVATE PDP CONTEXT ACCEPT message to the MS.
i 9.8
At GPRS/EGPRS detach, all PDP contexts for the MS are implicitly deactivated.
Access to the Network (Establishment of a TBF)

The establishment of a Temporary Block Flow (TBF) is initiated to transfer LLC PDUs between the network and the MS. The request for establishment of a TBF can be done: on CCCH if the PBCCH/PCCCH is not congured in the cell; on PCCCH if the PBCCH/PCCCH is allocated in the cell. Two types of establishment exists: TBF establishment initiated by the MS, i.e. a MS initiated packet transfer (see 9.8.2); TBF establishment initiated by the network, i.e. a network initiated packet transfer (see 9.8.3).
9.8.1
Medium Access Modes

Two types of access modes exist: a) Dynamic Allocation: the assignment message includes the list of PDCHs and the corresponding USF value for each assigned PDCH. A unique TFI is allocated and is thereafter included in each RLC Data and Control Block related to that TBF. Dynamic allocation is characterized by that the MS monitors the USF values on the allocated PDCHs and transmits Radio blocks on those which currently bear the USF value reserved for the usage of the MS;
172
A30808-X3247-L24-1-7618
b) Fixed Allocation: it is characterized by xed allocation of radio blocks and PDCHs in the assignment message, without assigning USF values. In BR7.0 release Fixed Allocation is not supported.
9.8.2
TBF Establishment Initiated by the MS on CCCH/PCCCH

The purpose of the packet access procedure is to establish a TBF to support the transfer of LLC PDUs in the direction from the mobile station to the network. Packet access is done on PCCCH if it exists, otherwise packet access is done on CCCH.
In the following, messages that are exchanged either on CCCH or PCCCH channel are shown, using the following method: messages exchanged on CCCH are normally used, whereas the corresponding PCCCH messages are inserted in brackets. The packet access procedure is initiated by the mobile station when a request to transfer LLC PDUs comes from upper layers. Two different access types are foreseen: one phase access: the network responds reserving resources on PDCH(s) to allow uplink packet transfer of a number of Radio Blocks; two phases access: the network responds reserving resources for transmitting a PACKET RESOURCE REQUEST message; this message is used by the MS to better define the needed radio resources. In both cases, when the uplink TBF is set up, the following parameters and radio resources are allocated to the MS (with the assignment message): USF; TFI; Time Slot numbers; Channel Coding Scheme ARFCN; optionally the Timing Advance parameters (TAI and Timeslot number); if the timing advance index (TAI) is included in the uplink assignment construction, the mobile station shall use the continuous update timing advance mechanism, using PTCCH in the same timeslot as the assigned PDCH (see 4.6). If a timing advance index (TAI) eld is not included, the continuous update timing advance mechanism shall not be used; MAC access mode (always set to dynamic in BR7.0, see "9.8.1 Medium Access Modes"). In addition, the EGPRS uplink assignment contains also these information: the EGPRS modulation and coding scheme; the EGPRS window size; information whether retransmitted uplink data blocks must be resegmented or not. When a MS tries to access to the network, the GPATH parameter indicates if the MS, according to its priority class, is authorized to do a random access to request packet switched services.
9.8.2.1
8 Bits or 11 Bits Uplink Access

To access the GSM network a slotted-aloha protocol is used; the access is performed sending a traditional 8 bits Access Burst type.
A30808-X3247-L24-1-7618
173
According to ETSI specifications a new enhanced Access Burst type with 11 information bits can be sent by the mobile station to try to access the network. In fact 8 bits of information do not allow to widely specify the needed resources. Then to overcome this bottleneck an access burst using 11 information bits is defined. Fig. 9.5 shows the coding process of the 11 bits access burst. So, a GPRS/EGPRS mobile station can access the network by using a 8 bits or an 11 bits access burst, in particular: the CHANNEL REQUEST message sent on RACH is always formatted with 8 bits of information; the PACKET CHANNEL REQUEST sent on PRACH can be formatted either with 8 or 11 bits. The possibility to use one message type or the other one for the PACKET CHANNEL REQUEST depends on network settings: the capability of the network to receive 8 or 11 bits length message is broadcast by the System Information parameter ABUTYP, that indicates the allowed kind of access. The ABUTYP parameter setting indicates also which kind of access burst (8 or 11 bits) has to be sent: for PACKET CONTROL ACKNOWLEDGMENT messages, that are formatted as four access burst; in the PTCCH channel, for the continuous timing advance estimation (see 4.6).
Besides, the 11 bit access burst is the only one supporting the EGPRS PACKET CHANNEL REQUEST message, that can be used from EDGE mobile stations to access a cell, see "9.8.2.4 TBF Establishment for EDGE Mobile Stations". The advantages of the 11 bits uplink access are the following: it allows more often a one phase access instead of a two phases access; it speeds up the call set-up and decreases the signalling load. The 8 bit access on PRACH or RACH is used in case of PAGING RESPONSE, CELL UPDATE, MM PROCEDUREs and in all cases that the MS requires to send no more information than the MS class and priority. The 11 bits access on PRACH is used in all cases described for 8 bits access, but with additional information to be carried in the access phase, e.g. an enhanced random reference number, leading to less probability of MS collision, when trying to establish an uplink TBF. 11 information bit + 6 parity bit + 4 tail bits
1/2 Convolutional coder
6 bit puncturing
36 encrypted bit
Access Burst Tail Synchronization Sequence Information bit 36 bit Fig. 9.5 Coding of the 11 Bit Access Burst Tail
Guard period
174
A30808-X3247-L24-1-7618
9.8.2.2
Establishment using a One Phase Access

A mobile station initiates the packet access procedure by scheduling the sending of CHANNEL REQUEST (PACKET CHANNEL REQUEST) messages on the RACH (PRACH), and simultaneously leaving the packet idle mode.
The topics described in this chapter are valid for GPRS MSs and also for EDGE MSs when the EGPRS PACKET CHANNEL REQUEST is not supported in the cell (see "9.8.2.4 TBF Establishment for EDGE Mobile Stations"). Then the mobile station monitors the full CCCH (PCCCH) corresponding to its RACH (PRACH) to wait for the network answer.
If the PCCCH is configured, when the mobile station receives from the network the PERSISTENCE_LEVEL parameter, the value of the PERSISTENCE_LEVEL parameter shall be taken into account at the next following PACKET CHANNEL REQUEST attempt (see "9.8.2.6 Uplink Access on PRACH (Access Persistence Control)"). When the MS has sent the CHANNEL REQUEST (PACKET CHANNEL REQUEST) message the following behaviors are foreseen, according the its class: a mobile station in class A or class B mode of operation shall respond to a paging message indicating a circuit switched connection establishment; a mobile station in class B mode of operation may abort the packet access procedure, if it receive a paging message indicating the establishment of circuit switched connections; mobile stations in class C mode of operation shall not respond to any type of paging messages during the packet access procedure. CHANNEL REQUEST (PACKET CHANNEL REQUEST) messages are sent on RACH (PRACH) and contain, beside the indication of the type of access, the required parameters to indicate the MSs demand of radio resources. When the network receives the CHANNEL REQUEST (PACKET CHANNEL REQUEST) message, it may assign radio resources on one or more PDCHs, to be used by the mobile station for the TBF. The allocated PDTCH(s) and PACCH resources are assigned to the mobile station in the IMMEDIATE ASSIGNMENT (PACKET UPLINK ASSIGNMENT) message, sent on any AGCH (PAGCH) block on the same CCCH (PCCCH) on which the network has received the CHANNEL REQUEST (PACKET CHANNEL REQUEST) message. In the one phase access, the reservation is done accordingly to the information about the requested resources, that is comprised in the channel request. On RACH, in the CHANNEL REQUEST message, there are only 8 bits of information, so there are only two available values for denoting PS calls; these values can be used to request limited resources in the one phase access (EGPRS TBFs cannot be opened using a one phase access on RACH, using the CHANNEL REQUEST message, see "9.8.2.4 TBF Establishment for EDGE Mobile Stations") or to request a two phases access. On PRACH, the PACKET CHANNEL REQUEST may contain more adequate information about the requested resources and, consequently, uplink resources on one or several PDCHs can be assigned by using the PACKET UPLINK ASSIGNMENT message. Fig. 9.6 shown a one phase access procedure on PCCCH.
A30808-X3247-L24-1-7618
175
Fig. 9.6
One Phase Access on PCCCH
9.8.2.3
TBF Establishment using a Two Phases Access

In the first phase of a two phases access, the same procedure as for one phase access is used, until the network sends the IMMEDIATE ASSIGNMENT (PACKET UPLINK ASSIGNMENT) message. This message denotes a single block allocation, which indicates to the MS the two phases access. In this message, the network reserves a limited resource (single radio block) on one PDCH to the mobile station, where the mobile station transmits a PACKET RESOURCE REQUEST message. The two phases access can be initiated either by the MS or the network, following these rules: if PCCCH is provided in the cell, a two phase access can be initiated: by the network by ordering the mobile station to send a PACKET RESOURCE REQUEST message. The order is sent implicitly to the mobile station in the PACKET UPLINK ASSIGNMENT message by including the Single Block Allocation structure; by a mobile station, by requiring a two phases access in the PACKET CHANNEL REQUEST message. In this case, if access is granted, the network shall order the mobile station to send a PACKET RESOURCE REQUEST message. The order is sent implicitly to the mobile station in the PACKET UPLINK ASSIGNMENT message by including the Single Block Allocation Structure.
176
A30808-X3247-L24-1-7618
if no PCCCH is provided in the cell, a two phase access can be only initiated by a mobile station, by requiring this type of access within the CHANNEL REQUEST message.
When the network receives the PACKET RESOURCE REQUEST message, it responds by sending to the mobile station either a PACKET UPLINK ASSIGNMENT message (radio resources assignment on one or more PDCHs to be used by the mobile station for the TBF) or a PACKET ACCESS REJECT message. Fig. 9.7 shown a two phases access procedure on CCCH.
Fig. 9.7
Two Phases Access on CCCH
9.8.2.4
TBF Establishment for EDGE Mobile Stations

As it has been described in "4.4.1 Packet Broadcast Control Channel (PBCCH)", the MS knows that EGPRS is available in the cell, reading the GPRS Cell Option IE in SI13 or in PSI1 and nding the EGPRS_PACKET_CHANNEL_REQUEST support indication eld. The EGPRS_PACKET_CHANNEL_REQUEST support indication field, is represented by one bit, and can assumes the two values 0 or 1. In the rst case an EGPRS capable MS, to access a cell, shall use: the EGPRS PACKET CHANNEL REQUEST message for EGPRS uplink TBF establishment on the PRACH when there is a PBCCH in the cell; the EGPRS PACKET CHANNEL REQUEST message for EGPRS uplink TBF establishment on the RACH when there is no PBCCH in the cell. In the second case an EGPRS capable MS, to access a cell, shall use: a two phase access with PACKET CHANNEL REQUEST message on the PRACH for uplink TBF establishment when there is a PBCCH in the cell;
A30808-X3247-L24-1-7618
177
a two phase access with CHANNEL REQUEST message on the RACH when there is no PBCCH in the cell. The EGPRS PACKET CHANNEL REQUEST message is formatted as 11 bit of information, and it is supported only by the EDGE Access Burst. The EDGE Access Burst uses two different training sequences, TS1 and TS2, to allow a mobile station to signal to the network, during the access phase, its uplink capability. In fact, as it has been described in "9.1 Mobile Stations for Packet Switched Services" two mobile classes are foreseen for what concern EGPRS mobile stations; so: when the mobile station is an EGPRS one, with 8PSK modulation capability in uplink direction, it uses the EDGE access burst with TS1 training sequence; when the mobile station is an EGPRS one, with GMSK modulation capability in uplink direction, it uses the EDGE access burst with TS2 training sequence; Instead, a GPRS mobile station will use a traditional access burst with the training sequence already used for GSM (TS GSM). It is important to underline that only EDGE CUs are able to manage access bursts containing TS1 and TS2 (and as a consequence the EGPRS PACKET CHANNEL REQUEST message), so the EGPRS PACKET CHANNEL REQUEST message will be used to access a cell only if the BCCH carrier supports EDGE, i.e. (see "6.1.2 Enabling EGPRS Service in the Cell"): a) at least one EDGE CU is congured in the BTS equipment handling the cell; b) the TRXMD parameter of the BCCH carrier is set to EDGE; c) the TrxCapability of the BCCH carrier is set to EDGE. Besides, the ABUTYP parameter that indicates the format of the information field of access bursts must be set to ACBU11BIT. So, if the SI13 (or the PSI1) indicates that the cell is EGPRS capable, and EGPRS PACKET CHANNEL REQUEST on RACH (PRACH) is supported in the cell, an EGPRS mobile station sends the 11 bits EGPRS PACKET CHANNEL REQUEST message. If the SI 13 (or the PSI1) indicates that the cell is EGPRS capable and EGPRS PACKET CHANNEL REQUEST on RACH /PRACH) is not supported in the cell, the EGPRS mobile station shall use the CHANNEL REQUEST message on RACH (or PACKET CHANNEL REQUEST message on PRACH) message and initiates a two phases access request. In the following the access procedures are described with more details. EGPRS Uplink TBF Establishment using a One Phase Access Regarding this kind of Uplink TBF establishment different cases exist: a) EGPRS PACKET CHANNEL REQUEST is supported: if the PBCCH channel is not supported, the MS sends an EGPRS PACKET CHANNEL REQUEST message on RACH channel. Then the procedure is similar to those described in "9.8.2.2 Establishment using a One Phase Access": the BSC answers with the IMMEDIATE ASSIGNMENT message for Uplink EGPRS TBF, and then it sends a Packet Uplink Assignment for Uplink EGPRS TBF if the TBF is multislot; if the PBCCH channel is supported, the MS sends an EGPRS PACKET CHANNEL REQUEST message on PRACH channel. Then the procedure is similar to those described in "9.8.2.2 Establishment using a One Phase Access": the BSC answers with a Packet Uplink Assignment for Uplink EGPRS TBF.
178
A30808-X3247-L24-1-7618
b) EGPRS PACKET CHANNEL REQUEST is NOT supported: in this case, the one phase access does not allow to establish a EGPRS TBF; a GPRS TBF will be allocated following the procedure described in "9.8.2.2 Establishment using a One Phase Access". EGPRS Uplink TBF Establishment using a Two Phases Access Regarding this kind of Uplink TBF establishment different cases exist: a) EGPRS PACKET CHANNEL REQUEST is supported: if the PBCCH channel is not supported, the MS sends an EGPRS PACKET CHANNEL REQUEST message on RACH channel. The BSC answers with IMMEDIATE ASSIGNMENT message, then the MS sends a Packet Resource Request message following the procedure described in "9.8.2.3 TBF Establishment using a Two Phases Access"; if the PBCCH channel is supported, the MS sends an EGPRS PACKET CHANNEL REQUEST message on PRACH channel. The BSC answers with a Packet Uplink Assignment message, then the MS sends a Packet Resource Request message following the procedure described in "9.8.2.3 TBF Establishment using a Two Phases Access"; b) EGPRS PACKET CHANNEL REQUEST is NOT supported: if the PBCCH channel is not supported, the MS sends a Channel Request (with two phase indication) on RACH channel. The BSC answers with IMMEDIATE ASSIGNMENT (single block), then the MS sends a Packet Resource Request message following the procedure described in "9.8.2.3 TBF Establishment using a Two Phases Access"; if the PBCCH is not supported, the MS sends an Packet Channel Request (with two phase indication) on PRACH channel. The BSC answers with PACKET UPLINK ASSIGNMENT (single block), then the MS sends a Packet Resource Request message following the procedure described in "9.8.2.3 TBF Establishment using a Two Phases Access";
9.8.2.5
Contention Resolution
Contention resolution is an important part of RLC/MAC protocol operations, especially because one channel allocation can be used to transfer a number of LLC frames. As defined in the previous chapters, there are two basic access possibilities, the one phase and the two phases access. The two phases access is inherently immune from the possibility that two MSs can perceive the same channel allocation as their own. Namely the second access phase, i.e. the Packet Resource Request, uniquely identifies the MS by its TLLI. The same TLLI is included in the Packet Uplink Assignment/Packet Downlink Assignment and no mistakes are possible.
The Temporary Logical Link Identity (TLLI) identifies a GPRS/EGPRS user inside the cell. The relationship between TLLI and IMSI is known only in the MS and in the SGSN. TLLI is derived from the P-TMSI allocated by the SGSN, or it is built by the MS. The P-TMSI identifies the MS for location purposes, whereas TLLI identifies the MS from the packet data transfer point of view. The one phase access is somewhat insecure, and an efficient contention resolution mechanism has to be introduced.
A30808-X3247-L24-1-7618
179
The first part of the solution is the identification of the MS. The identification of transmitting MS on the RLC/MAC level is necessary not only for contention resolution, but also to be able to establish the RLC protocol entity for that Temporary Block Flow on the network side. Additionally, TLLI is necessary to be able to match simultaneous uplink and downlink packet transfers by taking into consideration multislot capability of that MS. In order to uniquely identify the MS when sending on uplink, the RLC Header for all the RLC Data Blocks on uplink is extended to include the TLLI, until the contention resolution is completed on the MS side. The second part of the solution is the notification from the network side about who owns the allocation. That is solved by the inclusion of the TLLI in the PACKET UPLINK ACK/NACK and PACKET DOWNLINK ACK/NACK messages. By doing so, the contention is resolved after the first occurrence of Packet Ack/Nack.
9.8.2.6
Uplink Access on PRACH (Access Persistence Control)

The mobile station makes at most MAX_RETRANS + 1 attempts to send a PACKET CHANNEL REQUEST message. After sending each PACKET CHANNEL REQUEST message, the mobile station listens to the full PCCCH that corresponds to the PRACH (i.e. carried by the same PDCH). The Control Parameters Information Element of PRACH contains the access persistence control parameters, and it is broadcast on PBCCH and PCCCH. The parameters included in the PRACH Control Parameters IE are: MAX_RETRANS, for each Radio Priority i (i=1,2,3,4); it denes (for each radio priority) the maximum number of re-transmissions of the PACKET CHANNEL REQUEST message; it corresponds to the GMANRETS database parameter; PERSISTENCE_LEVEL, which consists of the PERSISTENCE_LEVEL P(i) for each radio priority i (i = 1, 2, 3, 4), where P(i) is a value taken inside the {0, 1, 14, 16} group. If the PRACH Control Parameters IE does not contain the PERSISTENCE_LEVEL parameter, this shall be interpreted as if P(i)=0 for all radio priorities. The user can set the four PERSISTENCE_LEVEL values (one for each priority) by the following parameters: PERSTLVPRI1, PERSTLVPRI2, PERSTLVPRI3 and PERSTLVPRI4; S; it corresponds to the GS database parameter; TX_INT; it corresponds to the GTXINT database parameter; The first attempt to send a PACKET CHANNEL REQUEST message, may be initiated at the first possible TDMA frame containing PRACH, on the PDCH matching the mobile stations PCCCH_GROUP. After each attempt, S and TX_INT parameters are used to determine the next TDMA frame in which the MS is allowed to make a successive attempt. The number of TDMA frames between two successive attempts to send a PACKET CHANNEL REQUEST message, excluding the TDMA frames potentially containing the messages themselves, is a random value drawn, for each transmission, with a uniform probability distribution in the set {S, S + 1, , S + TX_INT - 1}. When the MS has made MAX_RETRANS + 1 attempts to send a PACKET CHANNEL REQUEST message, the packet access procedure is aborted, a packet access failure is indicated to upper layers and the mobile station returns to packet idle mode. When the MS initiates a packet access procedure and receives from the network a Packet Access Reject message, corresponding to one of the 3 last PACKET CHANNEL REQUESTs sent by the MS, it starts the T3172 timer; when the timer is running, the MS
180
A30808-X3247-L24-1-7618
is not allowed to access to the cell (i.e. it cannot send any other PACKET CHANNEL REQUEST messages). Then one of the two following situations can happen (see Fig. 9.8): if the MS receives the Packet Uplink Assignment message, it stops the T3172 timer; it the T3172 timer expires, the MS can start new transmissions of packet channel requests.
t Start T3172 Stop T3172 T3172 Expired (Reception of a Packet (Reception of a Packet Access in the cell is Access Reject message) Uplink Assignment message) no longer prohibited
Fig. 9.8
Packet Access Reject Procedure
9.8.3
TBF Establishment Initiated by the Network on CCCH/PCCCH

When the GPRS/EGPRS MS is in standby state and the PCCCH channel is configured in the serving cell, the mobile station listens to paging sub-channels on PCCCH. If PCCCH is not present in the considered cell, the mobile station listens to paging subchannels on CCCH.
Paging sub-channels are, in any case, monitored according to the paging groups defined for the mobile station and its current DRX mode (see "9.8.3.2 Discontinuous Reception"). Paging for GPRS/EGPRS are performed on Routing Areas instead ones of standard GSM that are done on Location Areas. If the MS is in Standby state, the SGSN knows only the Routing Area on which the MS is camped on. In order to initiate a downlink packet transfer, the SGSN sends to the MS one or more PACKET PAGING REQUEST messages on the downlink PCH (PPCH). The MS responds to one PACKET PAGING REQUEST message by initiating a mobile originated packet transfer, as described in "9.8.2 TBF Establishment Initiated by the MS on CCCH/PCCCH". This mobile originated packet transfer allows the MS to send a PACKET PAGING RESPONSE to the network. The packet paging response is one or more RLC/MAC data blocks containing an arbitrary LLC frame. When the packet paging response has been sent by the MS and it has been received by the network, the mobility management state of the MS changes from standby to ready.
If the MS is already in READY state, the SGSN knows exactly the cell where the MS is camped on; then the SGSN sends the assignment message on PCH (PPCH) or AGCH (PAGCH), without sending the PACKET PAGING REQUEST message. In case there is an uplink packet transfer in progress, the PACKET DOWNLINK ASSIGNMENT message is transmitted on PACCH. The transmission of MAC/RLC blocks to a MS in the ready state is initiated by the network using the packet downlink assignment procedure. The network initiates the packet downlink assignment procedure by sending the IMMEDIATE ASSIGNMENT
A30808-X3247-L24-1-7618
181
(PACKET DOWNLINK ASSIGNMENT) message on the CCCH (PCCCH) timeslot corresponding to CCCH (PCCCH) group the mobile station belongs to. If the mobile station does not apply DRX, there is no further restriction on what part of the downlink CCCH (PCCCH) timeslot an IMMEDIATE ASSIGNMENT (PACKET DOWNLINK ASSIGNMENT) message can be sent. If the mobile station applies DRX, the message shall be sent in a CCCH (PCCCH) block corresponding to a paging group determined for the mobile station in packet idle mode. The downlink assignment message includes the list of PDCH(s) that will be used for downlink transfer. When the downlink TBF is set up, the following parameters and radio resources are allocated to the MS: TFI; Time Slot numbers; ARFCN; optionally Timing Advance parameters (TAI and Timeslot number); MAC access mode (always set to dynamic, see "9.8.1 Medium Access Modes"). optionally, for EGPRS MSs, the EGPRS window size. The TBF establishment initiated by the network is shown Fig. 9.9 in case of PCCCH.
Fig. 9.9
TBF Establishment Initiated by the Network on PCCCH
9.8.3.1
Network Operation Modes for Paging

The network may provide co-ordination of paging for circuit-switched and packetswitched services. Paging coordination means that the network sends paging messages
182
A30808-X3247-L24-1-7618
for circuit switched services on the same channel as used for packet switched services, i.e.: on the PPCH paging channel, if the MS is in packet idle mode; on the PDCH if the MS is in packet transfer mode. Then the MS needs only to monitor one channel at any time. Three network operation modes are defined (see Tab. 9.2): Network operation mode I: the network sends CS paging messages for a GPRS/EGPRS-attached MS, either on the same channel as the PS paging channel (i.e. the PCCCH if it is congured, otherwise the CCCH), or on a PDCH trafc channel. This means that the MS needs only to monitor one paging channel, and that it receives CS paging messages on the packet data channel when it has been assigned a packet data channel. When the network operation mode I is used, the network works in a coordinated way. Network operation mode II: the network sends CS paging messages for a GPRS/EGPRS-attached MS on the CCCH paging channel, and this channel is also used for PS paging. This means that the MS needs only to monitor the CCCH paging channel, but that CS paging continues on this paging channel even if the MS has been assigned a packet data channel. Network operation mode III: the network sends CS paging messages for a GPRS/EGPRS-attached MS on the CCCH paging channel, and sends PS paging messages either on PCCCH (if it is allocated in the cell) or on the CCCH paging channel. This means that a MS that wants to receive pages for both circuit-switched and packet-switched services shall monitor both paging channels if the packet paging channel is allocated in the cell. No paging co-ordination is performed by the network. Mode Mode I CS services paging channel PPCH paging channel CCCH paging channel Packet data channel Mode II Mode III CCCH paging channel CCCH paging channel CCCH paging channel Tab. 9.2 Network Operation Modes PS paging channel PPCH paging channel CCCH paging channel Not Applicable CCCH paging channel PCCCH paging channel CCCH paging channel NO NO Paging co-ordination YES
When the Gs interface exists, all MSC-originated pages of GPRS/EGPRS-attached MSs go via the SGSN, thus allowing network co-ordination of paging. Paging co-ordination is made by the SGSN based on the IMSI, and it is provided independently of whether the MS is in STANDBY or in READY state. The network operates in mode I. When the Gs interface does not exist, all MSC-originated pages of GPRS/EGPRSattached MSs goes via the A interface, and co-ordination of paging cannot be performed. The network shall then either: operate in mode II, meaning that the packet common control channel is not allocated in the cell;
A30808-X3247-L24-1-7618
183
operate in mode III, meaning that the packet common control channel is used for PS paging when the packet paging channel is allocated in the cell.
The network operation modes (mode I, II, or III) are indicated as system information to MSs. The user sets this value by the NMO parameter. For proper operation, the mode of operation should be the same in each cell of a routing area. Based on the mode of operation provided by the network, the MS can then choose, according to its capabilities, whether it can attach to PS services, to non-PS services, or to both of them.
9.8.3.2
Discontinuous Reception
Paging is used to send paging information to mobile stations in packet idle mode (quite apart from the current MM state, i.e. ready state or standby state), so a mobile station in packet idle mode listens to radio blocks on CCCH or PCCCH. For PS services, as for the well known CS service, its also possible to organize paging channels in combination with discontinuous reception (DRX). DRX allows MSs to reduce power consumption. A GPRS/EGPRS MS may be able to choose if it wants to use discontinuous reception (DRX) or not. If the MS uses DRX mode, the MS shall also specify other DRX parameters that indicate the delay for the network to send page requests or channel assignments to the MS. DRX parameters are indicated by the MS in the Attach procedure (see 9.3.2.1). The SGSN then in each page request sends these parameters to the BSS, that uses both this information and the IMSI of the MS to calculate the correct paging group. In the GPRS attach procedure the following parameters are established: DRX/non-DRX indicator: it indicates whether the MS uses DRX or not. DRX period: the DRX period indicates the period of time between two consecutive paging blocks (within a timeslot used as CCCH or PCCCH) where a MS, which is using DRX mode, can receive its paging messages. When PCCCH is used the DRX period is dened by the SPLIT_PG_CYCLE parameter. The mobile station requests values for the SPLIT_PG_CYCLE parameter to be applied on PCCCH. The SPLIT_PG_CYCLE parameter handles the occurrence of paging blocks on PCCCH monitored by the mobile station in DRX mode.
The support of the SPLIT_PG_CYCLE parameter on CCCH is optional. The SPGC_CCCH_SUP parameter (not configurable in the database) indicates the support of the SPLIT_PG_CYCLE on CCCH from the network side. If SPLIT_PG_CYCLE is not supported on CCCH, the period of monitoring paging blocks on CCCHs is defined by the GSM NFRAMEPG parameter. The NFRAMEPG parameter determines the number of 51 TDMA multiframes between two consecutive transmissions of the same paging message in the same paging group. The parameters used to define the paging groups for GPRS/EGPRS are shown in Tab. 9.3, together with the corresponding GSM parameters. Non-DRX timer: it is used to determine the duration of the non-DRX mode period to be applied by the mobile station when it has left the packet transfer mode and enters the packet idle mode. A MS in non-DRX mode is required to monitor all the radio blocks of the PCCCH or CCCH channel; so the required time to execute the paging procedure is reduced. Besides, as long as the timer is running (hence the MS is in non-DRX mode), the BSC sends downlink assignments on AGCH or
184
A30808-X3247-L24-1-7618
PAGCH (and not in paging blocks that the MS monitors when DRX mode is active, and that occur with a low frequency) reducing the time to allocate resources. So, when the MS changes from packet transfer mode to packet idle mode, the BSC starts a timer; the duration of this timer is determined by:
timer = min (DRX_TIMER_MAX, NON_DRX_TIMER)
where: DRX_TIMER_MAX represents the DRXTMA parameter, and it is broadcast in the cell; NON_DRX_TIMER is a parameter requested by the MS in the PS attach procedure. During this period, the MS is in non-DRX mode; when the timer expires, the MS resumes discontinuous reception.
In applications like WAP the needed time to get a reply is a key factor for end user acceptance. Because of highly interactive behavior of WAP with few seconds between answers from network and subsequent user actions (for example navigating through menus), response times are drastically reduced by sending the immediate assignment/packet downlink assignment messages (polling requests) on the AGCH/PAGCH instead of PCH/PPCH. So, when the DRX mode is temporarily disabled, the time that occurs to receive at the MS side a data block which has been sent from the Gb interface, is in average reduced by 50%. When the mobile station receives a new value of the DRXTMA parameter, the mobile station is not required to consider the new value until the next time it enters packet idle mode.
There is another case when the MS enters the non-DRX mode: when initiating the MM procedures for PS attach and routing area update, the mobile station enters the MM non-DRX mode period. This period ends when the corresponding MM procedures terminate.
Subjects PCCCH DRX period Blocks not available for paging per multiframe SPLIT_PG_CYCLE
GPRS/EGPRS CCCH NFRAMEPG (*) SPLIT_PG_CYCLE (**) NBLKACGR
Corresponding GSM parameters CCCH NFRAMEPG NBLKACGR (***)
BSPBBLK + BPAGCHR
Number of timeslots (phys- Depending on the number ical channels) containing of slots reserved for paging PCCCH by means of the GDCH parameter. Tab. 9.3 Parameters for DRX Operation
Depending on the number Depending on the of slots reserved for number of slots reserved CCCH. for CCCH.
A30808-X3247-L24-1-7618
185
Subjects PCCCH
GPRS/EGPRS CCCH
Corresponding GSM parameters CCCH
(*) only when DRX period split is not supported. (**) only when DRX period split is supported. (***) NBLKACGR is a GSM parameter the indicates the number of CCCH blocks reserved for the access grant signalling during a period of a 51 TDMA frames (i.e. during a period of a 51 TDMA multiframe). Tab. 9.3 Parameters for DRX Operation GPRS/EGPRS Paging using CCCH A mobile station using DRX is only required to monitor the PCH blocks belonging to its paging group. The network sends the paging subchannel for a given MS every NFRAMEPG multiframes, or every 64/SPLIT_PG_CYCLE multiframes if SPLIT_PG_CYCLE is supported. A mobile station not using DRX is required to monitor every PCH block on the same CCCH as for DRX. The network internal message flow is the following: 1. the SGSN, which has the knowledge about the usage of DRX, sends a paging message to all PCUs which are supporting the right Routing Area. This messages includes the information whether DRX is used or not, and additionally, if the enhanced DRX mechanism is used, the SPLIT_PG_CYCLE parameter which indicates that the existing DRX mechanism is supported by the network; 2. the PCU forwards the Packet Paging Request message combined with the requested paging parameters over the internal interface to the TDPC; 3. the TDPC calculates the right paging group and forwards per LAPD connection the Packet Paging Request message to the paging queues inside the BTS. Additionally the BSC evaluates all needed DRX parameters which have to be broadcast on BCCH; 4. the BTS queues all Packet Paging Request messages and sends them in order rstin rst-out on the PCHs in the CCCH multiframe. GPRS/EGPRS Paging using PCCCH A MS using DRX is required to monitor the PPCH. The network sends the paging subchannel for a given MS every 64/SPLIT_PG_CYCLE multiframes. A mobile station not using DRX is required to monitor every PPCH block on the same PCCCH as for DRX. The network internal message flow is following: 1. The SGSN, which has the knowledge about the usage of DRX, sends a paging message to all PCUs which are located in the right Routing Area. This message includes the information whether DRX is used or not and additionally (if the enhanced DRX mechanism is used) the SPLIT_PG_CYCLE parameter; 2. the PCU calculates the right paging group and adds all Packet Paging Request messages on its paging group queues. Additionally the PCU evaluates all needed DRX parameters which have to be broadcast on PBCCH; 3. the PCU includes the Packet Paging Request messages into RLC/MAC blocks and schedules the messages into the PDCH multiframes, which contains PCCCH. The
186
A30808-X3247-L24-1-7618
RLC/MAC blocks are transferred via PCU frames to the BTS, which transmits the Packet Request message immediately.
9.8.4
Relative Reserved Block Period Field (RRBP)

The RRBP field is contained in the MAC Header of every MAC/RLC block sent in downlink direction. Its value specifies a single uplink block in which the mobile station shall transmit either a PACKET CONTROL ACKNOWLEDGEMENT message (to acknowledge a downlink control block) or another PACCH block to the network. If the RRBP field is received as part of a MAC/RLC control block containing any message except Packet Paging Request, Packet Access Reject, and Packet Queueing Notification, the mobile station shall transmit a PACKET CONTROL ACKNOWLEDGEMENT message in the specified uplink radio block. If the RRBP field is received as part of a MAC/RLC control block containing a Packet Paging Request, Packet Access Reject, or Packet Queueing Notification message, the mobile station ignores this RRBP field. If the RRBP field is received as part of a MAC/RLC data block, the mobile station shall transmit a PACCH block (e.g. a PACKET UPLINK ACK/NACK message to acknowledge the downlink data block) in the specified uplink radio block. The mobile station shall always transmit the uplink radio block on the same timeslot as the block where the RRBP has been received. To indicate to the MS whether the received RRBP field is valid or not valid, a bit of the MAC Header is used; according to the value of this bit, the MS knows if, in the received block, the RRBP field is meaningful.
The multislot class of the MS limits allowed combinations and configurations when the MS supports multislot communications. When a MS has established a downlink TBF, it cannot transmit in uplink direction (after a polling by the network) on any timeslot; in fact for each mobile station, according to its multislot class, downlink and uplink timeslots usage is specified (see "4.7.1 Mobile Station Classes for Multislot Capabilities"). So the network, to poll the MS, must send the downlink block with a valid RRBP field on a timeslot where the polled MS is able to answer.
9.8.5
Packet Queuing Notification Procedure

Occasionally, the number of received Packet Channel Requests could be higher than the number of requests that can be served. To handle this situation, a PACKET QUEUING NOTIFICATION message is transmitted from the network to the sender of the Packet Channel Request. The notification includes information that the Packet Channel Request message has been correctly received and that the Packet Uplink Assignment may be transmitted later. The PACKET QUEUING NOTIFICATION message is sent on the same PCCCH on which the network has received the PACKET CHANNEL REQUEST message. It contains a Temporary Queuing Identity which will be used later to identify the mobile station (either when the MS will be polled or when the network will send an assignment message). After having sent the PACKET QUEUING NOTIFICATION message, the network may send to the mobile station a PACKET UPLINK ASSIGNMENT message (see Fig. 9.10). In this case, the reference address to the mobile station is the Temporary Queuing Identity received in the PACKET QUEUING NOTIFICATION message.
A30808-X3247-L24-1-7618
187
If the Timing Advance information becomes inaccurate for a MS, the network can send the PACKET POLLING REQUEST message to trigger the MS to send four random access bursts. This can be used to estimate the new Timing Advance value before issuing the Packet Uplink Assignment (see "9.8.6 Polling Procedures").
The Packet Queuing Notification procedure is not foreseen in BR7.0 release.
Fig. 9.10
Packet Queuing Notification Procedure
9.8.6
Polling Procedures
As it has been described in "4.6 Packet Timing Advance Estimation", the initial timing advance estimation is based on the single access burst carrying the Packet Channel Request. The Packet Uplink Assignment or Packet Downlink Assignment (or the Immediate Assignment if the PCCCH is not configured) then carries the estimated timing advance value to the MS. Two special cases exist: when Packet Queuing Notication is used (see 9.8.5), the initial estimated timing advance may become too old to be sent in the Packet Downlink (/Uplink) Assignment; when Packet Downlink Assignment has to be sent without prior paging (i.e., in the Ready state), no valid timing advance value may be available. Then the network has three options:
188
A30808-X3247-L24-1-7618
1. a PACKET POLLING REQUEST message can then be used to trigger the transmission of the PACKET CONTROL ACKNOWLEDGEMENT message from the MS to the network. The PACKET CONTROL ACKNOWLEDGEMENT message is sent on the PACCH from the mobile station to the network (see Fig. 9.11). The message is formatted either as a RLC/MAC control block or as 4 identical access bursts. If it is sent as a response to a PACKET POLLING REQUEST message, this latter message must specify, by the type_of_ack eld, the format of the PACKET CONTROL ACKNOWLEDGEMENT message. Otherwise the System Information parameter CACKTYP (CONTROL_ACK_TYPE) indicates which format the mobile station shall use to send the PACKET CONTROL ACKNOWLEDGEMENT message;
The Packet Polling Request procedure is not used in BR7.0 release.
2. the RRBP eld of the Packet Downlink Assignment message can be set to trigger the transmission of the PACKET CONTROL ACKNOWLEDGEMENT message (see "9.8.4 Relative Reserved Block Period Field (RRBP)"). This can be used only if System information indicates that acknowledgement is access bursts, i.e. it can be used only if CACKTYP is set to 0;
The CACKTYP parameter is hard-coded to the value 0.
3. Packet Downlink Assignments can be sent without timing advance information. In that case it is indicated to the MS that it can only start the uplink transmission after the timing advance value has been obtained by the continuous timing advance update procedure.
Fig. 9.11
Packet Polling Request
A30808-X3247-L24-1-7618
189
Besides, the continuous timing advance update procedure can create some delays between the packet downlink assignment message and the beginning of data transfer in downlink direction (this delay is due to the time that is needed to exchange timing advance information between the network and the MS). In order to reduce the time between a packet downlink assignment message and the effective beginning of downlink data transmission, a polling procedure is executed by the network to order the MS to send a Packet Control Acknowledgment message, formatted as four Access Bursts. This procedure foresees to poll the MS by means of the RRBP field of the assignment message; as a consequence the CACKTYP parameter must be set to 0, to force the MS to respond with four Access Burst. Different procedures are executed according to whether the PBCCH is configured or not. Procedure when PBCCH is configured If PBCCH is configured the following steps are executed: the BSC sends the PACKET DOWNLINK ASSIGNMENT message (on the PPCH/PAGCH) setting the RRPB eld to poll the MS; upon reception of the PACKET CONTROL ACKNOWLEDGEMENT message from the MS, the BSC can immediately start downlink transmission of data blocks; as soon as possible (also before the transmission of the rst downlink data block) the BSC must send to the MS the PACKET POWER CONTROL/TIMING ADVANCE message, including the estimated timing advance value. Procedure when PBCCH is not configured If PBCCH is not configured the following steps are executed: the BSC sends the IMMEDIATE ASSIGNMENT message for downlink TBF on PCH/AGCH; then the BSC sends on the assigned PDCH(s) a PACKET DOWNLINK ASSIGNMENT message setting the RRPB eld to poll the MS (the BSC, to poll the MS, instead of transmitting the PACKET DOWNLINK ASSIGNMENT message can either send a PACKET POLLING REQUEST message with type_of_ack=four access bursts); upon reception of the PACKET CONTROL ACKNOWLEDGEMENT message from the MS, the BSC can immediately start downlink transmission of data blocks; as soon as possible (also before the transmission of the rst downlink data block) the BSC must send to the MS the PACKET POWER CONTROL/TIMING ADVANCE message, including the estimated timing advance value.
9.9
RLC Data Block Transfer

The RLC functions support two modes of operation: RLC acknowledged mode: this mode is used for data applications where the payload content needs to be preserved. It is the typical mode for Background class (background delivery of e-mails, SMS, download of databases) and Interactive class applications (web browsing). RLC unacknowledged mode: this mode is used for delay sensitive services, such as Conversational class (voice, video conference) and Streaming class applications (one-way real time audio and video). A TBF may operate in either RLC acknowledged mode or RLC unacknowledged mode.
190
A30808-X3247-L24-1-7618
9.9.1
Acknowledged Mode for RLC/MAC Operation

Regarding GPRS and EGPRS acknowledged modes there are some differences; they are described in the following.
9.9.1.1
GPRS Acknowledged Mode

GPRS acknowledged operation mode uses retransmission of RLC data blocks to achieve high reliability. The transfer of RLC Data Blocks in the RLC/MAC acknowledged mode is controlled by a selective ARQ mechanism (type I ARQ) coupled with the numbering of the RLC Data Blocks within one Temporary Block Flow. The sending side (the MS or the network) transmits blocks within a window (the length of the window is fixed to 64 blocks) and the receiving side sends a Packet Uplink Ack/Nack or a Packet Downlink Ack/Nack message when needed. The transmitting side numbers the RLC data blocks via the block sequence number (BSN), which is used for retransmission and for reassembly. Every such message acknowledges all correctly received RLC Data Blocks up to an indicated block sequence number (BSN), thus moving" the beginning of the sending window on the sending side. Additionally, the bitmap that starts at the same RLC Data Block is used to selectively request erroneously received RLC Data Blocks for retransmission. The sending side then retransmits the erroneous RLC Data Blocks, eventually resulting in further sliding of the sending window. A missing Packet Ack/Nack is not critical and a new one can be issued whenever.
9.9.1.2
EGPRS Acknowledged Mode

The transfer of RLC Data Blocks in the EGPRS acknowledged RLC/MAC mode can be controlled: a) by a selective type I ARQ mechanism, where coding of a RLC Data Block is solely based on the prevailing transmission (i.e. erroneous blocks are not stored); b) or by type II hybrid ARQ mechanism (called Incremental Redundancy - IR) where erroneous blocks are stored by the receiver and a joint decoding with new transmissions is done. Both the methods are coupled with the numbering of the RLC Data Blocks within one Temporary Block Flow.
In BR7.0 release, the Incremental Redundancy mechanism for EGPRS is only used in downlink direction; in uplink direction only the selective type I ARQ mechanism is used. The sending side (the MS or the network) transmits blocks within a window and the receiving side sends Packet Uplink Ack/Nack or Packet Downlink Ack/Nack message when needed. For EGPRS, the window size (WS) shall be set by the operator according to the number of timeslots allocated in the direction of the TBF (uplink or downlink). The operator can set the window sizes by the following parameters: EGWSONETS, in case of one timeslot assigned; EGWSTWOTS, in case of two timeslots assigned; EGWSTHREETS, in case of three timeslots assigned; EGWSFOURTS, in case of four timeslots assigned; EGWSFIVETS, in case of ve timeslots assigned; EGWSSIXTS, in case of six timeslots assigned; EGWSSEVENTS, in case of seven timeslots assigned;
A30808-X3247-L24-1-7618
191
EGWSEIGHTTS, in case of eight timeslots assigned.
According to the link quality, an initial MCS is selected for a RLC block. For the retransmission, the same or another MCS from the same family of MCSs can be selected (see "10.5 Link Adaptation"). E.g. if MCS-7 is selected for the first transmission of an RLC block, any MCS of the family B can be used for retransmissions. Further, RLC data blocks initially transmitted with MCS4/MCS5 or MCS6/MCS7/MCS8 or MCS9, can optionally be retransmitted with MCS1, MCS2 and MCS3 respectively, using two 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. For blocks initially transmitted with MCS8 which are retransmitted using MCS6 or MCS3, padding of the first six octets in the data field shall be applied, and the CPS field shall be set to indicate that this has been done. As it has been said, incremental redundancy is used in downlink direction only. The split block field is used to indicate to the MS if the block has been segmented or not. In fact, it must be noted that: a) when ARQ mode type I is used, the retransmission is executed with a coding scheme of the same family of the block received with errors, and the block splitting is possible; b) when ARQ mode type II is used, the retransmission is executed with a coding scheme of the same family of the block received with errors (but with another puncturing scheme) and the block splitting is not allowed; In the EGPRS type II Hybrid ARQ mode, the information is first sent with one of the initial code rates (i.e., the rate 1/3 encoded data is punctured with the puncturing scheme (PS) 1 of the selected MCS). If the RLC Data Block is received in error, additional coded bits (i.e., the output of the rate 1/3 encoded data which is punctured with PS 2 of the prevailing MCS) are sent and decoded together with the already received code-words until decoding succeeds. If all the code-words (different punctured versions of the encoded data block) have been sent, the procedure shall start over, and the first codeword (which is punctured with PS 1) shall be sent followed by PS 2 etc. RLC data blocks which are retransmitted using a new MCS shall at the first transmission after the MCS switch be sent with the puncturing scheme indicated in Tab. 9.4. MCS switched from MCS9 MCS switched to PS of last transmission before MCS switch PS1 or PS3 PS2 MCS6 MCS9 PS1 PS2 MCS7 MCS5 MCS5 MCS97 any any any PS of rst transmission after MCS switch PS1 PS2 PS3 PS2 PS1 PS2 PS1
MCS6
all other combinations Tab. 9.4
Puncturing Schemes to be used after a Coding Scheme Switch
192
A30808-X3247-L24-1-7618
In the EGPRS type I ARQ, the operation is similar to the one of the EGPRS type II hybrid ARQ, except that the decoding of an RLC Data Block is solely based on the prevailing transmission (i.e., erroneous blocks are not stored). So, the MS can use according to the current situation either the type I ARQ or the type II ARQ mode. If the memory for IR operation run out in the MS, the MS shall indicate this by setting the LA/IR bit in the EGPRS PACKET DOWNLINK ACK/NACK message. If IR is considered as "not-properly working"at the MS (IR_statusk<0.5, see "10.5 Link Adaptation"), then the PCU may decide to re-segment not acknowledged blocks. Therefore, for retransmissions, an MCS within the same family as the initial transmission may be used and the payload may be split. On the contrary, if IR is considered as "properly working" (IR_statusk>0.5) at the MS, retransmissions may be realized with an MCS within the same family as the initial transmission without splitting the payload. Furthermore, it is mandatory for an EGPRS MS receiver to be able to perform joint decoding among blocks with different MCSs if the combination of MCSs is one of the following: MCS5 and MCS7, MCS6 and MCS9.
9.9.2
Unacknowledged Mode for RLC/MAC Operation

RLC unacknowledged operation mode does not include any retransmission. The transfer of RLC Data Blocks in the RLC/MAC unacknowledged mode is controlled by the numbering of the RLC Data Blocks within one Temporary Block Flow. The block sequence number (BSN) in the RLC data block header is used to number the RLC data blocks for reassembly. The receiving side extracts user data from the received RLC Data Blocks and attempts to preserve the user information length by replacing missing RLC Data Blocks by dummy information bits. To convey the necessary control signalling (e.g. monitoring of channel quality for downlink channel or timing advance correction for uplink transfers) temporary acknowledgement messages are transmitted, with the same mechanisms and the same message format used by the MAC/RLC acknowledged mode. The fields for denoting the erroneous RLC blocks may be used as an additional measure for channel quality (i.e. parameter for link adaptation). The sending side (the MS or the network) transmits a number of radio blocks and then polls the receiving side to send an acknowledgement message. A missing acknowledgement message is not critical and a new one can be obtained whenever. When working in RLC unacknowledged mode, badly received blocks are not retransmitted (ARQ functions are not used). BLER information could be derived and the link adaptation algorithm could work in a similar way to the acknowledged mode case. But the unacknowledged mode is typically used to support real time applications and in this case minimizing the data unit error ratio, i.e. the fraction of data unit lost or detected as erroneous, is much more important than maximizing throughput.
9.9.3 9.9.3.1
Operations on Uplink TBF Uplink TBF Using the Acknowledged Mode

The mobile station transmits RLC/MAC blocks in each assigned uplink data block. RLC/MAC control blocks have precedence to RLC data blocks, i.e., temporarily
A30808-X3247-L24-1-7618
193
replacing the PDTCH with PACCH. The network sends PACKET UPLINK ACK/NACK messages when needed. To indicate to the network, when it has to send a PACKET UPLINK ACK/NACK, the NRLCMAX parameter is defined: by this parameter the user can configure how many blocks have to be transmitted by the MS, before receiving a PACKET UPLINK ACK/NACK message. The NRLCMAX value is chosen as a compromise between two necessities: it shall avoid to reach the stall condition of the transmitting window (see below); from this point of view the value should be quite low; it shall avoid a frequent number of PACKET UPLINK ACK/NACK messages; from this point of view the value should be quite high. If the mobile station does not receive PACKET UPLINK ACK/NACK messages that allows it to advance the transmitting window, the transmitting window stall condition is reached: upon detecting this condition, the mobile station sets the Stall indicator (SI) bit in all subsequent uplink RLC data block, until the stall condition ceases to exist (i.e. when a valid PACKET UPLINK ACK/NACK message is received). Upon detecting the stall condition, the mobile station starts also the T3182 timer. T3182 timer is stopped upon the reception of a PACKET UPLINK ACK/NACK message, that allows to terminate the stall condition (see Fig. 9.12). If T3182 timer expires: the mobile station decrements the N3102 counter by the PAN_DEC value; the PAN_DEC value is dened by the PKTNDEC parameter; the mobile station aborts all TBFs in progress and its associated resources; if N3102 counter has not reached the value 0, the mobile station returns to the CCCH or PCCCH and initiates the establishment of a new uplink TBF, otherwise the MS performs an abnormal release with cell reselection (see below). Whenever the mobile station receives a PACKET UPLINK ACK/NACK message that allows the advancement of the sending window, the mobile station increments the N3102 counter by the PAN_INC value, however N3102 shall never exceed the PAN_MAX value. The user can configure PAN_INC and PAN_MAX values by PKTNINC and PKTNMA parameters respectively. Upon cell reselection the mobile station sets N3102 counter to the PAN_MAX value. When N3102 = 0 is reached, the mobile station performs an abnormal release with cell re-selection (see Abnormal Cell Re-selection).
If PAN_DEC, PAN_INC, or PAN_MAX are set to the value 0, counter N3102 is disabled.
194
A30808-X3247-L24-1-7618
N3102 = N3102 + PAN_INC
N3102 = N3102 - PAN_DEC
t Cell reselection N3102 = PAN_MAX Start T3182 Stall condition Stop T3182 (Reception of a Packet Uplink Acknowledge) T3182 Expired Abort all TBFs
Fig. 9.12
Behavior of T3182 Timer and N3102 Counter
9.9.3.2
Uplink TBF Using the Unacknowledged Mode

When the unacknowledged mode is used, the network sends PACKET UPLINK ACK/NACK messages when needed, while the mobile station sets the Stall indicator bit to 0 in all RLC data blocks. In unacknowledged mode, the number of blocks to be transmitted by the MS, before receiving a control message from the network, is fixed to 64 (i.e. the value of the transmitting window used in acknowledged mode). If the mobile station transmits 64 data blocks without receiving a PACKET UPLINK ACK/NACK message, the mobile station starts T3182 timer. T3182 shall be stopped upon reception of a PACKET UPLINK ACK/NACK message. If timer T3182 expires, the mobile station decrements the N3102 counter by the PAN_DEC (PKTNDEC) value, aborts all TBFs in progress and its associated resources, returns to CCCH or PCCCH and initiates the establishment of a new uplink TBF. Whenever the mobile station receives a PACKET UPLINK ACK/NACK message, the mobile station shall increment N3102 by PAN_INC (PKTNINC), however N3102 shall never exceed the value PAN_MAX (PKTNMA). Upon cell reselection the mobile station shall set counter N3102 to the PAN_MAX value. When N3102 = 0 is reached, the mobile station performs an abnormal release with cell re-selection.
i
9.9.3.3
If PAN_DEC, PAN_INC, or PAN_MAX are set to the value 0, the N3102 counter is disabled.
Anomalies During an Uplink TBF

Mobile Station Side When the mobile station transmits a RLC/MAC block to the network, it starts timer T3180. When the mobile station detects an assigned USF value on an assigned PDCH, the mobile station reset T3180 timer. If T3180 timer expires, the mobile station aborts all TBFs in progress and its associated resources, returns to the CCCH or PCCCH and initiates the establishment of a new uplink TBF.
A30808-X3247-L24-1-7618
195
Network Side Whenever the network receives a valid RLC/MAC block from the mobile station, it resets the N3101 counter. The network increments the N3101 counter for each allocated radio block to that mobile station, for which no data is received. If N3101 reaches the N3101max value, the network stops the scheduling of RLC/MAC blocks from the mobile station and starts T3169 timer. When T3169 expires, the network may reuse the USF and TFI values (the procedure is shown in Fig. 9.13). The user can also define the N3101max value by the N3101 parameter.
N3101 = 0
N3101 = N3101 + 1
N3101 = N3101+1= N3101max
t NW sends Data is USF received from the MS. NW sends Data is not USF received from the MS. NW sends USF Data is not received from the MS. Start T3169 communication with MS is broken. T3169 Expired Reuse of TFI and USF
Fig. 9.13
Detection of Anomalies during an Uplink TBF on the Network Side
9.9.3.4
Release of an Uplink TBF

The release of resources is normally initiated from the MS by counting down the last blocks. For the normal release of resources of a RLC connection, carrying a mobile originated packet transfer, the mechanism based on the acknowledgment of the final Packet Uplink Ack/Nack message (combined with timers) is used (see Fig. 9.14). The MS initiates the release of the uplink TBF by beginning the countdown process. The MS sends the Countdown Value (CV) in each uplink RLC data block to indicate to the network the absolute BSN (Block Sequence Number) of the last RLC data block, that will be sent in the uplink TBF. The CV value is calculated as follows:
TBC BSN 1 x = round --------------------------------------- - NTS

then
x CV = 15
if
x BSCVMAX otherwise
196
A30808-X3247-L24-1-7618
where: - TBC = total number of RLC data blocks that will be transmitted in the TBF; - BSN = absolute block sequence number of the RLC data block, with range from 0 to (TBC - 1); - NTS = number of timeslots assigned to the uplink TBF, with range 1 to 8; - BSCVMAX is the BSCDVMA parameter, broadcasted in the system information; - the round() function rounds upwards to the nearest integer; the division operation is non-integer and results in zero only for (TBC - BSN - 1) = 0. The final RLC data block transmitted in the TBF (i.e., the RLC data block with BSN = TBC - 1) shall have CV set to the value 0. Once the mobile station transmits a value of CV other than 15, the MS shall not queue any new RLC data blocks, and any data which arrives after the commencement of the countdown process shall be sent within a future TBF. After the MS has sent its last RLC Data Block (indicated by the countdown field), the acknowledgement is expected from the network side. By sending the last block, the MS may no longer use the same assignment, unless a negative acknowledgement arrives. It also means that the network side may reallocate the same USF(s) to another user as soon as all the RLC Data Blocks belonging to that Temporary Block Flow are correctly received. When sending the last RLC data block, the MS starts also the T3182 timer. Then the network, if all RLC Data Blocks have been correctly received, sends the Packet Uplink Ack/Nack message to the MS which has to be immediately acknowledged by the MS in the reserved uplink block period (the network also resets the N3103 counter). If T3182 timer expires, before the MS receives the Packet Uplink Ack/Nack message, then the mobile station aborts all TBFs in progress and its associated resources, returns to the CCCH/PCCCH and initiates the establishment of a new uplink TBF. When the MS receives the Packet Uplink Ack/Nack message, it responds to the network by the Packet Control Acknowledgment message in the reserved uplink block period. Upon the reception of the acknowledgement, the network can reuse the TFI and USF values.
A30808-X3247-L24-1-7618
197
Fig. 9.14
Release of an Uplink TBF If the network does not receive the PACKET CONTROL ACKNOWLEDGEMENT message in the radio block indicated by the RRBP field (see "9.8.4 Relative Reserved Block Period Field (RRBP)"), it increments the N3103 counter and retransmits the PACKET UPLINK ACK/NACK message. If counter N3103 exceeds its limit, which the user can define by the N3103 parameter, the network starts T3169 timer. When T3169 timer expires the network may reuse the TFI and USF resources (see Fig. 9.15).
N3103 = N3103 + 1
N3103 = N3103+1= N3103max
t NW waits for NW has not received any acknowledgment ackn. from the MS. NW has not received any ackn. from the MS. Start T3169 communication with MS is broken. T3169 Expired Reuse of TFI and USF
Fig. 9.15
Release of Resources on the Network Side during an Uplink TBF (in case of T3169 timer expiration)
198
A30808-X3247-L24-1-7618
Improving the overall performances in the interaction between TCP/IP based applications and the GPRS/EGPRS network (uplink direction) In the PS network, the continuous interruptions of data flow due to frequent establishments and releases of TBFs, reduce the performances of many TCP/IP based applications, such as Web Browsing applications. To reduce these disadvantages during uplink data transfer, a delay into the uplink TBF release procedure is introduced (see Fig. 9.14). The BSC delays the sending of the final PACKET UPLINK ACK/NACK message. This behavior is introduced to save time when a downlink LLC PDU arrives from SGSN just after the reception of the RLC Block having CV = 0. In this case the BSC can open the downlink TBF as a concurrent case, that is faster then the normal procedure (where normal means assignment messages sent on control channel, after the PACKET CONTROL ACKNOWLEDGEMENT message that has closed the uplink TBF). This delay is a fixed value (400 msec.), and it isn't longer because during this delay the MS can't require the opening of a new uplink TBF. If during the delay time a new downlink TBF is opened, final PACKET UPLINK ACK/NACK is sent without waiting the expiration of delay timer.
9.9.4 9.9.4.1
Operations on Downlink TBF Acknowledged and Unacknowledged Modes on Downlink TBFs

The mobile station receives RLC/MAC blocks on the assigned downlink PDCHs. On each assigned PDCH, the mobile station decodes the TFI value, and decodes the RLC data blocks intended for the mobile station. In acknowledged mode, to indicate to the MS when it has to send a PACKET DOWNLINK ACK/NACK message, the NRLCMAX parameter is defined: by this parameter the user can configure how many blocks have to be transmitted by the network, before receiving a PACKET DOWNLINK ACK/NACK message. In unacknowledged mode, the MS has to send a PACKET DOWNLINK ACK/NACK message after it has received 64 blocks (this is used to check the connection between the MS and the network, see below). Besides, for both the operation modes, a control procedure is used by the network to verify if the MS is correctly receiving the downlink RLC/MAC blocks. The network, using the RRBP field (see "9.8.4 Relative Reserved Block Period Field (RRBP)"), reserves the uplink resource to transmit control messages. The N3105 parameter implements the threshold for not received control messages from the MS, after sending RRPB field in downlink direction. If the threshold is reached the communication with the associated MS is broken. Every time the network doesnt receive the control message from the MS, the N3105 counter is increased; every time the network receives the control message from the MS, the N3105 counter is reset. When the N3105 counter reaches its maximum value (N3105max) the communication with the MS is broken (see Fig. 9.16). The user can configure the N3105max threshold, by the N3105 parameter.
A30808-X3247-L24-1-7618
199
N3105 = N3105 + 1
Reset N3105
N3105 = N3105 +1= N3105max
t NW sets RRPB NW has not received any in DL data block control message from the MS. NW has received a control message from the MS. NW has not received any control message from the MS. Communication with MS is broken.
Fig. 9.16
Control Procedure Executed by the Network during a Downlink TBF
9.9.4.2
Release of a Downlink TBF

The release of resources (see Fig. 9.17) is initiated by the network by terminating the downlink transfer and polling the MS for a final Packet Downlink Ack/Nack message. The network indicates the last downlink RLC data block by setting the Final Bit Indicator bit (FBI) to 1. It is possible for the network to change the current downlink assignment by using the Packet Downlink Assignment or Packet Timeslot Reconfigure message, which then has to be acknowledged by the MS in a reserved radio block on the uplink. The TFI handling is steered with timers that runs on both the MS and the network sides: after having sent the last RLC Data Block to the MS, the network starts the T3191 timer; when the MS receives the last RLC Data Block, the MS starts the T3192 timer; when it expires, the current assignment becomes invalid for the MS. Further, upon the reception of the final Packet Downlink Ack/Nack from the MS (with Final Ackn = 1), the T3193 timer is started on network side (and the T3191 timer is stopped). When it expires, the current assignment becomes invalid for the network, and TFI can be reused by the network.
200
A30808-X3247-L24-1-7618
Fig. 9.17
Release of a Downlink TBF If the mobile station (in acknowledged mode), after having received a RLC data block with FBI=1, transmits a PACKET DOWNLINK ACK/NACK message with the Final Ack indicator not set to 1, it shall continue to monitor all assigned PDCHs; in fact in this case the network has to retransmit some RLC blocks. If the network receives a PACKET DOWNLINK ACK/NACK message before timer T3191 expires, and if retransmissions are required, then the network stops timer T3191 and retransmits necessary RLC data blocks. Improving the overall performances in the interaction between TCP/IP based applications and the GPRS/EGPRS network (downlink direction) As it has been also described in 9.9.3.4, the continuous interruptions of data flow due to frequent establishments and releases of TBFs, reduce the performances of many TCP/IP based applications. To reduce these disadvantages during downlink data transfer, a delay into the downlink TBF release procedure is introduced (see Fig. 9.17). The BSC, before sending the FBI=1, waits for the expiration of a timer. The operator can set this timer by the TIMEDTBFREL attribute.
Setting the TIMEDTBFREL attribute to 0 means no the delay in TBF downlink releases. During this time the BSC maintains opened the downlink TBF, by sending Dummy LLC frames included in single RLC Blocks, having the polling bit (RRBP) set to one. There are two advantages using Dummy LLC frames:
A30808-X3247-L24-1-7618
201
1. the MS may request UL resource in the PACKET DOWNLINK ACK/NACK message; by these Dummy frames, the BSC presses the MS for an answer, i.e. if the MS has data to send, it will send it quickly. The delay time is not only inuenced by the network, but also by the MS, so the delay time can be different using different mobile stations; 2. if a new LLC should arrive from SGSN, it's possible to send the relative RLC block immediately (without an explicit assignment procedure). In this manner there is a virtually unique long single DL TBF, instead of several DL TBFs with a lot of assignment messages.
i
9.9.5
In BR7.0 release, polling periods last about 60 ms.
Notes About Concurrent TBFs

When concurrent TBFs have to be established during either the resource allocation or the resource upgrade strategy (see "6.3 Management of Packet Data Channels"), and when the multislot class of the mobile station allows a degree of freedom on how to assign resources between uplink and downlink, it is necessary to manage resources in an optimal way to balance the traffic of the two directions.
Mobile stations for which this problem arises is those providing a dynamic allocation of the number of resources, i.e. those belonging to multislot class from 6 to 12 (see Tab. 4.6). Tests with a mobile station with multislot class 6 have shown that with two simultaneous FTP connections, one in uplink and the other one in downlink direction (duplex FTP), in case of downlink preferred configuration (3+1) the downlink throughput is worse than in uplink preferred configuration (2+2). This is due to the fact that FTP connections are based on the TCP transfer protocol, which causes acknowledged traffic in the opposite direction. Because of the delayed acknowledgement packets (caused by the queue in MS or notebook, which is always full concerning the uplink traffic) the downlink transfer is reduced (stalled condition). If the chosen solution was always downlink biased (i.e. 3+1), also pure uplink traffic like FTP put would not be handled optimally, since the network would change to downlink preferred allocation as soon as first downlink TBFs for TCP/IP acknowledgments arrives. The current implementation to manage concurrent TBFs is the following. When a downlink data transfer is set up, data transfer is always allocated with downlink priority. Regarding the uplink direction, the mobile station might request the uplink TBF with either the Packet_Ressource_Request or the Packet_Downlink_Ack/Nack message (PDAN). Within these messages there is the Channel_Request_Description information element that contains a field called RLC_Octet_Count. The RLC_Octet_Count field indicates the number of RLC data octets, that the mobile station wishes to transfer; its range is from 0 to 65535, and: the value 0 is interpreted as a request for an open-ended TBF by the mobile station (i.e. the mobile station does not specify the number of blocks it has to transmit); all other values are interpreted as a request for a close ended TBF (i.e. the RLC_Octet_Count value indicates the number of blocks the MS has to transmit).
202
A30808-X3247-L24-1-7618
The RLC_Octet_Count field is also used to change the priority between uplink and downlink, such that the uplink allocation is extended. When the MS asks for uplink resources, if RLC_Octet_Count=0 or if RLC_Octet_Count is upper than a value defined by the THSULBAL parameter, then a switch from downlink priority to uplink priority is executed; in fact in this case the number of blocks the MS has to transmit is supposed to be quite big. Otherwise a timer defined by TSULBAL is activated. If the uplink TBF is closed until the timer is still running, then the timer is stopped and downlink priority in maintained; it the timer elapses and the uplink TBF is still opened, than a switch from downlink priority to the uplink one is executed.
9.9.6
Suspend/Resume Procedures
These procedures are used when the Circuit Switched dedicated mode is entered and it is temporarily necessary to suspend the GPRS/EGPRS service. In fact, when a GPRS/EGPRS-attached MS enters the Circuit Switched dedicated mode, and when the MS limitations make it unable to handle both the CS dedicated mode and the packet switched transfer mode, the MS requests the network for suspension of PS services. This is the case of a MS operating in Class B mode. The MS is attached to both PS and other CS services, but it can only operate one set of services at a time (see "9.1 Mobile Stations for Packet Switched Services"). For instance, an ongoing downlink transmission can be suspended, a circuit switched call accepted and, after the call release, the packet switched data transmission continued. The suspend procedure is explained in the following (see Fig. 9.18): 1. The MS enters the CS dedicated mode. 2. The MS sends a GPRS SUSPENSION REQUEST message to the BSC to inform the BSC that it shall suspend PS services. The GPRS SUSPENSION REQUEST message contains: the Temporary Logical Link Identity (TLLI); the Routing Area Identier (RAI); the Suspension Cause (SC). The BSC stores the information related to the request, namely the TLLI and the RAI, associating them to the CS call of the MS. 3. When the BSC receives the GPRS SUSPENSION REQUEST message, it sends a SUSPEND message to the SGSN containing the TLLI and the RAI; when the message is sent, the T3 timer is started. In case the T3 timer expires without receiving the ACK message from the SGSN, the SUSPEND message will be sent again and the T3 timer is restarted. This retry step is repeated up to SUSPEND-RETRIES times (SUSPEND-RETRIES=3.) In case the T3 timer expires SUSPEND-RETRIES times or a SUSPEND NACK is received from the SGSN, the suspend procedure is considered unsuccessful and an Alarm Reporting notication is sent to LMT/RC. 4. If the SGSN acknowledges the SUSPEND message by returning the SUSPEND ACK one, while the T3 timer is running, the procedure is considered successful. The BSS shall store TLLI and RAI in order to be able to request the SGSN to resume PS
A30808-X3247-L24-1-7618
203
services when the MS leaves dedicated mode; moreover the BSC receives from the SGSN also the SRN (Suspend Reference Number) information. The T3 timer is stopped and the involved TLLI is marked as "Suspended" in the BSC.
Each received SUSPEND-ACK message is discarded (without notification towards RC/LMT) by the BSC either if the MS related to the received TLLI/RAI is already "Suspended" or if the received TLLI/RAI does not correspond to a MS requiring the suspension. The BSC will suspend the GPRS/EGPRS service for the relevant MS, meaning that no traffic for the MS (TLLI/RAI) will be forwarded to the MS even if the radio resources are kept allocated to be available for the following Resume.
MS
BSC Dedicated Mode is entered
SGSN
MSC/VLR
GPRS SUSPENSION REQUEST
Start T3
SUSPEND (TLLI, RAI)
Stop T3
SUSPEND ACK (TLLI, RAI, SRN)
Fig. 9.18
Suspend Procedure
The BSC will start the resume procedure as soon as the circuit switched dedicated mode is left, that is when the MS is disconnected from the MSC. Two cases have to be distinguished: a) during the suspension period, the MS has remained in the same cell; b) during the suspension period the MS has changed cell or routing area. In case a) the resumption request is managed together with the SGSN; in the following this procedure is explained (the procedure in case of successful resume is shown in Fig. 9.19):
204
A30808-X3247-L24-1-7618
1. The BSC starts the resume procedure sending the RESUME message containing the TLLI, the RAI and the SRN towards the SGSN; the T4 timer is started too. In case the T4 timer expires without receiving the ACK message from the SGSN, the RESUME message will be sent again and the T4 timer is restarted. This retry step is repeated up to RESUME-RETRIES times (RESUME-RETRIES=3). In case the T4 timer expires RESUME-RETRIES times or a RESUME NACK is received from the SGSN, the resume procedure is considered unsuccessful and an Alarm Reporting notication is sent to LMT/RC. 2. If the SGSN acknowledges the RESUME message by returning the RESUME ACK one, while the T4 timer is running, the procedure is considered successful and the T4 timer is stopped. 3. In both cases, successful and unsuccessful, the involved TLLI is marked as "Not Suspended" in the BSC. Moreover, the BSC removes the information related to the previous suspend request and, in both cases, it closes the procedure by sending a CHANNEL-RELEASE message to the MS with the following topics: in the successful case, the message includes the "GPRS Resumption" infoelement set to "resumption of PS services successfully acknowledged"; otherwise, the "GPRS Resumption" will be set to "resumption of PS services not successfully acknowledged" In the former case, the MS will consider the GPRS/EGPRS service resumed, in the latter, it will be invited to initiate a Routing Area Update procedure.
Each received RESUME-ACK message is discarded if either the MS related to the received TLLI/RAI is already "Resumed" or the received TLLI/RAI does not correspond to a MS for which the resumption has been required. 4. eventually, the BSS determines that the circuit-switched radio channel shall be released. If the BSS is able to request the SGSN to resume PS services, the BSS shall send a Resume (TLLI, RAI) message to the SGSN. The SGSN acknowledges the successful outcome of the resume by returning Resume Ack; 5. the BSS sends an RR Channel Release (Resume) message to the MS. Resume indicates whether the BSS has successfully requested the SGSN to resume GPRS/EGPRS services for the MS, i.e., whether Resume Ack was received in the BSS before the RR Channel Release message was transmitted. The MS leaves dedicated mode; 6. if the BSS did not successfully request the SGSN to resume PS services, or if the RR Channel Release message was not received before the MS left dedicated mode, then the MS shall resume GPRS/EGPRS services by sending a Routing Area Update Request message to the SGSN, as described in subclause "Routing Area Update Procedure".
A30808-X3247-L24-1-7618
205
MS
BSC
SGSN
MSC/VLR
Start T4
RESUME (TLLI, RAI, SRN)
RESUME ACK (TLLI, RAI) Stop T4
Channel Release
Fig. 9.19
Resume Procedure (The MS Has Remained in the Same Cell - Successful Resume)
In case b) the resume procedure towards the SGSN is skipped; in the following this procedure is explained (the procedure is shown in Fig. 9.20): 1. The BSC removes the information related to the previous suspend request and it sends a CHANNEL-RELEASE message to the MS immediately. The information element "GPRS Resumption" will not be included in the message. 2. As a result, in case the Routing Area was changed, a Routing Area Update procedure is initiated by the MS; in case the cell was changed but not the Routing Area, depending on its state, the MS will continue in the following way: Ready state: a Cell Update procedure is initiated by the MS. The SGSN is therefore aware of the cell the MS is currently belonging to. Standby state: the MS does nothing. When the SGSN side Ready Timer expires, the SGSN will page the MS in the Routing Area it knows, in order to nd the right cell.
206
A30808-X3247-L24-1-7618
MS
BSC
SGSN
MSC/VLR
Channel Release (no Resumption Result)
Routing Area Update Request
Fig. 9.20
Resume Procedure (The MS has changed the Routing Area)
If the MS performs an inter-BSC handover while suspended, during handover procedure, the old BSC transfers to the new one, the Old BSS to New BSS information IE; this information element contains the GPRS Suspend information field (this field contains the SUSPEND ACK PDU message sent on the Gb interface. With this information the new BSC is able to resume the MS that was suspended in the old BSC, without executing any routing area update procedure.
In BR7.0 the GPRS/EGPRS Suspend/Resume feature is automatically enabled in the system, and both T3 and T4 timers can not be set by the operator, but they assume the following default values: - T3 = 5 sec - T4 = 1 sec
9.9.7
Notes About GPRS/EGPRS TBF Scheduling

The distribution of the active TBFs over the available GPRS/EGPRS carriers, and the multislot allocation of a particular TBF on the timeslots of the corresponding GPRS/EGPRS carrier, is done by the resource allocation algorithm, which is described in "6.3 Management of Packet Data Channels". Once resources have been allocated, allowing each TBF to reach the maximum required throughput, it is up to the scheduler to dynamically assign permissions to access the physical channels, when several TBFs are multiplexed on the same resources. Therefore the scheduler is be able to handle the case when EGPRS and GPRS mobiles are multiplexed on the same PDCHs: in this case the main problem is due to the fact that GPRS mobiles are not able to read the USF in downlink blocks transmitted with 8PSK modulation; therefore uplink and downlink scheduling must be performed jointly, trying to avoid to set USFs for GPRS mobiles in 8PSK coded downlink blocks. Moreover, when different TBFs are multiplexed together, the scheduler takes into account their different QoS requirements. The scheduler then assures that each TBF is served according to its own priority.
A30808-X3247-L24-1-7618
207
9.9.7.1
Supported QoS Attributes

As already mentioned, the task of the scheduler is to distribute permissions to access the physical resources, after the allocation phase performed by the resource manager. The QoS requirements to fulfil are linked to the R97/98 QoS attributes that can be handled by the BSS; these attributes are different between uplink and downlink directions. As regards downlink scheduling, the BSC handles the two R97/98 attributes specified in the DL-UNITDATAs coming from the Gb interface; they are. the Peak Throughput (used in the allocation phase); the Service Precedence. The Service Precedence, strictly speaking, indicates the relative importance of maintaining the service commitments under abnormal conditions, for example which packets are discarded in the event of problems such as limited resources or network congestion. Therefore even if this attribute should be used to handle congestion cases, it seems reasonable to simplify things, handling it in the scheduling phase. So, the Service Precedence is then used to assign different priorities to different connections; there are three possible values, from 1 (highest priority) to 3 (lowest priority). Consequently, the scheduling priorities (needed to prioritize among TBFs that share the same resources) are defined as follows: QoS Attribute Service Precedence = 1 Service Precedence = 2 Service Precedence = 3 Scheduling Priority 1 2 3
When multiple TBFs are allocated on the same physical resources, they will be served according to their own scheduling priorities, see next paragraphs for details. As regards the scheduling of uplink TBFs, the Radio Priority attribute is used. Such an attribute is mapped one to one to uplink scheduling priority as follows: QoS Attribute Radio Priority = 1 Radio Priority = 2 Radio Priority = 3 Radio Priority = 4 Scheduling Priority 1 2 3 4
9.9.7.2
Scheduling Process
As a general rule the scheduling algorithm for each PDCH checks the active TBFs onto that timeslot, both in uplink and in downlink directions; then it verifies the scheduling priorities of each TBF, and associates to each priority the corresponding scheduling weights Wk. In fact each scheduling priority is associated to a specific scheduling weight: the association between priorities and weights can be performed by the user by the following parameters: SCHWEIPRI1: weight associated to scheduling priority 1; SCHWEIPRI2: weight associated to scheduling priority 2;
208
A30808-X3247-L24-1-7618
SCHWEIPRI3: weight associated to scheduling priority 3; SCHWEIPRI4: weight associated to scheduling priority 4.
For each direction of transmission, and for each timeslot, the algorithm then selects a TBF using a deterministic approach which guarantees that each TBF(i) is selected W(i) times each sum(Wk) extractions, where W(i) is the scheduling weight of TBF(i) and sum(Wk) is the sum of the scheduling weights of all the TBFs allocated on the same timeslot. Besides, there are several cases that require high priority handling, both in downlink and uplink directions. These cases are: Polling Requests: when a MS needs to be polled, the scheduler manages the downlink block (containing the RRBP value) for this MS, with an higher priority than other blocks to be sent in downlink direction; Downlink Control Blocks for uplink TBFs: when a downlink control block (i.e. Packet Uplink Ack/Nack message) must be sent for an uplink TBF, the scheduler manages the downlink block for this uplink TBF, with an higher priority than other blocks to be sent in downlink direction; Constraint due to PCCCH Scheduling: if the PCCCH channel is allocated on a certain timeslot, some radio blocks in a multiframe should be reserved for PCCCH. So, the scheduler manages, on this timeslot, both the downlink PCCCH blocks (PBCCH, PAGCH, PPCH) and the uplink PCCCH blocks (PRACH) with an higher priority than other blocks to be sent in downlink/uplink direction on the same timeslot. Besides, when EGPRS and GPRS mobiles are multiplexed on the same PDCHs some further constraints have to be taken into account. The main problem is due to the fact that GPRS mobiles are not able to read the USF in downlink blocks transmitted with 8PSK modulation. Therefore uplink and downlink scheduling must be performed jointly, trying to avoid to set USFs for GPRS mobiles in 8PSK-coded downlink blocks. In this case the problem arises when, e.g., a downlink block coded with 8PSK modulation has to be sent and at the same time the USF should be coded with GMSK modulation to allow to a GPRS-only mobile station to read the USF value and to transmit on the next uplink block. To solve this incompatibility, the following approach is used: a) if the downlink block corresponds to a TBF that is using the GMSK modulation, an USF (the rst in the list of the USF to be transmitted) corresponding to a GMSK mobile is selected; if there are no GMSK USF, then an 8PSK one is selected, because this choice does not cause any problem; b) If the downlink block corresponds to a TBF that is using the 8PSK modulation, an USF (the rst in the list of the USF to be transmitted) corresponding to a 8PSK mobile is selected; if there are no more 8PSK USF to be scheduled (in the list), then: one more 8PSK USF is anyhow selected (starting from UL TBFs with higher priority/weight) at the same time one GMSK USF is cancelled from the list; after a few cancellations for a given TBF, a GMSK USF for that TBF is inserted in an High_priority list (i.e. a list of TBF to be served with an higher priority). This guarantees that, even in worst case scenarios (only 8PSK TBFs in downlink), some GMSK USFs are still transmitted.
A30808-X3247-L24-1-7618
209
10 GPRS/EGPRS Functionalities
10.1 Cell Selection and Re-selection
No Handover functionality is foreseen for PS services: the MS selects the best cell following cell re-selection criteria. If the MS is involved in data transfer, packets may be lost during cell re-selection. Upper layers will then recognize the inconsistency, discard the frame and ask for a retransmission. In GPRS standby and ready states (see "9.3.1 Mobility Management States"), cell reselection is performed by the MS. The only exception regards class A mobile stations in dedicated mode of a circuit switched connection: in this case the cell is determined by the network according to the handover procedures, since the handover takes precedence over GPRS/EGPRS cell re-selection. When the circuit switched connection is released, the MS resumes the cell re-selection process. For GPRS/EGPRS mobile stations, new re-selection criteria (C1, C31 and C32) can be used. These new algorithms apply to the MSs attached to GPRS/EGPRS if the PBCCH exists in the serving cell.
The C1 criterion is the same criterion used in GSM cell selection and re-selection processes, but it make use of new parameters (see "10.1.2.1 GPRS/EGPRS Path Loss Criterion (C1 Criterion)"). If PBCCH exists, the MS is not required to monitor system information on both the serving cell and non-serving cells, but it is only required to monitor system information on PBCCH of the serving cell. In other words: if PBCCH is congured, the GPRS/EGPRS MS retrieves all the information, regarding both the serving cell and neighboring cells, from the serving PBCCH; the MS monitors the other BCCH carriers only to take signal level measurements; if PBCCH is not congured, the GPRS/EGPRS MS retrieves all the information regarding the serving cell from the serving BCCH, while the information about neighboring cells are taken from the BCCH carriers of the neighboring cells; the MS monitors the other BCCH carriers also to take signal level measurements.
If PBCCH is not configured, i.e. PS services are supported only on BCCH, old C1 and C2 criteria are used for cell selection and re-selection purposes.
In addition, it is possible to run a procedure, which is called Network Controlled CellReselection (see "10.3 Network Controlled Cell Reselection and Traffic Control Management"), where the network may control the cell selection process. If the PBCCH is configured, cells to be monitored for cell re-selection are defined in the BA(GPRS) list, which is broadcast on PBCCH. This list could be different from the BA(BCCH) list, that is used for GSM. If PBCCH does not exist, BA(GPRS) list is equal to the BA(BCCH) one (see "10.1.4 Management of GPRS/EGPRS Neighboring Cells").
10.1.1
Measurements for Cell Selection and Re-selection

The MS measures the received RF signal level on: the BCCH carrier of the serving cell; the BCCH carriers of surrounding cells as indicated in the BA(GPRS) list.
210
A30808-X3247-L24-1-7618
Then it calculates the average received level (RLA_P) for each carrier. In addition the MS verifies the BSIC of the BCCH carriers. Only cells with allowed BSIC are considered for re-selection purposes. A distinction must be done between mobile stations in packet idle mode and mobile stations in packet transfer mode: a) Packet Idle Mode: whilst in packet idle mode a MS monitors continuously all BCCH carriers as indicated by the BA(GPRS) list and the BCCH carrier of the serving cell. At least one receive signal level measurement sample on each BCCH carrier is taken for each paging block monitored by the MS according to its current DRX mode and its paging group (see "9.8.3.2 Discontinuous Reception"). The MS shall take at least one measurement for each BCCH carrier for every 4 second. The MS is however not required to take more than 1 sample per second for each BCCH carrier. RLA_P is an average level determined using samples collected over a period of 5 s, and is maintained for each BCCH carrier. The same number of measurement samples is taken for all BCCH carriers, and the samples allocated to each carrier shall as far as possible be uniformly distributed over the evaluation period. At least 5 received signal level measurement samples are required for a valid RLA_P value. The list of the 6 strongest non serving carriers are updated at a rate of at least once per running average period. The MS shall attempt to check the BSIC for each of the 6 strongest non serving cell BCCH carriers at least every 14 consecutive paging blocks of that MS, or 10 seconds, whichever is greater. If a change of BSIC is detected then the carrier shall be treated as a new carrier. In the case of a multiband MS, the MS shall attempt to decode the BSIC, if any BCCH carrier with unknown BSIC is detected, among the number of strongest BCCH carriers in each band, as indicated by the GNMULBAC parameter (MULTIBAND_REPORTING); this parameter is broadcast on PBCCH, or if PBCCH does not exist, on BCCH. b) Packet Transfer Mode: whilst in packet transfer mode a MS monitors continuously all BCCH carriers as indicated by the BA(GPRS) list and the BCCH carrier of the serving cell. In every TDMA frame, a received signal level measurement sample is taken on at least one of the BCCH carriers, one after the another. RLA_P is an average value determined using samples collected over a period of 5 s, and is maintained for each BCCH carrier. The samples allocated to each carrier shall as far as possible be uniformly distributed over the evaluation period. At least 5 received signal level measurement samples are required for a valid RLA_P value. The MS shall attempt to check the BSIC for each of the 6 strongest non serving cell BCCH carriers as often as possible, and at least every 10 seconds. A multi-RAT MS is allowed to extend this period to 13 seconds, if the neighbor cell list contains cells from other RATs and if indicated by the GUMTSSRHPRI parameter. The MS shall use the two Idle frames of the PDCH multiframe for this purpose. These frames are termed search frames. In the case of a multiband MS, the MS shall attempt to decode the BSIC, if any BCCH carrier with unknown BSIC is detected, among the number of strongest BCCH carriers in each band, as indicated by the GNMULBAC parameter (MULTIBAND_REPORTING); this parameter is broadcast on PBCCH, or if PBCCH does not exist, on BCCH.
A30808-X3247-L24-1-7618
211
10.1.2 10.1.2.1
Cell selection and Re-selection Criteria GPRS/EGPRS Path Loss Criterion (C1 Criterion)
The MS measures the received signal level on the PBCCH carriers of the serving cell and the surrounding cells and calculate the mean received level (RLA_P) for each carrier, where: RLA_P(s) is the averaged level for the serving cell; RLA_P(n) are the averaged levels for neighboring cells. Cells to be monitored for cell reselection are defined by the BA(GPRS) list, which is broadcast on PBCCH, At least 5 received signal level measurement samples are required for a valid RLA_P:
RLA_P = 1/5 * (GPRS_RXLEV1 + GPRS_RXLEV2 + ...+ GPRS_RXLEV5) The path loss criterion C1, i.e. the minimum signal level criterion for GPRS/EGPRS cell selection and cell re-selection, is defined by:
C1 = RLA_P GPRS_RXLEV_ACCESS_MIN Max( 0, GPRS_MS_TXPWR_MAX_CCH P) Where: - P is the Power Class of the MS; - GPRS_RXLEV_ACCESS_MIN is the minimum allowed received level to access a cell; the user can define this value by the GRXLAMI parameter; - GPRS_MS_TXPWR_MAX_CCH is the maximum power that the MS can use to access the cell; the user can define this value by the GMSTXPMAC parameter.
The path loss criterion is satisfied if C1>0.

This means that the minimum allowed received downlink level to access the network has to be above a threshold defined by GRXLAMI value. To ensure a sufficient uplink received level even for MS of low transmit power level P, the C1 criteria works as follows: If P < GPRS_MS_TXPWR_MAX_CCH C1 = RLA_P GPRS_RXLEV_ACCESS_MIN (GPRS_MS_TXPWR_MAX_CCH P) i.e. the received level must be higher than the access threshold (GPRS_RXLEV_ACCESS_MIN) plus another term, given by the difference between the maximum power that can be transmitted in the cell (GPRS_MS_TXPWR_MAX_CCH) and the nominal power of the MS (P).
If P > GPRS_MS_TXPWR_MAX_CCH
212
A30808-X3247-L24-1-7618
C1 = RLA_P GPRS_RXLEV_ACCESS_MIN i.e. the received level must be only higher than the access threshold (GPRS_RXLEV_ACCESS_MIN); in fact in this case the nominal power of the MS is higher than GPRS_MS_TXPWR_MAX_CCH.
C1 criterion is just an assessment about the field strengths (on both uplink and downlink directions). If PBCCH is used, the C1 criterion is calculated by the same formula used in GSM, but with a separate parameter set (i.e. GRXLAMI and GMSTXPMAC), which is transmitted on the PBCCH. With this separate parameter set it is possible for the network operator to configure in a different way the cell selection and reselection procedures, for GPRS/EGPRS and not-GPRS/EGPRS subscribers. If PBCCH is not configured, the C1 criterion is calculated by means of the same formula and parameters (i.e. RXLEVAMI and MSTXPMAXCH) used for GSM cell selection and re-selection. Please remember that on PBCCH the network has the chance to indicate in the BA(GPRS) list a different set of neighboring cells with respect to the BA list transmitted on BCCH (see 10.1.4).
Beside the C1 radio criterion, there are some other criteria for a cell to be suitable for GPRS/EGPRS cell selection purpose: a cell is considered suitable for GPRS/EGPRS cell selection if: 1. 2. 3. 4. C1 is greater than 0; the cell belongs the selected PLMN; the cell supports PS services; the cell is not barred.
10.1.2.2
C31 Criterion
The C31 signal level threshold criterion for hierarchical cell structures (HSCs) is used to determine whether prioritized hierarchical GPRS/EGPRS cell re-selection is applied. It is defined by: Serving Cell C31(s) = RLA_P(s) HCS_THR(s)
Neighboring Cell PRIORITY_CLASS(n) = PRIORITY_CLASS (s) C31(n) = RLA_P(n) HCS_THR(n)
Neighboring Cell PRIORITY_CLASS(n) < > PRIORITY_CLASS (s) There are two cases: If T<=GPRS_PENALTY_TIME C31(n) = RLA_P(n) HCS_THR(n) GPRS_TEMPORARY_OFFSET(n)
A30808-X3247-L24-1-7618
213
If T > GPRS_PENALTY_TIME C31(n) = RLA_P(n) HCS_THR(n)

Where: HCS_THR is the signal threshold for applying GPRS/EGPRS hierarchical cell structures criteria in cell reselection. The user can dene this threshold by means of the GHCSTH parameter. The user denes the threshold both for the cell and for its neighboring cells, in fact: HCS_THR(s) represents the threshold of the serving cell; the user species it by the GHCSTH parameter of the PTPPKF object; HCS_THR(n) represents the thresholds of neighboring cells; the user sets a HCS_THR(n) value for every adjacent relationship, by the GHCSTH parameter of the ADJC object; PRIORITY_CLASS is the priority of each cell. The user can dene this priority by the GHCSPC parameter (an higher value means an higher priority). The user defines the priority both for the cell and for its neighboring cells, in fact: PRIORITY_CLASS(s) represents the priority of the serving cell; the user species it by the GHCSPC parameter of the PTPPKF object; PRIORITY_CLASS(n) represents the priority of neighboring cells; the user sets a PRIORITY_CLASS(n) value for every adjacent relationship, by the GHCSPC parameter of the ADJC object; GPRS_TEMPORARY_OFFSET(n) applies a negative offset to C31 for the duration of GPRS_PENALTY_TIME(n) after the timer T has started for that cell. The T timer is started in the MS for each cell in the list of the 6 strongest neighboring cells, as soon as it is placed in the list. T is reset to 0 if the cell is removed from the list. GPRS_PENALTY_TIME is the duration for which GPRS_TEMPORARY_OFFSET applies. The user sets a GPRS_TEMPORARY_OFFSET(n) value and a GPRS_PENALTY_TIME(n) value for every adjacent relationship, by GTEMPOFF and GPENTIME parameters of the ADJC object.
Regarding the previous parameters, it is important to underline that their values are broadcasted on the PBCCH of the serving cell, i.e. the MS can retrieve all the cell reselection information from the PBCCH of the serving cell without monitoring the other neighboring carriers. To understand how this feature is implemented, see "10.1.4 Management of GPRS/EGPRS Neighboring Cells". This is different from the traditional GSM implementation for which the MS has to retrieve the cell re-selection parameters of the neighboring cells, by reading their BCCH carriers.
C31 is used for hierarchical cell structures; the advantage is that C31 uses also a priority mechanism. It is necessary to introduce C31 into GPRS/EGPRS, to make re-selection for PS services similar to the GSM handover algorithm. The MS need to get information of the neighbor cells (e.g. in which layer the neighboring cells are laying, and which priority the neighbor cells have), to decide about cell reselection. For CS services the Handover decision is done completely by the BTS, so there is not the necessity to give additional information to the MS.
214
A30808-X3247-L24-1-7618
10.1.2.3
C32 Criterion
The C32 cell ranking criterion is used to select cells among those with the same priority. It is defined by: Serving Cell C32(s) = C1(s)
Neighboring Cell PRIORITY_CLASS(n) = PRIORITY_CLASS (s) There are two cases: If T <= GPRS_PENALTY_TIME C32(n) = C1(n) + GPRS_RESELECT_OFFSET(n) GPRS_TEMPORARY_OFFSET(n)
If T <= GPRS_PENALTY_TIME C32(n) = C1(n) + GPRS_RESELECT_OFFSET(n)

Neighboring Cell PRIORITY_CLASS(n) < > PRIORITY_CLASS (s) C32(n) = C1(n) + GPRS_RESELECT_OFFSET(n)
Where: PRIORITY_CLASS is the priority of each cell. The user can dene this priority by the GHCSPC parameter (an higher value means an higher priority). The user defines the priority both for the cell and for its neighboring cells, in fact: PRIORITY_CLASS(s) represents the priority of the serving cell; the user species it by the GHCSPC parameter of the PTPPKF object; PRIORITY_CLASS(n) represents the priority of the neighboring cells; the user sets a PRIORITY_CLASS(n) value for every adjacent relationship, by the GHCSPC parameter of the ADJC object; GPRS_RESELECT_OFFSET(n) is a positive offset that increases the priority of cell in the list of the strongest neighbor cells. The user sets a GPRS_RESELECT_OFFSET(n) value for every adjacent relationship, by GRESOFF parameter of the ADJC object; GPRS_TEMPORARY_OFFSET(n) applies a negative offset to C32 for the duration of GPRS_PENALTY_TIME(n) after the timer T has started for that cell. The T timer is started in the MS for each cell in the list of the 6 strongest neighboring cells, as soon as it is placed on the list. T is reset to 0 if the cell is removed from the list. GPRS_PENALTY_TIME is the duration for which GPRS_TEMPORARY_OFFSET applies. The user sets a GPRS_TEMPORARY_OFFSET(n) value and a GPRS_PENALTY_TIME(n) value for every adjacent relationship, by GTEMPOFF and GPENTIME parameters of the ADJC object. GPRS_RESELECT_OFFSET, GPRS_TEMPORARY_OFFSET, PRIORITY_CLASS and GPRS_PENALTY_TIME are broadcast on PBCCH of the serving cell.
A30808-X3247-L24-1-7618
215
Regarding the previous parameters it is important to underline that their values are broadcasted on the PBCCH of the serving cell, i.e. the MS can retrieve all the cell reselection information from the PBCCH of the serving cell without monitoring the other neighboring carriers. To understand how this feature is implemented, see "10.1.4 Management of GPRS/EGPRS Neighboring Cells". This is different from the traditional GSM implementation for which the MS has to retrieve the cell re-selection parameters of the neighboring cells, by reading their BCCH carriers.
C32 is similar to the C2 criteria used for GSM, but it makes use of GPRS/EGPRS parameters. C32 contains in addition to C1 an offset (to make a cell better or worse than another) and a temporary offset, which is used to make the cell worse during the first x seconds (i.e. the MS must "see" that cell for that period of time before it may re-select it; this can be used for preventing some cells to be re-selected by a fast driving MS).
10.1.3
Cell Re-selection Algorithm

The MS makes a cell reselection if: C1 (serving cell) < 0 for a period of 5 seconds; MS detects DL Signalling failure (e.g. no paging has been possible); Cell becomes barred. Beside these conditions that regard only the serving cell, other conditions derives from the comparison between the serving cell and the neighboring ones. There are different conditions: a) Both GPRS/EGPRS serving cell and GPRS/EGPRS neighboring cells configured with BCCH; ; b) Both GPRS/EGPRS serving cell and GPRS/EGPRS neighboring cells configured with PBCCH. a) GPRS/EGPRS serving cell and GPRS/EGPRS neighboring cells configured with BCCH
C2 (GSM) criteria is switched on; a cell reselection is executed if:

C2 (GPRS/EGPRS serving cell) < C2 (suitable GPRS/EGPRS neighboring cell) If the suitable neighboring cell is in the same location area for a period of 5sec C2(GPRS/EGPRS serv. cell) + CELL_RESELECT_HYST < C2 (suit. GPRS/EGPRS neigh.cell) If the suitable neighboring cell is in another location area for a period of 5 sec.
The C1 value of the neighboring cell must be obviously greater than 0.
C2 (GSM) criteria is not switched on; a cell reselection is executed if:

C1 (GPRS/EGPRS serving cell) < C1 (suitable GPRS/EGPRS neighboring cell) If the suitable neighboring cell is in the same location area for a period of 5 seconds.
216
A30808-X3247-L24-1-7618
C1(GPRS/EGPRS serv. Cell) + CELL_RESELECT_HYST < C1 (suit. GPRS/EGPRS neigh.cell) If the suitable neighboring cell is in another location area for a period of 5 sec.
The CELL_RESELECT_HYST value is defined by the user through the GSM CELLRESH parameter. b) GPRS/EGPRS serving cell and GPRS/EGPRS neighboring cells configured with PBCCH First of all the C31 criterion for the serving cell and all neighboring cells is calculated. Under all these cells the best cells are found, therefore it is checked: If there are cells for which C31>=0, then only for these cells the PRIORITY_CLASS is checked. If there is only one cell with the highest PRIORITY_CLASS, then this cell will be the best cell to make cell reselection on. If there are more cells with the highest PRIORITY_CLASS, then for these cells the C32 criterion will be calculated. The cell with the highest C32 criterion will be the best cell to make cell reselection on. If there arent cells for which C31>0, then the C32 criterion is calculated for all cells. The cell with the highest C32 criterion will be the best cell to make cell reselection on. When evaluating the better cell, the following hysteresis values shall be subtracted from the C32 value of the neighboring cells: a) in standby state, if the new cell is the same routing area no hysteresis values are subtracted; b) in ready state, if the new cell is in the same routing area, a GPRS_CELL_RESELECT_HYSTERESIS value is subtracted, to delay a cell reselection, as a TBF might be interrupted; the user sets this hysteresis by means of the GCELLRESH parameter.
If the C31H parameter (C31_HYST) is set to TRUE, and the MS is in MM ready state, the GPRS_CELL_RESELECT_HYSTERESIS is also subtracted from the C31 value for the neighboring cells.
c) in standby or ready state, if the new cell is in a different routing area a RA_RESELECT_HYSTERESIS value is subtracted, to delay a cell re-selection, as routing area changes will produce a lot of extra signalling; the user sets this hysteresis by means of the RARESH parameter. d) in case of a cell re-selection occurred within the previous 15 seconds a value of 5dB is subtracted. C31_HYST, RA_RESELECT_HYSTERESIS, and RA_RESELECT_HYSTERESIS are broadcast on the PBCCH of the serving cell.
If the parameter C32QUAL (C32_QUAL) is set to TRUE, positive GPRS_RESELECT_OFFSET values are only applied to the neighbors with the highest RLA_P value, among those cells for which C32 is compared above.
A30808-X3247-L24-1-7618
217
Cell re-selection for any other reason (see GSM 03.22) takes place immediately, but the cell that the MS was camped on shall not be returned to within 5 seconds, if another suitable cell can be found. If valid RLA_P values are not available, the MS shall wait until these values are available and then perform the cell re-selection if it is required. The MS may accelerate the measurement procedure within the requirements to minimize the cell reselection delay. If no suitable cells are found within 10 seconds, the cell selection algorithm shall be performed. Since information concerning a number of channels is already known by the MS, it may assign high priority to measurements on the strongest carriers from which it has not previously made attempts to obtain BCCH information and omit repeated measurements on the known ones.
10.1.4 10.1.4.1
Management of GPRS/EGPRS Neighboring Cells Handling of Neighboring Cells

A mechanism has been introduced to manage both internal adjacent cells (i.e. cells belonging to the same BSC) and external adjacent cells (i.e. cells belonging to other BSCs). The management of both internal and external adjacent cells is provided by using the TGTCELL attribute of the ADJC object; this attribute is a mandatory one that specifies the path of the target cell instance (see the explanation below). On creating an adjacent cell relationship it shall be made a distinction between two possible situations: adjacency between cells supporting only GSM service (adjacent relationships between BTSs); adjacency between cells supporting GPRS/EGPRS service too (adjacent relationships between PTPPKFs). ADJACENT RELATIONSHIPS BETWEEN BTSs In case of an adjacency to an internal BTS, the TGTCELL attribute will contain a reference (i.e. the complete path) to the internal target BTS. In case of external adjacency the TGTCELL attribute will contain a reference to a new object, namely the TGTBTS object. A TGTBTS managed object instance contains a copy of the attributes of an external BTS MOI, to which an adjacent relationship has to be made up. Once a TGTBTS MOI is configured, it will be treated by the system, for the management of the adjacencies, as the other internal target BTSs. This means that, in the case in which the external target BTS is adjacent to more than one internal serving BTS, it will no more be necessary to replicate all the attribute values in every ADJC managed object instance, but it will be enough that the different ADJC MOIs refer to the same TGTBTS MOI. Fig. 10.1 shows the management of adjacent cells.
218
A30808-X3247-L24-1-7618
Fig. 10.1
Management of Adjacent Cells Referring to BTS:1, two adjacent relationships are built: BTS:1/ADJC:1; internal adjacent relationship towards BTS:2 (belonging to BSC:1); BTS:1/ADJC:2; external adjacent relationship towards BTS:5 (belonging to BSC:2). When the user creates the ADJC1 instance he must specify only those attributes that are not enclosed in BTS:2 (i.e. handover management attributes), while for the other attributes (i.e. BCCH, BSIC, CELLGLID, etc.) the TGTCELL attribute provides the reference to BTS:2. When the user creates the ADJC2 instance he must specify only those attributes that are not enclosed in BTS:5 (i.e. handover management attributes). The TGTCELL attribute will provide the reference to the TGTBTS:0 instance, that contains all the attributes (i.e. BCCH, BSIC, CELLGLID, etc.) enclosed in BTS:5. So, the user, before creating an external adjacent relationship, must create the TGTBTS instance containing the attributes belonging to the external cell. ADJACENT RELATIONSHIPS BETWEEN PTPPKFs The same considerations apply for the management of the adjacencies between PTPPKFs. The TGTPTPPKF object class is introduced to configure, in the BSC database, external GPRS/EGPRS neighboring cells.
A30808-X3247-L24-1-7618
219
Functional object TGTPTPPKF
Meaning Configure external GPRS/EGPRS neighboring cells.
Tab. 10.1
TGTPTPPKF Object.
The TGTPTPPKF object class is hierarchically dependent by the TGTBTS object class, in the containment tree. A TGTPTPPKF managed object instance will contain a copy of the attributes, of an external PTPPKF instance, involved in the management of the adjacency. Once a TGTPTPPKF object instance is configured, it is treated by the system, for the management of the adjacencies, as the other internal target PTPPKFs. Therefore: in case of internal adjacency, the TGTCELL attribute identies the target PTPPKF instance, through the reference to the superordinate BTS instance; in case of external adjacency, the TGTCELL will identify the TGTPTPPKF object instance, through the reference to the superordinate TGTBTS object instance.
i
10.1.4.2
For each serving cell, it is possible to configure up to 32 neighboring cells supporting GPRS/EGPRS.
GPRS/EGPRS Neighboring Cells and Involved Parameters

As it has been described in the previous chapters, cell re-selection parameters of both the serving cell and its neighboring cells are transmitted on the PBCCH of the serving cell. In this way a MS camped on a cell can read all the re-selection parameters without synchronizing to the other cells. This happens only if the PBCCH is configured on the serving cell; if the PBCCH is not configured on the serving cell: 1. old C1 and C2 GSM criteria, and old GSM parameters are used for cell re-selection; 2. the MS takes the re-selection parameters of the neighboring cells from the BCCHs of those cells; i.e. the MS has to synchronize to these cells to read their data. To allow to the MS to read from the PBCCH of the serving cell the re-selection parameters of neighboring cells, the involved parameters are specified both in the PTPPKF and in the ADJC/TGTPTPPKF objects. Tab. 10.2 shows these parameters. Siemens GRXLAMI GMSTXPMAC GHCSTH GHCSPC GRESOFF GTEMPOFF Tab. 10.2 ETSI GPRS_RXLEV_ACCESS_MIN GPRS_MS_TXPWR_MAX_CCH HCS_THR PRIORITY_CLASS GPRS_RESELECT_OFFSET GPRS_TEMPORARY_OFFSET
Parameters Involved in the Management of GPRS/EGPRS Neighboring Cells
220
A30808-X3247-L24-1-7618
Siemens GPENTIME Tab. 10.2
ETSI GPRS_PENALTY_TIME
Parameters Involved in the Management of GPRS/EGPRS Neighboring Cells
Among parameters shown in Tab. 10.2 a distinction must be done: a) GRXLAMI and GMSTXPMAC parameters are only cell parameters; i.e. they must be dened on a cell basis only, using the PTPPKF object. Nevertheless to allow the transmission of the neighboring cell parameters in the packet system information of the serving cell, they shall be also dened for every adjacent relationship; they must be dened in the TGTPTPPKF object, only if the adjacent cell does not belong to the same BSC of the serving one; b) GHCSTH and GHCSPC parameters are dened both on a cell basis and on the adjacent relationship basis; they are dened on a cell basis in the PTPPKF object to dene the values for the cell; for each neighboring cell of the involved cell, the two parameters are specied in the ADJC object, to species the values of the neighboring cells. c) GRESOFF, GTEMPOFF and GPENTIME parameters regard only adjacent relationships; i.e. for each neighboring cell of the involved cell, the parameter values are specied in the ADJC object, to indicate the values of the neighboring cells. To manage the previous features, the following three parameters (belonging to the ADJC object) are involved: GSUP this parameter is meaningful only if the PBCCH is congured on the serving cell. It enables the transmission of parameters of the neighboring cell, it is referred to, in the packet system information of the serving cell. The following considerations can be done about GSUP: if the PBCCH is not enabled in the serving cell, the GSUP in meaningless, but PS sevices are active in the neighboring cell however. So, if in the serving cell the GSUP attribute of one of its neighboring cell is set to FALSE, the MS can re-select the cell (with GSM C1 and C2) without any problem. if the PBCCH is enabled in the serving cell, the neighborhoods that will be considered in the BA(GPRS) list will be those cells for which the GSUP attribute has been set to TRUE in the adjacent relationship. 2. TGTCELL when the cell is internal, this parameter allows to make a link to the BTS (PTPPKF) object the denes this cell in the database; if the cell is external, this parameter allows to make a link to the TGTBTS (TGTPTPPKF) object the denes this cell in the database. 1.
10.1.4.3
Configuration of an Adjacent Cell with GSUP= TRUE

When the PBCCH is configured on the serving cell and the user configures a neighboring cell with GSUP=TRUE two cases exists: 1. the neighboring cell is internal; 2. the neighboring cell is external.
A30808-X3247-L24-1-7618
221
In the following these two possibilities are examined from the point of view of the GPRS/EGPRS parameters shown in Tab. 10.2. The Neighboring Cell is INTERNAL If the target cell is internal, the user by means of the TGTCELL attribute executes a link to the BTS object (and as a consequence to the PTPPKF one) related to this cell. Regarding parameters shown in Tab. 10.2, the following considerations can be done: GRXLAMI and GMSTXPMAC parameters must not be dened in the TGTPTPPKF object (because this object in this case does not exist for the neighboring cell), since they are cell parameters and they are directly taken from the linked PTPPKF object; 2. GHCSPC and GHCSTH parameters could be specied in the ADJC object; if they are not specied, their default values are taken; 3. GPENTIME, GRESOFF and GTEMPOFF parameters could be specied in the ADJC object; if they are not specied, their default values are taken. 1. The Neighboring Cell is EXTERNAL If the target cell is external, the user by means of the TGTCELL attribute executes a link to the TGTBTS object (and as a consequence to the TGTPTPPKF one) related to this cell, since this object does not belong to the same BSC. Regarding the parameter shown in Tab. 10.2, the following considerations can be done: GRXLAMI and GMSTXPMAC parameters must be dened in the TGTPTPPKF object; they must have the same values that they have in the PTPPKF object of the BSC database where they have been dened; 2. GHCSPC and GHCSTH parameters could be specied in the ADJC object; if they are not specied, their default values are taken; 3. GPENTIME, GRESOFF and GTEMPOFF parameters should be specied in the ADJC object; if they are not specied, their default values are taken. 1.
When the target cell is external, both RACODE and RACOL parameters (see "9.2 Network Structure") must be specified in the TGTPTPPKF object; they must have the same values that they have in the database where they have been defined.
10.1.4.4
Configuration of an Adjacent Cell with GSUP= FALSE

In this case, since GSUP is set to FALSE for the neighboring cell, the GPRS/EGPRS reselection parameters of the neighboring cell are not transmitted in the serving cell. Besides, this cell is not included in the BA(GPRS) list, i.e. the list of cells over which GPRS/EGPRS re-selection can be done; from the GSM point of view the cell is always considered for cell re-selection purposes (using GSM C1 and C2 criteria). To well understand, letss consider the following example referred to a cell (in which the PBCCH is configured) that has 10 neighboring cells. If: for 6 neighboring cells the GSUP attribute is set to TRUE; for the remaining 4 cells the GSUP attribute is set to FALSE; then starting from the serving cell: 6 cells can be re-selected from the PS/CS services point of view by means of C1 (with GPRS/EGPRS parameters), C31 and C32 criteria; 4 cells can be re-selected only from GSM mobile stations by means of C1 (with GSM parameters) and C2 criteria.
222
A30808-X3247-L24-1-7618
In this case we have a BA(GPRS) list composed by 6 cells, and a BA(GSM) list composed by 10 cells.
Considering the previous example, if in the same cell the PBCCH is not configured, both the BA(GPRS) list and the BA(GSM) list are composed by 10 neighboring cells, since the GSUP attribute is meaningless. When the PBCCH is configured on the serving cell and the user configures a neighboring cell with GSUP= FALSE, independently if the neighboring cell is internal of external, the GPRS/EGPRS re-selection parameters must not be specified in the ADJC object, since they are not transmitted on the serving cell.
10.1.5
Abnormal Cell Re-selection

In the event of an abnormal release with cell reselection when PBCCH exists, an abnormal cell reselection based on BA(GPRS) list is attempted.
E.g. the mobile station starts the abnormal release with cell reselection procedure after having made M+1 attempts to send a Packet Channel Request on PRACH, without receiving any answer from the network (see "9.8.2.6 Uplink Access on PRACH (Access Persistence Control)"). To enable the abnormal cell re-selection, the RAARET (RANDOM_ACCESS_RETRY) parameter must be set to TRUE. This parameter allows to enable the abnormal cell reselection starting from the serving cell, when an abnormal release with cell reselection occurs. The MS performs the following algorithm to determine which cell to be used for this cell reselection attempt: 1. the received level measurement samples, taken on the neighboring carriers indicated in the BA (GPRS) list, and received in the last 5 seconds, are averaged; the carrier with the highest received average level (RLA) and with a permitted BSIC is taken; 2. on this carrier the MS attempts to decode the PBCCH data block containing the parameters affecting cell selection; 3. if: the C1 parameter is greater than zero; the cell belongs to the selected PLMN; the cell is not barred; access in another cell is allowed, i.e. RAARET parameter is set to TRUE; the abnormal cell reselection is attempted on this cell; 4. if the MS is unable to decode the PBCCH data block, or if the conditions in step 3. are not met, the carrier with the next highest received average level (RLA) and with a permitted BSIC is taken; then the MS repeats steps 2. and 3.; 5. if the cells with the 6 strongest received average level values (and with permitted BSICs) have been tried, but cannot be used, the abnormal cell reselection attempt is abandoned, and the usual reselection algorithm (see "10.1.3 Cell Re-selection Algorithm") is performed. When a MS has executed an abnormal cell reselection, it is not allowed to reselect the original cell for a number of seconds specified by the TRESEL parameter. The MS is under no circumstances allowed to access a cell to attempt abnormal cell reselection later than 20 seconds after the detection within the MS of the abnormal release causing the abnormal cell reselection attempt. In the case where the 20 seconds
A30808-X3247-L24-1-7618
223
elapses without a successful abnormal cell reselection, the attempt is abandoned, and the usual reselection algorithm (see "10.1.3 Cell Re-selection Algorithm") is performed. In the event of an abnormal release with cell reselection when only BCCH exists, the MS only performs the usual reselection algorithm, using the C1 and C2 criteria of GSM.
10.2
Cell Re-selection from GSM/GPRS/EGPRS Network to UMTS Network

With the introduction of the UMTS network, it becomes very important to allow a dual mode mobile station to re-select an UMTS cell starting from a GSM one. Without this feature, once a dual mode GSM/UMTS terminal is camped on the GSM/GPRS/EGPRS network, it does not have the possibility to select the UMTS network
Only the re-selection of a UMTS cell starting from the GSM network is considered; the opposite case is outside the scope of this chapter. To allow this feature, the UMTS adjacent cell information must be sent (in the 3G Cell Reselection List) on the broadcast carrier of the GSM network, to inform the UE/MS which UMTS frequencies have to be monitored for re-selection purposes. For this monitoring, the MS may use search frames that are not required for BSIC decoding. If indicated by the parameter GUMTSSRHPRI, the MS may use up to 25 search frames per 13 seconds without considering the need for BSIC decoding in these frames. According to both the type of service the MS supports and the configuration of the serving GSM cell, two different algorithms are defined to reselect an UMTS cell (either FDD cell or TDD one), starting from a GPRS/EGPRS one; so we can have: 1. re-selection of the UMTS cell in case of circuit switched modality; this type of reselection is executed when: the MS is not GPRS/EGPRS attached (so it must use the circuit switched modality to re-select UMTS cells); the MS is attached to GPRS/EGPRS services, but the PBCCH channel is not congured in the GSM serving cell; 2. re-selection of the UMTS cell in case of packed switched modality; this modality is used when the MS is GPRS/EGPRS attached and the PBCCH has been congured in the serving cell. In the following, the two cases are briefly discussed.
10.2.1
GSM-UMTS Re-selection Algorithm: Circuit Switched Case

When the PBCCH is not configured in the serving cell, the MS performs a cell re-selection to an adjacent UMTS (FDD or TDD) cell, only if the following conditions are satisfied for a period of 5 seconds: for the serving cell: RSCP(UTRAN cell) >= RLA_C_s + XXX_Qoffset for all the suitable GSM neighboring cells: RSCP(UTRAN cell) >= RLA_C_n + XXX_Qoffset
224
A30808-X3247-L24-1-7618
and also (only for FDD cells): Ec/No (UTRAN FDD cell) >= FDD_Qmin where: RSCP (Received Signal Code Power): is the power level received from the UMTS cell; Ec/No: is the signal/noise ratio regarding the UMTS FDD cell; RLA_C_s: is the power level received from the serving cell; RLA_C_n: is the power level received from neighboring cells; XXX_Qoffset: offset for cell reselection for UMTS cells; the user sets this value by the FDDQO parameter (BTS object) for FDD cells, or by TDDQO parameter (BTS object) for FDD cells; FDD_Qmin: minimum threshold for Ec/No for UMTS FDD cell re-selection; the user sets this value by the FDDQMI parameter of the BTS object. If the 3G Cell Reselection list (sent by the network to the MS) includes UTRAN frequencies, the MS shall, at least every 5 seconds update the RLA_C value for the serving cell and each of the at least 6 strongest non-serving GSM cells. The MS shall then reselect a suitable UTRAN cell if its measured RSCP value exceeds the value of RLA_C for the serving cell and all of the suitable non-serving GSM cells by the value XXX_Qoffset for a period of 5 seconds, and (only in case of FDD cells) the UTRAN cells measured Ec/No value is equal or greater than the value FDD_Qmin. In case of a cell reselection occurring within the previous 15 seconds, XXX_Qoffset is increased by 5 dB. If more than one UTRAN cell fulfill the above criteria, the MS selects the cell with the highest RSCP value. If the MS has reselected a GSM cell from an UTRAN one, cell reselection to UTRAN does not occur within 5 seconds, if a suitable GSM cell can be found. There is also a threshold by which the network indicates whether the measurements for the cell reselection of the UMTS cells should be performed or not; the threshold indicates if the signal level of the serving cell should be below or above it, in order to perform UMTS cells measurements; the user sets this value by the QSRHI parameter of the BTS object.
i
10.2.2
FDDQO, TDDQO, FDDQMI and QSRHI parameters are broadcast on the BCCH of the serving cell.
GSM-UMTS Re-selection Algorithm: Packet Switched Case

When the PBCCH is configured in the serving cell, the MS performs a cell re-selection to an adjacent UMTS (FDD or TDD) cell, only if the following three conditions are satisfied for a period of 5 seconds: for the serving cell: RSCP(UTRAN cell) >= RLA_P_s + XXX_GPRS_Qoffset for all the suitable GSM neighboring cells: RSCP(UTRAN cell) >= RLA_P_n + XXX_GPRS_Qoffset
A30808-X3247-L24-1-7618
225
and also (only for FDD cells): Ec/No (UTRAN FDD cell) >= FDD_Qmin where: RSCP (Received Signal Code Power): it is the power level received from the UMTS cell; Ec/No: is the signal/noise ratio; RLA_P_s: is the power level received from the serving cell; RLA_P_n: is the power level received from the neighboring cells; XXX_GPRS_Qoffset: offset for cell reselection for FDD cells; the user sets this value by the FDDGQO parameter of the PTPPKF object for FDD cells, or by the TDDGQO parameter of the PTPPKF object for TDD cells; FDD_Qmin: minimum threshold for Ec/No for UMTS FDD cell re-selection; the user sets this value by the FDDQMI parameter of the BTS object; If the GPRS 3G Cell Reselection list includes UTRAN frequencies, the MS shall, at least every 5 second update the value RLA_P for the serving cell and each of the at least 6 strongest non-serving GSM cells. The MS shall then reselect a suitable UTRAN cell if its measured RSCP value exceeds the value of RLA_P for the serving cell and all of the suitable non-serving GSM cells by the value XXX_GPRS_Qoffset for a period of 5 seconds and (only in case of FDD cells) the UTRAN cells measured Ec/No value is equal or greater than the value FDD_Qmin. In case of a cell reselection occurring within the previous 15 seconds, XXX_GPRS_Qoffset is increased by 5 dB. If more than one UTRAN cell fulfill the above criteria, the MS selects the cell with the highest RSCP value. If the MS has reselected a GSM cell from an UTRAN one, cell reselection to UTRAN does not occur within 5 seconds, if a suitable GSM cell can be found. There is also a threshold by which the network indicates whether the measurements for the cell reselection of the UMTS cells should be performed or not; the threshold indicates if the signal level of the serving cell should be below or above it, in order to perform UMTS cells measurements; the user sets this value by the QSRHPRI parameter of the PTPPKF object.
i
10.2.3
FDDGQO, TDDGQO, FDDQMI and QSRHPRI parameters are broadcast on the PBCCH of the serving cell.
Handling of UMTS Neighboring Cells

Besides defining the re-selection criteria, the user must also define the UMTS neighboring cells to be re-selected (obviously a UMTS cell is always considered an external cell, i.e. a cell that does not belong to the BSC). To define an UMTS neighboring cell for a specific BTS object instance, the user create an instance of the ADJC3G object (subordinated to the BTS one).
For each BTS object instance, the user can define up to 32 neighboring GSM/GPRS/EGPRS cells (ADJC object) and up to 64 neighboring UMTS cells (ADJC3G object). The TGTCELL parameter of the ADJC3G object contains a reference to:
226
A30808-X3247-L24-1-7618
a TGTFDD object instance, in case of FDD neighboring cell; a TGTFDD managed object instance contains all the parameters that allow to describe, in the BSC database, the external UMTS FDD cell (the same principle as described in "10.1.4.1 Handling of Neighboring Cells" is used to manage external UMTS cells too). The more important parameters of the TGTFDD object are: CELLGLID (C-ID cell identier): it identies univocally the UMTS FDD cell in the UMTS/GSM networks and it is composed by MCC (Mobile Country Code), MNC (Mobile Network Code), LAC (Location Area Code) and CI (Cell Identier); FDDARFCN: it denes the frequency of the cell; RNCID: it identies the RNC; FDDSCRMC: it denes the scrambling code; FDDDIV: it indicates if diversity is applied for the cell. a TGTTDD object instance, in case of TDD neighboring cell; a TGTTDD managed object instance contains all the parameters that allow to describe, in the BSC database, the external UMTS TDD cell. The more important parameters of the TGTTDD object are: CELLGLID (C-ID cell identier): it identies univocally the UMTS TDD cell in the UMTS/GSM networks and it is composed by MCC (Mobile Country Code), MNC (Mobile Network Code), LAC (Location Area Code) and CI (Cell Identier); TDDARFCN: it denes the frequency of the cell; RNCID: it identies the RNC; BNDWIDTDD: it denes the bandwidth used for TDD; TDDDIV: it indicates if diversity is applied for the cell.
So, before creating the ADJC3G object related to an UMTS neighboring cell of a specific BTS, the user must have already created either the TGTFDD or the TGTTDD object defining the UMTS cell. In this way, different BTS objects, having as neighboring cell the same UMTS cell, will indicate the same TGTFDD (or the same TGTTDD) object instance in the adjacent relationship defined by the subordinate ADJC3G object instance. EXAMPLE: if the TGTFDD:0 instance has been created to define in the BSC database an UMTS cell, this UMTS cell can be defined as adjacent of both the BTS:1 and BTS:5 cells in the following way: if for example the ADJC3G:4 instance of the BTS:1 object, represents the neighboring relationship towards the UMTS cell dened by the TGTFDD:0 instance, the user sets the TGTCELL attribute equal to TGTFDD:0; if for example the ADJC3G:2 instance of the BTS:5 object, represents the neighboring relationship towards the UMTS cell dened by the TGTFDD:0 instance, the user sets the TGTCELL attribute equal to TGTFDD:0.
10.3
Network Controlled Cell Reselection and Trafc Control Management

As it has been described in "10.1 Cell Selection and Re-selection", normally the cell reselection algorithm is executed by the mobile station. Every MS in packet idle mode and in packet transfer mode measures received signals from both the serving cell and neighboring ones, and performs autonomously cell reselection.
A30808-X3247-L24-1-7618
227
The Network Controlled Cell Reselection is another available cell reselection method: the network may request the measurement reports from the MSs and control their cell reselection. So, if the user enables this feature, the network can ask the mobile to transmit the carrier level of both serving and adjacent cells through packet measurement reports; depending on these reported values, the network can transfer a mobile station to a another cell, which is better from a radio condition point of view. This algorithm is called Radio Link Network Controlled Cell Reselection, because the network cell reselection brings mobile stations to another cell that is better from the radio condition point of view. But there is another topic that must be considered: the BSC allocates PDCHs as long as there are available resources in a given cell. This might lead to congestion, although in neighboring cells traffic capacity might be available. So, if the user enables the Traffic Control feature, the network may redistribute MSs among cells, to satisfy the maximum number of service requests; i.e. the Traffic Control Network Controlled Cell Reselection can be executed. The Traffic Control network controlled cell reselection guarantees the optimum usage of resources, i.e. the better traffic distribution among the available channels in all the available cells. So, even if the handover functionality is not foreseen for GPRS/EGPRS services, the functionality of the traffic control network controlled cell re-selection has the same purpose of the handover due to traffic, i.e. the distribution of MSs among cells according to network criteria. It must be clear that: a) if the user enables only the network controlled cell reselection feature, only the Radio Link controlled cell reselection is enabled; b) if the user wants to enable the Trafc Control controlled cell reselection, he has to enable, besides the network controlled cell reselection, the trafc control strategy too. In the following paragraphs the following subjects are described: 10.3.1 describes how the network controlled cell reselection works; 10.3.1.1 describes some notes about packet measurement reports; 10.3.1.2 describes the Radio Link network controlled cell reselection algorithm; 10.3.1 and 10.3.2.1 describe the Trafc Control strategy and the related trafc control network controlled cell reselection algorithm.
10.3.1
Network Controlled Cell Reselection

As it has been said, with the Network controlled cell reselection, the network may request measurement reports from the MSs and control their cell re-selection. The NTWCOR (NETWORK_CONTROL_ORDER) parameter indicates if and how the network controls the reselection process. The meaning of different values of the NTWCOR parameter is specified as follows: NC0: normal MS control; the MS performs autonomous cell re-selection as described in "10.1 Cell Selection and Re-selection"; NC1: MS control with measurement reports; the MS sends measurement reports to the network, but it performs autonomous cell re-selection; NC2: network control; the MS sends measurement reports to the network, and it does not perform autonomous cell re-selection.
228
A30808-X3247-L24-1-7618
The NETWORK_CONTROL_ORDER parameter is broadcast from the network to all MS in the cell, by PSI5 on PBCCH or SI13 on BCCH. Alternatively the network can use the Packet_Measurement_Order or Packet_Cell_Change_Order messages on PACCH to address a particular MS. To enable the Network Controlled Cell Reselection feature the user must set at ENABLE the NCRESELFLAG parameter, belonging to the BSC object.
Remember that when the user set at ENABLE the NCRESELFLAG parameter, only the radio link controlled cell reselection is enabled. When the feature is enabled, the network can ask the mobile (by setting the NTWCOR parameter for that mobile, see below) to transmit the carrier level of both serving and adjacent cells; then the MS sends measurement reports periodically. The period is defined by two attributes: NTWCREPPIDL (NC_REPORTING_PERIOD_I) for MS in idle mode; NTWCREPPTR (NC_REPORTING_PERIOD_T) for MS in transfer mode.
Regarding measurement reports, there is also the NTWCNDRXP parameter the defines the minimum time the mobile station shall stay in non-DRX mode after a measurement report has been sent with the mobile in packet idle mode; but this parameter is not used, since, as it has been described below, MSs in packet idle mode do not send measurement reports. GPRS and EGPRS mobiles in packet idle mode work always in NC0 mode, otherwise the network would have to manage the packet measurement reports and associated access requests needed by mobiles to transmit periodically packet measurement reports. In fact taking into account that the longest period of transmission of packet measurement report for mobile in packet idle mode is about 60 seconds, at least 60 channel requests per mobile per hour have to be considered, only for measurement report transmission; this would increase very hardly PCU real time requirements. Besides there are impacts even on battery power safe. Consequently NC2 will be used only for mobiles in packet transfer mode, which will then submit measurement reports with the reporting period defined by NTWCREPPTR. So, if the network controlled cell reselection is enabled (NCRESELFLAG set at ENABLE) things work in the following way. The NTWCOR broadcast value (PSI5 on PBCCH or SI13 on BCCH) is always NCO, so every mobile station in packet idle mode does not transmit any packet measurement report to the BTS. When a GPRS/EGPRS mobile station is involved in a TBF (uplink or downlink), the BSC modifies the NTWCOR mode value, from NC0 to NC2, by the Packet Measurement Order message, transmitted to that single mobile on PACCH. This message carries also the NTWCREPPTR parameter, which overwrites the correspondent value optionally broadcasted by PSI5 or SI13. In the Packet Measurement Order message NTWCNDRXP and NTWCREPPIDL have not significant value (MS transmits packet measurement report only in packet transfer mode). After this change, mobile working in NC2 control mode transmits periodically Packet Measurement Report messages to BSC: if MS is involved in uplink TBF, it uses an USF scheduled block; if Ms is involved in downlink TBF, it uses a RRBP assigned block. If needed conditions are verified (see "10.3.1.2 Radio Link Network Controlled Cell Reselection Algorithm" and "10.3.2.1 Network Controlled Cell Reselection Algorithm for
A30808-X3247-L24-1-7618
229
Traffic Control Strategy") the BSC may transfer the MS to another cell by a Packet Cell Change Order message; this message contains: the characteristics of the new cell that are necessary to identify it (i.e. BSIC + BCCH frequency); the network controlled measurement parameters valid for the mobile station in the new cell (e.g. NTWCREPPTR); the IMMEDIATE_REL parameter. Upon receipt of the Packet Cell Change Order message the mobile station starts timer T3174. When a network controlled cell reselection is made, the mobile station shall act upon the IMMEDIATE_REL value which has been received in the Packet Cell Change Order. If required, it shall immediately abort any TBF in progress by immediately ceasing to decode the downlink and to transmit on the uplink, stopping all RLC/MAC timers except for timers related to measurement reporting, otherwise the mobile station may continue its operation in the old serving cell, until TBF end. The mobile station shall then switch to the identified new cell and shall obey the relevant RLC/MAC procedures on this new cell. The mobile station regards the procedure as completed when it has received a successful response to its access request on the new cell. If timer T3174 expires before a response to the access request message has been received on the new cell, or, if an IMMEDIATE ASSIGNMENT REJECT or PACKET ACCESS REJECT message is received from the new cell, or, if the contention resolution procedure fails on the new cell, then the mobile station shall start timer T3176 and return to the old cell. If the mobile station was in uplink packet transfer mode or in a simultaneous uplink and downlink packet transfer mode before the cell change, the mobile station shall establish a new uplink TBF and send the PACKET CELL CHANGE FAILURE message on this TBF. The mobile station shall then resume its uplink transfer on this TBF. When the mobile station has sent a PACKET CELL CHANGE FAILURE message, timer T3176 shall be stopped. If T3176 expires and the mobile station was previous in an uplink packet transfer mode or in a simultaneous uplink and downlink packet transfer mode on the old cell, the mobile station shall perform the abnormal release with random access. If the mobile station was previous in a downlink packet transfer mode only on the old cell the mobile station shall perform an abnormal release with return to CCCH or PCCCH. On the mobile station side, if the Packet Cell Change Order message instructs the mobile station to use a frequency that it is not capable of using, then the mobile station shall return a PACKET CELL CHANGE FAILURE message with cause "frequency not implemented". If the Packet Cell Change Order message is received by the mobile while a circuit switched connection is on-going, then the mobile station shall return a PACKET CELL CHANGE FAILURE message with the cause "on-going CS connection". When a network controlled cell reselection occurs (ordered by the BSC), the BSS shall signal this exception condition to a SGSN by sending a RADIO-STATUS PDU (Radio Cause value: cell reselection ordered). It shall contain a reference to the MS, (either TLLI or TMSI or IMSI). This condition indicates that the SGSN should wait for a cell update or a routing area update before resuming the transmission of LLC PDU to the BSS. When the MS changes cell, it starts a cell update procedure or a routing area update procedure towards the SGSN.
230
A30808-X3247-L24-1-7618
After this procedure, the SGSN transmits the FLUSH_LL message towards BSC indicating the new cell where the MS is entered. The BSC uses this indication to route the queued RLC blocks related to that MS; if the cell belongs to a different PPXU, the queued RLC blocks are discarded. Then the BSC transmits the FLUSH_LL_ACK message to the SGSN, indicating if re-route or discard is made. It is responsibility of the higher layer protocols in the SGSN to cope with discarded LLC frames. If new cell belongs to another SGSN, a inter_SGSN routing area update is required before the TBF starts in the new cell (Fig. 10.2 shows this procedure). Before ending TBF, the BSC changes again the network control mode to NC0, so when this mobile station enters the packet idle mode, it no longer transfers packet measurement reports.
MS
Packet Cell Change Order Start T3174
BSC
SGSN
Radio Status Cell Change
EGPRS Packet Channel Request Packet Uplink Assignment Stop T3174 End of Cell Update or Routing Area update Flush II Flush II Ack
Fig. 10.2
Network Controlled Cell Reselection Procedure
10.3.1.1
Measurement Reporting
As it has been described, after each reporting period defined by NTWCREPPTR, the MS sends a measurement report to the BSS. The MS shall then discard any previous measurement report, which it has not been able to send. The Packet Measurement Report contains: RXLEV for the serving cell; received signal level for the non-serving cells. For normal measurement reporting, carriers shall be reported if they are among the 6 strongest carriers and BSIC is successfully decoded and allowed i.e. either equal to the BSIC of the list or with allowed NCC part of BSIC. In the latter case, which applies for BA(BCCH) where no BSIC is given, the decoded BSIC shall be included in the report.
A30808-X3247-L24-1-7618
231
In the case of a multiband MS, the MS shall report the number of strongest BCCH carriers in each band as indicated by the GNMULBAC parameter, broadcast on PBCCH, or if PBCCH does not exist, on BCCH. For multi-RAT MS, the MS shall report the number of best valid cells in each other radio access technology as indicated by specific parameters: GFDDMURREP (GPRS FDD MULTIRAT REPORTING) and GTDDMURREP (GPRS TDD MULTIRAT REPORTING) parameters dene the number of best valid UMTS neighbor cells (FDD and TDD) which shall be reported by the MS/UE. The remaining positions in the measurement report shall be used for reporting of GSM cells. If there are still remaining positions, these shall be used to report the next best valid UMTS cells. In this case, the received signal level is replaced by the relevant measurement quantity.
The UMTS FDD measurement quantity Ec/No is not a suitable parameter for a comparison with the GSM received level because the Ec/No is a quality parameter and not a received level parameter. Therefore, the GFDDREPQTY parameter (FDD_REP_QUANT), is introduced in order to tell the GPRS/EGPRS attached MS/UE whether to report, to the BTS, the RSCP value (GFDDREPQTY=RSCP) or the Ec/No one (GFDDREPQTY=EC_NO). Network Controlled Cell Reselection towards the UMTS network is not supported in BR7.0.
i
10.3.1.2
Radio Link Network Controlled Cell Reselection Algorithm

When the network controlled cell reselection is enabled (i.e. the NCRESELFLAG parameter is set at ENABLE) the radio link controlled cell reselection algorithm is executed by the BSC.
The algorithm works, independently if the GPRS/EGPRS control strategy (see "10.3.2 GPRS/EGPRS Traffic Control Strategy") has been enabled by the operator. When the radio scenario of the mobile station is degraded, the BSC chooses a better neighboring cell and commands that mobile to move on this new cell. According to what has been described in "10.3.1 Network Controlled Cell Reselection" the mobile station sends measurement reports to the BSC; when the BSC receives a packet measurement report from a mobile, the following values are calculated: the C1 value for the serving cell [C1(s)]; and the C1 value for each adjacent cell [C1(n)] reported in the packet measurement report. The C1 value for both serving and neighboring cells is calculated with the following criteria:
C1 = RLA_P GPRS_RXLEV_ACCESS_MIN Max( 0, GPRS_MS_TXPWR_MAX_CCH P) Where:
232
A30808-X3247-L24-1-7618
- P is the Power Class of the MS; - GPRS_RXLEV_ACCESS_MIN is the minimum allowed received level to access a cell; the user can define this value by the GRXLAMI parameter (for the serving cell this parameter is set in the PTPPKF object, for neighboring cells it is set in the TGTPTPPKF one); - GPRS_MS_TXPWR_MAX_CCH is the maximum power that the MS can use to access the cell; the user can define this value by the GMSTXPMAC parameter (for the serving cell this parameter is set in the PTPPKF object, for neighboring cells it is set in the TGTPTPPKF one). If C1(s) < NCC1TH, the mobile has to be moved to another cell, for avoiding to lose it.
The PKTMEASREPCNT parameter specifies how many consecutive measurements, of the BCCH carrier of the serving cell, under the NCC1TH threshold, are necessary to order a cell change. First of all, among the neighboring cells reported in the packet measurement report, only those for which C1 (n) > NCC1THADJC are selected. Then, according to the value of the NCSARA attribute, the selected cells are ordered according to different priorities. If NCSARA = TRUE, the adjacent cell is searched before among cells belonging to the same routing area of serving cell; so the following priorities are used to order cells: 1. 2. 3. 4. 5. target cell with the same Routing Area on the same PPXU/PPCU; target cell with different Routing Area but on the same PPXU/PPCU; target cell with the same Routing Area on different PPXU/PPCU and same BSC; target cell with different Routing Area on different PPXU/PPCU and same BSC; target cell on different PPXU/PPCU and different BSC.
If NCSARA = FALSE, adjacent cells of the same routing area have no priority compared to adjacent cells of other routing areas; so the following priorities are used to order cells: 1. target cell with the same RA or target cell with different RA but on the same PPXU/PPCU; 2. target cell on different PPUX/PPCU and same BSC; 3. target cell on different PPUX/PPCU and different BSC. Among neighboring cells having the same priority, the cell with the highest C32(n) value is chosen. The C32(n) value is calculated as: there are two cases: If T <= NC_GPRS_PENALTY_TIME C32(n) = C1(n) + NC_GPRS_RESELECT_OFFSET(n) NC_GPRS_TEMPORARY_OFFSET(n)
If T <= NC_GPRS_PENALTY_TIME C32(n) = C1(n) + NC_GPRS_RESELECT_OFFSET(n)

Where: NC_GPRS_RESELECT_OFFSET(n) is a positive offset that increases the priority of cell in the list of the strongest neighbor cells. The user sets a NC_GPRS_RESELECT_OFFSET(n) value for every adjacent relationship, by NCGRESOFF parameter of the ADJC object;
A30808-X3247-L24-1-7618
233
NC_GPRS_TEMPORARY_OFFSET(n) applies a negative offset to C32 for the duration of NC_GPRS_PENALTY_TIME(n) after the timer T has started for that cell. The T timer is started for each cell in the list of the 6 strongest neighboring cells, as soon as it is placed on the list. T is reset to 0 if the cell is removed from the list. NC_GPRS_PENALTY_TIME is the duration for which NC_GPRS_TEMPORARY_OFFSET applies. The user sets a NC_GPRS_TEMPORARY_OFFSET(n) value and a NC_GPRS_PENALTY_TIME(n) value for every adjacent relationship, by NCGTEMPOFF and NCGPENTIME parameters of the ADJC object.
When NCSARA is set at FALSE an hysteresis value is subtracted from the C32 value for the neighbor cells. The hysteresis value can be set by the user via the NCRARESH parameter, belonging to the PTPPKF object. NCRARESH must be set at DB00 (default value) when NCSARA is set at TRUE.
10.3.2
GPRS/EGPRS Traffic Control Strategy

The GPRS/EGPRS Traffic Control Strategy feature makes possible to control the traffic distribution among cells belonging to the same PCU; the feature is based on the Network Controlled Cell Reselection one (see 10.3.1) and on appropriate trafc thresholds set in each cell. In fact, the Network Controlled Cell Re-Selection feature introduces the management of measurements related to the neighboring cells reported by the GPRS/EGPRS MS, but it does not specify any traffic control strategy, on how to run this available information (only radio link conditions are taken into account); the GPRS/EGPRS Traffic Control Strategy feature exploits this information to distribute the trafc among all available network resources. To enable the Traffic Control Strategy feature at BSC level, the user must set at TRUE the TRFPS (trafficPs) parameter
The feature can be enabled only if Network Controlled Cell Reselection feature (see 10.3.1) is already enabled. When TRFPS is set at TRUE the traffic control algorithm is applied (see "10.3.2.1 Network Controlled Cell Reselection Algorithm for Traffic Control Strategy"). The feature goal is to spread the cell traffic on more than one cell, that is to move MSs inside an high traffic cell towards available resources in neighboring cells.
Traffic control algorithm is applied only to cells belonging to the same PCU, because every PCU knows its own traffic only. Traffic control algorithm performs an evaluation of the radio resource occupation into each cell, based on the number of channels configured and in service available for GPRS/EGPRS, and the type of strategy set by the operator.
234
A30808-X3247-L24-1-7618
10.3.2.1
Network Controlled Cell Reselection Algorithm for Traffic Control Strategy

When the Traffic control strategy is enabled, every TBF activation it is checked if, for a specific cell, the radio resource occupation has reached or exceeded a threshold, defined by the CRESELTRHSOUT parameter.
The radio link criteria, described in "10.3.1.2 Radio Link Network Controlled Cell Reselection Algorithm" is maintained also when Traffic Control Strategy is enabled. In positive case, the algorithm looks for MSs candidates to be forced to a cell reselection. The mobile(s) to move are chosen among those in packet transfer mode, applying the following criteria for the choice of target cell. First of all, among the neighboring cells reported in the packet measurement report, only those for which C1 (n) > NCC1THADJC are selected. Then, according to the value of the NCSARA attribute, the selected cells are ordered according to different priorities. If NCSARA = TRUE, the adjacent cell is searched before among cells belonging to the same routing area of serving cell; so the following priorities are used to order cells: 1. target cell with the same Routing Area on the same PPXU/PPCU; 2. target cell with different Routing Area but on the same PPXU/PPCU. If NCSARA = FALSE, adjacent cells of the same routing area have no priority compared to adjacent cells of other routing areas; so only priority level exist, i.e. target cell with the same RA or target cell with different RA but on the same PPXU/PPCU Among neighboring cells having the same priority, the cell with the highest C32(n) value is chosen. The C32(n) value is calculated as: there are two cases: If T <= NC_GPRS_PENALTY_TIME C32(n) = C1(n) + NC_GPRS_RESELECT_OFFSET(n) NC_GPRS_TEMPORARY_OFFSET(n)
If T <= NC_GPRS_PENALTY_TIME C32(n) = C1(n) + NC_GPRS_RESELECT_OFFSET(n)

Where: NC_GPRS_RESELECT_OFFSET(n) is a positive offset that increases the priority of cell in the list of the strongest neighbor cells. The user sets a NC_GPRS_RESELECT_OFFSET(n) value for every adjacent relationship, by NCGRESOFF parameter of the ADJC object; NC_GPRS_TEMPORARY_OFFSET(n) applies a negative offset to C32 for the duration of NC_GPRS_PENALTY_TIME(n) after the timer T has started for that cell. The T timer is started for each cell in the list of the 6 strongest neighboring cells, as soon as it is placed on the list. T is reset to 0 if the cell is removed from the list. NC_GPRS_PENALTY_TIME is the duration for which NC_GPRS_TEMPORARY_OFFSET applies. The user sets a NC_GPRS_TEMPORARY_OFFSET(n) value and a NC_GPRS_PENALTY_TIME(n) value for every adjacent relationship, by NCGTEMPOFF and NCGPENTIME parameters of the ADJC object. When NCSARA is set at FALSE an hysteresis value is subtracted from the C32 value for the neighbor cells. The hysteresis value can be set by the user via the NCRARESH
A30808-X3247-L24-1-7618
235
parameter, belonging to the PTPPKF object. NCRARESH must be set at DB00 (default value) when NCSARA is set at TRUE. The algorithm also looks for a possible candidate cell to move a MS into. A cell can be a candidate for this procedure only if: it belongs to the same PCU of the serving cell; it is adjacent to the origin cell (i.e. the relevant ADJC object already exists); it is not barred; it supports the GPRS service and its resource occupation is under a threshold. This threshold can be set by the user by means of the CRESELTRSHINP parameter. Then, the number of MSs to be forced in reselection is determined taking as many MSs as the radio resources that have to be released, in order to put the traffic load under the NCTRFPSCTH parameter. The network sends to each concerned MS a PACKET CELL CHANGE ORDER message with the indication of the new cell where the MS has to perform the cell reselection.
10.4
Power Control
The objective of the power control feature is to adapt the transmitted power of the MS, as well as of the BTS, to the reception conditions. The advantages of the power control algorithm are substantially two: 1. reduction of the power consumption of the MSs batteries; 2. reduction of the interference which is experienced by both co-channel and neighboring channel users. For the uplink, the MS follows a flexible power control algorithm, which the network can optimize through a set of parameters. The algorithm can be used for both the following power control methods: open loop power control: the MS output power is based on the received signal strength at the MS side, assuming the same path loss in uplink and downlink directions; closed loop power control: the MS output power is commanded by the network based on signal measurements made in the BTS. In BR7.0 only open loop power control is supported. For the downlink, the power control is performed in the BTS. Therefore, there is no need to specify the actual algorithm, but information about the downlink performance is needed. Therefore the MSs have to transfer Channel Quality reports to the BTS. In BR7.0 downlink power control is not supported: power control is a mandatory feature for the MS, while it is optional for the network.
10.4.1
Power Control Algorithm

The RF output power, Pch, to be employed by the MS on each individual uplink PDCH is given by the following formula:
Pch= min (GAMMA0 - GAMMAch - ALPHA * (C+48), Pmax) where:
(1)
236
A30808-X3247-L24-1-7618
is a MS and channel specific power control parameter, sent to the MS in control messages such as IMMEDIATE ASSIGNMENT, PACKET UPLINK/DOWNLINK ASSIGNMENT, PACKET UPLINK ACK/NACK. The operator can set this value using the GAM parameter of the PTPPKF object. GAMMA0: = 39 dBm for GSM900 = 36 dBm for DCS1800. ALPHA: is the ALPHA system parameter, which is broadcast on BCCH/PBCCH or optionally sent to MS in a control message. C: is the normalized received signal level at the MS side Pmax: is the maximum allowed output power in the cell. It is equal to: - GMSTXPMAC if PBCCH is configured in the serving cell; - MSTXPMAXCH (i.e. the analogous GSM parameter) otherwise. Power levels are expressed in dBm. When the MS receives either a new GAM or ALPHA value, the MS shall use the new value to update Pch according to equation (1). The MS uses the same output power on all four bursts within one radio block. When accessing a cell on PRACH or RACH (random access) and before receiving the first power control parameters during packet transfer on PDCH, the MS shall use the output power defined by Pmax. If a calculated output power is not supported by the MS, the MS uses the supported output power which is closest to the calculated output power.
GAMMAch:
10.4.2
Measurement at the MS Side

A procedure is implemented in the MS to monitor periodically downlink received signal level and quality from its serving cell. To calculate the Pch value according to equation (1), the MS must derive the C value. Two different methods are used to estimate the C value, according to the MS state (i.e. packet idle mode or packet transfer mode).
10.4.2.1
Packet Idle Mode: Measurements for Power Control

In packet idle mode, the MS measures periodically the received signal level of the PCCCH or, if PCCCH is not configured, of the BCCH. The MS measures the received signal level of each paging block monitored by the MS according to its current DRX mode and its paging group (see "9.8.3.2 Discontinuous Reception"). The normalized C value for each radio block is calculated as:
Cblock(n)= SSblock(n) + Pb where:
(2)
A30808-X3247-L24-1-7618
237
SSblock(n): Pb:
is the mean value of the received signal levels on the four normal bursts that compose the block; is the BTS output power reduction (relative to the output power used on BCCH) used on the channel on which the measurements are performed; it corresponds to the PRPBCCH parameter. For PCCCH, Pb is broadcast on PBCCH. For BCCH, Pb = 0 (not broadcast).
Finally, the Cblock(n) values are filtered with a running average filter:
C(n)= (1- a)* C(n- 1) + a * Cblock(n) where a is the forgetting factor:
C(0)=0
a = 1/MIN(n, MAX (5, TAVG_W/TDRX)
TDRX: TAVG_W:
is DRX period for the MS (see "9.8.3.2 Discontinuous Reception"); is the TAVGW parameter and indicates the signal strength filter period for power control in packet idle mode. It is broadcast on PBCCH or, if PBCCH does not exist, on BCCH. n is the iteration index. The filter shall be restarted with n=1 for the first sample every time a new cell is selected. Otherwise, when entering packet idle mode, the filter shall continue from the n and C(n) values obtained during packet transfer mode. The filter shall also continue from its previous state if TDRX is changed.
The current C(n) value is used in formula (1) to calculate the output power when the MS transfers its first radio block.
10.4.2.2
Packet Transfer Mode: Measurements for Power Control

In packet transfer mode, the MS uses the same received signal level measurements on the BCCH carrier of the serving cell as made for cell reselection (see "10.4.2.2 Packet Transfer Mode: Measurements for Power Control"). The measurements are filtered with a running average filter:
C(n)= (1- b)* C(n- 1) + b * SS(n) where b is the forgetting factor: b = 1/(6 * TAVG_T) and:
238
A30808-X3247-L24-1-7618
SSn: TAVG_T:
is the received signal level of the measurement samples; is the TAVGT parameter and indicates the signal strength filter period for power control in packet transfer mode. It is broadcast on PBCCH or, if PBCCH does not exist, on BCCH. n is the iteration index; when entering packet transfer mode, the filter shall continue from the n and C(n) values obtained during packet idle mode.
If indicated by the PCMECH (PC_MEAS_CHAN) parameter, the MS shall instead measure the received signal level of each radio block on one of the PDCH monitored by the MS for PACCH. For each downlink radio block a Cblock(n) value is derived according to formula (2) (if PBCCH does not exist, Pb = 0). Finally, the Cblock(n) values are filtered with a running average filter:
C(n)= (1- c)* C(n- 1) + c * Cblock(n) where c is the forgetting factor: b = 1/(12 * TAVG_T) and: TAVG_T: is the TAVGT parameter and indicates the signal strength filter period for power control in packet transfer mode. It is broadcast on PBCCH or, if PBCCH does not exist, on BCCH. n is the iteration index; when entering packet transfer mode, the filter shall continue from the n and C(n) values obtained during packet idle mode.
Once a the current C(n) value has been obtained, this value is used to update formula (1). Each time a new C(n) value is obtained or whenever the MS applies new GAM or ALPHA values, the Pch value is updated.
10.4.2.3
Derivation of Channel Quality Reports

The channel quality is measured as the interference signal level during the idle frames of the multiframe, when the serving cell is not transmitting. In packet transfer mode, the MS measures the interference signal strength of all eight channels (slots) on the same carrier as the assigned PDCHs. The MS shall make these measurements during the search frames and PTCCH frames. The measured interference shall be averaged in a running average filter. For each channel, the MS shall perform at least NAVGI measurements before valid running average filter values can be determined. NAVGI is broadcast on PBCCH or, if not exists, on BCCH. In packet idle mode, the MS shall measure the interference signal strength on certain channels which are indicated on the PBCCH or, if PBCCH not exist, on BCCH. The inter-
A30808-X3247-L24-1-7618
239
ference measurements shall be made and averaged in the same way as for packet transfer mode.
10.4.3
BTS Output Power

The BTS uses constant power on those PDCH radio blocks which contain PBCCH or which may contain PCCCH. This power may be lower than the output power used on BCCH. The difference shall be broadcast on PBCCH by means of the PRPBCCH parameter. On the other PDCH radio blocks, downlink power control may be used (but it is not supported in BR7.0 release). Thus, a procedure may be implemented in the network to control the power of the downlink transmission based on the Channel Quality report (see 10.4.2.3). The network shall ensure that the output power is sufficient for the MS.
10.5
Link Adaptation
As is has been described (see 4.2), GPRS offers four different coding schemes, instead, for EGPRS nine different modulation and coding schemes are defined. In both cases (GPRS and EGPRS) lowest coding schemes (e.g. CS1 and MCS1 respectively) show good performances in poor radio conditions; on the other hand, only highest coding schemes (e.g. CS4 and MCS9 respectively) can provide high data throughput in good radio environments. Therefore an algorithm is needed in order to dynamically select the coding scheme that behaves better in a specific radio condition. The dynamic selection of the coding scheme, to suit radio link quality, is referred to as Link Adaptation. So, the basic idea is to dynamically select the coding scheme that allows the highest throughput according to the present radio conditions. Then the problem is to find the switching points that allow to change from one coding scheme to another one. Link Adaptation can be enabled, for both GPRS and EGPRS services, using the ELKADPT parameter of the PTPPKF object. Link Adaptation is enabled in both uplink and downlink directions at the same time. The advantage for switching to a more robust coding scheme can be seen in Fig. 10.3 taking into account GPRS CS2 and CS1 coding schemes.
240
A30808-X3247-L24-1-7618
Gross Throughput [kbit/sec]
CS2
CS1
C/I [dB] Fig. 10.3 CS1 and CS2 Throughput Depending on C/I (dB)
Let us assume that the C/I ratio is better (i.e. higher, direction towards '+') than the value denoted with '='. In this case the use of the higher coding scheme (i.e. CS2) results in an improved gross throughput, compared to the use of CS1. The situation changes, if, according to the propagation conditions, the C/I becomes lower than '=' (direction towards '-'). In this case the use of CS2 results in a lower gross throughput than with CS1. This due to the necessity to re-send many blocks because they could not be received without errors the first time. In that situation not only the gross throughput is lower than possible (i.e. if CS1 had been used) but also the delay increases. In other words: if conditions get worse then a switch to the more robust coding scheme improves gross throughput and reduces delay. On the other hand, if propagation conditions improve, a switch to a higher coding scheme results in a better gross throughput. In general C/I values are difficult to estimate in a real network, so another mechanism is followed. The triggering of the switch does not use separate measurements of channel quality, but it is executed by analyzing the number of blocks to be repeated (not acknowledged blocks) versus the number of transmitted blocks in total (i.e. the sum of the acknowledged blocks and the not acknowledged one). So to fix the switching points the NACK/(ACK+NACK) ratio is used; it is called Block Erasure Ratio (BLER) and link adaptation is then based on BLER measurements (indirect measures of the radio quality). The switching points between coding schemes, to be used in link adaptation, are then defined in terms of BLER thresholds (see 10.5.1 and 10.5.2.). Since switching points depend on the actual RF scenario, it is impossible to calculate such optimal values for each particular scenario. Upgrade switching points and downgrade switching points are then stored in pre-calculated matrix tables, one for each possible RF environment (these matrix tables can not be set by O&M). By O&M, it is then possible to select the suitable matrix table, containing all the ideal switching points (downgrade/upgrade switching points from/to all coding schemes) for the particular RF scenario, by selecting the right radio environment. The RAENV parameter allows the operator to specify the radio environment. As it has been described before, according to the chosen radio environment certain matrix tables
A30808-X3247-L24-1-7618
241
are selected (specific either for GPRS or for EGPRS) to define the BLER thresholds of the switching points. The parameter can assume two values: LOWDIV (lowDiversity): it means that, for a MS, radio conditions can change slowly, for example because Frequency Hopping is disabled and the cell is characterized by low user mobility (e.g. because MS have a speed less than 50 Km/h or because the cell is a small one); HIGHDIV (highDiversity): it means that, for a MS, radio conditions can change fast, for example because Frequency Hopping is enabled. Even if there are some common parameters to manage link adaptation, some differences exist between GPRS and EGPRS handling. They are described in the following.
10.5.1
Link Adaptation for GPRS

In the following, link adaptation features in case of GPRS service are described. Remember that with GPRS the receiver operates only in type I ARQ mode (see "9.9.1.1 GPRS Acknowledged Mode"); so link adaptation procedure is based on this mode of operation only.
10.5.1.1
GPRS: Switching Points

As it has been described, the exact values of the switching points depend on the real network situation and are subjects of simulation and/or measurements. For a first idea about the values to be expected, it is possible to interpret the following simulations based on TU3 with ideal frequency hopping (see Fig. 10.4).
Fig. 10.4
Gross Throughput Depending on CS and C/I (dB)
So it is possible to estimate the 'ideal' switching points as follows:
242
A30808-X3247-L24-1-7618
CS1 <---> CS2 CS2 <---> CS3 CS3 <---> CS4
C/I=6.2 dB C/I=9.6 dB C/I=16.5 dB
But, as it has been said, switching points between coding schemes are defined in terms of BLER thresholds. The corresponding BLER values are shown in Fig. 10.5.
Fig. 10.5
BLER as Function of C/I (dB) for all GPRS Coding Schemes.
In case of GPRS the following BLER thresholds, e.g., could be defined: BLER_CS1(CS1 ---> CS2) = 17% BLER_CS2(CS2 ---> CS3) = 14% BLER_CS3(CS3 ---> CS4) = 2% BLER_CS2(CS2 ---> CS1) = 43% BLER_CS3(CS3 ---> CS2) = 26% BLER_CS4(CS4 ---> CS3) = 17% C/I=6.2 dB C/I=9.6 dB C/I=16.5 dB
For example, if BLER goes below 17%, while using CS1, then a change to CS2 will be decided; if BLER goes over 43%, while using CS2, then a change to CS1 will be decided. A crosscheck e.g. for CS1<->CS2 gives approximately the same gross throughputs: (1-0.17)*9.05kbps=7.51kbps (1-0.43)*13.4kbps=7.64kbps
It is also possible to see, that depending on the wished QoS the hysteresis should be more towards the more stable CS: in the example above both CS have nearly the same gross throughput, but with CS2, 43% of all blocks have to be repeated at least once, so the delay will be much higher than if one uses CS1. So the '-' point should be as close as possible to the '=' point. When considering the net throughput, the maximum data rate values would become 8, 12, 14.4 and 20 kbits/s. So the curves above (see Fig. 10.4) are re-scaled, each one by a proper factor, and the 'ideal' switching points should be recalculated accordingly.
A30808-X3247-L24-1-7618
243
These switching points are reported in Tab. 10.3, and they are the values that are contained in the GPRS internal switching matrix. It is important to underline that in case of GPRS, only one switching matrix exists, independently from the value given to the RAENV parameter. CS1 CS1 CS2 CS3 CS4 Tab. 10.3 >50% <50% >30% GPRS Thresholds with RAENV set to LOWDIV/HIGHDIV CS2 <10% <10% <1% CS3 CS4
In Tab. 10.3, coding schemes written in vertical direction represent the starting coding schemes, whereas those written in horizontal represent the arrival ones. So, for example, watching at Tab. 10.3, to go from CS1 to CS2 the BLER value shall be less than 10%; to go from CS2 to CS1 the BLER value shall be greater than 50%. Let BLER(CSi-->CSi+1) be the (upgrade) switching point from CSi to CSi+1 and BLER(CSi<--CSi+1) the corresponding (downgrade) switching point and BLER(CSi=CSi+1) the BLER of the current coding scheme where both corresponding coding schemes have with same C/I the same throughput. Then it always must be valid: 1) 2) BLER(CSi-->CSi+1)<BLER(CSi=CSi+1) BLER(CSi=CSi+1)<=BLER(CSi<--CSi+1) i=1..3 i=1..3
10.5.1.2
Quality Traps Disadvantage

It would be desirable, to enforce in the downgrade situation a re-sending of the NACK blocks in the new, more robust coding scheme. However this is forbidden by Specifications and it may lead to following situation (called quality trap): if conditions worsen (or too 'high' CS was selected in the beginning) before all NACK blocks could be resent successfully, remaining blocks will never be transferred at all (conditions are too bad for transfer with current CS, but CS may not be changed because blocks have to be resent with old CS).
Of course this is a very pessimistic case. In more common cases interference and fading conditions are variable enough, from block to block, to allow for an RLC block correct reception within a reasonable number of retransmissions. If p is the probability of retransmission, each RLC block will be correctly received after an average 1/(1-p) number of retransmissions. Therefore, when radio conditions are bad and the link adaptation leads to switch to a lower coding scheme, in progress retransmission shall be in any case performed using the old coding scheme. As usual, when the number of retransmissions of a block exceeds the N3101 value, the TBF is closed. If the TBF is re-opened within a time configured by the STGTTLLIINF parameter, it will be re-opened with the last commanded/used coding scheme, overtaking quality traps disadvantages (see "10.5.3 Selection of the Candidate Initial Coding Scheme" to get more details about this procedure).
244
A30808-X3247-L24-1-7618
For example, in case of transmission in downlink direction, if the current coding scheme is CS4 and link adaptation leads to switch to CS3 than: CS3 coding scheme is used to transmit new blocks; CS4 (old coding scheme) is used for in progress retransmissions. When the number of retransmissions of a block exceeds the N3101 value, the TBF is closed. If the TBF is re-opened within the STGTTLLIINF time, CS3 coding scheme (last used coding scheme) will be used. For example, in case of transmission in uplink direction, if the current coding scheme is CS4 and link adaptation leads to switch to CS3 than: CS3 coding scheme is commanded (and used by the MS to transmit new blocks); CS4 (old coding scheme) is used by the MS for in progress retransmissions. When the number of retransmissions of a block exceeds the N3101 value, the TBF is closed. If the MS requires again the TBF within the STGTTLLIINF time, CS3 coding scheme will be used (last commanded coding scheme).
10.5.1.3
GPRS: Link Adaptation Algorithm

Speaking about GPRS service, link adaptation is based on the following features: 1. all the signalling is done with CS1; 2. data transfer is started with the highest available coding scheme; the following considerations can be drawn: if the transmission to be started is a retry due to a previous 'quality trap' (see 10.5.1.2) the CS to be selected has to be a more stable one than that used before. So the PCU has to store abnormal releases for a certain time, to recognize a retry and to adapt the CS for that case. the highest CS is the highest the MS and BSS have in common; as it has been described in 10.5.1.2, the PCU holds in memory for a dened time the value of the last used coding scheme; this coding scheme is the coding scheme to be used when a new TBF is opened. If the time is elapsed (or if a cell reselection is executed) the used coding scheme is those provided by the INICSCH parameter (see "10.5.3 Selection of the Candidate Initial Coding Scheme"). 3. basing on received blocks, the BSC can evaluate the BLER value; 4. if conditions worsen, a downgrade to the lower CS is performed as soon as possible, i.e. after all NACK blocks have nally be sent successfully, using the same coding scheme (i.e. before changing from coding scheme A to coding scheme B, it is necessary to retransmit all the not acknowledged blocks using coding scheme A); this may lead to the already described 'quality trap'. This is problem currently solved only by expiration of a timer and reestablishing the transmission with a more appropriate CS. 5. if conditions improve, an upgrade to the higher CS is performed as soon as no more blocks have to be resent (i.e. all NACK blocks were nally transmitted successfully). In uplink case the BSC informs the MS to change the coding scheme; in downlink direction the BSC starts sending blocks with the new coding scheme. The upgrade procedure depends not only on the propagation conditions (i.e. C/I or BLER) but also on the available resources. A switch (e.g. CS2 to CS3) is not allowed, if there is e.g. not sufcient transmission capacity on the Abis (e.g. a 32kbps channel available for a CS3, see "5.3 PCU Frames and Dynamic Allocation on the Abis Interface").
A30808-X3247-L24-1-7618
245
10.5.2
Link Adaptation for EGPRS

As it has been previously described, in case of EGPRS, up to nine modulation and coding schemes are defined, and they belong to a certain family. In general, according to the link quality, an initial Modulation and Coding Scheme (MCS) is selected for an RLC block. For retransmissions, the same or another MCS from the same family of MCSs can be selected. E.g. if MCS7 is selected for the first transmission of an RLC block, any MCSs of the family B can be used for the retransmission. In the type I ARQ mode (see "9.9.1.2 EGPRS Acknowledged 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. Link Adaptation procedure allows the receiver to operate either in type I or type II hybrid ARQ mode.
10.5.2.1
EGPRS: Switching Points

As is case of GPRS, with EGPRS different MCSs allow different performance (throughput) as a function of the C/I ratio (and the actual RF channel); Fig. 10.6 shows curves for TU3 with no frequency hopping, for family A + MCS1 (without Incremental Redundancy).
Fig. 10.6
Simulation Results for Family A (+MCS1) without IR
It is possible to estimate the 'ideal' C/I switching points where the MCS should be changed in order to maximize the net throughput. Referring to the previous case, and assuming to use only MCSs belonging to family A (plus MCS1), the 'ideal' switching points could be the following:
246
A30808-X3247-L24-1-7618
MCS1 <---> MCS3 MCS3 <---> MCS6 MCS6 <---> MCS9
C/I=1.5 dB C/I=7.5 dB C/I=16 dB
As in GPRS case, since C/I values are difficult to estimate, the thresholds are given in terms of BLER; some examples of defined BLER thresholds could be the following: BLER(MCS1 ---> MCS3) = 61% BLER(MCS3 ---> MCS6) = 38% BLER(MCS6 ---> MCS9) = 24% BLER(MCS3 ---> MCS1) = 77% BLER(MCS6 ---> MCS3) = 69% BLER(MCS9 ---> MCS6) = 62% C/I=1.5 dB C/I=7.5 dB C/I=16 dB
The throughput is then maximized changing the coding schemes according to these threshold values. For example, if BLER goes below 38%, while using MCS3, then a change to MCS6 will be decided; if BLER goes over 69%, while using MCS6, then a change to MCS3 will be decided. In real networks 'ideal' switching points will depend on the actual RF scenario and it is impossible to calculate such optimal values for each particular scenario. Upgrade switching points (BLER(MCSx--->MCSy), 1<=x<y<=9) and downgrade switching points (BLER(MCSy--->MCSx), 1<=x<y<=9) are adaptable to the radio environment. More precisely, these values are stored in pre-calculated matrix tables, one for each possible RF environment; so: if RAENV is set to HIGHDIV some threshold values are used; if RAENV is set to LOWDIV some other threshold values are used. By O&M it is then be possible (by setting the RAENV parameter) to select the suitable matrix table, containing all the ideal switching points (downgrade/upgrade switching points from/to all MCSs) for the particular RF scenario. When IR is taken into account, different BLER threshold values should be considered: BLER(MCSx_wIR--->MCSy_wIR), 1<=x<y<=9 as upgrade switching points and BLER(MCSy_wIR--->MCSx_wIR), 1<=x<y<=9, as downgrade switching points. Even these values are stored in matrix tables, one for each possible RF scenario. Among all possible EGPRS coding schemes, the operator must define which sets of coding schemes must be used in the cell, both in uplink and downlink direction (see "10.5.2.2 EGPRS: Link Adaptation Algorithm" to know how to enable EGPRS coding schemes in a cell). When configuring these sets, the following constraints are automatically considered by the system: a) MCS1 is always included in the selection: this is needed for signalling and due to the fact that MCS1 is the only MCS that requires only one Abis timeslot; b) if MCSx is implemented, all the lower order MCSy (y<x) of the same family must be implemented. This is needed because retransmissions may have to be performed with a (lower order) MCS of the same family.
Link Adaptation is not restricted within a family. Only retransmissions must be performed using a coding scheme in the same family of the original one (the one that was used for the first transmission of the radio block).
c) if more than one family is congured, considering a given MCSx in use, the general rule to decide the upgrading/downgrading MCS is the following: the upgrading
A30808-X3247-L24-1-7618
247
MCS is the one characterized by the highest switching threshold (among the congured ones), while the downgrading MCS is the one characterized by the lowest switching threshold (among the congured ones).
It may happen that the upgrading threshold is higher that the downgrading threshold. In this case one of the two conditions is always satisfied (implicitly this means that the current MCS is a transition one and the best choice is to switch immediately to a new one). In case both conditions are satisfied, the best choice is to switch to the upgrading MCS.
Switching is only allowed among all selected MCSs, from the actual one to the previous/next available one. As it has been described, according to the chosen sets of coding schemes (in uplink or downlink direction), different thresholds have to be considered, since different coding schemes are selected. Tab. 10.4 shows which thresholds are considered if, for instance, the user has enabled FamilyA plus MCS1. Instead Tab. 10.5 shows which thresholds are considered if, for instance, the user has enabled FamilyB plus MCS1. In the tables, coding schemes written in vertical direction represent the starting coding schemes, whereas those written in horizontal represent the arrival ones. So, for example, watching at Tab. 10.4, to go from MCS1 to MCS3 the BLER shall be less than a XX% value; to go from MCS3 to MCS1 the BLER shall be greater than another XX% value.
If more than one family is enabled, the possible switching points are those given by the sum of tables related to the single families.
Fam C
Fam B
Fam A + Fam C Fam A Padding MCS3 <XX% MCS4
Fam B
Fam A + Fam B Fam A Padding MCS6 MCS7
Fam A Fam A Padding MCS8 MCS9
MCS1 Fam C Fam B MCS1 MCS2 >XX%
MCS2
MCS5
Fam A + MCS3 Fam A Padding Fam C Fam B MCS4 MCS5
<XX%
Fam A + MCS6 Fam A Padding Fam B MCS7
>XX%
<XX%
Fam A MCS8 Padding Fam A Tab. 10.4 MCS9 Thresholds to be used if Family A plus MCS1 is chosen >XX%
248
A30808-X3247-L24-1-7618
Fam C
Fam B
Fam A + Fam C Fam A Padding MCS3 MCS4
Fam B
Fam A + Fam B Fam A Padding MCS6 MCS7
Fam A Fam A Padding MCS8 MCS9
MCS1 Fam C Fam B MCS1 MCS2 >XX%
MCS2 <XX%
MCS5
<XX%
Fam A + MCS3 Fam A Padding Fam C Fam B MCS4 MCS5 >XX% <XX%
Fam A + MCS6 Fam A Padding Fam B MCS7 >XX%
Fam A MCS8 Padding Fam A Tab. 10.5 MCS9 Thresholds to be used if Family B plus MCS1 is chosen If we consider enabled all EGPRS coding schemes, according to radio environment (i.e. RAENV parameter setting) and IR, four different threshold settings are foreseen: a) b) c) d) To From MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7 MCS8 MCS9 Tab. 10.6 >60% >70% >70% >60% >60% >70% >45% >65% >70% >70% >75% >70% >80% >70% >75% >80% >75% >80% >80% MCS1 MCS2 <35% RAENV set to LOWDIV and IR is working (see Tab. 10.6); RAENV set to LOWDIV and IR is not working (see Tab. 10.7); RAENV set to HIGHDIV and IR is working (see Tab. 10.8); RAENV set to HIGHDIV and IR is not working (see Tab. 10.9); MCS3 <35% <30% MCS4 <30% <25% <20% <35% <35% <40% <30% <40% <40% <45% <40% <40% <30% <40% <30% <15% MCS5 MCS6 MCS7 MCS8 MCS9
EDGE with Incremental Redundancy working and RAENV set to "LOWDIV"
A30808-X3247-L24-1-7618
249
To From MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7 MCS8 MCS9
MCS1
MCS2 <35%
MCS3 <35% <30%
MCS4 <30% <25% <20%
MCS5
MCS6
MCS7
MCS8
MCS9
>60% >70% >70% >60% >50% >70%
<35% <35% <40% <30% <40% <40% >70% >65% >60% >65% >65% >50% >45% >30% <25% <30% <25% <30% <15% <15% <15%
>45% >65% >70% >70% >75%
Tab. 10.7
EDGE with Incremental Redundancy not working and RAENV set to "LOWDIV"
To From MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7 MCS8 MCS9
MCS1
MCS2 <15%
MCS3 <10% <3%
MCS4 <10% <1% <5%
MCS5
MCS6
MCS7
MCS8
MCS9
>45% >50% >55% >35% >40% >70%
<20% <40% <45% <35% <45% <15% >45% >70% >45% >60% >75% >25% >35% >50% <30% <5% <15% <5% <40% <5% <15%
>25% >70% >70% >70% >70%
Tab. 10.8
EDGE with Incremental Redundancy working and RAENV set to "HIGHDIV"
To From MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7
MCS1
MCS2 <15%
MCS3 <3% <3%
MCS4 <1% <1% <5%
MCS5
MCS6
MCS7
MCS8
MCS9
>45% >50% >55% >35% >40% >60%
<10% <50% <90% <35% <75% <15% >45% >55% >45% <2% <5% <2% <5% <2% <5%
>25% >80% >70% >90% >90%
Tab. 10.9
EDGE with Incremental Redundancy not working and RAENV set to "HIGHDIV"
250
A30808-X3247-L24-1-7618
MCS8 MCS9 Tab. 10.9
>50% >55%
>25% >35% >50%
<15%
EDGE with Incremental Redundancy not working and RAENV set to "HIGHDIV"
To summarize, the basic ideas are: link Adaptation is based on BLER measurements; different BLER thresholds are needed to take into account type I ARQ and type II Hybrid ARQ cases; only a subset of MCSs should be used; especially due to the fact that is quite difcult to dene consistent thresholds among all the possible MCSs.
10.5.2.2
EGPRS: Link Adaptation Algorithm

Regarding the EGPRS link adaptation algorithm some differences exist between uplink and downlink directions; these differences arise from the following situations: a) there are EGPRS mobile stations that are not able to use PSK modulation in uplink direction, but only the GMSK one (see "9.1 Mobile Stations for Packet Switched Services"); b) incremental redundancy is not supported in uplink direction. Uplink Direction The operator can configure which sets of coding schemes can be used in uplink direction. At least two sets of available MCSs must be enabled, one for 8PSK transmit capable mobiles, and the other one for GMSK-only transmit capable mobiles. To enable sets of coding schemes, a parameter for each family is given. The parameters are (remember that in uplink direction, the Incremental Redundancy is not implemented): EMFA1UNIR8PSK (enMcsFamAMcs1UplinkWoutIncrRed8Psk): it enables MCS belonging to FamilyA and MCS1 to be used, if MS support 8PSK modulation in Uplink; EMFAP1UNIR8PSK (enableMcsFamilyApMcs1UplinkWithoutIncrementalRedundancy8Psk): it enables MCS belonging to FamilyA padding and MCS1 to be used, if MS support 8PSK modulation in Uplink case; EMFB1UNIR8PSK (enMcsFamBMcs1UplinkWoutIncRed8Psk) it enables MCS belonging to Family B and MCS1 to be used, if MS support 8PSK modulation in Uplink EGPRS TBF; EMFCUNIR8PSK (enMcsFamCUplinkWoutIncRed8Psk): it enables MCS belonging to Family C and MCS1 to be used, if MS support 8PSK modulation in Uplink case; EMFGUNIR8PSK (enMcsFamGmskUplinkWoutIncRed8Psk): it enables MCS belonging to Family Gmsk to be used, if MS supports 8PSK modulation in Uplink case; EMFCUNIRGMSK (enMcsFamCUplinkWoutIncrRedGmsk): it enables MCS belonging to Family C to be used, if MS does not support 8PSK modulation in Uplink case;
A30808-X3247-L24-1-7618
251
EMFGUNIRGMSK (enMcsFamGmskUplinkWoutIncrRedGmsk): it enables MCS belonging to Family Gmsk to be used, if MS does not support 8PSK modulation in Uplink case.
Family GMSK is constituted by MSCs that can be used from a mobile station supporting, in uplink direction, the GMSK modulation only. The coding schemes belonging to Family GMSK are: MCS1, MCS2, MCS3, and MCS4; in fact these coding schemes use the GMSK modulation (see "3.1 GPRS and EGPRS Modulation Principles"). The operator can also define the initial MCS to be used as default in uplink direction; if no information about a MS in a cell is available, the defined MCSs will be used (see "10.5.3 Selection of the Candidate Initial Coding Scheme"). The IMCSULNIR8PSK attribute suggests the MCS to be used in uplink direction if the MS supports the 8 PSK modulation in this direction; the IMCSULNIRGMSK attribute suggests the MCS to be used in uplink direction if the MS supports only the GMSK modulation in this direction. The link adaptation algorithm in uplink direction works as follows: 1. the initial Modulation and Coding Scheme is decided. In absence of Abis congestion, the initial MCS will be IMCSULNIR8PSK (or IMCSULNIRGMSK for GMSK mobiles), unless some information is available about the last MCS used for a previous UL TBF characterized by the same TLLI. In this case the initial MCS of the new TBF will be set equal to the last MCS of the previous one (see 10.5.3); 2. once the connection is established, BLER is continuously updated at the PCU (each 20 ms) by checking if RLC blocks have been carefully received or not; the ltering period can be dened, in units of 20 msec, by the BLERAVEUL parameter; 3. once the initial ltering period has elapsed (e.g. after 2 seconds if BLERAVEUL is set to UNIT100), BLER is continuously monitored. Each time (i.e. for each received block) BLER is checked and tested against the appropriate thresholds; if MCSx is the actual MCS, MCSy the next available one and MCSz the previous available one, the appropriate thresholds are: Up_th= BLER(MCSx--->MCSy) Dn_th= BLER(MCSx--->MCSz) upgrade threshold downgrade threshold
4. if actual BLER falls below the upgrade threshold (Up_th) the algorithm switches to the next (less protected) available MCS; if it exceeds the downgrade threshold (Dn_th) the algorithm switches to the previous (more protected) available MCS.
When upgrading to a less protected MCS, Abis availability should be checked, see "5.3 PCU Frames and Dynamic Allocation on the Abis Interface" and "6.3.4.2 Upgrade of Abis Resources". Downlink direction In downlink direction incremental redundancy is assumed to be always enabled, since it is mandatory for EGPRS mobiles. The operator can configure which sets of coding schemes can be used in downlink direction. EGPRS mobiles will be able to receive 8PSK modulated signals, therefore at least one family of available MCSs must be enabled (all the MSs are 8PSK receive capable).
252
A30808-X3247-L24-1-7618
To enable sets of coding schemes, a parameter for each family is given. The parameters are (remember that in downlink direction, the Incremental Redundancy is always supported by MSs): EMCSFAMA1DL (enMcsFamAMcs1Downlink): it enables MCS belonging to Family A and MCS1 to be used, in Downlink case; EMCSFAMAP1DL (enMcsFamAPaddingMcs1Downlink): it enables MCS belonging to Family A padding and MCS1 to be used, in Downlink case; EMCSFAMB1DL enMcsFamBMcs1Downlink): it enables MCS belonging to Family B and MCS1 to be used, in Downlink case; EMCSFAMCDL (enMcsFamCDownlink): it enables MCS belonging to Family C to be used, in Downlink case; EMCSFAMGDL (enableMcsFamilyGmskDownlink): it enables MCS belonging to Family GSMK to be used, in Downlink case. The operator can also define, by the INIMCSDL attribute, the initial MCS to be used as default in downlink direction; if no information about a MS in a cell are available the suggested MCSs will be used (see "10.5.3 Selection of the Candidate Initial Coding Scheme"). The link adaptation algorithm in downlink direction works as follows: 1. the initial Modulation and Coding Scheme is decided. In absence of Abis congestion, the initial MCS will be INIMCSDL, unless some information is available about the last MCS used for a previous DL TBF characterized by the same TLLI. In this case the initial MCS of the new TBF will be set equal to the last MCS of the previous one (see 10.5.3); 2. once the connection is established, BLER is updated at the PCU with the information provided by the EGPRS PACKET DOWNLINK ACK/NACK MESSAGE, reported by the MS upon periodic request from the network (let be k the reporting instant); the ltering period can be dened, in units of 20 msec, by the BLERAVEDL parameter; 3. moreover, when an EGPRS PACKET DOWNLINK ACK/NACK message is received (i.e. at the instant k), the MS OUT OF MEMORY bit is checked to verify if no more memory for incremental redundancy procedure is available at the MS; the IR_status_k variable gives information about the efciency of incremental redundancy at the MS at a specic instant k: IR is considered as "not-properly working when IR_status_k<0.5 at the MS; IR is considered as "properly working when IR_status_k>0.5 at the MS; 4. BLER is continuously monitored; each time an EGPRS PACKET DOWNLINK ACK/NACK is received, BLER is checked and tested against the appropriate thresholds; if MCSx is the actual MCS, MCSy the next available one and MCSz the previous available one, the appropriate thresholds are: if IR was perfect (no memory size limitations, etc.), the appropriate thresholds would be: Up_th_k= BLER(MCSx_wIR--->MCSy_wIR) upgrade threshold Dn_th_k= BLER(MCSx_wIR--->MCSz_wIR) downgrade threshold
if IR didn't work at all, the appropriate thresholds would be: Up_th_k= BLER(MCSx--->MCSy) Dn_th_k= BLER(MCSx--->MCSz) upgrade threshold downgrade threshold
A30808-X3247-L24-1-7618
253
in the more general case (IR efciency given by IR_statusk) the appropriate thresholds would be something between thresholds dened above: Up_th_k= (1-IR_status_k)*BLER(MCSx--->MCSy)+ IR_status_k*BLER(MCSx_wIR--->MCSy_wIR) Dn_th_k= (1-IR_status_k)*BLER(MCSx--->MCSz)+ IR_status_k*BLER(MCSx_wIR--->MCSz_wIR) upgrade threshold downgrade threshold
5. if actual BLER falls below the upgrade threshold (Up_th_k) the algorithm switches to the next (less protected) available MCS; if it exceeds the downgrade threshold (Dn_th_k) the algorithm switches to the previous (more protected) available MCS.
When upgrading to a less protected MCS, Abis availability should be checked, see "5.3 PCU Frames and Dynamic Allocation on the Abis Interface" and "6.3.4.2 Upgrade of Abis Resources".
10.5.3
Selection of the Candidate Initial Coding Scheme

The Initial Coding Scheme is the coding scheme to be applied, when a new TBF starts. As it has been described, the user can configure the coding scheme to be used when a new data transmission starts both for GPRS and EGPRS services: for GPRS service, the INICSCH parameter is used; for EGPRS service, in uplink direction, as it is described in "9.1 Mobile Stations for Packet Switched Services", not all the EDGE mobile stations support the 8PSK modulation, so: the IMCSULNIR8PSK attribute suggests the MCS to be used in uplink direction if the MS supports the 8 PSK modulation in this direction; the IMCSULNIRGMSK attribute suggests the MCS to be used in uplink direction if the MS supports only the GMSK modulation in this direction; for EGPRS service, in downlink direction, all the EDGE MS are obliged to support the 8 PSK modulation, so the INIMCSDL attribute suggests the MCS to be used in downlink direction for all the EGPRS mobiles. These values are used to choose the initial coding scheme, only when the PCU does not have a valid information of the coding scheme to use when the TBF starts. In fact the PCU holds into memory, for each mobile station, the last coding scheme (CS or MCS) used in Uplink or Downlink direction for TBFs associated to the MS. These values are refreshed at the end of each TBF, and cleared from memory if either a timer defined by the STGTTLLIINF (storageTimeTLLIInfo) parameter expires or if a cell reselection is performed. These values of coding scheme are called historical coding schemes; configured by O&M coding schemes will be used only if no historical values are available at PCU side.
Besides the coding scheme, the PCUholds in memory, for the same time, also the historical BLER, i.e. the last measured BLER. This value is used to assign radio resources to the new TBF (see "6.3.3 Management of Incoming GPRS/EGPRS Requests"). So when a new TFB starts, the Candidate Initial Coding Scheme must be selected: a) for GPRS capable mobiles only the candidate initial CS has to be calculated; b) for EGPRS capable mobiles both the candidate initial MCS and the candidate initial CS have to be calculated. In fact, only after the Resource Allocation procedure
254
A30808-X3247-L24-1-7618
(see "6.3.3.1 PCU Algorithm" and "6.3.3.2 TDPC Algorithm") it will be clear the TBF mode (GPRS or EGPRS) to be used. So, the candidate initial coding scheme is selected in the order looking at:
In case of GPRS capable mobiles: historical CS, if available; congured initial CS, if historical CS is not available; In case of EGPRS capable mobiles:
a) canditate initial MCS: based on historical MCS, if any; based on historical CS, if available (see Tab. 10.11); congured initial MCS, if historical CS/MCS are not available b) canditate initial CS: historical CS, if available; based on historical MCS, if available (see Tab. 10.10); congured initial CS, if historical CS/MCS are not available. Besides, for EGPRS service it is important to rember that the operator can configure separately: MCS families to be used in downlink transmission; MCS families to be used in uplink transmission for 8PSK capable mobiles; MCS families to be used in uplink transmission for GMSK capable mobiles. As a consequence it could happen that an available (historical) MCS can not be directly usable for the new TBF to be set up, because e.g. the user has changed the value of O&M parameters. In this case the rule for selecting the candidate initial MCS is: take the highest configured MCS less or equal to the available historical MCS. The following tables show rules to decide the candidate initial coding scheme for: a GPRS TBF mode, when the last coding scheme was stored for an EGPRS TBF mode (see Tab. 10.10). a EGPRS TBF mode, when the last coding scheme was stored for a GPRS TBF mode (see Tab. 10.11); Historical MCS MCS1 MCS2 MCS3 MCS4 or higher MCSs CS1 CS2 CS3 CS4 Candidate CS
Tab. 10.10 Candidate Initial Coding Scheme for a GPRS TBF when the Historical Coding Scheme is Related to an EGPRS TBF
A30808-X3247-L24-1-7618
255
Historical CS CS1 CS2 CS3 -MCS1
Candidate MCS
-MCS2 if FamilyB is configured -MCS1 otherwise -MCS3 if FamilyA is configured -MCS2 if FamilyB is configured -MCS1 otherwise DL or UL TBF for fully 8PSK capable mobiles -Configured Initial MCS if it is upper than MCS4 -MCS4 if FamilyC is configured -MCS3 if FamilyA is configured -MCS2 if FamilyB is configured -MCS1 otherwise UL TBF for GMSK capable mobiles -MCS4 if FamilyC is configured -MCS3 if FamilyA is configured -MCS2 if FamilyB is configured -MCS1 otherwise
CS4
Tab. 10.11 Candidate Initial Coding Scheme for an EGPRS TBF when the Historical Coding Scheme is Related to a GPRS TBF
256
A30808-X3247-L24-1-7618
GPRS\EGPRS Global Description
11 Database Parameters and Objects

This chapter of the manual contains four tables: in the rst table the user nds, in the alphabetical order, all the parameters, related to GPRS/EGPRS only, which are discussed in the manual. For each parameter he nds one or more links to the chapters of the manual where the parameter is described and also a link to the title of Feature Sheets (or Change Requests) that introduce or describe the parameter in Siemens technology; in the second one the user nds, in the alphabetical order, the not specic GPRS/EGPRS parameters which are discussed in the manual since they are also related to GPRS/EGPRS . For each parameter he nds one or more links to the chapters of the manual where the parameter is described; besides, starting from parameters of BR5.5 release onwards, a link to the features that describe the parameter is executed. in the third one the user nds, in the alphabetical order, all the database objects which are related to GPRS/EGPRS only. For each object he nds the link to Feature Sheets (or Change Requests) that introduce the object in Siemens technology; in the fourth one, the user nds, in the alphabetical order, all the not specic GPRS/EGPRS database objects which are involved in GPRS/EGPRS too. For each object he nds the link to the chapters of the manual that describe it; besides, starting from parameters of BR5.5 release onwards, a link to the features that describe the parameter is executed.
Parameter ABUTYP
Feature/CR FSH0720
Chapters "9.8.2.1 8 Bits or 11 Bits Uplink Access" "9.8.2.4 TBF Establishment for EDGE Mobile Stations"
ACCEPTGDEGR ALPHA
FSH0516 FSH0720
"6.3.4.1 Upgrade of Radio Resources" "10.4.1 Power Control Algorithm" "10.4.2.2 Packet Transfer Mode: Measurements for Power Control"
BAF BEPAVGP BER BLERAVEDL BLERAVEUL BNDWIDTDD BPAGCHR
FSH0720 FSH0420 FSH0720 FSH0444 FSH0444 FSH0418 FSH0720
"7.1 Physical Layer" NOT USED IN BR7.0 "7.1 Physical Layer" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.2.3 Handling of UMTS Neighboring Cells" "4.5.2 PDCH Carrying both PBCCH and PCCCH" "9.8.3.2 Discontinuous Reception" "4.5.3 PDCH Carrying PCCCH"
Tab. 11.1
GPRS/EGPRS Parameters Summary Table
A30808-X3247-L24-1-7618
257
Parameter BPRACHR
Feature/CR FSH0720
Chapters "4.5.2 PDCH Carrying both PBCCH and PCCCH" "4.5.3 PDCH Carrying PCCCH"
BSCDVMA BSPBBLK
FSH0720 FSH0720
"9.9.3.4 Release of an Uplink TBF" "4.5.2 PDCH Carrying both PBCCH and PCCCH" "9.8.3.2 Discontinuous Reception"
C31H C32QUAL CACKTYP CODE CRC CRESELTRHSOUT CRESELTRSHINP CSCH3CSCH4SUP DRXTMA
FSH0720 FSH0720 FSH0720 CR - X617 FSH0720 FSH0720 FSH0418 FSH0418 FSH0419 FSH0720 CR - F190 CR - X617 FSH0420
"10.1.3 Cell Re-selection Algorithm" "10.1.3 Cell Re-selection Algorithm" "9.8.6 Polling Procedures" "7.1 Physical Layer" "7.1 Physical Layer" "10.3.2 GPRS/EGPRS Traffic Control Strategy" "10.3.2 GPRS/EGPRS Traffic Control Strategy" "4.2.1 GPRS Channel Coding" "9.8.3.2 Discontinuous Reception"
EBCCHTRX
"6.1.3 Aspects Related to Carrier Configuration" "6.3.3 Management of Incoming GPRS/EGPRS Requests"
EEDGE
FSH0420 CR - X0158 FSH0420 CR - X0158 FSH0420 FSH0420 FSH0420 FSH0420 FSH0420 FSH0420 FSH0420 FSH0420
"6.1 Enabling Packet Switched Services in a Cell" "6.1 Enabling Packet Switched Services in a Cell" "9.9.1.2 EGPRS Acknowledged Mode" "9.9.1.2 EGPRS Acknowledged Mode" "9.9.1.2 EGPRS Acknowledged Mode" "9.9.1.2 EGPRS Acknowledged Mode" "9.9.1.2 EGPRS Acknowledged Mode" "9.9.1.2 EGPRS Acknowledged Mode" "9.9.1.2 EGPRS Acknowledged Mode" "9.9.1.2 EGPRS Acknowledged Mode"
EGPRS EGWSONETS EGWSTWOTS EGWSTHREETS EGWSFOURTS EGWSFIVETS EGWSSIXTS EGWSSEVENTS EGWSEIGHTTS Tab. 11.1
258
A30808-X3247-L24-1-7618
Parameter ELKADPT EMCSFAMA1DL EMCSFAMAP1DL EMCSFAMB1DL EMCSFAMCDL EMCSFAMGDL EMFA1UNIR8PSK EMFAP1UNIR8PSK EMFB1UNIR8PSK EMFCUNIR8PSK EMFCUNIRGMSK EMFGUNIR8PSK EMFGUNIRGMSK ESUP FDDGQO FRSTD GAMMA
Feature/CR FSH0444 FSH0444 FSH0444 FSH0444 FSH0444 FSH0444 FSH0444 FSH0444 FSH0444 FSH0444 FSH0444 FSH0444 FSH0444 FSH0420 CR - X482 FSH0720 ----
Chapters "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "6.1.2 Enabling EGPRS Service in the Cell" "10.2.2 GSM-UMTS Re-selection Algorithm: Packet Switched Case" "7.1 Physical Layer" "10.4.1 Power Control Algorithm" "10.4.2.2 Packet Transfer Mode: Measurements for Power Control"
GASTRABISTH
FSH0516
"6.3.2.4 Switching between VA and HA according to Abis Interface Conditions" "6.3.2.5 Allocation of Resources" "6.3.3.2 TDPC Algorithm" "6.3.4.2 Upgrade of Abis Resources"
GASTRTH
FSH0503
"6.3.2.3 Switching between VA and HA According to Radio Conditions" "6.3.2.5 Allocation of Resources" "6.3.4.1 Upgrade of Radio Resources"
GDCH (ex GCCH)
FSH0720 FSH0457 FSH0503 CR - X706
"6.2 Configuration of GPRS Channels in a Cell" "6.3.2.3 Switching between VA and HA According to Radio Conditions" "9.8.3.2 Discontinuous Reception"
GCELLRESH GFDDMURREP Tab. 11.1
FSH0720 FSH0418
"10.1.3 Cell Re-selection Algorithm" "10.3.1.1 Measurement Reporting"
A30808-X3247-L24-1-7618
259
Parameter GFDDREPQTY GHCSPC
Feature/CR FSH0418 FSH0720 CR - F205
Chapters "10.3.1.1 Measurement Reporting" "10.1.2.2 C31 Criterion" "10.1.2.3 C32 Criterion" "10.1.4 Management of GPRS/EGPRS Neighboring Cells" "10.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUE"
GHCSTH
FSH0720 CR - F205
"10.1.2.2 C31 Criterion" "10.1.4 Management of GPRS/EGPRS Neighboring Cells" "10.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUE"
GLK
FSH0720
"7.1 Physical Layer" "7.2.1.1 Examples of Addressing"
GMANMSAL
FSH0720
"4.3.3 Multiplexing MSs on the same PDCH: Configuration" "4.4.3 Packet Data Traffic Channel (PDTCH)" "6.2 Configuration of GPRS Channels in a Cell" "6.3.2 Horizontal/Vertical Allocation Strategies" "6.3.2.1 Vertical Allocation Strategy (VA)" "6.3.3.1 PCU Algorithm"
GMANPAL GMANPRES (restored in BR7.0)
FSH0720 CR - X232 CR - F187
REMOVED IN BR6.0 "6.2 Configuration of GPRS Channels in a Cell" "6.3.2.1 Vertical Allocation Strategy (VA)" "6.3.2.3 Switching between VA and HA According to Radio Conditions" "6.3.3.2 TDPC Algorithm"
GMAPERTCHRES Tab. 11.1
CR - X706
REMOVED IN BR7.0
260
A30808-X3247-L24-1-7618
Parameter GMSTXPMAC
Feature/CR FSH0720 FSH0418
Chapters "10.1.2.1 GPRS/EGPRS Path Loss Criterion (C1 Criterion)" "10.1.4 Management of GPRS/EGPRS Neighboring Cells" "10.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUE" "10.3.1.2 Radio Link Network Controlled Cell Reselection Algorithm" "10.3.2.1 Network Controlled Cell Reselection Algorithm for Traffic Control Strategy"
GNMULBAC
FSH0418
"10.1.1 Measurements for Cell Selection and Re-selection" "10.3.1.1 Measurement Reporting"
GPATH GPDPDTCHA
FSH0720 FSH0503 CR - X617
"9.8.2 TBF Establishment Initiated by the MS on CCCH/PCCCH" "6.2 Configuration of GPRS Channels in a Cell" "6.3.2.1 Vertical Allocation Strategy (VA)" "6.3.2.3 Switching between VA and HA According to Radio Conditions"
GPENTIME
FSH0720 CR - F205
"10.1.2.2 C31 Criterion" "10.1.2.3 C32 Criterion" "10.1.4 Management of GPRS/EGPRS Neighboring Cells" "10.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUE"
GRESOFF
FSH0720 CR - F205 CR - X617
"10.1.2.2 C31 Criterion" "10.1.2.3 C32 Criterion" "10.1.4 Management of GPRS/EGPRS Neighboring Cells" "10.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUE"
Tab. 11.1
A30808-X3247-L24-1-7618
261
Parameter GRXLAMI
Chapters "10.1.2.1 GPRS/EGPRS Path Loss Criterion (C1 Criterion)" "10.1.4 Management of GPRS/EGPRS Neighboring Cells" "10.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUE" "10.3.1.2 Radio Link Network Controlled Cell Reselection Algorithm" "10.3.2.1 Network Controlled Cell Reselection Algorithm for Traffic Control Strategy"
GS GSUP (TRX object)
FSH0720 FSH0512
"9.8.2.6 Uplink Access on PRACH (Access Persistence Control)" "6.1.1 Enabling GPRS Service in the Cell" "6.1.2 Enabling EGPRS Service in the Cell" "6.2 Configuration of GPRS Channels in a Cell"
GSUP (ADJC object)
FSH0720
"10.1.4 Management of GPRS/EGPRS Neighboring Cells" "10.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUE" "10.1.4.4 Configuration of an Adjacent Cell with GSUP= FALSE"
GTDDMURREP GTEMPOFF
FSH0418 FSH0720 CR - F205
"10.3.1.1 Measurement Reporting" "10.1.2.2 C31 Criterion" "10.1.2.3 C32 Criterion" "10.1.4 Management of GPRS/EGPRS Neighboring Cells" "10.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUE"
GTS
FSH0720
"7.1 Physical Layer" "7.2.1.1 Examples of Addressing"
GTXINT GUMTSSRHPRI
FSH0720 FSH0418
"9.8.2.6 Uplink Access on PRACH (Access Persistence Control)" "10.1.1 Measurements for Cell Selection and Re-selection" "10.2 Cell Re-selection from GSM/GPRS/EGPRS Network to UMTS Network"
Tab. 11.1
262
A30808-X3247-L24-1-7618
Parameter IMCSULNIR8PSK
Feature/CR FSH0444
Chapters "4.2.2 EGPRS Channel Coding" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.3 Selection of the Candidate Initial Coding Scheme"
IMCSULNIRGMSK
FSH0444
"4.2.2 EGPRS Channel Coding" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.3 Selection of the Candidate Initial Coding Scheme"
INIBLER
FSH0516
"6.3.3.1 PCU Algorithm" "10.5.3 Selection of the Candidate Initial Coding Scheme"
INICSCH
FSH0720
"4.2.1 GPRS Channel Coding" "10.5.1.3 GPRS: Link Adaptation Algorithm" "10.5.3 Selection of the Candidate Initial Coding Scheme"
INIMCSDL
FSH0444
"4.2.2 EGPRS Channel Coding" "10.5.2.2 EGPRS: Link Adaptation Algorithm" "10.5.3 Selection of the Candidate Initial Coding Scheme"
LOWBER N3101
FSH0720 FSH0720 CR - X617 FSH0444
"7.1 Physical Layer" "9.9.3.3 Anomalies During an Uplink TBF" "10.5.1.2 Quality Traps Disadvantage" "9.9.3.4 Release of an Uplink TBF" "9.9.4.1 Acknowledged and Unacknowledged Modes on Downlink TBFs" "7.2.1.3 Procedures for PVCs" "7.2.1.3 Procedures for PVCs" "7.2.1.3 Procedures for PVCs" "10.4.2.3 Derivation of Channel Quality Reports" "7.3.1.1 BVC Procedures" "7.3.1.1 BVC Procedures" "7.3.1.1 BVC Procedures" "10.3.1.2 Radio Link Network Controlled Cell Reselection Algorithm"
N3103 N3105 N391 N392 N393 NAVGI NBVCBR NBVCUR NBVCRR NCC1TH
FSH0720 FSH0720 FSH0720 FSH0720 FSH0720 FSH0720 FSH0720 FSH0720 FSH0720 FSH0418
Tab. 11.1
A30808-X3247-L24-1-7618
263
Parameter NCC1THADJC
Feature/CR FSH0418
Chapters "10.3.1.2 Radio Link Network Controlled Cell Reselection Algorithm" "10.3.2.1 Network Controlled Cell Reselection Algorithm for Traffic Control Strategy"
NCGPENTIME
FSH0418
"10.3.1.2 Radio Link Network Controlled Cell Reselection Algorithm" "10.3.2.1 Network Controlled Cell Reselection Algorithm for Traffic Control Strategy"
NCGRESOFF
FSH0418
NCGPENTIME
FSH0418
NCRARESH
FSH0418
NCRESELFLAG
FSH0418
"10.3.1 Network Controlled Cell Reselection" "10.3.1.2 Radio Link Network Controlled Cell Reselection Algorithm" "10.3.2 GPRS/EGPRS Traffic Control Strategy"
NCSARA
FSH0418
NCTRFPSCTH NMO NNSVCBLKR NNSVCRR NNSVCTSTR
FSH0418 FSH0720 FSH0720 FSH0720 FSH0720
"10.3.2 GPRS/EGPRS Traffic Control Strategy" "9.8.3.1 Network Operation Modes for Paging" "7.2.2.2 Control Procedures" "7.2.2.2 Control Procedures" "7.2.2.2 Control Procedures" "7.3.3 SGSN-BSS Flow Control"
NNSVCUBLR Tab. 11.1
FSH0720
"7.2.2.2 Control Procedures"
264
A30808-X3247-L24-1-7618
Parameter NRLCMAX
Feature/CR FSH0720 CR - X617
Chapters "9.9.3.1 Uplink TBF Using the Acknowledged Mode" "9.9.4.1 Acknowledged and Unacknowledged Modes on Downlink TBFs"
NSEI
FSH0720
"7.2.1 Sub-Network Service: Frame Relay on Gb Interface" "7.2.1.1 Examples of Addressing" "7.3.1 BSSGP Addressing: BSSGP Virtual Connections (BVCs)"
NSVCI
FSH0720
"7.2.1 Sub-Network Service: Frame Relay on Gb Interface" "7.2.1.1 Examples of Addressing" "7.2.2.2 Control Procedures"
NSVLI
FSH0720
"7.2.1 Sub-Network Service: Frame Relay on Gb Interface" "7.2.1.1 Examples of Addressing"
NTWCNDRXP NTWCOR NTWCREPPIDL NTWCREPPTR
FSH0418 FSH0720 FSH0418 FSH0418
"10.3.1 Network Controlled Cell Reselection" "10.3.1 Network Controlled Cell Reselection" "10.3.1 Network Controlled Cell Reselection" "10.3.1 Network Controlled Cell Reselection" "10.3.1.1 Measurement Reporting"
NUA PCMECH PCML
FSH0720 FSH0720 FSH0720
"7.1 Physical Layer" "10.4.2.2 Packet Transfer Mode: Measurements for Power Control" "7.1 Physical Layer" "7.1 Physical Layer" "7.2.1.1 Examples of Addressing" REMOVED IN BR6.0 "9.8.2.6 Uplink Access on PRACH (Access Persistence Control)" "9.8.2.6 Uplink Access on PRACH (Access Persistence Control)" "9.8.2.6 Uplink Access on PRACH (Access Persistence Control)" "9.8.2.6 Uplink Access on PRACH (Access Persistence Control)"
PCUID (FLR object - FSH0720 In previous releases it was called PCUN) PCUN (PTPPKF object) PERSTLVPRI1 PERSTLVPRI2 PERSTLVPRI3 PERSTLVPRI4 FSH0720 FSH0420 FSH0420 FSH0420 FSH0420
Tab. 11.1
A30808-X3247-L24-1-7618
265
Parameter PKTMEASREPCNT PKTNDEC
Chapters "10.3.1.2 Radio Link Network Controlled Cell Reselection Algorithm" "9.9.3.1 Uplink TBF Using the Acknowledged Mode" "9.9.3.2 Uplink TBF Using the Unacknowledged Mode"
PKTNINC
FSH0720
"9.9.3.1 Uplink TBF Using the Acknowledged Mode" "9.9.3.2 Uplink TBF Using the Unacknowledged Mode"
PKTNMA
FSH0720
"9.9.3.1 Uplink TBF Using the Acknowledged Mode" "9.9.3.2 Uplink TBF Using the Unacknowledged Mode"
PRPBCCH
FSH0720
"10.4.2.1 Packet Idle Mode: Measurements for Power Control" "10.4.3 BTS Output Power"
QSRHPRI RAARET RACODE
CR - X482 FSH0720 FSH0720
"10.2.2 GSM-UMTS Re-selection Algorithm: Packet Switched Case" "10.1.5 Abnormal Cell Re-selection" "9.2 Network Structure" "10.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUE"
RACOL
FSH0720
"9.2 Network Structure" "9.2 Network Structure"
RAENV
FSH0444
"10.5 Link Adaptation" "10.5.1.3 GPRS: Link Adaptation Algorithm"
RARESH REMAL SCHWEIPRI1
FSH0720 FSH0720 FSH0550
"10.1.3 Cell Re-selection Algorithm" "7.1 Physical Layer" "9.9.7.2 Scheduling Process" "6.3.3.1 PCU Algorithm"
SCHWEIPRI2
FSH0550
"9.9.7.2 Scheduling Process" "6.3.3.1 PCU Algorithm"
SCHWEIPRI3
FSH0550
SCHWEIPRI4
FSH0550
Tab. 11.1
266
A30808-X3247-L24-1-7618
Parameter STGTTLLIINF
Feature/CR FSH0444
Chapters "10.5.1.2 Quality Traps Disadvantage" "10.5.3 Selection of the Candidate Initial Coding Scheme"
T1 T2 T3169
FSH0720 FSH0720 FSH0720
"7.3.1.1 BVC Procedures" "7.3.1.1 BVC Procedures" "9.9.3.3 Anomalies During an Uplink TBF" "9.9.3.4 Release of an Uplink TBF"
T3172 T3191 T3192 T3193 T391 TAVGT TAVGW TCONG TCONOFF TDDARFCN TDDDIV TDDGQO TEMPCH
FSH0720 FSH0720 FSH0720 CR - X617 FSH0720 CR - X617 FSH0720 FSH0720 FSH0720 FSH0720 FSH0720 FSH0418 FSH0418 FSH0418 FSH0720
"9.8.2.6 Uplink Access on PRACH (Access Persistence Control)" "9.9.4.2 Release of a Downlink TBF" "9.9.4.2 Release of a Downlink TBF" "9.9.4.2 Release of a Downlink TBF" "7.2.1.3 Procedures for PVCs" "10.4.2.2 Packet Transfer Mode: Measurements for Power Control" "10.4.2.1 Packet Idle Mode: Measurements for Power Control" "7.2.1.2 Frame Relay Structure" "7.2.1.2 Frame Relay Structure" "10.2.3 Handling of UMTS Neighboring Cells" "10.2.3 Handling of UMTS Neighboring Cells" "10.2.2 GSM-UMTS Re-selection Algorithm: Packet Switched Case" "6.3.1 Generalities about Resource Assignments" "6.3.3.1 PCU Algorithm" "6.3.3.2 TDPC Algorithm"
TEMPPDT TF1 THPROXT
FSH0429 FSH0720 FSH0720 CR - F287 CR - X617 CR - X1495 CR - X617 FSH0720
"6.3.1 Generalities about Resource Assignments" "7.3.3 SGSN-BSS Flow Control" This parameter was introduced for an older SMG release, and it is no longer used starting from BR6.0 release. "9.9.5 Notes About Concurrent TBFs" "9.9.4.2 Release of a Downlink TBF" "7.2.2.2 Control Procedures"
THSULBAL TIMEDTBFREL TNSVCBLK Tab. 11.1
A30808-X3247-L24-1-7618
267
Parameter TNSVCPTST
Feature/CR FSH0720
Chapters "7.2.2.2 Control Procedures" "7.3.3 SGSN-BSS Flow Control"
TNSVCR TNSVCTST
FSH0720 FSH0720
"7.2.2.2 Control Procedures" "7.2.2.2 Control Procedures" "7.3.3 SGSN-BSS Flow Control"
TRESEL TRFPS TRFPSCTRLT TRXMD
FSH0720 FSH0418 FSH0418 FSH0420
"10.1.5 Abnormal Cell Re-selection" "10.3.2 GPRS/EGPRS Traffic Control Strategy" This parameter in BR7.0 release is not significant. "6.1.1 Enabling GPRS Service in the Cell" "6.1.2 Enabling EGPRS Service in the Cell" "6.1.3 Aspects Related to Carrier Configuration" "9.8.2.4 TBF Establishment for EDGE Mobile Stations" "6.2 Configuration of GPRS Channels in a Cell"
TSULBAL UPGRFREQ Tab. 11.1
CR - X1495 FSH0516
"9.9.5 Notes About Concurrent TBFs" "6.3.4.1 Upgrade of Radio Resources"
Parameter ASSLAPD BSCT17 BSCT18 CELLGLID CELLRESH CPOLICY
Object
Feature/CR
Chapters "5.3.3 Configuration of the Abis Interface" "8.2 PCU Overload Management" "8.2 PCU Overload Management" "10.2.3 Handling of UMTS Neighboring Cells" "10.1.3 Cell Re-selection Algorithm" "6.3.3 Management of Incoming GPRS/EGPRS Requests" "6.3.3.1 PCU Algorithm" "6.3.3.2 TDPC Algorithm" "6.3.6.1 Pre-emption of PDCH Channels"
SUBTSLB FSH0419 BSC BSC TGTFDD BTS BSC ------CR - X260 ---FSH0457 CR - F092 CR - X1150
ENFOIAHO
BSC
FSH0457 CR - F092
"6.3.6.3 Forced Intracell Handovers of Already Established CS Calls"
Tab. 11.2
Not Specic GPRS/EGPRS Parameters Involved in PS Services
268
A30808-X3247-L24-1-7618
Parameter DGRSTRGY
Object BSC
Feature/CR FSH0457 CR - F092 CR - X912 CR - X1150 CR - X260 CR - X260 CR - X260 CR - X260 CR - X482
Chapters "6.3.6 Waiting Queue Management" "6.3.6.1 Pre-emption of PDCH Channels"
FDDARFCN FDDDIV FDDQO FDDQMI
TGTFDD TGTFDD BTS BTS
"10.2.3 Handling of UMTS Neighboring Cells" "10.2.3 Handling of UMTS Neighboring Cells" "10.2.1 GSM-UMTS Re-selection Algorithm: Circuit Switched Case" "10.2.1 GSM-UMTS Re-selection Algorithm: Circuit Switched Case" "10.2.2 GSM-UMTS Re-selection Algorithm: Packet Switched Case"
FDDSCRMC MSTXPMAXCH NBLKACGR NFRAMEPG NTWCARD
TGTFDD BTS BTS BTS BSC
CR - X260 ---------FSH0397
"10.2.3 Handling of UMTS Neighboring Cells" "10.1.2.1 GPRS/EGPRS Path Loss Criterion (C1 Criterion)" "9.8.3.2 Discontinuous Reception" "9.8.3.2 Discontinuous Reception" "4.2.1 GPRS Channel Coding" "5.1 Supported BSC Types" "6.1.2 Enabling EGPRS Service in the Cell"
PUREBBSIG44 CONF QSRHI RNCID RXLEVAMI TDDQO TGTCELL
BTS BTS TGTFDD BTS BTS ADJC
---CR - X260 CR - X260 ---FSH0418 FSH1928 CR - F119
"4.2.1 GPRS Channel Coding" "10.2.1 GSM-UMTS Re-selection Algorithm: Circuit Switched Case" "10.2.3 Handling of UMTS Neighboring Cells" "10.1.2.1 GPRS/EGPRS Path Loss Criterion (C1 Criterion)" "10.2.1 GSM-UMTS Re-selection Algorithm: Circuit Switched Case" "10.1.4 Management of GPRS/EGPRS Neighboring Cells" "10.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUE"
TGTCELL
ADJC3G
CR - X260
"10.2.3 Handling of UMTS Neighboring Cells"
Tab. 11.2
Not Specic GPRS/EGPRS Parameters Involved in PS Services
A30808-X3247-L24-1-7618
269
Object FRL NSVC PCMG PCU PTPPKF TGTPTPPKF
Feature FSH0720 FSH0720 FSH0720 FSH0720 FSH0720 FSH1928 CR - F119
Chapters "7 Gb Interface" "7 Gb Interface" "7 Gb Interface" "5 Hardware and Software Features" "4 Radio Interface" "10.1.4 Management of GPRS/EGPRS Neighboring Cells"
Tab. 11.3
Object Related to the GPRS/EGPRS Services only
Object ADJC ADJC3G SUBTSLB TGTBTS TGTFDD TGTTDD Tab. 11.4
Feature/CR ---CR - X260 FSH0419 FSH1928 CR - F119 CR - X260 FSH0418
Chapters "10.1 Cell Selection and Re-selection" "10.2.3 Handling of UMTS Neighboring Cells" "5.3.3 Configuration of the Abis Interface" "10.1.4 Management of GPRS/EGPRS Neighboring Cells" "10.2.3 Handling of UMTS Neighboring Cells" "10.2.3 Handling of UMTS Neighboring Cells"
Not Specic GPRS/EGPRS Objects Involved in PS Services
270
A30808-X3247-L24-1-7618
12 Abbreviations
AGCH BCCH BECN BSC BSN BSS BSSGP BTS BVC BVCI CCCH CCU CS DCE DE DLCI DRX DTE EGPRS FDD FECN FR FRL GGSN GMSK GPRS HA HCS HLR HSCSD HSN IMSI IP IR LA LAC LAPD LLC LMT MA Access Grant Channel Broadcast Control Channel Backward Explicit Congestion Notification Base Station Controller Block Sequence Number Base Station Subsystem Base Station System GPRS Protocol Base Transceiver Station BSSGP Virtual Connection BSSGP Virtual Connection Identifier Common Control Channel Channel Control Unit Circuit Switched Data Circuit-terminating Equipment Discard Eligibility Indicator Data Link Connection Identifier Discontinous Reception Data Terminal Equipment Enhanced General Packet Radio Service Frequency Division Duplex Forward Explicit Congestion Notification Frame Relay Frame Relay Link Gateway GPRS Support Node Gaussian Minimum Shift Keying General Packet Radio Service Horizontal Allocation Hierarchical Cell Structures Home Location Register High Speed Circuit Switched Data Hopping Sequence Number International Mobile Subscriber Identity Internet Protocol Incremental Redundancy Location Area Location Area Code Link Access Procedure on the D-channel Logical Link Control Local Maintenance Terminal Mobile Allocation
A30808-X3247-L24-1-7618
271
MAC MAIO MCC MCS MNC MOI MS MSC NS SDU NS NSEI NSVC NSVCI NSVL NSVLI NUC O&M PAGCH PBCCH PCCCH PCH PCU PDCH PDT PDTCH PDU PDU PLMN PPCH PRACH PS PSI PSK PTCCH PTM P-TMSI PTP PTPPKF PVC QoS
Medium Access Control Mobile Allocation Index Offset Mobile Country Code Modulation and Coding Scheme Mobile Network Code Managed Object Instance Mobile Station Mobile Switching Centre Network Service Service Data Unit Network Service Network Service Entity Identifier Network Service Virtual Connection Network Service Virtual Connection Identifier Network Service Virtual Link Network Service Virtual Link Identifier Nailed Up Connection Operation and Maintenance Packet Acces Grant Channel Packet Broadcast Control Channel Packet Common Control Channel Paging Channel Packet Control Unit Packet Data Channel Packet Data Terminal Packet Data Traffic Channel Packet Data Network Packet Data Unit Public Land Mobile Network Packet Paging Channel Packet Random Acces Channel Packet Switched Packet System Information Phase Shift Keying Packet Timing Advance Control Channel Point to Multipoint Packet Temporary Mobile Subscriber Identity Point to Point Point To Point Packet Function Permanent Virtual Circuit Quality of Service
272
A30808-X3247-L24-1-7618
RA RAC RACH RAI RAT RC RLC SGSN SMS SNDCF SS7 TAI TBF TCH TDD TDMA TFI TLLI TSC UE UMTS USF VA VLR
Routing Area Routing Area Code Random Access Channel Routing Area Identity Radio Access Technology Radio Commander Radio Link Control Serving GPRS Support Node Short Message Service SubNetwork Dependent Convergence Protocol Signalling System number 7 Timing Advance Index Temporary Block Flow Traffic Channel Time Division Duplex Time Division Multiple Access Temporary Flow Identity Temporary Logical Link Identity Training Sequence Code User Equipment Universal Mobile Telecommunication System Uplink State Flag Vertical Allocation Visitor Location Register
A30808-X3247-L24-1-7618
273

Gprs Siemens

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Gprs Siemens

Transféré par

Droits d'auteur :

Formats disponibles

Information

Base Station System GPRS/EGPRS Global Description

GPRS/EGPRS Global Description

Information Base Station System

Important Notice on Product Safety

Copyright (C) Siemens AG 2003.

Information Base Station System

GPRS/EGPRS Global Description

Reason for Update

GPRS/EGPRS Global Description

Information Base Station System

Information Base Station System

GPRS/EGPRS Global Description

GPRS/EGPRS Global Description

Information Base Station System

Information Base Station System

GPRS/EGPRS Global Description

GPRS/EGPRS Global Description

Information Base Station System

Information Base Station System

GPRS/EGPRS Global Description

Fig. 5.2 Fig. 5.3

GPRS/EGPRS Global Description

Information Base Station System

Fig. Fig. Fig. Fig.

5.4 5.5 5.6 5.7

Fig. 8.3 Fig. 8.4 Fig. 8.5

Information Base Station System

GPRS/EGPRS Global Description

GPRS/EGPRS Global Description

Information Base Station System

Information Base Station System

GPRS/EGPRS Global Description

Structure of the Manual

GPRS/EGPRS Global Description

Information Base Station System

Information Base Station System

GPRS/EGPRS Global Description

2 Siemens Features Description

BR5.5 Feature Description

GPRS/EGPRS Global Description

Information Base Station System

Information Base Station System

GPRS/EGPRS Global Description

BR6.0 Feature Description

GPRS/EGPRS Global Description

Information Base Station System

Information Base Station System

GPRS/EGPRS Global Description

GPRS/EGPRS Global Description

Information Base Station System

BR7.0 Feature Description

Information Base Station System

GPRS/EGPRS Global Description

GPRS/EGPRS Global Description

Information Base Station System

Information Base Station System

GPRS/EGPRS Global Description

GPRS/EGPRS Global Description

Information Base Station System

GPRS and EGPRS Modulation Principles

Basic GMSK Constellation of Signal Vectors

Basic 8 PSK Constellation of Signal Vectors