Gprs

Information
System
GPRS/EGPRS Global Description
A30808-X3247-M24-5-7618
GPRS/EGPRS Global Description Information
System
f 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
Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.
In diesen Anlagen stehen die Netzversorgungsleitungen unter gefährlicher Spannung. Einige Komponenten
können auch eine hohe Betriebstemperatur aufweisen.
Nichtbeachtung der Installations- und Sicherheitshinweise kann zu schweren Körperverletzungen oder
Sachschäden führen.
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 accor-
dance with the relevant standards referenced in the manual “Guide to Documentation”, may cause harmful inter-
ference to radio communications.
For system installations it is strictly required to choose all installation sites according to national and local require-
ments 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 2006.
Issued by the Communications Group

Hofmannstraße 51
D-81359 München
Technical modifications possible.

Technical specifications and features are binding only insofar as
they are specifically and expressly agreed upon in a written contract.
2 A30808-X3247-M24-5-7618
Information GPRS/EGPRS Global Description
System
This document consists of a total of 391 Pages. All pages are issue 5.
Reason for Update

Summary:
Fifth Edition for release BR 8.0
Details:
Chapter/Section Reason for Update
3 Changes due to enhancements to current features

4 Changes due to enhancements to current features
Issue History
Issue Date of Reason for Update
Number Issue
1 01/2005 First Edition for new release BR 8.0

2 04/2005 Second Edition for release BR 8.0
3 07/2005 Third Edition for release BR 8.0
4 11/2005 Fourth Edition for release BR 8.0
5 03/2006 Fifth Edition for release BR 8.0
A30808-X3247-M24-5-7618 3
System
Contents
1 Introductions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1 Generality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Structure of the Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Siemens Features Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 SBS BR5.5 Feature Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 GPRS/EGPRS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1 GPRS and EGPRS Modulation Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3 GPRS/EGPRS supported by satellite links . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.1 Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4 GPRS/EGPRS Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5 Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6 RLC/MAC Block and Radio Block Structures. . . . . . . . . . . . . . . . . . . . . . . . 50
3.6.1 RLC/MAC and Radio Block Structures: Data Transfer . . . . . . . . . . . . . . . . 50
3.6.1.1 RLC/MAC Block and Radio Block Structures for GPRS Data Transfer . . . . 51
3.6.1.2 RLC/MAC Block and Radio Block Structure for EGPRS Data Transfer. . . . 51
3.6.2 RLC/MAC Block Structure: Control Signaling . . . . . . . . . . . . . . . . . . . . . . . 52
4 Radio Interface Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.1 GPRS/EGPRS Physical Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2 Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.1 GPRS Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.2 EGPRS Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3 Temporary Block Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.1 Extended Uplink Temporary Block Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.2 Multiplexing MSs on the same PDCH: Downlink Direction . . . . . . . . . . . . . 70
4.3.3 Multiplexing MSs on the same PDCH: Uplink Direction. . . . . . . . . . . . . . . . 71
4.3.4 Multiplexing MSs on the same PDCH: Configuration. . . . . . . . . . . . . . . . . . 73
4.4 GPRS/EGPRS Logical Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4.1 Packet Broadcast Control Channel (PBCCH) . . . . . . . . . . . . . . . . . . . . . . . 74
4.4.2 Packet Common Control Channel (PCCCH) . . . . . . . . . . . . . . . . . . . . . . . . 75
4.4.3 Packet Data Traffic Channel (PDTCH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.4.4 Packet Dedicated Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.4.5 Coding of GPRS/EGPRS Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . 78
4.5 Mapping of Logical Channels onto Physical Channels . . . . . . . . . . . . . . . . 79
4.5.1 PDCH without the Specific GPRS/EGPRS Signaling . . . . . . . . . . . . . . . . . 79
4.5.2 PDCH Carrying both PBCCH and PCCCH . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.5.3 PDCH Carrying PCCCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.6 Packet Timing Advance Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.6.1 Initial Timing Advance Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.6.2 Continuous Timing Advance Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.7 Multislot Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4 A30808-X3247-M24-5-7618
System
4.7.1 Mobile Station Classes for Multislot Capabilities . . . . . . . . . . . . . . . . . . . . 86

4.7.2 Mapping of Uplink Packet Traffic Logical Channels . . . . . . . . . . . . . . . . . . 87
4.7.3 Mapping of Downlink Packet Traffic Logical Channels . . . . . . . . . . . . . . . . 88
5 Radio Resources Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.1 Radio Channel Allocation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2 Radio Resource Allocation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3 Multiband Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4 Dual Band Standard Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.5 Enabling Packet Switched Services in a Cell . . . . . . . . . . . . . . . . . . . . . . 101
5.5.1 Aspects Related to Carrier Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.6 Configuration of GPRS Channels in a Cell . . . . . . . . . . . . . . . . . . . . . . . . 104
5.7 Management of Packet Data Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.7.1 Generalities about Resource Assignments. . . . . . . . . . . . . . . . . . . . . . . . 106
5.7.2 Horizontal/Vertical Allocation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.7.2.1 Vertical Allocation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.7.2.2 Horizontal Allocation Strategy (HA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.7.2.3 Switching between VA and HA According to Radio Conditions . . . . . . . . 110
5.7.2.4 Switching between VA and HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.7.2.5 Allocation of Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.7.3 Extended Dynamic Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.7.4 Management of Incoming GPRS/EGPRS Requests . . . . . . . . . . . . . . . . 119
5.7.4.1 PCU Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.7.4.2 TDPC Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.7.5 Upgrading Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.7.5.1 Upgrade of Radio Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.7.5.2 Upgrade of Abis Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.7.6 Incoming CS Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.7.7 Waiting Queue Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.7.7.1 Pre-emption of PDCH Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.7.7.2 Pre-emption of PDT Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.7.7.3 Forced Intracell Handovers of already established CS Calls . . . . . . . . . . 139
5.7.8 Flexible USF Granularity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6 Hardware and Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

6.1 Supported BSC Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.1.1 BSC/72 (Standard BSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.1.2 BSC/120 (High Capacity BSC Step II) . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.1.3 Redundancy and Configuration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.2 BTS Equipment Supporting GPRS and EGPRS. . . . . . . . . . . . . . . . . . . . 151
6.3 PCU Frames and Dynamic Allocation on the Abis Interface. . . . . . . . . . . 151
6.3.1 Concatenated PCU Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.3.2 Flexible Abis Allocation and Concatenated PCU Frames . . . . . . . . . . . . . 157
6.3.3 Configuration of Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.3.4 Algorithms Regarding Flexible Abis Allocation . . . . . . . . . . . . . . . . . . . . . 160
6.3.5 Abis over satellite links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.4 Packet Switched Services Supported on CCCH/PCCCH . . . . . . . . . . . . . 163
A30808-X3247-M24-5-7618 5
System
7 Gb Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
7.2 Network Service Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
7.2.1 Sub-Network Service: Frame Relay on Gb Interface . . . . . . . . . . . . . . . . . 172
7.2.1.1 Examples of Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
7.2.1.2 Frame Relay Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
7.2.1.3 Procedures for PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
7.2.2 Network Service Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
7.2.2.1 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
7.2.2.2 Control Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
7.3 BSSGP Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
7.3.1 BSSGP Addressing: BSSGP Virtual Connections (BVCs). . . . . . . . . . . . . 186
7.3.1.1 BVC Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
7.3.2 Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
7.3.3 SGSN-BSS Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
7.3.3.1 MS Flow Control Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
7.3.3.2 BVC Flow Control Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
7.3.3.3 Flow Control sending criteria (for both BVC and MS) . . . . . . . . . . . . . . . . 200
7.3.4 Multiple PCU Pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
7.3.4.1 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
7.3.4.2 Suspend/Resume. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
7.3.4.3 Flush LL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
7.3.4.4 BSS Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7.3.4.5 Dynamic Cell Allocation and Load Balancing. . . . . . . . . . . . . . . . . . . . . . . 207
7.3.5 Enhanced Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7.3.6 Quality Control Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
7.4 High Speed Gb Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
7.4.1 Gb over IP protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
7.4.2 BSC Hardware and Upgrade Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
8 Load Control for Packet Switched Services . . . . . . . . . . . . . . . . . . . . . . . . 221

8.1 Dynamic PTPPKF Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
8.1.1 System Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
8.1.2 Creation of a PCU Object and Enabling a NSVC for It . . . . . . . . . . . . . . . 224
8.1.3 PCU Not Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
8.1.4 PCU Comes Back in Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
8.1.5 Time Needed to Execute PTPPKF Reconfiguration . . . . . . . . . . . . . . . . . 230
8.2 PCU Overload Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
9 GPRS/EGPRS Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

9.1 Mobile Stations for Packet Switched Services . . . . . . . . . . . . . . . . . . . . . . 232
9.2 Network Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
9.3 Mobility Management Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
9.3.1 Mobility Management States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
9.3.1.1 IDLE State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
9.3.1.2 STAND-BY State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
9.3.1.3 READY State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
9.3.2 Mobility Management Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
6 A30808-X3247-M24-5-7618
System
9.3.2.1 Attach Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

9.3.2.2 Detach Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
9.4 Radio Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
9.4.1 Packet Idle State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
9.4.2 Packet Transfer State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
9.5 Correspondence between RR States and MM States . . . . . . . . . . . . . . . 239
9.6 Packet Data Protocol Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
9.6.1 INACTIVE State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
9.6.2 ACTIVE State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
9.7 Activation and Deactivation of a PDP Context . . . . . . . . . . . . . . . . . . . . . 241
9.7.1 PDP Context Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
9.7.2 PDP Context Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
9.7.3 One Time Slot for MM and SM procedures . . . . . . . . . . . . . . . . . . . . . . . 242
9.8 Access to the Network (Establishment of a TBF) . . . . . . . . . . . . . . . . . . . 243
9.8.1 Medium Access Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
9.8.2 TBF Establishment Initiated by the MS on CCCH/PCCCH. . . . . . . . . . . . 243
9.8.2.1 8 Bit or 11 Bit Uplink Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
9.8.2.2 Establishment using a One Phase Access . . . . . . . . . . . . . . . . . . . . . . . . 245
9.8.2.3 TBF Establishment using a Two Phases Access . . . . . . . . . . . . . . . . . . . 247
9.8.2.4 TBF Establishment for EDGE Mobile Stations . . . . . . . . . . . . . . . . . . . . . 248
9.8.2.5 Contention Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
9.8.2.6 Uplink Access on PRACH (Access Persistence Control) . . . . . . . . . . . . . 251
9.8.3 TBF Establishment Initiated by the Network on CCCH/PCCCH . . . . . . . . 252
9.8.3.1 Network Operation Modes for Paging. . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
9.8.3.2 Discontinuous Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
9.8.4 Relative Reserved Block Period Field (RRBP) . . . . . . . . . . . . . . . . . . . . . 258
9.8.5 Polling Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
9.9 RLC Data Block Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
9.9.1 Acknowledged Mode for RLC/MAC Operation . . . . . . . . . . . . . . . . . . . . . 260
9.9.1.1 GPRS Acknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
9.9.1.2 EGPRS Acknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
9.9.2 Unacknowledged Mode for RLC/MAC Operation . . . . . . . . . . . . . . . . . . . 263
9.9.3 Operations on Uplink TBF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
9.9.3.1 Uplink TBF Using the Acknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . 263
9.9.3.2 Uplink TBF Using the Unacknowledged Mode . . . . . . . . . . . . . . . . . . . . . 265
9.9.3.3 Anomalies During an Uplink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
9.9.3.4 Release of an Uplink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
9.9.4 Operations on Downlink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
9.9.4.1 Acknowledged and Unacknowledged Modes on Downlink TBFs . . . . . . . 269
9.9.4.2 Release of a Downlink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
9.9.5 Notes About Concurrent TBFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
9.9.6 Suspend/Resume Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
9.9.7 GPRS/EGPRS TBF Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
9.9.7.1 Supported QoS Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
9.9.7.2 Scheduling Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
9.9.8 EGPRS/GPRS Scheduler Enhancements for Rel5 Qos Support . . . . . . . 280
9.10 Quality of Service Support for PS Services . . . . . . . . . . . . . . . . . . . . . . . 286
A30808-X3247-M24-5-7618 7
System
9.10.1 QoS and RRM procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

9.10.2 QoS and BSS impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
9.11 EGPRS/GPRS on Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
9.11.1 Assignment of resources on extended cells. . . . . . . . . . . . . . . . . . . . . . . . 299
9.11.2 TAI Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
9.11.3 Time Offset values in Abis Downlink PCU frames . . . . . . . . . . . . . . . . . . . 300
9.11.4 Timing Advance Update in Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . 301
9.11.5 Transition between near and far Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
9.11.6 Extended Cells and Radio Resource Manager . . . . . . . . . . . . . . . . . . . . . 302
10 GPRS/EGPRS Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

10.1 Cell Selection and Re-selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
10.1.1 Measurements for Cell Selection and Re-selection . . . . . . . . . . . . . . . . . . 304
10.1.2 Cell selection and Re-selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
10.1.2.1 GPRS/EGPRS Path Loss Criterion (C1 Criterion) . . . . . . . . . . . . . . . . . . . 305
10.1.2.2 C31 Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
10.1.2.3 C32 Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
10.1.3 Cell Re-selection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
10.1.4 Management of GPRS/EGPRS Neighboring Cells . . . . . . . . . . . . . . . . . . 311
10.1.4.1 Handling of Neighboring Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
10.1.4.2 GPRS/EGPRS Neighboring Cells and Involved Parameters . . . . . . . . . . . 313
10.1.4.3 Configuration of an Adjacent Cell supporting GPRS . . . . . . . . . . . . . . . . . 314
10.1.4.4 Configuration of an Adjacent Cell not supporting GPRS . . . . . . . . . . . . . . 315
10.1.5 Abnormal Cell Re-selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
10.2 Network Assisted Cell Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
10.3 Cell Re-selection from GSM/GPRS/EGPRS Network to UMTS Network . 321
10.3.1 GSM-UMTS Re-selection Algorithm: Circuit Switched Case . . . . . . . . . . . 321
10.3.2 GSM-UMTS Re-selection Algorithm: Packet Switched Case . . . . . . . . . . 322
10.3.3 Handling of UMTS Neighboring Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
10.4 Network Controlled Cell Reselection and Traffic Control Management . . . 325
10.4.1 Network Controlled Cell Reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
10.4.1.1 Measurement Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
10.4.1.2 Radio Link Network Controlled Cell Reselection Algorithm . . . . . . . . . . . . 329
10.4.2 NC Cell Reselection due to sufficient UMTS coverage . . . . . . . . . . . . . . . 331
10.4.2.1 Enhancement of the NCCR G->G algorithm . . . . . . . . . . . . . . . . . . . . . . . 337
10.4.3 GPRS/EGPRS Traffic Control Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 340
10.4.3.1 Network Controlled Cell Reselection Algorithm . . . . . . . . . . . . . . . . . . . . . 341
10.5 Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
10.5.1 Power Control Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
10.5.2 Measurement at the MS Side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
10.5.2.1 Packet Idle Mode: Measurements for Power Control. . . . . . . . . . . . . . . . . 345
10.5.2.2 Packet Transfer Mode: Measurements for Power Control . . . . . . . . . . . . . 346
10.5.2.3 Derivation of Channel Quality Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
10.5.3 BTS Output Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
10.5.4 DTM Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
10.6 Mobile Station Overheating Management . . . . . . . . . . . . . . . . . . . . . . . . . 348
10.7 Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
10.7.1 Link Adaptation for GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
8 A30808-X3247-M24-5-7618
System
10.7.1.1 GPRS: Switching Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

10.7.1.2 “Quality Traps” Disadvantage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
10.7.1.3 GPRS: Link Adaptation Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
10.7.2 Link Adaptation for EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
10.7.2.1 EGPRS: Switching Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
10.7.2.2 EGPRS: Link Adaptation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
10.7.3 Selection of the Candidate Initial Coding Scheme . . . . . . . . . . . . . . . . . . 368
11 Managed Objects and attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
12 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
A30808-X3247-M24-5-7618 9
System
Illustrations
Fig. 3.1 Basic GMSK Constellation of Signal Vectors . . . . . . . . . . . . . . . . . . . . . 40
Fig. 3.2 Basic 8 PSK Constellation of Signal Vectors . . . . . . . . . . . . . . . . . . . . . 41
Fig. 3.3 GPRS/EGPRS Network Architecture.. . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Fig. 3.4 Protocol Stack for Data Transmission in GPRS/EGPRS Network. . . . . . 46
Fig. 3.5 Data Flow across Protocol Layers in case of GPRS/
EGPRS(MSC1...MSC6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Fig. 3.6 Data Flow across Protocol Layers in case of EGPRS(MSC7...MSC9) . . 48
Fig. 3.7 Data Flow from the SGSN up to the Mobile Station.. . . . . . . . . . . . . . . . 50
Fig. 3.8 RLC/MAC block’s structure for Data Transfer. . . . . . . . . . . . . . . . . . . . . 51
Fig. 3.9 Radio Block structure for Data Transfer on the “Um” Interface. . . . . . . . 51
Fig. 3.10 RLC/MAC Block structure with one RLC Data Block field . . . . . . . . . . . 51
Fig. 3.11 RLC/MAC Block structure with two RLC Data block fields . . . . . . . . . . . 52
Fig. 3.12 Radio Block for Data Transfer with one RLC Data Block field . . . . . . . . 52
Fig. 3.13 Radio Block for Data Transfer with two RLC Data Block field . . . . . . . . 52
Fig. 3.14 RLC/MAC Block Structure for Control Messages . . . . . . . . . . . . . . . . . . 53
Fig. 3.15 Radio Block for Control Messages (signaling). . . . . . . . . . . . . . . . . . . . . 53
Fig. 4.1 Packet Data Channel (PDCH) within a TDMA frame . . . . . . . . . . . . . . . 55
Fig. 4.2 Multiframe Structure for a PDCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Fig. 4.3 GPRS Coding Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Fig. 4.4 Coding of the RLC/MAC Block using CS-1. . . . . . . . . . . . . . . . . . . . . . . 60
Fig. 4.5 EGPRS Coding Schemes and Families . . . . . . . . . . . . . . . . . . . . . . . . . 63
Fig. 4.6 Interleaving of MCS9 Coded Data into Two Consecutive Normal Bursts65
Fig. 4.7 Interleaving of MCS6 Coded Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Fig. 4.8 Multiplexing Mobile Station on the same PDCH (Downlink) . . . . . . . . . . 71
Fig. 4.9 Multiplexing Mobile Station on the same PDCH (Uplink) . . . . . . . . . . . . 72
Fig. 4.10 Example of Mapping of the PBCCH Channel. . . . . . . . . . . . . . . . . . . . . 75
Fig. 4.11 Packet Common Control Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Fig. 4.12 Example of Mapping of the PCCCH Channel. . . . . . . . . . . . . . . . . . . . . 77
Fig. 4.13 Example of Mapping of two PCCCH Channels. . . . . . . . . . . . . . . . . . . . 77
Fig. 4.14 Mapping of Logical Channels into DL Physical Channel . . . . . . . . . . . . 79
Fig. 4.15 Mapping of Logical Channels into UL Physical Channel . . . . . . . . . . . . 80
Fig. 4.16 Example of DL Configuration with PBCCH and PCCCH Channels . . . . 81
Fig. 4.17 Example of Uplink Configuration with PRACH Channel. . . . . . . . . . . . . 82
Fig. 4.18 Continuous Timing Advance Update Feature . . . . . . . . . . . . . . . . . . . . . 85
Fig. 4.19 Example of Multislot Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Fig. 5.1 Multiband GSM mobile network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Fig. 5.2 Example of GPRS/EGPRS configuration.. . . . . . . . . . . . . . . . . . . . . . . 105
Fig. 5.3 Example of Vertical Allocation strategy. . . . . . . . . . . . . . . . . . . . . . . . . 109
Fig. 5.4 Example of the Horizontal Allocation Algorithm . . . . . . . . . . . . . . . . . . 110
Fig. 5.5 Example of a Cell Configured with Five TRXs. . . . . . . . . . . . . . . . . . . . 112
Fig. 5.6 Channel Allocation Algorithm’s Flow Chart (CAA) . . . . . . . . . . . . . . . . 116
Fig. 5.7 Algorithm for MS configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Fig. 5.8 Resource Reallocation Process and Functional Entities affected. . . . . 118
10 A30808-X3247-M24-5-7618
System
Fig. 5.9 Allocation Algorithm implemented in PCU . . . . . . . . . . . . . . . . . . . . . . 126

Fig. 5.10 Allocation Algorithm implemented in TDPC . . . . . . . . . . . . . . . . . . . . . 131
Fig. 6.1 EGPRS/GPRS BSS Hardware and Software Entities . . . . . . . . . . . . . 142
Fig. 6.2 BSC/72 (standard BSC) Rack.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Fig. 6.3 High Capacity BSC with the New Rack . . . . . . . . . . . . . . . . . . . . . . . . 149
Fig. 6.4 Fundamental Principle of Concatenated PCU Frames . . . . . . . . . . . . 154
Fig. 6.5 Abis Mapping for a DL MCS9 radio block . . . . . . . . . . . . . . . . . . . . . . 156
Fig. 6.6 Relationship between PCU Frames and Abis Allocation . . . . . . . . . . 157
Fig. 6.7 PCU Frames and Abis Allocation Relationship (BSS < BR8.0) . . . . . . 158
Fig. 6.8 BTSE not supporting the Abis Dynamic Allocation . . . . . . . . . . . . . . . 159
Fig. 6.9 Mapping of CCCH/PCCCH Channels on the Abis Interface.. . . . . . . . 163
Fig. 6.10 CCCH/PCCCH Message Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Fig. 7.1 Gb Interface: Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Fig. 7.2 Connection Types between BSC and SGSN . . . . . . . . . . . . . . . . . . . 167
Fig. 7.3 Example of Frame Relay Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Fig. 7.4 Example of Frame Relay Link (GTS=3). . . . . . . . . . . . . . . . . . . . . . . . 171
Fig. 7.5 Example of Frame Relay Link (GTS=3&4&5&6).. . . . . . . . . . . . . . . . . 171
Fig. 7.6 Example of Frame Relay Link (GTS=3&4&7&8).. . . . . . . . . . . . . . . . . 171
Fig. 7.7 Network Service Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Fig. 7.8 Gb Interface with a Frame Relay Network . . . . . . . . . . . . . . . . . . . . . . 173
Fig. 7.9 Creation of a NSVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Fig. 7.10 BSC Configured with One PCU and Two FR Links (64 kbit/s each).. . 176
Fig. 7.11 BSC supporting 1 PCU and 2 FR Links . . . . . . . . . . . . . . . . . . . . . . . 177
Fig. 7.12 BSC Configured with Two PCUs and Two FR Links each one.. . . . . . 178
Fig. 7.13 Frame Relay Network Connecting two DTE Devices . . . . . . . . . . . . . 180
Fig. 7.14 Frame Relay Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Fig. 7.15 Periodic Polling Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Fig. 7.16 Distribution of Packet Switched Data Traffic among Different Cells . . 188
Fig. 7.17 Cascaded Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Fig. 7.18 Token Leaky Bucket (in the SGSN network node) . . . . . . . . . . . . . . . 192
Fig. 7.19 Closed Loop Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Fig. 7.20 Example Cell Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Fig. 7.21 Message:MS-FLOW-CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Fig. 7.22 SGSN does not answer with the message: MS-FLOW-CONTROL. . . 201
Fig. 7.23 Closed-loop control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Fig. 7.24 BSSGP Flow Control Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Fig. 7.25 Example of TBF Establishment and TBF Reconfiguration. . . . . . . . . . 211
Fig. 7.26 Example of messages in case of TBF Release . . . . . . . . . . . . . . . . . . 212
Fig. 7.27 QCF and PFC Flow Control processes . . . . . . . . . . . . . . . . . . . . . . . . 214
Fig. 7.28 Uplink guaranteed bandwidth: system’s model . . . . . . . . . . . . . . . . . . 215
Fig. 7.29 High Speed Gb interface: Logical Network view . . . . . . . . . . . . . . . . . 216
Fig. 7.30 Gb over IP protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Fig. 7.31 Wan Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Fig. 7.32 IP over Ethernet Encapsulation schema . . . . . . . . . . . . . . . . . . . . . . . 219
A30808-X3247-M24-5-7618 11
System
Fig. 8.1 Example of PTPPKF Distribution During System Initialization . . . . . . . 224

Fig. 8.2 Example of PTPPKF distribution-Step 1 . . . . . . . . . . . . . . . . . . . . . . . . 225
Fig. 8.3 Example of PTPPKF distribution - Step 2 . . . . . . . . . . . . . . . . . . . . . . . 226
Fig. 8.4 Example of PTPPKF distribution in case of PCU unavailable . . . . . . . 227
Fig. 8.5 Example of PTPPKF distribution when a PCU is in Service . . . . . . . . . 229
Fig. 9.1 Network Structure: Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Fig. 9.2 Mobility Management States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Fig. 9.3 Radio Resource States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Fig. 9.4 Packet Data Protocol States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Fig. 9.5 Coding of the 11 Bit Access Burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Fig. 9.6 One Phase Access on PCCCH channel . . . . . . . . . . . . . . . . . . . . . . . 247
Fig. 9.7 Two Phases Access on the CCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Fig. 9.8 Packet Access Reject Procedure.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Fig. 9.9 TBF Establishment Initiated by the Network on the PCCCH channel. . 254
Fig. 9.10 Behavior of T3182 Timer and N3102 Counter . . . . . . . . . . . . . . . . . . . 265
Fig. 9.11 Detection of anomalies during an Uplink TBF on the Network Side . . . 266
Fig. 9.12 Release of an Uplink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Fig. 9.13 Release of the resources on Network Side during an UL TBF . . . . . . 268
Fig. 9.14 Control Procedure Executed by the Network during a Downlink TBF . 270
Fig. 9.15 Release of a Downlink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Fig. 9.16 Suspend Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Fig. 9.17 Resume Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Fig. 9.18 Resume Procedure (The MS has changed the Routing Area) . . . . . . . 278
Fig. 9.19 Enabled PFC Management without Multiple TBF . . . . . . . . . . . . . . . . . 281
Fig. 9.20 Example of Mobile Stations with two Uplink timeslots . . . . . . . . . . . . . 298
Fig. 10.1 Management of Adjacent Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Fig. 10.2 Network Assisted Cell Change algorithm . . . . . . . . . . . . . . . . . . . . . . . 319
Fig. 10.3 Network Controlled Cell Reselection Procedure . . . . . . . . . . . . . . . . . . 328
Fig. 10.4 Combined GSM/UMTS Network Architecture . . . . . . . . . . . . . . . . . . . . 332
Fig. 10.5 Allocation phase: Calculation of: “Max_N_UL_TS”. . . . . . . . . . . . . . . . 350
Fig. 10.6 Overheating Management Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Fig. 10.7 OME and RRM Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Fig. 10.8 CS1 and CS2 Throughput Depending on C/I (dB) . . . . . . . . . . . . . . . . 354
Fig. 10.9 Gross Throughput Depending on CS and C/I (dB) . . . . . . . . . . . . . . . . 356
Fig. 10.10 BLER as Function of C/I (dB) for all GPRS Coding Schemes . . . . . . . 357
Fig. 10.11 Simulation Results for Family A (+MCS1) without IR . . . . . . . . . . . . . . 360
12 A30808-X3247-M24-5-7618
System
1 Introductions
1.1 Generality
With the implementation of the second generation of mobile systems, due to the digital
transmission mode they use, not only pure speech transmission, but also low rate data
transmission and several supplementary services have been provided to final users.
Nevertheless, since the request for data transmission supported by the mobile network
is currently increasing respect to the voice services, growths in the area of data trans-
mission are much higher than in the area of speech transmission.
For increasing the data transmission rates in the GSM mobile network the HSCSD
feature (High Speed Circuit Switched Data) has been implemented. It provides the
possibility to match the ISDN transmission rate, by combining four timeslots of the
TDMA frame.
One disadvantage of HSCSD, however, is related to the circuit switched data transmis-
sion it uses; in fact when the circuit switched connections are used the following limita-
tions have to be considered:
– efficient resource management becomes difficult to reach.
– additional costs arise for the user.
For this reason the HSCSD feature is essentially suited for those applications that
involve high, but constant, transmission rates (for example the video telephony).
To further increase the data rates with also the purpose to exceed the HSCSD limita-
tions, the GPRS (General Packet Data Service) technology has been implemented.
The GPRS provides the transmission of huge volumes of data in a very short time; on
the other hand it ensures a better management of available resources, that means:
– increase the number of users;
– reduce the costs arising for individual users (volume-oriented fees).
Using the GPRS technology it is possible to reach a maximum data throughput of about
150-170 kbit/s per each user.
The incoming third generation of mobile networks, however, requires, for its forthcoming
multimedia applications, much more bandwidth, at least 384 kbit/s. The Enhanced
General Packet Data Service (EGPRS) represents the more recent GPRS upgrade and
offers the opportunity to achieve those high data rates by preserving the most important
GSM air interface features (like, for example, the 200 kHz channeling, TDMA access
type, cell planning processes), by introducing a new modulation scheme (the “8 PSK”
instead of the “GMSK”). This means that the EGPRS services will rely completely on the
underlying GSM functionality.
Due to its GSM/GPRS compatibility, EGPRS is the optimal packet data feature for
established GSM operators. It provides 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 have been assigned UMTS licenses, EGPRS is also a good
opportunity for those operators that require an evolutionary step for their mobile
networks and provides the opportunity to offer advanced services foreseen for the third
generation of mobile networks.
For this reason it is expected that both UMTS and GPRS/EGPRS networks will coexist
in the near future. The UMTS will serve mainly hotspots that require up to 2 Mbit/s data
A30808-X3247-M24-5-7618 13
System
services per subscriber and the GPRS/EGPRS will be used to cover the rest of the area
offering up to 384 kbit/s data services.
1.2 Structure of the Manual

This manual is the complete collection of GPRS/EGPRS features; each feature is
described in detail together with the services that it provides to the final users. Therefore
its main purpose is to allow the users in understanding the main characteristics of the
Packet Switched (PS) data services that support both GPRS and EGPRS technology.
Besides in order to provide the reader an easy mean to find more information about the
parameters related to the Managed Objects involved in the EGPR/GPRS system, for
each parameter a link to the corresponding BSC:CML manual is provided; The link
addresses the table in which the parameter is described in detail as follow:
– Its meaning.
– Its range.
– The default value.
– The commands to which the parameter belongs to.
Also the complete list of all the Siemens technical documents describing the
GPRS/EGPRS features is present in this manual. The documents are Feature Sheets
and Change Requests. A Feature Sheet describes in detail in which way the related
feature has been implemented in the SBS system. A Change Request provides a short
indication of what is necessary to modify or to implement in the current BSS system due
to new customer requirements or internal development system’s improvements. Each
Feature Sheet or Change Request provides the following information:
– Its internal code (number) and title;
– A short description of the feature;
– The release of the system in which the described feature will be implemented.
Finally four different tables are contained in the last part of the manual:
– In the first table all the parameters, of GPRS/EGPRS only competence, which have
been described in the manual are collected in their alphabetical order. Each param-
eter is related to the link pointing to the section in the manual in which the parameter
is described and also to the link pointing to the title of the eventual Feature Sheets
(or Change Requests) that introduce or describe the parameter in the SBS system.
In this way an user searching technical details or more information can easily find in
the manual the location where the parameter is described and also which are the
other documents that provide additional information.
– In the second table all the parameters, not of GPRS/EGPRS competence but that
are however related to this technology, which have been described in the manual are
collected in their alphabetical order. Each parameter is related to the link pointing to
the section in the manual in which the parameter is described and also to the link
pointing to the title of the eventual Feature Sheets (or Change Requests) that intro-
duce or describe the parameter in the SBS system starting from the SBS BR 5.5. In
this way an user searching technical details or more information can easily find in
the manual the location where the parameter is described and also which are the
other documents that provide additional information.
– In the third table all the Managed Objects, of GPRS/EGPRS only competence,
which have been described in the manual are collected in their alphabetical order.
Each Managed Object is related to the link pointing to the title of the eventual
Feature Sheets (or Change Requests) that introduce or describe it within the SBS
system. In this way an user searching technical details or more information can
14 A30808-X3247-M24-5-7618
System
easily find in the manual the location where the parameter is described and also
which are the other documents that provide additional information.
– In the fourth table all the Managed Objects which are not specific for the GPRS tech-
nology but however related to the provided services are listed in their alphabetical
order. Each Managed Object is related to the link pointing to the section in the
manual in which it is described and also to the link pointing to the title of the eventual
Feature Sheets (or Change Requests) that introduce or describe the parameter in
the SBS system starting from the SBS BR 5.5. In this way an user searching tech-
nical details or more information can easily find in the manual the location where the
parameter is described and also which are the other documents that provide addi-
tional information.
The manual is structured in the following chapters:
• The Chapter 2 contains the list of all the features provided by the SBS
GPRS/EGPRS system.
• The Chapter 3 introduces the system, the network architecture, the protocol stack
and the data flow across the several involved network entities.
• The Chapter 4 describes the radio interface: the new logical channels, their mapping
on the corresponding physical channels and the rules that allow the sharing on the
same physical channel among several mobile stations and the assignment of more
physical channels to the same mobile station.
• The Chapter 5 introduces the Radio Resource Management in the context of the
GPRS/EGPRS system. It is described in which way the user can configure the
resources of the cell to allow the management of both circuit switched (CS) and
packet switched (PS) services; some examples are also introduced to clarify better
in which way the related resources (physical or logical) can be handled.
• The Chapter 6 describes the hardware architecture of the GPRS/EGPRS system
pointing to the new resources in the BSC requested by the new technology.
• The Chapter 7 is dedicated to the “Gb” interface, the interface that connects the BSC
to the core network. The frame relay protocol, which characterizes the Gb interface,
is described together with the physical layer, the permanent virtual connection and
some examples of configuration. Also some procedures are detailed.
• The Chapter 8 describes the load control mechanism, that is used to distribute in an
optimized way the GPRS/EGPRS traffic among the internal resources of the BSC.
• The Chapter 9 describes in details the more important and used GPRS/EGPRS
procedures.
• The Chapter 10 details the main GPRS/EGPRS functionalities, for example the Cell
Selection/Reselection, the management of neighbouring cells, etc.
• The Chapter 11 contains the tables with the list of all the Managed Objects and the
Parameters that have been described or referred in the manual.
• The Chapter 12 contains the list of the abbreviations adopted or referred in the
manual.
A30808-X3247-M24-5-7618 15
System
2 Siemens Features Description

This chapter contains the list of all the SBS technical documents (mainly “Feature
Request Sheets” and “Change Requests”) that specify the GPRS technology; Each
document provides the following information:
– Its code (number) and the title.
– A short description of the feature’s content.
– The SBS Release in which the feature has been implemented.
2.1 SBS BR5.5 Feature Description

FSH 0720
GPRS: HW and Basic SW for Packet Control Unit (PCU)

Release BR5.5
This feature is the most important one for the GPRS technology; it describes the
objects, the parameters and the functionalities regarding the packet switched data
service (PS).
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 the ETSI standard for the
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,
with the purpose to increase mainly the customer acceptance and performance of the
GPRS.
16 A30808-X3247-M24-5-7618
System
CR - F190
Support of Non-DRX Mode after Change to Packet Idle Mode

Release: BR5.5
This Change Request allows the reduction of about 50% of the time that is needed to
send data blocks from the Gb interface to the Mobile Station. 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 the reduction of the delay that occurs between the trans-
mission of downlink assignment messages and the beginning of packet downlink data
transfers (in a first step, see CR - F190, the delay that characterized downlink assign-
ment procedures has been reduced. However the delay can still be on 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 the improvement in the overall performance of the inter-
action between many TCP/IP based applications and the GPRS network.
CR - X232
GPRS Improvements for BR5.5

Release: BR5.5
This Change Request allows the improvement in the GPRS network, by introducing the
following features without O&M impacts:
- GPRS channels on all the TRXs of a cell;
- horizontal allocation.
A30808-X3247-M24-5-7618 17
System
CR - X366
Change Polling Strategy during Delay TBF Release

Release: BR5.5
This Change Request allows the reduction 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.

FSH 0397
High Capacity BSC

Release BR6.0
This feature introduces the first step for the High Capacity BSC (HC BSC step1), that
exploits the rack already used in the previous releases.
FSH 0457
Service Dependent Channel Allocation Strategy - Step1

Release BR6.0
This feature introduces new strategies to manage Circuit Switched, GPRS and HSCSD
calls.
FSH 0503
GPRS: Automatic Horizontal Allocation

Release BR6.0
This feature introduces the horizontal allocation strategy, and the parameter used to
handle it.
FSH 0512
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.
FSH 0515
Improvement in GPRS scheduler

Release BR6.0
This feature introduces a new mechanism to schedule data blocks to be sent/received
to/from the users.
18 A30808-X3247-M24-5-7618
System
FSH 1928
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 implementation of the Service Dependent Channel Allo-
cation Strategy - Step 1, described in FSH 0457, 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 FSH 1928.
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 FSH 0515.
A30808-X3247-M24-5-7618 19
System
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 implementation of 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 defini-
tion for the GDCH one.
20 A30808-X3247-M24-5-7618
System
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 the
DGRSTRGY parameter does not allow GPRS downgrade.
CR - X1086
GPRS - Uplink Balanced Assignment of Resources

Release: BR6.0
This Change Request allows to implement an Uplink Balanced assignment of
resources; so it will be possible to vary the number of timeslots assigned in Uplink direc-
tion on TBF basis for those MSs that support the dynamic allocation of resources in
downlink and uplink directions (Multi-slot mobiles class 6,7,10,11 and 12).
CR - X1519
Enable Throughput of GPRS Attach/Detach Requests to/from Rel. 99

Release: BR6.0
This Change Request allows stopping discarding the ATTACH ACCEPT message
when it contains optional fields; without this CR the discarding happened when using
Rel. 99 Handset in BR6.0 (Rel. 98) networks.
CR - X1553
Network Adaptation to Present MS Implementation Regarding PCCCH Operation

Release: BR6.0
This Change Request assures that PPCH is not used for data transfer in CS-2; other-
wise the MS will not be able to decode the radio blocks, and interprets them as
"corrupted". Then the downlink signalling counter expires, causing reselection to
another cell or loss of connection.
CR - X1681
Enlarge Fast Polling Period During Delayed DL TBF

Release: BR6.0
This Change Request allows speeding up the MS uplink establishment during the
Delay DL TBF Release Time. Improvements of about 80 ms are expected on Ping
Delay time and also on FTP throughput.
A30808-X3247-M24-5-7618 21
System
CR - X1706
Possibility to Enable/Disable Peak Throughput Management Feature

Release: BR6.0
This Change Request allows the possibility to Operator to enable/disable the Peak
Throughput Management feature. This permits to reduce the time to perform the GPRS
Attach procedure.

FSH 0418
GPRS: Network Controlled Cell Reselection

Release BR7.0
This feature introduces new strategies for the management of both GPRS and EGPRS
packet switched data traffic. It introduces new parameters for packet switched cell re-
selection from GSM to UMTS.
FSH 0419
Support of CS3, CS4

Release BR7.0
This feature introduces new GPRS coding schemes.
FSH 0420
MAC Protocol Enhancements for EDGE

Release BR7.0
This feature introduces the enhancements regarding the MAC protocol that is used for
the support of the EDGE functionality. The feature sheet also comprises enhancements
regarding both RLC and BSSGP protocols.
It introduces some EDGE parameters related to the previous protocols and new flags
to enable and disable GPRS and EGPRS on a cell basis.
FSH 0429
EDGE: Flexible Abis Allocation Strategy (FAAS)

Release BR7.0
This feature introduces a new strategy to manage resources of the Abis interface. 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.
22 A30808-X3247-M24-5-7618
System
FSH 0444
Link Quality Control: (LA)

Release BR7.0
This feature introduces the link adaptation algorithms regarding both GPRS and
EGPRS services.
FSH 0514
Gb/MS flow control (GPRS Step 1 Completion)

Release BR7.0
This feature describes the flow control procedure on the Gb interface.
FSH 0516
GPRS Resource Management

Release BR7.0
This feature introduces new algorithms to manage radio resources when packet
switched services (GPRS/EGPRS) are enabled.
FSH 0527
2nd Step of the High Capacity BSC

Release BR7.0
This feature introduces a further enhancement of the High Capacity BSC step1 imple-
mented in BR6.0, based on new rack and boards.It’s called: “2nd step of the High
Capacity BSC”.
FSH 0550
EGPRS/GPRS Scheduler Enhancements

Release BR7.0
This feature introduces enhancements in the process that manages the transmis-
sion/reception of GPRS/EGPRS radio blocks 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 related to the PTPPKF object, to
enable GPRS and EGPRS services on cell basis.
A30808-X3247-M24-5-7618 23
System
CR - X1150
Improvement of CS Channel Allocation

Release: BR7.0
This Change Request introduces changes in PDCH pre-emption, when a circuit
switched call must be served in a congested cell.
CR - X1152
Adaptation of FRS AEK0514A to the Current Implementation

Release: BR7.0
The current description of FRS AEK514 (MS/Gb flow control) does not reflect the
current implementation. It contains the general and not useful information that some
parameters are under investigation. The requirement contained in this Change
Request asks the alignment of the FRS to the current implementation (Feature Sheet).
CR - X1362
New O&M Attributes for Network Controlled Cell Reselection

Release: BR7.0
This Change Request asks the addition of the following attributes that are necessary
for the implementation of the feature: Network Controlled Cell Reselection
ADJC object:
NCGRESOFF,NCGTEMPOFF,NCGPENTIME,NCC1THRSADJC
PTPPKF object:
NCC1THRS,NCSAMERA,NCRARESH .
The following attribute have to be added for the Handover from GSM to UMTS
BSC object:
BSCT3121
CR - X1454
Multiplexing of GPRS and EGPRS on the same Timeslot

Release: BR7.0
This Change Request allows multiplexing of GPRS and EGPRS mobile stations on the
same PDCH dynamically.The possibility of multiplexing GPRS and EGPRS mobiles on
the same channel enables that the customer is not forced to have separated channels
for those mobile types. Especially Cingular and Vodafone D2 is asking for this function-
ality.Without this feature Cingular fears, that they cannot meet their business case due
to waste of resources.
24 A30808-X3247-M24-5-7618
System
CR - X1495
Uplink Balanced Assignment of E(GPRS) Resources

Release: BR7.0
This Change Request introduces a new strategy to better manage concurrent TBFs, for
Mobile Stations able to use more than one timeslot in the uplink direction.Mobile
stations (MS) which provides a dynamic allocation of the number of uplink and downlink
time slots (multislot class 6, 7, 10, 11 and 12) should be able to use the maximum
number of time slots in uplink direction compatible with dynamic allocation for data
transfer, if there is a considerable amount of uplink traffic available. The MS indicates
the amount of uplink data with a special parameter in the channel request description
and the network should take this parameter into account by assigning the time slots for
both uplink and downlink TBFs. Tests with a multislot class 6 MS have shown, that with
two simultaneous ftp connections, one in uplink the other 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 TCP as transfer protocol, which causes as acknowledged
protocol also 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).
Also pure UL traffic like FTP put is not handled optimally, since the network changes to
downlink preferred allocation as soon as first DL TBFs for TCP/IP acknowledgments
arrive.
CR - X1507
GPRS Improvements on Ping Delay

Release: BR7.0
With this CR it is requested to decrease the Ping Delay Time by reducing the internal
PCU queue from 3 to 1(or max2) radio blocks, that means more or less no internal
queueing but immediate sending of data when available. This improvement can save
approximately 20-40 msec per direction and it's requested only on PPXU.
CR - X1656
Shortening of Duration of Immediate Assignment Procedure for GPRS

Release: BR7.0
This Change Request allows to transmit immediate assignment message after that, on
each PDCH involved in TBF and which has to be aligned, only two complete uplink
PCU frame have been received by BSC. In this way the duration of Immediate Assign-
ment procedure is reduced.
A30808-X3247-M24-5-7618 25
System
CR - X1738
GPRS/EGPRS: Improvement of ABIC/PCUX Interface to Shorten PCU reaction

time
Release: BR7.0
With this Change Request it's requested to further shorten PCU reaction times (round
trip Delay on Abis, Abis-GB and Gb-Abis crossing times), by improving AbIC-PCUX
interface.This can be achieved with the following modifications:
1) Delay of Up Link frame interrupt to 4 ms (Currently 10 ms). This means that the UL
frames are segmented into 4 parts, allowing the parallel processing between receiving
information from the Abis and sending data to Pentium (SW modifications required on
both AbIC and PCUX).
2) DownLink (DL) Frame Request from DSP moved to roughly 9 - 6.5 ms before starting
Abis transmission (currently 20 - 16 ms). This allows the parallel processing between
receiving data from Pentium and transmission over ABIS interface (SW modifications
required on AbIC only).
3) DL Block scheduler activated around 5 - 7.5 ms before DL Frame Request (currently
20 - 16 ms). The granularity of DL interrupt is lowered to 2.5 msec, allowing the PCUX
to implement a very precise and timing mechanism.This change also increases the
probability that a GB downlink data is transmitted over the first block requested by DSP
(SW modifications required on both AbIC and PCUX). The coexistence of these
improvements should further save (with respect to BR 7.0 Step 1) approximately 40
msec on PCU round trip time, 20-25 msec on Gb-Abis and some msec on Abis-Gb
crossing time, and it's feasible only on PPXU
Important points to be outlined are the following:
- Timing is referred to a low_load condition;
- The new performance is highly challenging and requires a complex tuning between
PCUX Operating System, AbIC and UPK. With the current PPXU card, no further
improvements is possible.
CR - X1742
Enable/Disable of Delayed DL TBF During Mobility Management
26 A30808-X3247-M24-5-7618
System
Release: BR7.0
In this Change Request it is requested to maintain active the delayed TBF also during
Mobility management procedures considering always the peak throughput information
for the assignment of resources.
The Multislot class will be considered only if peak throughput information has inconsis-
tent values as already planned (e.g.0).
It's requested to give the possibility to the operator to decide if enable or disable
delayed TBF release during Mobility Management procedure in order not to have prob-
lems with other customers. When delayed TBF release during MM procedures is
disabled (current implementation):
the assignment of resources is done using the peak throughput information every time
the TBF is established for the different procedures (signalling or data). This means for
example that 1 TS will be assigned for signalling procedures and more TS for data
depending on the information sent by SGSN resources).
When delayed TBF release during MM procedures is enabled (to optimise GPRS
attach time):
the assignment of resources is done using the peak throughput information but the TBF
in this case is maintained active during "transaction" from signaling to data. Taking the
example made before, this means that 1 TS will be assigned for signalling procedures
and an upgrade procedure will be activated on the same TBF to assign more TS for
data.
CR - X1850
No “ping_pong” behaviour for mobiles which do not transmit packet cell change
failure
Release: BR7.0
This Change Request allows to prevent “ping_pong” effect due to questionable Mobile
Station behaviour during Network Controlled Cell Reselection.To handle this event the
BSC has not to order to mobile to move again into this adjacent target cell , in
spite of good radio link scenario , until the timer TRFPSCTRL is expired .
This action trust in the fact that mobile’s TLLI used in the old serving cell and mobile’s
TLLI used in the adjacent target cell may differ only for one bit ( bit 30th ,which distin-
guish between local / foreign TLLI ) , otherwise BSC may not track mobile in
its cell change.This procedure requires also that BSC stores information related to
mobile after the end of each TBF at least for the time STGTTLLIINF ( storage TLLI Info).
CR - X1869
Disable CS3&CS4
Release: BR7.0
Siemens is introducing the GPRS CS3&CS4 in BR7.0. Currently the CS3&CS4 feature
is dependent on the EDGE activation. It is activated when EDGE is on and de-activated
when EDGE is off. The Siemens customer Cingular has decided not to launch GPRS
with CS3&CS4 in all their markets. Therefore this CR allows to enable/disable the
CS3&CS4 feature independently from EDGE feature activation
A30808-X3247-M24-5-7618 27
System
CR-X2132
Title . Removal of BSS restrictions in extended band.

Release: BR7.0
Description: This Change Request requires to remove some limitations on
the GPRS and FHSY.For the GPRS the GSUP can be set also
in a different band that the BCCH one. It is left to the user
choice the decision to enable the GPRS on the Extended band.
For FHSY the new implementation allows the configuration of
FH laws in the extended band overlapping into the primary
band. No overlapping between primary/extended band and
DCS shall be kept
CR X-2199
Title: Common BCCH Improvements for 900 and 1800Mhz

Release: BR 7.0
Description: This Change Requests asks the implementation of the patch
solution described in the Change Request 1300 (Common
BCCH for Cingular - extension to BR 7.0) also for the frequen-
cies 900 / 1800. The CR1300 asks to extend to the release BR
7.0 the patch provided with the CR 688: “Modification of
Common BCCH Implementation via Patch”. The customer
asks the use of the common BCCH and (E)GPRS in the inner
area.Besides currently there are in progress commercial nego-
tiations with the customer Eurotel in Czech Republic. Siemens
has the big opportunity to swap NOKIA out of the customer’s
network. For the reason that Nokia has already implemented
the Common BCCH feature”, the patch solution described in
the Change Request is the precondition for a successful
commercial strategy.
CR X-2230
Title: Enhancement of throughput of 8PSK Mobile Stations when

multiplexed with GMSK Mobile Stations
Release: BR 7.0
Description: This change request asks to implement the requirements
described in the FRS AEK550. The throughput decreasing of
EDGE Mobile Station in 8PSK modulation could be at
maximum at 35% with BLER = 0 (no interference) and at
maximum 31% in the normal field condition while currently its
degrading is near to 70%.
CR X-2263
Title: Common BCCH allowing E(GPRS) in the complementary

Band.
Release: BR 7.0
Description: This Change Request enables the usage of a common BCCH
on the 900MHz frequency and it allows the releases of the
GPRS/EGPRS services on both 900 and 1800 MHz.
28 A30808-X3247-M24-5-7618
System
CR X-2313
Title: Enable Directed Retry to UMTS Independent of Enable Imper-

ative Handover HO).
Release: BR 7.0
Description: This Change Request asks to enable/disable the Directed
Retry to UMTS independently from the setting of the
enable/disable flag of the imperative Handover to UMTS. The
FRS AEK0490 shall be updated accordingly to this Change
Request.
CR X-2325
Title: (E) GPRS improvements on first ping and gap between IAMCD
and PRR/TBF start
Release: BR7.0
Description: This Change Request asks the following improvements for the
GPRS/EGPRS system: 1) For the First Ping the number of the
PDT assigned to a single block has to be set to 2 if concate-
nated PCU frames are used in the cell and to 1 if standard PCU
frames are used. 2) In the current load there is a gap of roughly
350-450ms between the IACMD and the PRR in case of 2
phase access. For this reason a reduction/optimization of the
overall delay for all kinds of the PRR/TBF start has to be
applied for cases with both idle channels as well as active
channels. 3) In the current load the BCCH change mark is
changed about every 15 minutes to refresh the system info.
The Mobile Station will release the ongoing TBF to read all the
incoming systeminfo even if they are not changed. Therefore it
is requested to enlarge the repetition rate to refresh the system
info in order to decrease the number of the TBF released in the
network. 4) Improvement and Optimization of the GPRS and
EGPRS Link Adaptation Thresholds.
CR X-2409
Title: Suppression of variable bitmap format

Release: BR 7.0
Description: In order to inform MSs about frequencies available in serving
cell or adjacent cells, BSC codes frequency set into bitmap
format depending on frequency range. Standards define
several formats, for example: bitmap0, variable bitmap, range
128, range 256, range 512, range 1024. All formats are
supported by Siemens BSC. It has been verified that, although
compliant to Standards, the variable bitmap format included in
some SysInfo is not correctly managed and supported by
several mobiles (for example, Nokia 6250/6310) in presence of
mix of frequencies in two ranges (0, 1..124) and (975..1023) in
the same cell. This change request asks to solve this problem
by setting bit 22 of MaintenanceBitmask.
A30808-X3247-M24-5-7618 29
System
CR X-2707
Title: Range 1024 for S25 and S35

Release: BR 7.0
Description: It has been verified that, although compliant to Standards,
bitmap formats different from Range 1024 included in
SysInfos, Assignment Command, Hand Over Command and
Frequency Redefinition, are not correctly managed by
Siemens mobiles of series 25 and 35 in the following scenario:
Mix of frequencies in two ranges (0, 1..124) and (975..1023) in
the same cell or in adjacent cells.This Change Request asks to
set bit 27 of MaintenanceBitmask to enable/disable this behav-
iour.

FSH 486
Title: Quality of service support for PS services

Release: BR 8.0
Description: This feature enhances Radio Resources Management proce-
dures (air interface side) and BSSGP procedures (SGSN inter-
face side) for supporting Release 99 EDGE/EGPRS and QoS
UMTS model (Recommendation: 23.107) and following
updates up to release 5 for the support of QoS for Non Real
Time and Real Time (Streaming only) services;
FSH 84566
Title: Improvement of Service Dependent Channel Allocation

Release: BR8.0
Description This feature provides the customers an improvement of the
allocation of the radio resources. A strategy for the radio
resource allocation process is defined on cell basis. This gives
the customers the best compromise between the services
supported in that cell and the requested radio quality. The new
concepts of Service List (SL) and Layer (LY) are introduced.
The SL is a list of services supported by the cell and it contains
for each entry a reference to one service type.
FSH 86774
Title: eFC:Enhanced Flow Control

Release: BR8.0
Description Enhanced Flow Control (eFC) feature has been introduced in
3GPP R5 in order to inform SGSN about the rate that can be
used for a specific Packet Flow Control (PFC) especially in
case of congestion. Triggering only Mobile Station Flow
Control, this mechanism would not be possible.
With the support of the eFC (PFC Flow Control) the traffic for
background PFCs while allowing the RT traffic for the same
user can be reduced. Although enhanced Flow Control (eFC)
is a R5 feature, it is applicable for all the Mobile Stations of
Release > = R99.
30 A30808-X3247-M24-5-7618
System
FSH 86853
Title: Network Assisted Cell Change (NACC)

Release: BR8.0
Description The NACC feature provides the reduction of the service inter-
ruption time during the cell reselection of a Mobile Station
providing the System Information of the target cell before
performing the cell change as long as the Mobile Station is
served by the old-serving cell. The NACC procedures affects
all the cells managed by the BSC.
FSH 86941
Title: EGPRS/GPRS Scheduler Enhancements for Rel5 Qos

Support
Release: BR 8.0
Description This Feature Sheet describes the enhancements implemented
to the BR7.0 GPRS/EGPRS scheduler. The scheduler has
been improved mainly for the following reasons:
1) to support new BR8.0 features: Packet Flow Context Proce-
dure, the Streaming Traffic Class in addition to Interactive and
Background ones and Release 5 QoS Attributes;
2) to improve the scheduler in case of only R97/98 attributes
can be managed.
The main purpose for the Temporary Block Flow (TBF) sched-
uler is to distribute permission to access the physical resources
to the different active TBFs. The distribution of the active TBFs
over the available GPRS/EGPRS carriers and the multislot
allocation of a particular TBF on the timeslot of the corre-
sponding GPRS/EGPRS carrier is executed by the resource
allocation algorithm.
FSH 86992
Title High Speed Gb Interface

Release BR 8.0
Description This Feature Request Sheet describes the High Speed Gb
Interface, also called “Gb over Ethernet”. This interface allows
the use of a broad spectrum of packet switched (PS) services
offered by IP network. It provides also an efficient broadband
access offered by the 1Gb physical interface provided by
Ethernet.
FSH 87029
Title: Network Controlled Cell Reselection from GSM/GPRS to

UMTS due to sufficient UMTS coverage.
Release: BR8.0
Description This feature describes the procedure for initiating a Network
Controlled Cell Reselection from GSM/GPRS (it includes also
E-GPRS) to UMTS.
A30808-X3247-M24-5-7618 31
System
FSH 87030
Title: Upgrading of the Common BCCH implementation

Release: BR 8.0
Description This feature allows the user to configure a new type of cell
supporting frequencies in two different bands and having the
BCCH in one of these bands (Common BCCH). The common
BCCH Cell has its own cell identity as any single band GSM
cell. Packet Switched Data can be allocated on both the
frequency bands.
FSH 87477
Title: Extended Uplink TBF

Release: BR 8.0
Description: This feature allows to keep an uplink Temporary Block Flow
(TBF) even in case of a short inactivity of the uplink traffic. In
this way it corresponds to the “Delayed TBF Release” that
offers a similar functionality but in downlink direction.The
delayed Downlink TBF and Extended Uplink TBF are indepen-
dent and can also run simultaneously. During a series of PING
commands both DownLink and UpLink TBF could be also inac-
tive at the same time. The “Extended UL TBF” feature has
been standardized in GERAN Release 4 and is therefore not
available for Release 99 and pre-Release 99 Mobile Stations.
The feature applies to open-ended TBFs in RLC acknowl-
edged and unacknowledged mode. It is not defined for closed-
ended TBFs.
FSH 88267
Title: EGPRS/GPRS on Extended Cells

Release: BR 8.0
Description: The radius of a GSM cell is limited to 35 km. It is defined
“extended cell” a cell whose radius can measure up to 100 km.
Extended cell support voice services, where BTS expects an
UpLink (UL) burst on two consecutive timeslots. Until BR8.0
Release the BSS system supports EGPRS/GPRS services
only in normal cells (radius up to 35km) and in the near area of
extended cells. The continuous increasing number of
EGPRS/GPRS mobiles and the increasing request for
Internet/streaming services have requested the support of the
GPRS services also in Extended Cells. This is the purpose of
the feature described in this Feature Request Sheet.
32 A30808-X3247-M24-5-7618
System
FSH 88442
Title: Multipel PCU pooling

Release: BR 8.0
Description: This feature describes network “overlay” scenarios with Radio
Access Network “split” between different BSS providers
connected to one or more SGSN network nodes ports. Each
SGSN node manages a routing area and the ports could
belong to one or more SGSNs. The number of PCU pools can
be limited by the configured number of PPXU boards in the
related BSCs and the requested redundancy scheme,
according to BSC types (BSC/72, BSC/120) installed in the
network. Multiple PCU Pooling is supported only by PCU func-
tionalities implemented on the PPXU cards (together with their
redundancy rules).
FSH 88930
Title: EGPRS/GPRS Enhancements:Extended Dynamic Allocation,

Flexible USF Granularity, Quality Control Function, Over-
heating Management.
Release: BR8.0
Description: This Feature sheets analyzes new features for the
EGPRS/GPRS. For each feature the impacts on the BSS
system are detailed together with main processes and inter-
faces. Also new attributes are described.
CR-X2144
Title: NC cell reselection GSM/GPRS to UMTS: dependency on

UMTS power class removed.
Release: BR8.0
Description: The attribute “MsTxPmaxUmts” related to the Managed
Objects “TGTFDD” and “TGTTDD” which has been
implemented in the BSS system starting from the BR 7.0
release (for GSM to UMTS handover) is still valid in the current
BR8.0 release. Only its default value is changed. The value of
this attribute shall not more be used in the computation of the
enhanced algorithm for network controlled cell reselection from
GSM/GPRS to UMTS due to sufficient coverage. In this way
the dependency on the UMTS power class (FDD, TDD) of the
Mobile Station is removed.
A30808-X3247-M24-5-7618 33
System
CR-X2336
Title: Improvement of CCCH Handling between PCH and AGCH

channels and usage of the immediate assignment extended.
Release: BR8.0
Description: This Change Request minimizes the overload situations for the
CCCH channel, which results in a better performance of the
mobile network. Paging messages and Access Grant are sent
via the same CCCH blocks. To ensure a certain AGCH
throughput the user can define reserved CCCH blocks that are
used only for Access Grant. On the other CCCH blocks Paging
messages and Access Grants are sent whereas the Paging
messages have higher priority.
CR-X2352
Title: Dual Band Standard Cell and Service Dependent channel allo-
cation improved handling
Release: BR8.0
Description: This change request asks to handle the “Dual Band Standard
Cell” in the same way as the “Standard” Cell. For example only
one area that includes both bands will be considered instead of
the current two. The features: Service Dependent Channel
Allocation, Common BCCH and Compression/Decompression
Handovers are affected.
CR-X2357
Title: Porting into BR8.0 of CR2132, 2199 and 2263

Release: BR8.0
Description: n BSS BR7.0 release some Change Requests (for example
2132, 2199, 2263) improving the BSS behaviour in GSM
extended and complementary band (for example GPRS) have
been implemented. This Change Requests asks the manage-
ment of these features also in the current BR 8.0 Release
removing the use of the MNTBMASK attribute’s bits
CR-X2387
Title: Porting into BR8.0 of CR2132,2199 and 2263

Release: BR8.0
Description: In BSS BR7.0 release some Change Requests (for example
2132, 2199, 2263) improving the BSS behaviour in GSM
extended and complementary band (for example GPRS) have
been implemented. This Change Request asks the manage-
ment of these features also in the current BR 8.0 Release
removing the use of the MNTBMASK attribute’s bits.
34 A30808-X3247-M24-5-7618
System
CR-X2446
Title: PDCH Time Alignment

Release BR8.0
Description This change request asks the following improvements to the
GPRS/EGPRS system:
- Speed up of the PDCH bring up by the enhancement of the
time alignment procedure.
- One Timeslot for the GMM and SM procedures.
- Handling of BCCH Change Mark.
CR-X2560
Title: Quick Immediate Assignment for satellite link

Release BR 8.0
Description This change request asks only for Abis over satellite link to
send the message: "Immediate assignment" to the Mobile
Station just after sending the message: "Channel Activation" to
the BTS. This permit to avoid MS double access. Besides BSC
manages the message: "Channel Activation Nack" from the
BTS without sending the message: "Immediate Assignment
reject". This modification increases the success rate for the
traffic channel assignment in high traffic conditions from 50%
up to 90%
A30808-X3247-M24-5-7618 35
System
CR-X2613
Title: NC1 usage in NACC and NCCR procedures

Release BR8.0
Description Due to the fact that it is not clear the behavior of the Mobile
Stations on the reception of NC1 this Change Request intro-
duces the following enhancements to the NACC/NCCR proce-
dure: a) Possibility to define the usage of NC0 or NC1 in the
PMO to the Mobile Station when the NACC procedure is
enabled and for Mobile Stations of Rel 4 or greater; The
attribute (NACC-NCO) has been implemented in the BSC
Managed Object to define the usage of NCO during NACC
when the Mobile Station is in Packet Transfer Mode. The
parameter’s values are: “NC0”, “NC1”. Default value: “NCO”.
The value broadcasted in the system info is always NC0. If the
Mobile Station does not add measures in the PCCN message,
the network will rely on the Mobile Station decision for the
target cell. For a target cell within the same BSS system the
network sends the PNCD message to the Mobile Station
before sending the PCCC message, otherwise PCCC is sent
directly. If the Mobile Station adds measures in the PCCN
message, the network may influence the target cell choice for
the cell reselection procedure according to radio condition and
load situation by sending the PCCO otherwise the PCCC is
sent. Before sending PCCO or PCCC the network shall send
PNCD if system info are available. b) In case Network
Controlled Cell Reselection is enabled it is used always NC2 in
the PMO message sent to Mobile Stations and in case also
NACC is enabled it is sent the System Info of the target cell (if
available) before the network controlled cell reselection to the
MS (only for Mobile Stations that support NACC) is triggered.
CR-X2616
Title: Increase capacity of the Maintenance Bit Mask

Release BR8.0
Description Currently after a “clean up” of MaintenaceBitMask all bits of
“MNTBMASK” attribute can be used. For maintaining the
system’s flexibility and also for satisfying the customers needs
this change request asks to increase the value range of this
attribute from [Bit0..Bit29] up to [Bit0..Bit61].
36 A30808-X3247-M24-5-7618
System
CR-X2844
Title: PDT Release Improvements

Release BR8.0
Description Unused PDTs of a PDCH channel are released by BSC after
the expiration of TEMPPDT timer (typical value: 15 seconds).
This happens for example during an active packet data transfer
after the execution of a link adaptation procedure to a more
robust codec as well as at the end of the packet data transfer,
in case no further data is available. Besides a single PDT is
maintained open up to TEMPCH timer expiration (typically 90
seconds), afterwards complete PDCH is closed. With this solu-
tion PDT(s) of PCU can be reused by other cells and or PDCH
channels. This Change Request asks to improve current
behaviour: EMPTY timer of second subframe counter can be
set to the same value of EMPTY PDCH timer instead of
EMPTY PDT timer depending on the setting of one bit of BSC
Maintenance. As a consequence there is the possibility to
maintain active one PDT (current procedure) or two PDT(s) per
PDCH channel up to expiration of TEMPCH attribute (new
procedure).
CR-X2874
Title: Attribute RAARET (Random Access Retry) looses its meaning

Release BR8.0
Description This change request asks to not more consider the meaning of
the attribute RAARET related to the Managed Object PTPPKF
due to 3GPP Recommendation. The attribute shall be main-
tained in BSS Information Model in order to avoid changes.
CR-X2891
Title: Qos handling for MS Rel 97/98 when PFM procedures are
enabled
Release BR8.0
Description This change request asks to change the QoS handling of
Release 97/98 Mobile Stations when PFM procedures are
enabled. With this approach, if the user wants to use Streaming
services, he has to enable the PFM procedures, but rel 97/98
MSs are handled in the system with “lowest priority” (for
example background) in respect to Rel 99 onwards MSs.
CR-X2954
Title: Network Control Order NC2 only to Rel 99 onwards MSs

Release BR8.0
Description This change request asks to introduce a parameter inside the
system at BSC level, in order to enable or disable the sending
of Network Control Order 2 to pre-Rel99 MSs.
A30808-X3247-M24-5-7618 37
System
CR-X3030
Title: TLLI_BLOCK_CHANNEL_CODING bit set to 0 for (E)GPRS

UL Assignments
Release BR8.0
Description This change request asks to set to 0 the
TLLI_BLOCK_CHANNEL_CODING bit in Packet UL Assign-
ment and UL Immediate Assignment messages on every
procedure (including GMM/SM Signalling such as
GPRS/EDGE Attach.
38 A30808-X3247-M24-5-7618
System
3 GPRS/EGPRS Overview
The General Packet Radio Service (GPRS) and the Enhanced General Packet Radio
Service (EGPRS) technology allow the packet switched data transmission on the frame-
work provided by the GSM mobile network.
EDGE (Enhanced Data rates for GSM Evolution) applies both to the circuit switched
i (CS) and to the packet switched (PS) services. EDGE is mainly a characteristic of the
Air Interface, including a new modulation (8PSK, besides the already used GMSK
modulation. See for more details the chapter:"3.1 GPRS and EGPRS Modulation Prin-
ciples".
The word EGPRS (Enhanced GPRS) applies only to the packet switched (PS) services.
Whenever in this document the word EGPRS is adopted, EDGE is referred and it is
applied to the packet switched (PS) services. That means, substantially, the coding of
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 the GPRS RLC/MAC control messages. In the previous BSS BR 7.0
release, EDGE is applied only to packet services. However, the generic term EDGE is
used in the Operation&Maintenance attributes that could be used to define the support
of EDGE also for the circuit switched (CS) service. In any case in this manual, the world
EDGE means EGPRS and viceversa.
When the GPRS/EGPRS technology is not configured, the GSM mobile network runs in
circuit switched connection mode, for example 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 (CS) 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 with the support of more radio chan-
nels to a given user, by the HSCSD feature. Nevertheless, when a circuit switched
connection is established and the user does not transmit further information, which is
typical of data transmission, the specific resources are wasted because they are not
available for other users waiting the availability of the service. In other words, it means
that the circuit switched connections do not provide an optimized support for data traffic.
In order to improve and optimize the use of both the network and radio resources, for
both GPRS and EGPRS technology the packet switched (PS) technique has been
implemented for supporting efficiently both data and signaling transfer.
New GPRS/EGPRS radio channels are defined, and the allocation of these channels is
flexible as follow:
– from 1 to 8 radio interface timeslots can be allocated for TDMA frame, for each trans-
ceiver of the cell;
– timeslots are shared by the active users (the same timeslot can be assigned to
different users at the same time);
– radio interface resources can be shared dynamically between speech services
(circuit switched services) and data services (packet switched services) as a func-
tion of service load and also on the basis of different operator’s needs;
– uplink and downlink resources are allocated separately.
Applications that take advantage of GPRS/EGPRS services have the following charac-
teristics:
• intermittent, non-periodic (i.e., bursts) data transmission;
• frequent transmission of small volumes of data;
• not frequent transmission of large volumes of data.
A30808-X3247-M24-5-7618 39
System
3.1 GPRS and EGPRS Modulation Principles

The GPRS technology is an evolution of the existing GSM technology and it uses the
same GMSK Gaussian Minimum Shift Keying) modulation scheme. The GMSK digital
modulation format relies on shifting the carrier 180˚ in phase to produce a binary modu-
lation scheme capable of delivering 1 bit/symbol as represented in the Fig. 3.1.
Fig. 3.1 Basic GMSK Constellation of Signal Vectors
The GPRS uses four different channel coding schemes (see the chapter: "4.2.1 GPRS
Channel Coding") to provide different levels of protection to the packets on the air inter-
face.
This modulation scheme, within 200 KHz bandwidth, provides a good spectral perfor-
mance and an adequate data rates for GSM voice applications, however it cannot
supply fast data services since it only transmits 1 bit/symbol.
The EDGE technology uses the same bandwidth allocated for GSM voice and GPRS
data services, but delivers a higher capacity and fast data services to the mobile network
by using a new modulation scheme called 8 PSK (8-level Phase Shift Keying). With this
8PSK modulation, there are eight distinct phase changes that the decoder looks for the
conversion into binary data. Each phase represents a symbol and carries three bits of
information as reported in next Fig. 3.2.
40 A30808-X3247-M24-5-7618
System
Fig. 3.2 Basic 8 PSK Constellation of Signal Vectors
As a consequence, the EDGE’s 8 level-shift keying modulation scheme allows a radio

throughput increase of almost 3 times the radio throughput of the GPRS with the same
number of timeslots with big advantages for the final users. In the following table the
comparison of the physical layer parameters is depicted.
GSM EDGE
Modulation GMSK, 1bit/sym 8 PSK, 3 bit/sym
Symbol Rate 270833 kbit/s 270833 kbit/s
Payload per Burst 114 bit 348 bit
Gross Rate per Time 22.8 kbit/s 69.6 kbit/s
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 tran-
sition, 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, as described in the chapter: "4.2.2 EGPRS
Channel Coding") using both the GMSK and the 8 PSK modulations are introduced and
a specific link adaptation algorithm allows the automatic switching between coding
schemes, based on the radio environment condition. The table below shows which
EDGE coding schemes are GMSK modulated and which instead are 8 PSK modulated.
GMSK modulated 8 PSK modulated
MCS1 MCS5
MCS2 MCS6
MCS3 MCS7
MCS4 MCS8
Tab. 3.1 EGPRS Coding Schemes and their Modulation
A30808-X3247-M24-5-7618 41
System
GMSK modulated 8 PSK modulated
MCS9
Tab. 3.1 EGPRS Coding Schemes and their Modulation
3.2 Network Architecture

The packet data mobile network establishes a logical connection between the users but
does not guarantee an immediate access to the transmission network: when more users
ask the access to the transmission resources at the same time, the network has to
schedule the access keeping some of them in a wait queue for avoiding traffic conges-
tion.
As shown in Fig. 3.3, the GPRS/EGPRS network is put on the top of the GSM existing
one but without substitute it. In fact the network architecture grants that speech and data
transmission with circuit switched connections (CS) are controlled by the MSC (through
the A interface).
Fig. 3.3 GPRS/EGPRS Network Architecture.
For providing the Packet Switched (PS) services two network nodes in the GSM core
network have been introduced:
• Serving GPRS Support Node (SGSN): the SGSN keeps track of the individual
Mobile Station location and performs security functions and access control. It is at
the same hierarchical level as the MSC and it can be connected to the Base Station
System (BSS) via a Frame Relay network. It is also possible to connect the SGSN
42 A30808-X3247-M24-5-7618
System
and the BSS via nailed-up connections (NUCs) or through point-to-point connec-
tions.
The SISGNREL99 parameter is broadcasted in the cell, in order to inform
i the Mobile Stations about the specification Release implementation in the
SGSN.
The SGSN and the BSC are connected by the Gb interface. It specifies the data flow
and the requested protocols (see the Chapter: "7 Gb Interface") and it consists of
connections which carry both data and signaling simultaneously, using the Frame
Relay protocol. Besides the Gb interface is “standard” and it guarantees multi-
vendor capabilities.
• Gateway GPRS Support Node (GGSN): this node GGSN provides:
– interworking with external packet switched (PS) networks;
– management of IP addresses.
The GGSN could be connected to the SGSN via an IP-based GPRS/EGPRS back-
bone network; in this way these two entities can also reside on the same physical
node.
The interface between the SGSN and the GGSN is the “Gn” Interface.Two GGSN nodes
can be interconnected through “Gp” Interface.
Besides the Home Location Register (HLR) Database has to be upgraded with
GPRS/EGPRS subscriber information, and optionally the MSC/VLR can be enhanced
for a more efficient coordination of GPRS and non-GPRS services and functionalities
like for example the following:
– paging of circuit switched calls through the SGSN;
– combined GPRS and non-GPRS location updates.
To allow the co-ordination of activities between the MSC and the SGSN, the Gs interface
must be supported as represented in above Fig. 3.3.
The security management functions for the GPRS/EGPRS technology do not differ for
those implemented for the GSM system: the SGSN performs authentication and cipher
setting procedures based on the same algorithms, keys, and criteria adopted in GSM;
the only difference is that GPRS/EGPRS networks require an enhanced ciphering algo-
rithm optimized for the packet data transmission.
In order to access to the packet switched (PS) services, a Mobile Station (a specific
hardware and software is needed for being able to provide GPRS services) first makes
its presence known to the SGSN by performing a GPRS attach procedure. It is
described in detail in the chapter: "9.3.2.1 Attach Function".This operation establishes a
logical link between the Mobile Station and the SGSN, and it provides the following func-
tions:
– paging via the SGSN;
– notification of incoming GPRS/EGPRS specific data;
– SMS services over GPRS services;
So at the end of a successful GPRS attach procedure, the SGSN establishes with the
mobile station a mobility management session, containing information pertaining to, for
example, mobility and security etc.
In order to send and receive packet switched (PS) data, the Mobile Station first activates
the packet data address that it wants to use. In this way the Mobile Station will be recog-
nized by the corresponding GGSN and then the interworking with external data
networks can begin. During this procedure, which is called PDP context activation (
Packet Data Protocol context activation), the SGSN establishes a PDP context with the
A30808-X3247-M24-5-7618 43
System
related GGSN as it is described in the chapter: "9.7 Activation and Deactivation of a

PDP Context" 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.
At the end of the successful execution of the attach and of the PDP context activation
procedures, the Mobile Station can start the transmission or reception of data.
For the purpose, the Mobile Station shall 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.
The User data is transferred transparently between the Mobile Station and the Core
network with a method known as encapsulation and tunnelling: data packets are
completed with GPRS/EGPRS specific protocol information and transferred between
the Mobile Station and the GGSN of competence. This transparent transfer method
lessens the requirement for the GPRS PLMN to interpret external data protocols, and it
enables an easy introduction of additional interworking protocols in the future. User data
can be compressed and protected with retransmission protocols, to get a consistent,
efficient and reliable data transmission.
3.3 GPRS/EGPRS supported by satellite links

The transmission of data requested by GPRS/EGPRS services is supported also by
means of satellite links. This transmission mode is often used for providing the services
via particular network configurations to users residing for example in wide or very large
areas with minimum additional infrastructure cost.
In next chapter a description of “Abis” interface supported by satellite links is provided.
3.3.1 Abis Interface

Abis interface is supported over satellite links. This transmission mode is the most
common implementation and it is often used to extend the GSM and GPRS/EGPRS
services to new locations with minimal infrastructure costs. For the reason that GSM
traffic grows also at remote sites, additional BTSs or a BSC may be deployed to support
higher traffic loads and/or a larger geographical area.
The satellite Abis configuration has the advantage that a minimal expense is requested
for deploying the service. An existing MSC and BSC can be used, which could possibly
support satellite connections to several remote locations.
The main disadvantage of the satellite Abis configuration is that the remote locations
relies heavily on the equipment located at the hub side so hand-offs and also eventual
subscriber to subscriber calls must go over satellite link increasing load and traffic.
The configuration’s parameters together with the related commands requested for the
Abis over satellite links are out of the scope of this manual. They are described in the
manual: “CML:BSC”.
Besides the value of the attribute: “nRLCMAX” (this attribute determines the number of
RLC data blocks before Ack/Nack block is requested) of PCU Managed Object has been
changed from “20” to “15” for reducing the problem related to Abis satellite’s delay. This
attribute is not configurable in the BSS system.
When BSS receives a message: "Channel Request" from a Mobile Station, a TCH
channel in case of direct assignment) is allocated by BSC. After this allocation an acti-
44 A30808-X3247-M24-5-7618
System
vation phase is triggered by the BSC sending the message: Channel Activation to the
BTS and waiting the message: Channel Activation acknowledge.
Only after successful completion of the activation phase the message: "Immediate
Assignment" is sent back to the Mobile Station. This procedures causes a double Mobile
Station access in case of Abis on satellite link.
For avoiding MS double access, in current release and only for Abis over satellite link,
a message: "Immediate assignment" is sent to the Mobile Station just after sending the
message: "Channel Activation" to the BTS. In this way BSC manages the message:
"Channel Activation Nack" from the BTS without sending the message: "Immediate
Assignment reject". This modification increases the success rate for the TCH channel’s
assignment in high traffic conditions from 50% up to 90%.
A30808-X3247-M24-5-7618 45
System
3.4 GPRS/EGPRS Protocol Stack

GPRS and EGPRS technology is supported at every level of OSI stack by a set of proto-
cols that are represented in Fig. 3.4 together with the corresponding interfaces starting
from the air-interface (“Um”) up to the core Network (“Gn” Interface between the SGSN
and the GGSN).
Fig. 3.4 Protocol Stack for Data Transmission in GPRS/EGPRS Network.
The different layers for the Um, Abis, Gb, Gn and Gi interfaces provide the following
functions:
• GSM RF: the GSM RF is the protocol specified for the Um and the Abis interfaces.
It supports the physical radio channel used to transfer packet data;
• MAC: The Media Access Control layer is the protocol specified for the Um and the
Abis interfaces.It provides the access to the physical radio resources. It is respon-
sible for the physical allocation of the packet data channels (PDCHs);
• RLC: the Radio Link Control layer is the protocol specified for the Um and the Abis
interfaces.It provides a reliable link over the air interface that fits the block structure
of the physical channel; therefore its main task is the segmentation and reassem-
bling of the LLC frames transmitted between the BSS and the SGSN. In addition it
performs:
– a sub-multiplexing to support more than one Mobile Station by one physical
channel;
– the channel combining to provide up to eight physical channels to one Mobile
station.
• LLC: the Logical Link Control layer provides a logical connection between the Mobile
Station and the SGSN even if no physical connection is established. The physical
connection is set up by the RLC/MAC layer when there is data to transmit;
• BSSGP: the BSSGP protocol is specified for the Gb interface and it is used to
transfer LLC frames together with related information between the SGSN and the
BSC. Such information include QoS (Quality of Service) and routing information;
46 A30808-X3247-M24-5-7618
System
• SNDCP: the Sub Network Dependent Convergence Protocol is the protocol speci-
fied for the logical interface between the Mobile Station and the SGSN. It performs
the following tasks:
– encryption;
– compression;
– segmentation/re-assembling;
– multiplexing/de-multiplexing of signaling information and data packets.
The encryption function grants the best security for the data transmission whereas
the compression and the segmentation are performed to limit the amount of data
transferred by the LLC layer.
• GTP: The GPRS Tunnelling Protocol is specified for the Gn interface. Its main task
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 then transferred between the GSN
nodes.
• IP/X.25: The network layer represents the network protocol that supports the infor-
mation transferred over the GPRS/EGPRS network starting from the Mobile Station
up to the GGSN. Depending on the supported network protocol (IP, X.25, CLNP),
there are several types of network layers;
• Application: The higher layers (for example the “Application Layer”) are outside the
scope of the GPRS/EGPRS, because they are not dependent from the underlying
network.
3.5 Data Flow

This chapter describes in which way the data are transmitted from the core network
(SGSN) up to the Mobile Station, and vice versa.
The figures Fig. 3.5 and Fig. 3.6 represent in which way the different protocol’s layers
manage the data flow:
– The Fig. 3.5 represents the data flow in case of GPRS and EGPRS when the
MSC1..MSC6 coding schemes are used;
– The Fig. 3.6 represents the data flow in case of EGPRS when the MSC7..MSC9
coding schemes are used (see description below);
A30808-X3247-M24-5-7618 47
System
Fig. 3.5 Data Flow across Protocol Layers in case of GPRS/

EGPRS(MSC1...MSC6)
Fig. 3.6 Data Flow across Protocol Layers in case of EGPRS(MSC7...MSC9)
It is supposed that an IP data packet has to be sent from an external data network to a
mobile subscriber.
Precondition is that the Mobile Station has already executed the “attach” procedure and
i 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 Mobile Station 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 Mobile Station (for example the cell where
the Mobile Station 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. The LLC frames have a variable length; since they have to be sent on the radio inter-
face, which has a limited capacity, the LLC frames are segmented in a certain
48 A30808-X3247-M24-5-7618
System
number of RLC/MAC blocks; these blocks have a well defined length (according to
the used coding scheme);
6. The RLC/MAC blocks are then sent through the Abis interface, to the right BTS;
RLC/MAC blocks are sent across the Abis interface, by means of PCU frames. Two
i types of PCU frames exists:
- standard PCU frames: they allow the transmission of 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).
More details are described in chapter: "6.3 PCU Frames and Dynamic Allocation on the
Abis Interface".
7. the BTS executes the following operations for the received RLC/MAC blocks:
– block coding;
– convolutional coding;
– puncturing;
– interleaving.
Regarding these operations, it is important to make a distinction among the following
different cases:
– when GPRS coding schemes are used, a single RLC/MAC block contains one
Information Field only; the BTS executes the described operations on it; after
these operations, each received RLC/MAC block reaches, independently from the
applied coding scheme, a fixed length of 456 bits;
– when EGPRS GMSK coding schemes are used (i.e., from MCS1 to MCS4), a
single contains one Information Field only; the BTS executes the described oper-
ations on it; after these operations, each received RLC/MAC block reaches, inde-
pendently from the applied coding scheme, a fixed length of 1368 bits;
– when EGPRS MCS5 and MCS6 coding schemes are used, a single RLC/MAC
block contains one Information Field only; the BTS executes the described oper-
ations on it; after these operations, each received RLC/MAC block reaches, inde-
pendently from the applied coding scheme, a fixed length of 1392 bits;
– when EGPRS MCS7, MCS8 and MCS9 coding schemes are used, a single
RLC/MAC block contains two Information Fields; the BTS executes the described
operations on the RLC/MAC block; after these operations, the RLC/MAC block
reaches, independently from the applied coding scheme, a fixed length of 1392
bits;
8. 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 cases of GPRS;
– up to 114 bits in cases of EGPRS when GMSK modulation is used;
– up to 348 bits in cases of EGPRS when 8PSK modulation is used.
The figure Fig. 3.7 shows the data flow between the SGSN and the Mobile Station in
the downlink direction through the Gb, Abis and Um interfaces (in the uplink direction
the same data flow is transmitted but in the opposite order).
A30808-X3247-M24-5-7618 49
System
Fig. 3.7 Data Flow from the SGSN up to the Mobile Station.
For more clearness the following definitions are used:

• RLC/MAC block: a RLC/MAC block is a block generated in the BSC (by the
RLC/MAC layer) starting from the LLC-PDU; then this block is sent using PCU
frames to the BTS that than it applies the right coding;
• Radio Block: a Radio Block is a RLC/MAC block that is generated after the BTS has
applied the block coding (i.e., it is a RLC/MAC block plus some coding bits).
After block coding, the BTS will apply the convolutional coding and both puncturing and
i interleaving procedures; after these operations the interested block will reach a fixed
length of 456 or 1392 bits, and it is still called Radio Block.
3.6 RLC/MAC Block and Radio Block Structures

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

As it has been described, two different RLC/MAC Block structures are defined for GPRS
and EGPRS data transfer.
50 A30808-X3247-M24-5-7618
System
3.6.1.1 RLC/MAC Block and Radio Block Structures for GPRS Data Transfer
A RLC/MAC block for data transfer supported by the GPRS technology consists of one
MAC Header, one RLC Header and one RLC Data Block as represented in next
Fig. 3.8.
– The MAC Header contains control fields with different values for the uplink and
downlink directions and it has a constant length of 8 bits.
– The RLC Header contains control fields with different values for the uplink and down-
link directions and it has a variable length;
– the RLC Data Block field contains octets from one or more LLC PDUs.
MAC Header RLC Header RLC Data
Fig. 3.8 RLC/MAC block’s structure for Data Transfer
The RLC/MAC block is sent to the BTS, that will apply a block coding for the error detec-
tion, adding to the RLC Data Block field the “Block Check Sequence (BCS)” field. At the
end of the operation the Radio Block is generated, as represented in next Fig. 3.9. This
Radio Block, after convolutional coding, puncturing and interleaving, is then transmitted
on the “Um” air interface and carried by four Normal Bursts.
MAC Header RLC Header RLC Data BCS
Fig. 3.9 Radio Block structure for Data Transfer on the “Um” Interface
3.6.1.2 RLC/MAC Block and Radio Block Structure for EGPRS Data
Transfer
A RLC/MAC block for data transfer supported by the EGPRS technology consists of one
RLC/MAC Header, and one or two RLC Data Blocks.
– the RLC/MAC Header contains control fields with different values for the uplink and
downlink directions. It also has a variable length;
– the RLC Data Block field contains octets from one or more LLC PDUs;The EGPRS
coding schemes from MCS1 to MCS6 use a RLC/MAC block constituted by only one
RLC Data Block field only (as represented in Fig. 3.10), whereas the coding
schemes from MCS7 to MCS9 use a RLC/MAC block constituted by two RLC Data
Block fields to reach a more high data rate as represented in Fig. 3.11.
RLC/MAC RLC Data Block

Header
Fig. 3.10 RLC/MAC Block structure with one RLC Data Block field
A30808-X3247-M24-5-7618 51
System
RLC/MAC RLC Data Block RLC Data Block

Header
Fig. 3.11 RLC/MAC Block structure with two RLC Data block fields
The RLC/MAC block is sent to the BTS, that will apply a block coding for the error detec-
tion. At the end of the operation the Radio Block is generated. (see Fig. 3.12 in case
only one RLC Data Block is inserted and Fig. 3.13 in case two RLC Data Blocks are
inserted). Besides two different block coding are applied for the error detection:
– the Block Check Sequence (BCS) is used for the error detection of the data part.
– the Header Check Sequence (HCS) is used for the error detection of the header
part.
The RLC/MAC Header does not interact from the RLC Data Block and it has its own
check sequence.
In cases of RLC/MAC blocks constituted by two RLC Data Block fields , each field has
its own block check sequence whereas the RLC/MAC Header is common for both the
fields.
At the end of the checks and after convolutional coding, puncturing and interleaving, the
RLC/MAC Block structure represented in Fig. 3.13 is transmitted on the “Um” Air Inter-
face and carried by four Normal Bursts.
RLC/MAC
Header HCS RLC Data Block BCS
Fig. 3.12 Radio Block for Data Transfer with one RLC Data Block field
RLC/MAC RLC Data Block

HCS RLC Data Block BCS BCS
Header
Fig. 3.13 Radio Block for Data Transfer with two RLC Data Block field
3.6.2 RLC/MAC Block Structure: Control Signaling

The same RLC/MAC Block for transferring a control message (for example a signaling
message) is supported by the GPRS and the EGPRS technology. It consists of one
MAC header and one RLC/MAC Control Message as represented in the Fig. 3.14. The
Header and the RLC?MAC Control Message have the following structure:
– the MAC Header contains control fields with different values for the uplink and down-
link directions and it has a constant length of 8 bits.
52 A30808-X3247-M24-5-7618
System
– the RLC/MAC Control Message field contains one RLC/MAC control message;
It is always carried by four normal bursts.
MAC Header RLC/MAC Control Message
Fig. 3.14 RLC/MAC Block Structure for Control Messages
The RLC/MAC block is sent to the BTS that will apply a block coding for the error detec-
tion by the addition of a Block Check Sequence (BCS) field. At the end of the operation
the Radio Block is generated as represented in Fig. 3.15. After convolutional coding,
puncturing and interleaving the Radio Block is then transmitted on the “Um” Air interface
and carried by four Normal Bursts.
MAC Header RLC/MAC Control Message BCS
Fig. 3.15 Radio Block for Control Messages (signaling).
The following control messages can be transmitted in the downlink direction within a
RLC/MAC signaling Block Structure:
– Packet Paging Request: This message is sent by the network to trigger the channel
access by up to four Mobile Stations for a connection’ s establishment.
– Packet Downlink Assignment: This message is sent from the network to assign
resources to the Mobile Station in the downlink direction.
– Packet Uplink Ack/Nack: This message is sent from the network to the Mobile
Station for the acknowledgement of data blocks sent in the uplink direction;
– Packet Power Control/Timing Advance: This message is sent by the network to the
Mobile Station for the reconfiguration of either the “timing advance (TA)” and/or the
power control parameters;
– Packet Access Reject: This message is sent by the network to the Mobile Station to
indicate that the network has rejected its access request.
The following control messages can be transmitted in the uplink direction within a
RLC/MAC signaling Block Structure:
– Packet Downlink Ack/Nack:This message is sent from the Mobile Station to the
network for the acknowledgement of data blocks sent in the downlink direction.
– Packet Control Acknowledgment: This message is sent from the Mobile Station to
the network for the acknowledge of control blocks sent in the downlink direction;
The Packet Control Acknowledgment message is not formatted as a single RLC/MAC
i block, but as four Access Bursts.
A30808-X3247-M24-5-7618 53
System
4 Radio Interface Description

For the configuration of the packet switched data (PS) services in a specific cell, the user
shall create the PTPPKF object (Point To Point Packet Function) related to that cell and
then he/she shall configure properly all the related attributes. The operation can be done
locally from the Local Maintenance Terminal Evolution (LMT Evolution) or from the
Network Management System (Radio Commander) by means of the command: “Create
PTPPKF”. This command creates an instance of the PTPPKF Managed Object Class
(MOC). In the Containment Tree the PTPPKF Managed Object is hierarchically depen-
dent from the BTS Managed Object. For each BTS instance (that means for each config-
ured cell) it is defined only one PTPPKF Managed Object Instance (MOI) subordinated
to it. Its default value is always “0”. The configuration’s operation is permitted if the
super-ordinated BTS and at least one instance (but it is recommended to create always
all the instances) of the NSVC (Network Service Virtual Container) Functional Managed
Object have been previously created. This Managed Object models the functional end-
to-end communication between the BSS and the core network (SGSN).
At the end of the PTPPKF Managed Object successfully creation the cell is allowed to
support Packet Switched (PS) services on the basis of the configuration settings
assigned by the user. These settings are specified in the chapter: "5 Radio Resources
Management".
Functional object Meaning
PTPPKF This Functional Managed Object models the Point to

Point service in a cell. It allows a cell to provide Packed
Switched (PS) data services supported by the
GPRS/EDGE technology. Only one instance (default
value: “0”) of the PTPKF Managed Object can be config-
ured for the superior BTS Managed Object.
Tab. 4.1 PTPPKF Managed Object.
Once packet switched services have been enabled, the radio resources of the cell can
be assigned to either GPRS/EGPRS packet or circuit switched services, accordingly to
the user’s preferences.
In the GPRS/EGPRS system two types of radio channels have been defined:
1. On-demand radio channels (also called dynamic channels): these channels are
shared between packet switched services and circuit switched services accordingly
to the current requests, but circuit switched services have an higher priority than
GPRS/EGPRS packed switched ones.
2. Dedicated radio channels (also called static channels): these channels are perma-
nently assigned to GPRS/EGPRS 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 (one timeslot of the TDMA frame) assigned to the Packet Data
Services (PS) (either statically or dynamically) is named “Packet Data Channel (PDCH)
as represented within next Fig. 4.1
54 A30808-X3247-M24-5-7618
System
TDMA frame
GPRS/
EGPRS
0 7
PDCH
Fig. 4.1 Packet Data Channel (PDCH) within a TDMA frame
When a timeslot is used for GPRS/EGPRS (that means when the timeslot is a PDCH
one), the multiframe structure for this PDCH consists of 52 TDMA frames structured as
follow:
– 12 blocks (one block is composed by 4 frames and it is represented as Bx, with x=
0..11); each block can convey a RLC/MAC Radio Block containing either data or
signaling as described in the chapter: "3.6 RLC/MAC Block and Radio Block Struc-
tures".
– 2 idle frames represented as “I” and used for measurements.
– 2 frames used for the continuous timing advance update procedure described in the
chapter "4.6 Packet Timing Advance Estimation").
52 TDMA Frame - PDCH Multiframe
B0 B1 B2 T B3 B4 B5 i B6 B7 B8 T B9 B10 B11 i
4 frames 1 frame
- i = Idle frame
- Bx = Radio Block
- T = PTCCH
Fig. 4.2 Multiframe Structure for a PDCH
4.2 Channel Coding

The Blocks B0..B11 sent on the radio interface inside the PDCH multiframe are coded
differently depending on the packet switched (PS) service used (GPRS or EGPRS). In
the following chapters 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 RLC/MAC
blocks used during the data transmission.
The "Tab. 4.2 GPRS Coding Schemes" below summarizes the main characteristics of
each coding scheme, referring to the structure of the GPRS RLC/MAC block for data
transfer as represented in the "Fig. 3.8 RLC/MAC block’s structure for Data Transfer".
A30808-X3247-M24-5-7618 55
System
Coding Bits of RLC Spare Network Data Rate Bits of Total size of
scheme Data Field bits in RLC/MAC the RLC/MAC
(without RLC Data Header block (bits)
spare bits) Field (including
USF)
CS1 160 0 8 kbit/s (160 bit/20 msec) 24 184

CS2 240 7 12 kbit/s (240 bit/20 msec) 24 271
CS3 288 3 14.4 kbit/s (288 bit/20 msec) 24 315
CS4 400 7 20 kbit/s (400 bit/20 msec) 24 431
Tab. 4.2 GPRS Coding Schemes
According to the coding scheme used, the message (RLC/MAC 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 cases of CS1;
– 431 bits in cases of CS4.
The BTS will then execute the following operations (the coding process, for every coding
scheme, is detailed in the Fig. 4.3:
1. the first step of the coding procedure is to add a Block Check Sequence (BCS) for
the error detection;
2. the second step consists of the USF pre-coding (except for CS1);
3. the third step consists of the addition of four tail bits. Then an half rate convolutional
coding for the error correction is applied (for CS4 there is no coding specific for the
error correction);
4. the fourth step consists of the puncturing operation. It is executed with the purpose
of obtaining the target coding rate.
56 A30808-X3247-M24-5-7618
System
Modulation
CS1
Block code 40 bit Convolutional Interleaving
USF= 3 bit code (R=1/2)
+ 4 tail bit
181 bit 184 bit 228 bit 456 bit
CS2 / CS3
Mod.
USF Block code16 bit Convolutional Puncturing Interleaving
USF= 3 bit + 4 tail bit code (R=1/2)
pre-coding
268 bit 271 bit 274 bit 294 bit 588 bit 456 bit
312 bit 315 bit 318 bit 338 bit 676 bit 456 bit
Modulation
CS4
USF Block code Interleaving
USF= 3 bit 16 bit
pre-coding
428 bit 431 bit 440 bit 456 bit
Fig. 4.3 GPRS Coding Process

In the first implementation of GPRS, CS1 and CS2 coding schemes have been intro-
duced. Standard PCU frames were designed to carry the necessary signaling and data
information between the BSC and the BTS, and the GPRS capacity on the Abis was
limited to 16 kbit/s.
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 higher 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/s, using the flexible Abis allocation strategy, as described in the chapter:
"6.3 PCU Frames and Dynamic Allocation on the Abis Interface".
So, regarding the Abis interface, the information is transmitted using two kinds of PCU
frames:
a) Concatenated PCU frames are used when the support of CS3/CS4 is enabled at
both BSC and at BTS level;
b) Standard PCU frames are used when the support of CS3/CS4 is disabled at the
BSC or at the BTS level.
To get more information about concatenated PCU frames and the flexible Abis alloca-
i tion strategy refer to the chapter:"6.3 PCU Frames and Dynamic Allocation on the Abis
Interface".
The PCU frame format (concatenated or standard) is chosen at the Initial Time Align-
ment 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 at O&M level with the configuration of the related parameters, the selected
PCU frame format is “Concatenated”, even if the initial coding scheme could be
supported by standard PCU frames.
A30808-X3247-M24-5-7618 57
System
As default, the CS-1 and CS-2 coding schemes are enabled in the BSS; the BSC capa-
bility to support CS3/CS4 coding schemes can be enabled/disabled by the user. For the
purpose the CSCH3CSCH4SUP attribute of the BSC Managed Object allows the user
to enable/disable CS-3/CS-4 coding schemes at the BSC level.
The user can then enable/disable the support of CS3/CS4 on a cell basis configuring the
CSCH3CSCH4SUP attribute of the PTPPKF Managed Object..
When enabling the CS-3 /CS-4 coding schemes the precondition is that the bit 25 of the
i MNTBMASK attribute has to be set to FALSE, otherwise (bit 25 of MNTBMASK=TRUE)
the max coding scheme usable is forced to CS2 independently from the
CSCH3CSCH4SUP value set to TRUE.
With bit 25 of MNTBMASK set to 1, then the CSCH3CSCH4SUP attribute becomes a

flag for stating if CONCATENATED PCU frames or STANDARD PCU frames will be
used in the whole PTPPKF, that is, on all the TRX supporting EGPRS or GPRS of the
related PTPPKF Managed Object:
- when CSCH3CSCH4SUP is set to TRUE, CONCATENATED PCU frames are used
- when CSCH3CSCH4SUP is set to FALSE, STANDARD PCU frames are used.
Therefore the check that the CSCH3CSCH4SUP attribute has to be set to TRUE for
enabling EGPRS services is kept.
This also means that in a PTPPKFManaged Object so configured:

- bit 25 of the MNTBMASK attribute = 1;
- CSCH3CSCH4SUP = TRUE;
- EEDGE = TRUE;
then the maximum GPRS coding scheme will be CS-2 and CONCATENATED PCU
frames will be used on all the TRX supporting EGPRS or GPRS.
Instead in a PTPPKF Managed Object so configured:

- bit 25 of the MNTBMASK attribute = 1
- CSCH3CSCH4SUP = TRUE;
- EEDGE = FALSE;
then the maximum GPRS coding scheme will be CS-2 and CONCATENATED PCU
frames will be used on all the TRX supporting EGPRS or GPRS.
The MNTBMASK attribute is related also to the feature: “Common Bcch allowing
GPRS/EGPRS in the complementary band” introduced in BR7.0 by the Change
Request 2263.
By means of the bit24 of the MNTBMASK attribute (plus an object patch) the feature can
be enabled also for GSMDCS.
In the current BSS BR8.0 release the same features are supported but without the use
of the “MNTBMASK” attribute’s bits, as follow:
Hybrid frequencies can be still defined. As a consequence the BSC accepts the values
of the ARFCN parameter in the range: “301..424”, it flags the frequencies as “extended
one” and it forwards the ARFCN value without offset.
The “F2only900” attribute has been removed since the behaviour associated to this
attribute has been realized by defining all the primary frequencies as “hybrid” including
also the BCCH. When the BCCH is configured in the extended band or on a “hybrid”
frequency the BSC refuses the configuration of the primary frequency. As a conse-
58 A30808-X3247-M24-5-7618
System
quence the current GSMDCS (EXT900+DCS1800) configuration is extended for

including the (“F2only900”+DSC1800).
The new attribute “Gexts (Gprsxts)” has been introduced related to BTS Managed
Object with the values: “All900, Null”. The value “All900” specifies that all the 900Mhz
frequencies can be used for GPRS/EGPRS and therefore can be included into the
SysInfo1 message. The value “Null” specifies that only the primary frequencies are
considered and therefore GPRS/EGPRS services are supported and provided only in
the primary band.
The additional value, “ALLFREQ”, related to the “Gprsext” attribute has been imple-
mented for enabling GPRS/EGPRS services on non-BCCH band in Common BCCH
cells.
“Gexts” attribute can be modified by the user only if BTS Managed Object has been
locked. Besides it applies to all the SysId dual band like for example: GSMDCS,
GSM850PCS, GSM850DCS. The management of the GPRS enabling is consequently
simplified. The encoding of “extended” or complementary frequencies in the SysInfo1
message, necessary for the expansion of the GPRS availability, has required the modi-
fication of the bitmap format contained in the Cell Channel Description IE accordingly to
Standards. From this it is derived the limitation on the maximum number of frequencies
mapped in the bitmap: 22 in case of the use of the extended frequencies, 16 if GPRS is
also enabled on non-BCCH frequencies.
Besides some phase2 Mobile Stations fail to decode the variable bitmap format in IEs
Cell Channel Description and Frequency List, if they include both frequencies in the
range: 975-1023 and frequencies in the range: 0-124. For these Mobile Stations
hopping should not be configured on signaling and traffic channels in cells where the
E900 band is used and the variable bitmap format is adopted.
Currently after a “clean up” of the MaintenaceBitMask all the bits of the “MNTBMASK”
attribute can be used. For maintaining the system’s flexibility and also for satisfying the
customers needs the range of the value of this attribute has been increased from
[Bit0..Bit29] up to [Bit0..Bit61].
The user can also indicate, on a cell basis, which coding scheme has to be used as
preferred for the data transmission, when a new transmission is initiated (whereas
signaling uses always the CS-1 coding scheme as described in the chapter:
"4.4.5 Coding of GPRS/EGPRS Logical Channels". For GPRS the user can set the
preferred initial coding scheme configuring the INICSCH attribute. .
The user defines a value of coding scheme to be used when a data transmission starts
i configuring the INICSCH parameter. This value will be used only when the system does
not have any other information to choose the initial coding scheme (more details are
described in the chapter: "10.7.3 Selection of the Candidate Initial Coding Scheme").
Then the link adaptation algorithm (the algorithm is described in the chapter: "10.7 Link
Adaptation"), if enabled, can change the coding scheme of the TBF according to specific
radio conditions. If the link adaptation is not enabled, the initial coding scheme is the only
one used for the data transmission in the cell.
As it is described in the chapter: "6 Hardware and Software Architecture": , in order to
support GPRS TBFs with CS3 or CS4 coding schemes, the requirements are the
following:
• Only High Capacity BSC(s) support the CS3/CS4 coding schemes;
• BTS1, BTS+, E-microBTS and PicoBTS, support the CS3/CS4 coding schemes.
A30808-X3247-M24-5-7618 59
System
The coding process of a RLC/MAC block, using CS1, is shown in the 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 for more details the chapter: "4.2.2 EGPRS Channel
Coding").
PCU
RLC/MAC block
USF TFI Data bits BCS Tail
3 bits 181 bits 40 bits 4 bits
R=1/2 Convolutional Code

Encrypted RLC frame
456 bits
456 bits are split in 4

Normal bursts.
Normal Burst
Training
Tail Encrypted bits Encrypted bits Tail Guard
Sequence period
57 bits 57 bits
Stealing bits
Fig. 4.4 Coding of the RLC/MAC Block using CS-1

In order to inform MSs about frequencies available in serving cell or adjacent cells, BSC
codes the frequency set into bitmap format depending on frequency range.Standards
define several formats: bitmap0, variable bitmap, range 128, range 256, range 512,
range 1024. All formats are supported by Siemens BSC.
It has been verified that, although compliant to Standards, bitmap formats different from
Range 1024 included in SysInfos, Assignment Command, Hand Over Command and
Frequency Redefinition, are not correctly managed by Siemens mobiles of series 25 and
35 in the following scenario: Mix of frequencies in two ranges (0, 1..124) and (975..1023)
in the same cell or in adjacent cells.
Besides also mobiles of other vendors could be affected by this problem, and could have
still unknown problems with certain bitmap formats. Range 1024 is the oldest format
introduced, and it will be likely well managed by all the MSs of every vendor.In these
scenarios, MSs affected by the problem are not able to camp on cell, so the user, intro-
ducing extended band, will loose a part of the MS in its network.
60 A30808-X3247-M24-5-7618
System
It shall be remarked that wrong behaviour of some MSs affects all procedures using
such format, not only the ones for extended band.The solution identified on network
side, to allow these MSs to camp on cells, is to code SysInfos, for example with a format
different from the critical ones, for example to give the possibility to force range 1024 in
case of mix of frequencies and “0”. The use of a reduced set of bitmap formats can lower
the limit of maximum number of frequencies in the cell (CALLF) and maximum number
of adjacent cells. For the purpose bit 27 of MaintenanceBitmask has been implemented
to enable/disable this behaviour.As for bit 17, bit 27 cannot be modified if any BTS is
configured in the DataBase. In order to inform Mobile Stations about frequencies avail-
able in serving cell or adjacent cells, BSC codes frequency set into bitmap format
depending on frequency range.
Standards define several formats, for example: bitmap0, variable bitmap, range 128,
range 256, range 512, range 1024. All formats are supported by Siemens BSC. It has
been verified that, although compliant to Standards, the variable bitmap format included
in some SysInfo is not correctly managed and supported by several mobiles (for
example, Nokia 6250/6310) in presence of mix of frequencies in two ranges (0, 1..124)
and (975..1023) in the same cell.
As a consequence several Mobile Stations cannot correctly manage variable format
included in SysInfos. The wrong behaviour of some Mobile Stations affects all proce-
dures using such format, not only procedures triggered for extended band. To solve
these limitations bit 22 of MaintenanceBitmask has been set. As for other bit (for
example: bit17, bit 27), bit22 cannot be modified if any BTS is configured in Database.
4.2.2 EGPRS Channel Coding

As it has been described in the chapter "3.1 GPRS and EGPRS Modulation Principles",
the following nine different modulation and coding schemes: “MCS1..MCS9”, are
defined for the EGPRS RLC/MAC Blocks, both GMSK and 8 PSK modulated.
The Tab. 4.3 summarizes the main characteristics of each coding scheme, referring to
the structure of the EGPRS RLC/MAC block for data transfer (see next Fig. 3.10 and
the Fig. 3.11).
Coding Bits of RLC Net Data Rate Bits of FBI+E Total size of
scheme Data Field RLC/MAC fields the RLC/MAC
(without Header DL/UL (bits) block DL/UL
spare bits) (including (bits)
USF)
MCS1 176 8,8 kbit/s (176 bit/20 msec) 31/31 2 209

MCS2 224 11,2 kbit/s (224 bit/20 msec) 31/31 2 257
MCS3 296 14.8 kbit/s (296 bit/20 msec) 31/31 2 329
MCS4 352 17.6 kbit/s (420 bit/20 msec) 31/31 2 385
MCS5 448 22.4 kbit/s (448 bit/20 msec) 28/37 2 478/487
MCS6 592 29.6 kbit/s (592 bit/20 msec) 28/37 2 622/631
MCS7 448+448 44.8 kbit/s (896 bit/20 msec) 40/46 2+2 940/946
Tab. 4.3 EGPRS Coding Schemes
A30808-X3247-M24-5-7618 61
System
Coding Bits of RLC Net Data Rate Bits of FBI+E Total size of
scheme Data Field RLC/MAC fields the RLC/MAC
(without Header DL/UL (bits) block DL/UL
spare bits) (including (bits)
USF)
Tab. 4.3 EGPRS Coding Schemes
According to the coding scheme used, the message (RLC/MAC block) delivered, by
means of PCU frames, to the encoder embedded in the BTS software has a fixed size
as follow:
– 209 bits in cases of MCS1;
– 478 bits in cases of MCS5 in the downlink direction, and 487 bits in cases of MCS5
in the uplink direction;
– 1132 bits in cases of MCS8 in the downlink direction, and 1138 bits in cases of
MCS8 in the uplink direction;
– 1228 bits in cases of MCS9 in the downlink direction, and 1234 bits in cases of
MCS8 in the uplink direction.
Obviously the message transmitted from the BTS to the BSC has the sane size for the
different MCSs:
The MCSs are divided into different families:
– A;
– A padding;
– B;
– C.
Each family has a different basic unit of payload: 37 (and 34) octects for the A and Apad-
ding family, 28 octects for the B family and 22 octets for the C family respectively.
Different code rates within a family are achieved by transmitting a different number of
payload units within one Radio Block. For the families A and B, one, two or four payload
units are transmitted, instead for the family C only one or two payload units are trans-
mitted.
The Tab. 4.2.4 shows the correspondence between the families and the related coding
schemes, whereas the Fig. 4.5 represents the different relationships among families,
coding schemes and possible units of payload.
FAMILY CODING SCHEMES
A MSC-3, MSC-6, MSC-9

A Padding MSC-3, MSC-6, MSC-8
Tab. 4.2.4EGPRS Coding Schemes and Families
62 A30808-X3247-M24-5-7618
System
FAMILY CODING SCHEMES
B MSC-2, MSC-5, MSC-7

C 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), they are split into two
separate RLC data fields of the same RLC/MAC block (that means with separate
sequence numbers and BCSs, as reported in the "Fig. 3.11 RLC/MAC Block structure
with two RLC Data block fields").
This can be clearly seen by comparing the "Fig. 4.6 Interleaving of MCS9 Coded Data
into Two Consecutive Normal Bursts" (family A, MCS9) and the "Fig. 4.7 Interleaving of
MCS6 Coded Data" (family A, MCS6).
A30808-X3247-M24-5-7618 63
System
After the reception of a RLC/MAC block from the BSC, the BTS executes the following
operations:
To ensure strong header protection, the header part of the Radio Block (i.e., the
i RLC/MAC header) is independently coded from the data part of the Radio Block.
1. the first step of the coding procedure of the data part of the RLC/MAC Block is to
add a Block Check Sequence (BCS, 12bits) for the error detection;
2. the second step consists of the addition of six tail bits (TB);
3. the third step is the activation of a 1/3 rate convolutional coding with constraint
length 7 for error correction;
4. the fourth step is the execution of the puncturing operation for obtaining the target
coding rate. The puncturing operation takes advantage of the different puncturing
schemes Pi (where i = 1..3), which has impact on Incremental Redundancy as Link
Quality Control method; the Pi for each MCS corresponds to different puncturing
schemes achieving the same coding rate;
5. As fifth and last step , the radio block is rectangular interleaved over 4 bursts (see
next Fig. 4.6 and Fig. 4.7). Hence the block length for each RLC block is:
– 4*114 = 456 bit in cases of GMSK modulation;
– 4*348 = 1392 bit in cases of 8 PSK modulation (including stealing symbols).
For MCS8 and MCS9, only the header is interleaved over 4 normal bursts. The data
i blocks are interleaved over 2 bursts only. The MCS7 header and data are interleaved
over 4 bursts.
The coding and puncturing scheme of a RLC/MAC 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 as follow:
• 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 cases of MCS1, MCS2, MCS3 and MCS4 coding
schemes;
– 8 stealing bits are used in cases of MCS5, MCS6, MCS7, MCS8 and MCS9 coding
schemes.
As it has been described in the chapter: "4.2.1 GPRS Channel Coding", stealing bits (8
bits) are also used to indicate the coding scheme used in cases of GPRS radio blocks.
Stealing bits coding is represented in the Tab. 4.2.5.
Coding Scheme Stealing Bits
GPRS CS1 none

GPRS CS2 1,1,0,0,1,0,0,0
GPRS CS3 0,0,1,0,0,0,0,1
GPRS CS4 0,0,0,1,0,1,1,0
MSC1, MSC2, MSC3, MCS4 0,0,0,1,0,1,1,0,0,0,0,0
Tab. 4.2.5Coding of Stealing Bits for GPRS and EGPRS Radio Blocks
64 A30808-X3247-M24-5-7618
System
Coding Scheme Stealing Bits
MSC5, MSC6 0,0,0,0,0,0,0,0

MSC7, MSC8, MSC9 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 indicate four header formats. There
are twelve stealing bits for GMSK mode which indicate two header formats: the first eight
of the twelve stealing bits indicate CS4 to allow Mobile Stations supporting GPRS
services to decode the header type 3 and to read the USF field of the header (more
details about the meaning of the USF field are described in the chapter: "4.3 Temporary
Block Flow" ).
The USF field has eight states, which are represented by a binary 3 bit field in the MAC
Header. The USF is encoded to twelve symbols similarly to GPRS, (that is 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
A30808-X3247-M24-5-7618 65
System
Fig. 4.7 Interleaving of MCS6 Coded Data
The user can also configure , on a cell basis, the coding scheme that has to be used as
preferred for the data transmission, when a new transmission is initiated (whereas
signaling always uses the CS1 coding scheme, as described in the chapter:
"4.4.5 Coding of GPRS/EGPRS Logical Channels").
The user can set the preferred initial coding scheme with the following parameters:
• in the uplink direction, as it is described in the chapter "9.1 Mobile Stations for
Packet Switched Services", not all the Mobile Stations that support the EGPRS
services support also the 8PSK modulation, therefore:
– the IMCSULNIR8PSK attribute suggests the MCS to be used in the uplink direc-
tion if the Mobile Station supports the 8 PSK modulation in this direction;
– the IMCSULNIRGMSK attribute suggests the MCS to be used in the uplink direc-
tion if the Mobile Station supports only the GMSK modulation in this direction;
• in the downlink direction all the Mobile Stations supporting EGPRS services are
obliged to support the 8 PSK modulation, so the INIMCSDL attribute suggests the
MCS to be used in the downlink direction for all the EGPRS Mobile Stations.
The user has to set a value of the coding scheme to be used when a data transmission
i starts. This value is adopted only when the system does not know any other information
for choosing the initial coding scheme (see the chapter "10.7.3 Selection of the Candi-
date Initial Coding Scheme").
The link adaptation algorithm, if enabled, can change the coding scheme of the TBF
according to the radio conditions. If the link adaptation algorithm is not enabled, the
initial coding scheme is the only one used for the data transmission in the cell (details
about the coding schemes’ management are described in the chapter "10.7 Link Adap-
tation").
For supporting the EGPRS coding schemes, concatenated PCU frames are used in the
66 A30808-X3247-M24-5-7618
System
system, and the Abis throughput per radio channel (PDCH) is increased to nx16 kbit/s,
using the flexible Abis allocation strategy as described in the chapter: "6.3 PCU
Frames and Dynamic Allocation on the Abis Interface".
4.3 Temporary Block Flow

The Temporary Block Flow (TBF) is the physical connection, between the Mobile
Station and the network, used to support the unidirectional transfer of LLC PDUs on the
packet data physical channels (PDCHs).
The TBF is characterized by a set of allocated radio resources on one or more PDCH
channels, and it comprises the transmission of a number of RLC/MAC blocks carrying
one or more LLC PDUs. A TBF is maintained only for the duration of the data transmis-
sion.
The TBF is established:
• in uplink direction to transfer data (or signaling) from the Mobile Station to the
network;
• in downlink direction to transfer data (or signaling) from the network to the Mobile
Station.
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 IMME-
DIATE ASSIGNMENT message (see "9.8 Access to the Network (Establishment of a
TBF)").
The EGPRS TBF mode is supported by EGPRS Mobile Stations only, see the chapter:
i "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 simultaneous TBFs in the same direction, for example.:
– 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 Mobile Station in a resource assignment message that
precedes the transfer of LLC frames (both in the uplink and the 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
(for example acknowledgements), in order to address the 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 cases of RLC data
block;
• the direction (UL or DL) in which the RLC/MAC control message is sent and the
message type, in cases of RLC/MAC control message.
Besides at BSC side the TLLI_BLOCK_CHANNEL_CODING bit in the messages:
Packet Uplink Assignment and Uplink Immediate Assignment related to each RRM
procedure is set to 0. With this value the Mobile Station is forced to use CS1/MCS1 for
any RLC data block containing a TLLI in its header.
Better performance on SM/GMM signaling and first Edge ping for EGPRS MS is
achieved when Extend Uplink TBF cannot be used.
A30808-X3247-M24-5-7618 67
System
With high coding schemes (MCS6 onwards) a standard ping (about 70 bytes in total) fits
in one only BSN. Therefore it is not possible to maintain artificially opened the UL TBF
waiting for a possible DL TBF arrival: the contention resolution shall be completed, and
the Packet Uplink Ack/Nack (PUAN) sent is a final one, given that the TBF is composed
by only 1 block. As a consequence any subsequent Downlink cannot be opened in
concurrent, but it is opened on BCCH/PBCCH (PCH/PPCH or AGCH/PAGCH channel).
The first ping time then arises to about 1500 msec. Exploiting the set to 0 of
TLLI_BLOCK_CHANNEL_CODING, the UL TBF is on the contrary composed by more
than 1 block, given that CS1 and MCS1 carry about 20 bytes only; therefore the conten-
tion resolution PUAN is not the final one, and it is possible to maintain artificially alive
the UL, waiting for a possible subsequent DL, that is then opened in concurrent way.
The first ping time can then be reduced below 1 second.
In general an improvement is obtained on every procedure opened with an UL LLC
included in the range (20 bytes – 150bytes), depending upon the CS/MCS applied at
BSC side. No improvement can be reached if the first UL LLC is shorter than 20 bytes.
4.3.1 Extended Uplink Temporary Block Flow

In the current BR8.0 release it is possible to keep an uplink Temporary Block Flow (TBF)
even in case of short inactivity of the uplink traffic. In this way it corresponds to the
“Delayed TBF Release” that offers a similar functionality but in downlink direction.The
delayed Downlink TBF and Extended Uplink TBF are independent and they can also run
simultaneously. During a series of PING commands both DownLink and UpLink TBF
could also be inactive at the same time. The “Extended UL TBF” feature has been stan-
dardized in GERAN Release 4 and it is therefore not available for Release 99 and pre-
Release 99 Mobile Stations. The feature applies to open-ended TBFs in RLC acknowl-
edged and unacknowledged mode. It is not defined for closed-ended TBFs.
When the Extended UpLink TBF feature applies, the release of an open-ended uplink
TBF is not initiated by the Mobile Station as today but the BSC decides according the
release. After the Mobile Station has signaled that its RLC buffer is empty, the BSC
assigns the uplink resources enabling the Mobile Stations to send new uplink LLC
PDUs. The BSC releases the TBF finally when the inactivity continues for a given time.
The BSC signals support the Extended Uplink TBF per cell (on the BCCH/PBCCH
channel). The BSC cannot negotiate the Extended Uplink TBF feature with the Mobile
Station on a TBF base: if the Mobile Station and the BSC signal support the Extended
UpLink TBF, all UpLink TBFs of the Mobile Station are handled in the Extended UpLink
TBF mode. In case a Mobile Station supports the Extended UpLink TBF mode, the rapid
polling algorithm that has been introduced for the pre-Release 4 Mobile Station can be
spared. Thanks to the rapid polling, the delay caused by the request for a new uplink
TBF (after a short uplink inactivity) is minimized. When an Extended Uplink TBF is
running the uplink TBF is kept and therefore the Mobile Station does not need to request
a new UpLink TBF.
The Extended UpLink TBF assumes that the new LLC PDUs are sent with the same
QoS and PFI as for the previously sent data. If the QoS or the PFI are modified, the TBF
must be reconfigured before new LLC PDUs could be sent.The mayor benefit
concerning the delay is the omitted establishment of a new TBF. The time for the estab-
lishment of a new Temporary Block Flow contains:
- The Mobile Station waiting time for a RLC data block with valid RRBP to send an uplink
channel request (it is assumed that a downlink TBF is ongoing);
68 A30808-X3247-M24-5-7618
System
- The time to transfer the Packet Downlink Ack/Nack message including the Channel
Request Description for the needed uplink resource from the Mobile Station to the BSC;
- The time to transfer the Packet Uplink Assignment message from the BSC to the
Mobile Station.This spares in average 50% of the polling period (interval between valid
RRBPs) and one round trip time. As drawback, the Uplink resources scheduled during
the inactivity are lost for other TBFs/Mobile Station. But this loss is comparable to the
loss caused by the rapid polling algorithm.
The support of this feature from the BSC is granted by the attribute: “Nw_Ext_Utbf” of
the GPRS Cell Options: if this attribute is set to “1”, the BSC supports the Extended
UpLink TBF.The GPRS Cell Options are contained in the messages: “Packet System
Information 1, 13 and 14” and in the System Information 13 Rest Octets.
The support of the Extended UpLink TBF mode from the Mobile Station is signaled from
the Mobile Station itself by its MS Classmark 3, Mobile Station Radio Access Capability
and Mobile Station Radio Access Capability 2 by indicating the support of “GERAN
Feature Package 1”.
The BSC can retrieve this information from:
• The “Packet Resource Request” message (if the message contains the Mobile
Station Radio Access Capability 2);
• A downlink TBF for the same MS/TLLI (if the MS Radio Access Capability are stored
for the downlink TBF);
• The BSS context for the same MS/TLLI.
In case the BSC is not able to retrieve this information (for example at one-phase packet
access the Mobile Station Radio Access Capabilities might not be available), the TBF
should be operated in non-extended UpLink TBF mode.
When both the Mobile Station and the network signal support the Extended Uplink TBF
mode this mode is used for each open-ended uplink TBF without further negotiation, as
follow:
• When the Mobile Station signals that it has no more RLC data blocks to send (CV=0)
and the BSS recognizes that all the RLC data blocks have been received correctly (RLC
acknowledged mode only, V(Q)=V(R)), the BSS starts the timer “TIMEEXTUTBF”. This
parameter is configurable from the LMT Evolution and also from the Radio Commander.
• While the timer TIMEEXTUTBF is running the scheduler continues to schedule USF
resources as normally;
• The procedures for timing advance and power control are kept running. The link
adaptation is suspended due to the fact that dummy uplink control blocks may be sent
on the PACCH channel using CS1 and this code may be different from the one used
during the data transfer of the uplink TBF;
• When the Mobile Station receives a valid USF flag and has no data to send, it sends
a RLC/MAC control block (for example the RLC/MAC Packet Uplink Dummy Control
Block);
• When the Mobile Station receives a valid USF flag and has new data to send (with
the same QoS and PFI as the already sent data), it sends an RLC/MAC data block. After
the reception of this block, the BSS stops the timer “TIMEEXTUTBF” and it continues its
normal operation;
• When the Mobile Station wants to send new data with different QoS or PFI, it sends
a “Packet Resource Request” message. In the BSS there are two different procedures:
A30808-X3247-M24-5-7618 69
System
1) If the PFI priority or peak throughput class changes, the BSS keeps the TBF and
change its properties by a Packet Uplink Assignment or Packet Timeslot Reconfigura-
tion. This procedure is identical to the procedure in the non-extended UpLink TBF mode;
2) If the RLC mode changes, the BSS shall release the existing TBF by sending a
“Packet Uplink Ack/Nack” message with FAI=1. When the Mobile Station acknowledges
the release by a Packet Control Ack, the BSS assigns the new resources;In both cases
the time “TIMEEXTUTBF” is stopped;
• When the timer TIMEEXTUTBF expires, the TBF is released. Additionally the TBF may
be released also by internal procedures (for example the Radio Resource Management
decides to preempt the TBF);
• If a downlink TBF gets inactive while an Extended UpLink TBF is running for the same
Mobile Station the rapid polling phase may be omitted.
In contrast to the non-extended UpLink Temporary Block Flow (TBF) mode in which the
CV=0 triggers the TBF release, the release of an extended UpLink Temporary Block
Flow (TBF) is triggered by the expiration of the timer “TIMEEXTUTBF”.
The BSS initiates the release of the TBF by the Packet Uplink Ack/Nack with FAI (Final
Ack Indicator) set to 1. The handling of this message and its acknowledgement is iden-
tical to the handling in non-extended UpLink TBF mode (for example for the support for
the establishment of a new Temporary Block Flow). Additionally the BSC may use the
Packet TBF Release message to release the TBF in “abnormal” cases (for example the
PDCH/PDT release requested by the TDPC processor).
4.3.2 Multiplexing MSs on the same PDCH: Downlink Direction

A downlink TBF, associated to a single PDCH, is set up giving to the Mobile Station:
– a PDCH (i.e., a timeslot);
– a TFI (each mobile station has its own TFI value).
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 Mobile Station, the block is skipped;
3. if the TFI is the one assigned to the Mobile Station, this means that the block belongs
to it and then data is taken.
The "Fig. 4.8 Multiplexing Mobile Station on the same PDCH (Downlink)" represents
the mobile station behavior.
70 A30808-X3247-M24-5-7618
System
Fig. 4.8 Multiplexing Mobile Station on the same PDCH (Downlink)
4.3.3 Multiplexing MSs on the same PDCH: Uplink Direction

An uplink TBF, associated to a single PDCH, is set up with the purpose to provide to the
Mobile Station:
– 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.
The USF is used in Dynamic Access Modes (see the chapter: "9.8.1 Medium
Access Modes"), and comprises 3 bits at the beginning of each Radio Block, that is
sent in the downlink direction (the 3 bits belong to the MAC header, see the chapter
"3.6 RLC/MAC Block and Radio Block Structures"). It enables the coding of 8
different USF states which are used to multiplex the uplink traffic.
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 Mobile Station, then the Mobile Station sends
its uplink data on the next uplink block, or on the next four uplink blocks;
3. if the USF is not the one assigned to the Mobile Station, then the Mobile Station
doesn’t send its uplink data on the next uplink block, or on next four uplink blocks.
Next Fig. 4.9 represents the Mobile Station behavior in cases of uplink transmission on
the next uplink block.
A30808-X3247-M24-5-7618 71
System
Fig. 4.9 Multiplexing Mobile Station on the same PDCH (Uplink)
On PDCHs (not carrying PCCCH, see the chapter "4.4.2 Packet Common Control
i Channel (PCCCH)"), eight USF values are used to reserve the uplink to different Mobile
Stations, by means of the following rule:
- 7 USF values are used for 7 Mobile Stations that have established an uplink TBF;
- one USF value is used to allow, to those Mobile Stations that have established a down-
link TBF, the transmission of control blocks in the uplink direction (e.g., to transmit the
Packet Downlink Acknowledge message).
So when the network wants to permit to one Mobile Stations, that doesn’t have an uplink
TBF, to transmit in uplink direction, it sets the USF field to this reserved value. In this
way, the Mobile Stations that have an uplink TBF do not transmit in the next uplink block
(since they don’t find their USF value), while the network informs the Mobile Stations
with the downlink TBF, that it must transmit in the uplink block that the network has
reserved for it. To inform the Mobile Stations 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 the chapter "3.6 RLC/MAC Block and Radio Block Structures"); with
the information stored in this field, the network informs the Mobile Stations that they
must send a control block in the uplink direction (see the chapter "9.8.4 Relative
Reserved Block Period Field (RRBP)").
The GPRS and EGPRS Mobile Stations can be multiplexed dynamically on the same
PDCH by utilizing the USF. The only problem is that if 8PSK modulation is used in the
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:
– uses the GMSK modulation, i.e., either CS 1 to CS 4 or MCS 1 to MCS 4, in those
blocks that assign 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.
The dynamic allocation using USF granularity requires that a GPRS Mobile Station is
able to do what the USF in an EGPRS GMSK block. This is enabled by setting stealing
72 A30808-X3247-M24-5-7618
System
bits in the EGPRS GMSK blocks to indicate CS4 (see the chapter "4.2.2 EGPRS
Channel Coding"). The coding and interleaving of the USF is done as defined for CS4;
this means that:
– a standard GPRS Mobile Station is 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 Mobile Station can not differentiate CS4 blocks and EGPRS GMSK
blocks by only looking at the stealing bits. This is however not needed for USF detec-
tion, 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.
Due to synchronization aspects related to the Mobile Station, if standard GPRS Mobile
Stations are multiplexed on the PDCH, at least one Radio Block every 360 ms on the
downlink direction must use GMSK (i.e., standard GPRS or MCS-1 to MCS-4); this
because every Mobile Station shall receive a radio block at least every 360 ms.
4.3.4 Multiplexing MSs on the same PDCH: Configuration

As it has been described, more than one Mobile Station can be multiplexed, either in the
downlink or in the uplink direction, on the same physical data channel (PDCH):
– in uplink direction up to 7 Mobile Stations can be multiplexed on the same physical
data channel; in fact, up to seven USF values can be used to multiplex Mobile
Stations on the same PDCH in the uplink direction;
– in the downlink direction, up to 16 Mobile Stations can be multiplexed on the same
physical data channel; this number is imposed by the Timing Advance Index (TAI)
necessary for the Timing Advance Update procedure (see the chapter "4.6 Packet
Timing Advance Estimation");
– in total (uplink and downlink) up to 16 Mobile Station can be multiplexed on the same
physical channel; this number is imposed by the Timing Advance Index (TAI)
necessary for the Timing Advance Update procedure (see the chapter "4.6 Packet
Timing Advance Estimation").
If, for instance, 7 Mobile Stations are using a PDCH in the uplink direction, at most
9 Mobile Stations can use the same PDCH but in the downlink direction.
The GMANMSAL attribute allows the user to define the maximum number of users that
can share the same timeslot (PDCH) in uplink (UL) and downlink (DL) direction. It is
composed of two fields:
• the first field specifies the maximum number of users in the uplink direction;
• the second field specifies the maximum number of users in the downlink direction.
4.4 GPRS/EGPRS Logical Channels

For supporting the packet switched services (PS) the following Packet Data Logical
Channels have been defined:
• Packet Broadcast Control Channel (PBCCH):;
• Packet Common Control Channel (PCCCH):
• Packet Data Traffic Channel (PDTCH);
• Packet dedicated control channels (PTCCH and PACCH).
A30808-X3247-M24-5-7618 73
System
These different packet data logical channels, which are specific for the GPRS/EGPRS
technology, can share the same physical channel (on the same PDCH), when the
timeslot is assigned to the GPRS/EGPRS users.
The sharing of the physical channel is based on blocks of 4 consecutive Normal Bursts,
i with the exception of the PTCCH (uplink direction) and the PRACH (see the chapter
:"4.4.4 Packet Dedicated Control Channels") where single Access Bursts are used.
4.4.1 Packet Broadcast Control Channel (PBCCH)

Within the GSM network, system information messages are regularly broadcasted by
the BCCH and busy TCHs. With the help of system information the Mobile Station 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 trans-
mitted on the BCCH, to allow circuit switched operation to Mobile Stations 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 (PS)
services; if the PBCCH is not allocated, the packet data specific system information is
broadcast on the BCCH (in the system information 13 message).
The following Packet System Information exists: PSI1, PSI2, PSI 3, PSI3 bis, PSI3
quater, PSI5, PSI8, PSI13 (see the specification: GSM 04.60):
• PSI1 message is sent by the network on either the PBCCH or PACCH channel,
providing information for cell selection, for control of the PRACH, for description of
control channels and optional power control parameters;
• PSI2 message is sent by the network on the PBCCH channel, providing information
of reference frequency lists, mobile allocations and PCCCH channel descriptions
applicable for the packet access in the cell;
• PSI3 message is sent by the network on the PBCCH or PACCH providing informa-
tion of the BCCH allocation (BA(GPRS)) in the neighbour cells and cell selection
parameters for serving cell and non-serving cells;
• PSI3 bis message is sent by the network on the PBCCH and PACCH providing infor-
mation of the BCCH allocation in the neighbour cells and cell selection parameters
for non-serving cells;
• PSI3 quater message is sent by the network on the PBCCH or PACCH providing
information on 3G Neighbour Cells and additional measurement and reporting
parameters;
• PSI5 message contains specific parameter for measurement reporting and network
controlled cell reselection;
• PSI8 message can be broadcast on PBCCH if additional information (for example
CBCH configuration and dynamic ARFCN mapping) shall be provided to the Mobile
Station camping on the cell;
• PSI13 message is sent by the network on the PACCH channel (when the PBCCH
channel is not configured), providing the Mobile Station 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 the system information
on the BCCH channel. From the BCCH channel, the MS understands if the cell supports
the GPRS service or not. If the cell supports the service, the Mobile Station starts
74 A30808-X3247-M24-5-7618
System
reading the system information 13, that provides GPRS cell specific information. From
system information 13, the Mobile Station also learns if the PBCCH channel is config-
ured in the cell. If it is configured, the Mobile Station stops reading system information
on the BCCH and starts reading packet system information on the PBCCH.
When an EGPRS mobile station camps on a cell it starts reading system information on
the BCCH channel. From the BCCH channel, it understands if the cell supports the
GPRS service. If the cell supports the service, the Mobile Station starts reading the
system information 13 message that provides information regarding the EGPRS avail-
ability too. From the system information 13 the Mobile Station also learns if the PBCCH
channel is configured in the cell, then:
a) if the PBCCH is not supported, the Mobile Station knows that EGPRS is available
reading GPRS Cell Option IE in the System Information 13 message and finding the
EGPRS Packet Channel Request support indication field. This field indicates if the
EGPRS PACKET CHANNEL REQUEST message is supported in the cell (see for
more details the chapter: "9.8.2.4 TBF Establishment for EDGE Mobile Stations").
Additionally the PSI13 message within the PACCH contains GPRS Cell Options
updated for EGPRS.
b) if the PBCCH is supported, GPRS Cell Options, updated for EGPRS, will be present
in the PSI1 message,
The PBCCH channel, when configured, is allocated on a PDCH physical channel
i (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 always resides in the slot 0 of the BCCH TRx).
TDMA frame
BCCH PBCCH
0 7
PDCH
Fig. 4.10 Example of Mapping of the PBCCH Channel.
When, for GPRS/EGPRS mobile stations, the PBCCH is used instead of the BCCH,
i more information and parameters regarding packet switched (PS) data services are
transmitted; for example new cell re-selection criteria are implemented (see the
chapter:"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 signaling,
introduced to support packet data services. These common channels are the following:
(see also the "Fig. 4.11 Packet Common Control Channels").
– Packet Paging Channel (PPCH): this channel is used, in the downlink direction
only, to page a Mobile Station prior to the downlink packet transfer. PPCH uses
paging groups in order to allow the usage of DRX mode.
– Packet Access Grant Channel (PAGCH): this channel is used, in the downlink
direction only, in the packet transfer establishment phase, to send resource assign-
ments to Mobile Stations prior to the packet transfer;
A30808-X3247-M24-5-7618 75
System
– Packet Random Access Channel (PRACH): this channel is used, in the uplink
direction only, by a Mobile Station to initiate the uplink transfer for sending data or
signaling information. Access Bursts are used on the PRACH channel (see for more
information the chapter: "4.2 Channel Coding".
Packet Random
- to initiate uplink transfer
Access Channel
- to request allocation of new PDTCHs
PRACH
Packet Common Packet Paging

Control Channels - to page a MS prior of a downlink
Channel
PCCCH transfer
PPCH
Packet Access
Grant Channel - to allocate resources
PAGCH
Fig. 4.11 Packet Common Control Channels

The PCCCH channels do not have to be allocated permanently on the cell. Whenever
the PCCCH channels are not allocated, the already configured CCCH channels (for
example the PCH, AGCH and RACH) are used to execute the described operations, in
the same way and with the same functionalities provided for the GSM services.
For this reason also for a GPRS/EGPRS mobile network the same eventual overload
situations as for a GSM mobile network can occur on the Common Control Channels in
downlink direction (overload related to the PCH and AGCH channels). These overload
situations have been minimized in the current BSS BR8.0 release.
Paging” and “Access Grant” messages are sent by means of the same CCCH blocks.To
ensure a certain throughput on the AGCH Channel the user can define reserved CCCH
blocks that are used only for the “Access Grant” messages. On the other CCCH blocks
both “Paging” and “Access Grant” messages are sent. The “Paging” messages have an
higher priority.
Specific CCCH configurations adapted to the traffic of each cell are defined by the
customers during their network planning activities. Nevertheless overload situations
also for the AGCH and PCH channels can occur, also if normally for a short time.
The reduction of the CCCH channels’ overload provides as a consequence higher
performances of the mobile network, that means less “Paging” messages and “Imme-
diate Assignment” commands lost. This increases also the call setup success rate and
any eventual further blocking depend on the missing SDDCH and TCH channels. The
overload reduction has been reached as follow:
• Implementation of the feature: “Immediate Assignment Extended”. According the
GSM 44.018 Recommendation this feature potentially doubles the throughput on the
AGCH channel. Additionally “Immediate Assignment reject” are re-arranged in the
76 A30808-X3247-M24-5-7618
System
BTS to carry up to four different Mobile Stations IDs instead of carry four times the
same Mobile Station.
• Modification of the priority on not reserved CCCH blocks for AGCH channels over
PCH channel to avoid lost assignments.
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 config-
i ured, and it resides in the same PDCH containing also the PBCCH as represented in
Fig. 4.12.
If the user needs more packet common signaling resources, it can configure another
PCCCH in another PDCH as represented in the "Fig. 4.13 Example of Mapping of two
PCCCH Channels.".
TDMA frame
PBCCH
BCCH +
PCCCH
0 7
PDCH
Fig. 4.12 Example of Mapping of the PCCCH Channel.
TDMA frame
PBCCH
BCCH + PCCCH
PCCCH
0 7
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
Mobile Station. In the multislot operation (see the chapter: "4.7 Multislot Configuration"),
one Mobile Station 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 includes also its dedicated control channels (see the chapter "4.4.4 Packet
Dedicated Control Channels").
Regarding the PDTCH assignment, according to the GMANMSAL attribute of the
PTPPKF Managed Object, the following restrictions must be satisfied (see also the
chapter: "4.3.4 Multiplexing MSs on the same PDCH: Configuration").
A30808-X3247-M24-5-7618 77
System
PDTCHUp<=7
PDTCHDown<=16
PDTCHUp + PDTCHDown <=16
4.4.4 Packet Dedicated Control Channels

Two types of packet dedicated control channels are supported by the GPRS/EGPRS
services:
• Packet Associated Control Channel (PACCH):The PACCH channel conveys
signaling information related to a given Mobile Station. The signaling information
includes for example acknowledgements and power control information. PACCH
also carries 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 transmission of data blocks, while the PACCH channel allows transmission of
the related signaling blocks; so the PACCH channel shares with PDTCHs the
resources that have been currently assigned to one Mobile Station.
For instance, the following control messages can be carried by the PACCH channel,
according to the direction of transmission:
Uplink Direction (UL):
– Packet Control Acknowledgment;
– Packet Downlink Ack/Nack.
Downlink Direction (DL):
– 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 Estima-
tion"). The PTCCH/U is used to transmit the random access burst to allow the esti-
mation of the timing advance for one Mobile Station in packet transfer mode; the
PTCCH/D is used to transmit timing advance information updates to several Mobile
Stations.
4.4.5 Coding of GPRS/EGPRS Logical Channels

Regarding the coding of packet switched logical channels, the following considerations
are necessary:
• Packet Data Traffic channels (PDTCHs) use:
– coding schemes from CS1 to CS4 in cases of support of the GPRS technology;
– coding schemes from MCS1 to MCS4 in cases of support of the EGPRS tech-
nology with GMSK modulation;
– coding schemes from MCS5 to MCS9 in cases of support of the EGPRS tech-
nology with 8PSK modulation;
• for all the packet control channels, with the exception of the PRACH and PTCCH/U,
the CS1 coding scheme is always used;
• both PRACH and PTCCH/U use access bursts; for access bursts, two coding
schemes are specified (8 bit coding and 11 bit coding, see the chapter: "9.8.2.1 8
Bit or 11 Bit Uplink Access").
78 A30808-X3247-M24-5-7618
System
• PTCCH/D is coded using the CS1 coding scheme.
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 channel carries packet logical channels only.
The 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 the uplink
direction only, 4 random access bursts.
Sometimes to allow the estimation of the timing advance, instead of transmitting a radio
i block, four access bursts are sent (see the chapter: "9.8.5 Polling Procedures").
It must be noted that the PRACH channel, when it is used in the uplink direction, it’s not
composed of a single block of four frames, but it is composed of 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 configuration’s
actions done by the user or to the direction of transmission. The following configuration
can be used for a single PDCH:
a) the PDCH does not carry the specific GPRS/EGPRS signaling (for example PBCCH
and PCCCH channels);
b) the PDCH carries both PBCCH and PCCCH channels;
c) the PDCH carries GPRS/EGPRS common signaling (for example PCCCH) but not
the PBCCH channel.
4.5.1 PDCH without the Specific GPRS/EGPRS Signaling

When the PDCH does not carry GPRS/EGPRS specific signaling, the following state-
ments are significant:
• in the downlink direction (see next 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 parameter TFI (Temporary
Flow Identifier);
PDCH Multiframe (downlink direction)
PDTCH/D PACCH/D PACCH/D PDTCH/D PDTCH/D PDTCH/D
Fig. 4.14 Mapping of Logical Channels into DL Physical Channel
• in the uplink direction (see the "Fig. 4.15 Mapping of Logical Channels into UL
Physical Channel") all blocks can be used as PDTCH/U or PACCH/U: the occur-
rence of the PDTCH/U (and/or the PACCH/U) at the given block(s) Bx (where Bx =
A30808-X3247-M24-5-7618 79
System
B0...B11) in the 52-multiframe structure for a given Mobile Station 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 Mobile Station may transmit a PDTCH block or a PACCH block on any of the
uplink blocks used for the purpose.
The occurrence of the PACCH/U associated to a PDTCH/D is indicated by the
network by polling the Mobile Station to transmit the PACCH/U block (as described
in the chapter:"9.8.4 Relative Reserved Block Period Field (RRBP)".
PDCH Multiframe (uplink direction)
PDTCH/U PDTCH/U PACCH/U PDTCH/U PACCH/U PDTCH/U
Fig. 4.15 Mapping of Logical Channels into UL Physical Channel
4.5.2 PDCH Carrying both PBCCH and PCCCH

When the PDCH carries both the PBCCH and the PCCCH channels, the following state-
ments are significant:
a) DOWNLINK DIRECTION:
– the first block (B0) of the multiframe (see previous Fig. 4.2) is reserved for the
PBCCH channel; the user can also configure up to 3 more blocks as additional
PBCCH. To configure additional blocks as PBCCH blocks, the BSPBBLK attribute
can be configured by the user: this attribute allows the specification of at most four
blocks, following the order: B0, B6, B3, B9.
– the next remaining blocks can be configured for PAGCH, PDTCH/D and
PACCH/D. To configure additional blocks to carry PAGCH, PDTCH/D and
PACCH/D, the BPAGCHR attribute can be configured by the user. This attribute
allows the specification of 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.
The 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 value of the BSPBBLK attribute to 2. It can be noted how the number of blocks
assigned to the logical channels change according to the value of the BSPBBLK
attribute.
In this example, since three blocks are always dedicated to the PBCCH channel, at
most 9 blocks can be dedicated to the PAGCH channel by the BPAGCHR parameter.
b) UPLINK DIRECTION:
– in the uplink direction, each block can be used as PRACH, PDTCH/U and
PACCH/U; the BPRACHR attribute allows the user to indicate how many blocks
must be reserved in a fixed way to the PRACH channel. The user can reserve up
to 12 blocks (i.e., all the multiframe) for the PRACH channel. Remember that in a
PRACH block, 4 random access bursts are always sent.
The Fig. 4.17 shows an example of one PDCH carrying PRACH channel; note how
the blocks assigned to the logical channels change according to the value given to
the BPRACHR attribute.
80 A30808-X3247-M24-5-7618
System
BSPBBLK BPAGCHR BO B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11
2 0
2 1
2 2
2 3
2 4
2 5
2 6
2 7
2 8
2 9
2 :
PBCCH
PAGCH + PDTCH + PACCH
PAGCH + PDTCH + PACCH + PPCH
Fig. 4.16 Example of DL Configuration with PBCCH and PCCCH Channels
A30808-X3247-M24-5-7618 81
System
BPRACHR BO B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11
0
1
2
3
4
5
6
7
8
9
10
11
12
PRACH
PRACH + PDTCH + PACCH
Fig. 4.17 Example of Uplink Configuration with PRACH Channel.
The value of the BSPBBLK and BPAGCHR attributes shall be set in such a way to have
i at least one block of any type:
- PBCCH, PPCH, PAGCH dor Downlink;
- PRACH and PDTCH/PACCH for Uplink.
For instance, if BSPBBLK is set to “1”, the maximum value for BPAGCHR is “9”.
4.5.3 PDCH Carrying PCCCH

When the PDCH carries the PCCCH channel (without the PBCCH one), the following
statements have to be considered:
a) DOWNLINK DIRECTION:
– up to 12 blocks can be configured for PAGCH, PDTCH/D and PACCH/D; to
configure blocks to carry PAGCH, PDTCH/D and PACCH/D, the BPAGCHR
attribute can be configured by the user. This attribute allows the specification of
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 the uplink direction each block can be used as PRACH, PDTCH/U and
PACCH/U; the BPRACHR attribute allows the user to indicate how many blocks
must be reserved in a fixed way to the PRACH channel. The user can reserve up
to 12 blocks (i.e., all the multiframe) for the PRACH channel. It is important to
outline that in a PRACH block, 4 random access bursts are always sent.
82 A30808-X3247-M24-5-7618
System
4.6 Packet Timing Advance Estimation

The packet timing advance estimation procedure is used to derive the correct value for
timing advance that the Mobile Station has to use for the uplink transmission of radio
blocks.
The timing advance procedure is organized into 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 Assign-
ment (see the chapter: "9.8 Access to the Network (Establishment of a TBF)") then
carries the estimated timing advance value to the Mobile Station. This value is used for
the uplink transmissions until the continuous timing advance update provides a new
value (see the chapter: "4.6.2 Continuous Timing Advance Update").
When Packet Downlink 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.
To get a valid timing advance value, the continuous timing advance update procedure
has been introduced by the specification (see the chapter: "4.6.2 Continuous Timing
Advance Update"). Since this procedure could create some delays between the packet
downlink assignment message and the beginning of the data transfer in downlink direc-
tion, in order to reduce the time between a packet downlink assignment message and
the effective beginning of downlink data transmission, a specific polling procedure is
executed to get the timing advance value.
This polling procedure is basically the following (The chapter: "9.8.5 Polling Procedures"
describes more details about it):
1. With the Packet Downlink Assignment message the network polls the MS to send a
Packet Control Acknowledgment message formatted as four access bursts.
2. The network calculates the initial timing advance value from these access bursts.
3. The network, by means of the PACKET TIMING ADVANCE/POWER CONTROL
message, sends to the MS the calculated timing advance value.
4.6.2 Continuous Timing Advance Update

The Mobile Stations in Packet transfer mode use the continuous timing advance update
procedure.
This procedure is carried on the PTCCH allocated to the Mobile Station. The following
statements have to be considered:
• For the uplink packet transfer within the Packet Uplink Assignment the network
assigns to the Mobile Station (besides the USF and the TFI) the parameter: Timing
Advance Index (TAI) and a PTCCH channel.
A30808-X3247-M24-5-7618 83
System
• For the downlink packet transfer, within the Packet Downlink Assignment, the
network assigns to the Mobile Station (besides the TFI) the parameter: Timing
Advance Index (TAI) and a PTCCH channel.
The TAI parameter specifies the PTCCH channel that the Mobile Station will use.
On the uplink, the Mobile Station sends an access burst in the assigned PTCCH/U,
which is used by the network to derive the timing advance value.
The network analyzes the received access bursts and determines a new timing advance
value for all the Mobile Stations performing the continuous timing advance update
procedure on that PDCH. The new timing advance value is sent via a downlink signaling
message (TA-message) on PTCCH/D. The network can also send the timing advance
information within the Packet Timing Advance/Power Control and Packet Uplink
Ack/Nack messages on the PACCH.
The Fig. 4.18 shows the mapping of both the uplink access bursts and the downlink TA-
messages on groups of eight 52- multiframes:
• the TAI value shows the position where a slot is reserved for a Mobile Station to send
an access burst in the uplink direction (e.g., TAI= 1 identifies 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 Mobile Stations and it is composed of
a radio block sent over four frames.
For example:
– the Mobile Stations 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 Mobile Stations 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 trans-
mitted in the downlink direction in terms of a radio block, distributed on the frames
number 16, 18, 20 and 22.
84 A30808-X3247-M24-5-7618
System
Fig. 4.18 Continuous Timing Advance Update Feature
The continuous timing advance update procedure could create some delays between
i the packet downlink assignment message and the beginning of the data transfer in the
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 has to be executed (see the chapter: "9.8.5 Polling Procedures" for
more details about the procedure).
4.7 Multislot Configuration

Multiple packet data traffic channels can be allocated to the same Mobile Station. This
is referred to as the “multislot packet” configuration. In this configuiration one Mobile
Station may use multiple PDTCHs in parallel for individual packet transfer.
The network may allocate to a Mobile Station:
– 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 Mobile Station. The PACCH may be mapped onto any of the
allocated PDCHs.
When a multislot configuration is used, a certain number of timeslots (PDCHs) are allo-
cated to the same Mobile Station, accordingly 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);
A30808-X3247-M24-5-7618 85
System
– Mobile Allocation Index Offset (MAIO);

– Hopping Sequence Number (HSN);
Regarding frequency hopping for GPRS/EGPRS services, both Base Band
i 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 Mobile Station supports the configuration of multiple timeslots,
it will belong to a multislot class as defined in the Tab. 4.6 (only the first 12 classes are
represented in the table):
Multislot Maximum number of slots Minimum number of slots

class
Rx_max Tx_max Sum Ttb Tra
1 1 1 2 2 4
2 2 1 3 2 3
3 2 2 3 2 3
4 3 1 4 1 3
5 2 2 4 1 3
6 3 2 4 1 3
7 3 3 4 1 3
8 4 1 5 1 2
9 3 2 5 1 2
10 4 2 5 1 2
11 4 3 5 1 2
12 4 4 5 1 2
Tab. 4.6 Mobile Station Multislot Classes
where the fields: “Rx_max, Tx_max, Sum, Ttbm, Tra” have the following meaning:
– Rx_max describes the maximum number of timeslots that the Mobile Station can
use per TDMA frame in the downlink direction. It shall be able to support all integer
values of timeslots (from 0 to Rx_max) in the downlink direction;
– Tx_max describes the maximum number of timeslots that the Mobile Station can
use per TDMA frame in the uplink direction. It shall be able to support all the integer
values of timeslots (from 0 to Tx_max) in the uplink direction;
– Sum is the total number of uplink(Tx) and downlink(Rx) timeslots that the Mobile
Station can use per TDMA frame (when it has established a TBF in both the direc-
tions). The MS must be able to support all combinations of integer values of Rx and
Tx timeslots where; 1 <= Rx + Tx <= Sum , Rx<=Rx_max and Tx<=Tx_max;
– Ttb relates to the time needed for the Mobile Station to get ready to transmit. This
minimum requirement is used when adjacent cell power measurements are not
required by the service selected. For type 1 Mobile Station it is the minimum number
of timeslots that will be allowed between the end of the last previous received
86 A30808-X3247-M24-5-7618
System
timeslot and the first next transmit timeslot or between the previous transmit timeslot
and the next transmit timeslot when the frequency is changed in between;
– Tra relates to the time needed for the Mobile Station to perform adjacent cell signal
level measurement and get ready to receive after it has transmitted in the uplink
direction. For type 1 MS it is the minimum number of timeslots that are allowed
between the previous transmit or receive timeslot and the next receive timeslot when
measurement is to be performed between. For type 2 MS it is the minimum number
of timeslots that are allowed between the end of the last receive burst in a TDMA
frame and the first receive burst in the next TDMA frame.
Type 1 Mobile Station are not required to transmit and receive at the same time,
i whereas Type 2 Mobile Station are instead required.
The Fig. 4.19 shows an example regarding a Mobile Station with multislot class=8: the
MS has established concurrent TBFs, and it has 4 timeslots in the downlink direction and
1 timeslot in the uplink direction (between downlink and uplink TDMA frames there is a
temporal offset of 3 timeslots). When the Mobile Station has monitored its last downlink
timeslot, it shall wait Ttb timeslots (i.e., 1 timeslot) before transmitting; after having
transmitted in the uplink direction, it shall wait Tra timeslots (i.e., 2 timeslots) before
starting to monitor on the downlink direction.
Mobile Class = 8
Rx = 4
Tx = 1
Sum = 5
Ttb= 1
Tra = 2
TDMA frame - Downlink
0 7 0
d d d d d d
u 7
0 7
TDMA frame - Uplink
Ttb Tra
Fig. 4.19 Example of Multislot Configuration
4.7.2 Mapping of Uplink Packet Traffic Logical Channels

The PDCHs where the Mobile Station may expect occurrence of its PDTCH/U(s) or
PACCH/U for a originated transfer is indicated in the resource allocation messages. The
PACCH/U is allocated respecting the resources allocated to the Mobile Station and to
its multislot class.
For each PDCH allocated to the Mobile Station, an USF value is assigned to it.
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).
A30808-X3247-M24-5-7618 87
System
– 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 Mobile Station may expect occurrence of its PDTCH/D(s) or
PACCH/D for a mobile terminated transfer is indicated within the resource allocation
messages.
The logical channel type is indicated in the block header. The Mobile Station owner of
the PDTCH/D or PACCH/D is indicated by the related TFI parameter (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.
88 A30808-X3247-M24-5-7618
System
5 Radio Resources Management

The PTPPKF Functional Managed Object models point to point packet data services in
a cell.
The point to point data services are related to:
• GPRS services: Packet switched data services using the traditional GMSK modula-
tion;
• EGPRS services: Packet switched data services using the 8PSK modulation in the
existing GSM network.
The creation of a PTPPKF Mnaged Object for a specific cell can be done by the user
from the Radio Commander and also from the LMT Evolution only if:
– the BTS Managed Object has been already created for the cell;
– at least one PCU (see the chapter: "6 Hardware and Software Architecture") has
been created;
– at least one permanent virtual connection (see the chapter: "7 Gb Interface") has
been configured for the PCU.
The operator can configure, according to his needs, the radio resources of the cell either
during or after having enabled the GPRS/EGPRS services in that 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 (for
example the PDCH channels), shared by GPRS/EGPRS Mobile Stations, are taken
from the common pool of physical channels available in the cell. The allocation of phys-
ical channels to the circuit switched services and packet switched services is done
according the following two principles:
• Master-slave concept: at least one PDCH channel, acting as a master, accommo-
dates:
– the packet broadcast channel (PBCCH);
– the packet common control channel (for example PCCCH);
– user data and dedicated signaling (for example PDTCH and PACCH).
Other PDCH channels, acting as slaves, are used for both user data transfer and
dedicated signaling only (PACCH channel).
The master-slave concept is only valid when the control signaling is carried on the
PCCCH channel. If control signaling is carried by the existing CCCH channel, the
concept is not more valid.
• Capacity on demand concept: the GPRS/EGPRS does not require permanently
allocated PDCH channels. The allocation of capacity for these services is based on
the needs for the packet transfers which is here referred to as the "capacity on
demand" principle.
The user can decide to dedicate permanently or temporarily some physical
resources (for example the PDCH channels) to the packet switched data traffic.
When the PDCH channels are congested due to GPRS/EGPRS traffic load and
more resources are available in the cell, the network can allocate more physical
A30808-X3247-M24-5-7618 89
System
channels as PDCH channels. However, the existence of PDCH channels does not
imply the existence of PBCCH/PCCCH.
When no PBCCH/PCCCH channel is allocated in the cell, all GPRS/EGPRS attached
i Mobile Stations camp on BCCH/CCCH channel. When the PCCCH channel is allocated
in a cell, all GPRS/EGPRS attached Mobile Stations camp on it.
The PCCCH channel can be allocated either as the result of the increased demand for
the packet data transfers or whenever there are enough available physical channels in
the cell (to increase the quality of service). When the capacity of PCCCH channel is
inadequate, it is possible to allocate additional PCCCH resources on one or several
PDCH channels (see the chapter "6.4 Packet Switched Services Supported on
CCCH/PCCCH").
According to the previous concepts, the user can adopt different strategies to configure
packet switched data services in a cell; for example he/she can:
a) reserve at least one static timeslot for GPRS/EGPRS specific signaling, and
configure other dynamic timeslots (shared with circuit switched services) for
GPRS/EGPRS data;
b) reserve at least one timeslot for GPRS/EGPRS specific signaling, and configure
other static timeslots (shared with circuit switched services) for GPRS/EGPRS data;
c) not reserve any timeslot for GPRS/EGPRS specific signaling, and configure some
static timeslots for GPRS/EGPRS data;
d) not reserve any timeslot for GPRS/EGPRS specific signaling, and configure some
dynamic timeslots for GPRS/EGPRS data;
e) not reserve any timeslot for GPRS/EGPRS specific signaling, and configure both
some static and some dynamic timeslots.
In case DTM feature is enabled in the network, Radio Resource Management supports
it with some enhancements described in the manual: “TED:BSS Common”.
5.1 Radio Channel Allocation Strategy

The decision to allocate a channel to support a call is taken by the BSC. This decision
is based on the idle channel measurements performed by the BTS.The received signal
level of each idle traffic channel of a BTS is measured periodically. This can be
enabled/disabled setting a specific attribute. Based upon this measured uplink interfer-
ence level, which is an indicator of the quality of a channel when it is allocated, each idle
traffic channel of a BTS is classified and assigned to one of five interference bands
(according to the Recommendation GSM 08.08, Section 3.1.3.1, 3.2.24; GSM 05.08
App A 3.1.e).
Band 1 contains channels with a low interference level (high quality), whereas Band 5
contains channels with a high interference level (low quality). No interference measure-
ments are carried out on the control channels which are used during the call setup
signaling. A traffic channel which has just become idle (i.e. the results of interference
measurements are not yet available) is classified as a Band 5 channel. The boundaries
of these interference bands can be configured by means of specific attributes. The result
of the classification is transferred periodically to the BSC, where it is used for the
channel allocation decision: the channel with the best available quality is selected.
90 A30808-X3247-M24-5-7618
System
5.2 Radio Resource Allocation Strategy

In the previous BSS Release the channel allocation procedures took into consideration
only the best interference band and not the related services. The user had the possibility
to choose the call policy for the resource allocation (for example the data call on the
BCCH carrier and the speech call on non BCCH carriers or vice versa) and also the
strategy to avoid or, in the worst case, to reduce congestion’s situations. A high flexibility
for power control and handover algorithms has been also provided by the configuration
of the RXLEV and RXQUAL thresholds for the handover and by the relevant Power
Control thresholds for the Enable/Disable flag independently for each Circuit Switched
(CS) service.
In the current BSS BR8.0 Release the allocation of the radio resources has been
improved. The enhancements provide the customers a way to define a strategy for the
radio resources’ allocation process on cell basis realizing the best compromise between
the services supported and provided by the cell and the requested radio quality.
The enhancement is based on three new concepts defined on cell base:
• Layer: It represents a group of radio resources with the same expected radio quality.
It is configurable on TRX base (each TRX belongs to a layer only). In case of conc-
ncetric cells, extended cells or in case of dual band standard cells, a layer could have
mixed channels (channels belong to inner/complete area, BCCH/no-BCCH band,
single/double). The user can decide to group TRXs having the same expected radio
quality in different layers, to support for example a service only on a subset of TRXs,
or to reserve them for a particular service;
• Service List: It is the list of services supported by the cell and contains for each entry
a reference to one service type. In case the cell is a dual area (Extended and
Concentric single band/dual band) two service lists are defined: Service List Primary
Area (SLPA), Service List complementary area (SLCA inner/near). For all other cells
different from dual area, only SLPA is defined;
• Service Layer List: It is a list of layers in decreasing priority order for searching of
channels’ allocation. A service is supported in a cell only if a Service Layer List (SLL)
is assigned to this service.
The following service’s types are defined:
• Signaling (SDCCH): It is used for services requiring only Signaling Channels (for
example: SMS, Call setup, Location Services);
• CS speech: It is used for speech call applying EFR- FR- HR codec;
• CS speech AMR FR: It is used for speech call applying AMR FR codec;
• CS speech AMR HR: It is used for speech call applying AMR HR codec;
• CS data: It is used for Circuit switched single slot data call allowed to use up to 9.6
Kb/s and 14.4 Kb/s coding;
• HSCSD: It is used for Circuit switch Multislot calls supported by HSCSD; •GPRS:
PDCH to be allocated dynamically to GPRS services;
• EGPRS: PDCH to be allocated dynamically to EGPRS services;
• ASCI: Broadcast channel to be used for allocating ASCI VBS/VGCS services.There
are two lists in a cell: SPLA and SLCA. For the Standard and Dual Band Standard cells
only SLPA is significant.
A30808-X3247-M24-5-7618 91
System
In case the cell is Standard, Extended (far area), Concentric (complete area), Dual Band
Standard, the list is SLPA, with the following services:
0) CS EFR FR HR;
1) CS AMR FR;
2) CS AMR HR;
3) CS DATA;
4) HSCSD (not present in case of extended cell);
5) GPRS;
6) EGPRS;
7) ASCI;
8) signaling.
If the cell is extended (near), Concentric (inner), the list is SLCA, with the following
services:
0) CS EFR FR HR;
1) CS AMR FR;
2) CS AMR HR:
3) CS DATA;
4) HSCSD;
5) GPRS (not supported in case the cell is concentric);
6) EGPRS (not supported in case the cell is concentric);
Each TRX has a number of layer associated. For each supported service, a Service
Layer List (SLL) shall be associated. A maximum of 12 Layers (LY0..11) for each cell
can be allocated by the user, that is in case of dual area cells the total number of levels
remains 12. The user on his/her own needs could group the TRXs providing the same
expected radio quality in different layers, to support for example a service only on a
subset of TRXs, or to have them reserved for a particular service.
When a resource is required, it shall be noted that the service has a SLL associated. In
case of single slot circuit call if the first LY in the SLL is congested the second one is
checked and so on till a resource is found. If the CS speech mobile support more that
one speech codec (for example AMR, no-AMR) and two rate for every codec (Full/Half
), and the mobile supports also Full both codec, the search is triggered in more SLL in
the following order, until the free channel is found:
a- one Full channel in CS AMR FR SLL;
b- one Half channel in CS AMR HR SLL;
c- one Full Preferred in CS EFR FR HR SLL (in every SLL layer, it is searched first one
Full Channel and then Half channel).
In general for every service, with the exception of packet services, if the required service
and the mobile position allowed and the cell is dual area, first the channel in SLLs of the
SLCA is searched, and then in SLLs of SLPA.
In case no resources are available for that service, the request is satisfied applying the
existing procedures (standard Service Dependent Channel Allocation). The downgrade
of the incoming call is applied only when the required multislot configuration is not found
in the complete SLLs .
92 A30808-X3247-M24-5-7618
System
In case of multislot circuit calls, the channels are searched in SLL for finding the better
configuration (higher throughput maximum), consequently the call can be served in a
layer that could not be preferred even if the first one is not congested. If the cell has dual
area and the Mobile Station can be served in both area in base to radio condition/posi-
tion, primary and complementary, the channels are searched first in complementary
area trying to find the better configuration; in case this area is in congestion, channels
are searched in primary area.
In case of packet calls, a layer could be preferred with respect to an higher priority one
if a better choice is found.
When the cell is a dual band standard cell, the Mobile Station request is served
according to SLL and MS capabilities. Therefore if the best layer for a service belongs
to the non-BCCH band only, the single band MSs are never be served in preferred layer
If for a specific service the allocated resources are not on the best layer (LY) with refer-
ence to the SLL (primary or complementary), the system tries as soon as there are avail-
able resources in a better LY to reorganize them. When possible (this is the case of
circuit services only), the allocation has to be changed in order to move the MS on the
LY with better priority of the SLL having free resources or in order to restore the original
HSCSD multislot configuration required; this means that the subarea in a cell will not be
changed due to the fact that the best layer is not found.
When the cell is a dual band standard cell the moving in a better level is possible only if
the available resources are compatible with the Mobile Station.
Each customer can therefore choose the best layer(s) for each service on the basis of
its radio planning and/or on the basis of its own network configurations needs or consid-
erations. Each TRX is related to a layer by means of configuration commands. In case
of single slots circuit calls, if the first layer in the Service Layer List (SLL) is congested,
the second layer is immediately checked and so on till a resource is found free. In case
of multislots circuit calls another layer could also be chosen also if there is no conges-
tion, for example when a better configuration is requested. Besides it is important to try
to serve each request in the highest Layer priority for the involved service.
To support the concept of Service List and Layer the following additional checks have
been implemented in the system:
- Dedicated layers for Packet Switched (PS) services and Circuit Switched (CS) data
multislot shall be at the highest priority in the correspondent Service Layer List (SLL);
- The Service Layer List (SLL) of signaling shall be ordered according the layers
“more shared” between CS services and signaling, when the Direct Assignment is
enabled.
This check has been instead removed in presence of at least one Layer shared between
CS and signaling when Direct Assignment feature is enabled.
In case of far area of extended cell, at least one double TS has to be configured to
i support the CS services and at least 2 singles TSs to support the EGPRS/GPRS
services.
In the following it is described in which way the resources have to be assigned by the
system for each type of cell and for Packed Switched (PS) data calls. Only Concentric
cells and Extended cells are associated to two different areas as summarized in the
following table:
A30808-X3247-M24-5-7618 93
System
Cell Type Primary Area Complementary Area
Concentric Cell Complete Inner

Extended Cell Inner Near
Tab. 5.1 Types of cells in relation to the different types of Area
1) STANDARD CELL:
If the cell is a standard cell, according to the Packet Switched (PS) services supported
in this cell, one Service Layer List per type of services is configured.
The search can be done in both EGPRS and GPRS Service Layer List.
In case the request is coming from a GPRS only capable Mobile Station, only the GPRS
list is considered for the allocation of resources.
In case the request is coming from an EDGE capable Mobile Station, the search can be
done in both the Service Layer Lists.
If the Mobile Station has EGPRS Capability and EGPRS is supported in the cell/cell area
(in case of Extended cell) then the EGPRS service is chosen and the configuration is
searched in the EGPRS Service Layer List. Otherwise the GPRS service is chosen and
the configuration is searched in GPRS Service Layer List. In case the configuration for
the EGPRS service is not found then the GPRS service is chosen and the configuration
is searched in the GPRS Service Layer List.
2): CONCENTRIC CELL:
If the cell is concentric, according to the Packed Switched (PS) services supported in
this cell, due to the fact that EGPRS/GPRS services can be supported only in the
complete area of the concentric cell, one Service Layer List per type of service has to
be configured (SLPA). The behaviour is the same as for a standard cell according to the
Packet Switched (PS) services supported in this cell and therefore it is not described
again.
3) EXTENDED CELL:
If the cell is an extended cell, according to the Packed Switched (PS) services supported
in this cell, two Service Layer List per type of service shall be configured.
When for a service there are both SLPA and SLCA lists, the search is done in the first
or the second one depending on the availability of the information related to the position
of the MS (Timing advance):
- UpLink request: the SLCA or SLPA is defined according to the Timing Advance;
- DownLink request:
1. if concurrent UL, the list is that already used for the UL direction;
2. if no concurrent UL, the list is the SLPA (far). In case of subsequent establishment
of concurrent UL, the resources will be allocated in the same area of UL direction (for
example if DL is allocated in far and then a concurrent UL is established in near area,
also DL is re-configured in near area).
Within the same area the behaviour already described for a standard cell is applied to
define the first list (EGPRS SLL or GPRS SLL) to be considered in the allocation proce-
dure. In case the resources are not available in the area of interest no change of the area
is at the moment foreseen.
94 A30808-X3247-M24-5-7618
System
4) DUAL BAND STANDARD CELL:

In case the cell is a “Dual band standard” the behaviour is the same as for the Standard
cell, but it is possible to define layers on two different bands (for example the following:
900/1800 and 850/1900). The Dynamic Maio Allocation (see the manual “TED: BSS
Common” for details about this feature) can be applied only to layers dedicated to CS
speech services and with frequencies defined within a single band, for example layers
only ‘900 primary band ‘ or ‘900 extended band’ or 1800 or 850 or 1900.
For the reason that it is possible to define the priority order in only one Service Layer List
including both bands (for example it can be defined the preferred band for each type of
service), the parameter: “Pref_Band_Db_MS” has no more meaning and therefore it has
been removed.
Between the nine type of services in the Service List, following services are specific for
GPRS/EGPRS technology:
GPRS service: The PDCH shall be dynamically allocated for supporting the GPRS
services.
EGPRS service: The PDCH shall be dynamically allocated for supporting the EGPRS
services.
This feature maintains the compatibility with the previous releases where the concept of
layers have not been implemented. This compatibility is reached by assigning all the
available TRX(s) to the same layer; in this way only one default Service Layer List
(SLL0) is defined.
For each cell the Service List (SL) is created on cell basis in the BTS Managed Object
during its configuration, by assigning to each entry a service type and a list of layers to
supporting it. The type of services are added/removed to/from the list by means of the
“SET” command without service interruption, both from the LMT Evolution and from the
Radio Commander. If one service is not present in the Service List this service is not
supported in that cell.
If for a service it is already foreseen an enabling/disabling flag, the system accepts to
change the flag to enable only if a Service Layer List (SLL) is associated to that service;
A service can be deleted from the Service List only if the relevant enabling/disabling flag
is set to false.
Eighteen new attributes have been introduced to the BTS Managed Object for config-
uring the SLL. The first group (nine attributes) specifies the list of TRX layers related to
each of the services in a single band standard cell, or in the complete/far area of a dual
area cell (extended, concentric single/dual band), or in the BCCH band of a dual band
standard cell. For GPRS service, the new attribute is: GLLPRM (GPRSLayerListPri-
mary). For EGPRS service, the new attribute is: ELLPRM (EDGELayerListPrimary).
The second group (nine attributes) specifies the different services supported in the
inner/near area of dual area cell (extended, concentric single/dual band), or in the
complementary band of a dual band standard cell. For GPRS service, the new attribute
is: GLLCOM (GPRSLayerListComplementary). For EGPRS service, the new attribute
is: ELLCOM (EDGELayerListComplementary).
To disable a service no cross checks between the Service List and the enabling flags
are foreseen because the user may use the enabling flag to switch off the feature tempo-
rary. Of course it has to be taken into account that when the user decides to assign
Layer only for a specific service, if the service is switched off by means of the corre-
sponding enabling/disabling flag, the resources allocated only for that service are kept
A30808-X3247-M24-5-7618 95
System
reserved and therefore can not be used (this situation may also happen if a configured
layer is not included in any service list); to assign the group of radio resources
supporting EGPRS/GPRS services to which the TRX belongs, the new attribute
LAYERID (LY0..LY11) has been added to the TRX Managed Object. Up to 12 layers are
supported in the cell.
Besides to avoid inconsistency in the system, the change of the TRX layer attribute is
done only if the TRX Managed Object is in the “Locked” State, moreover in order to
avoid as far as possible eventual call drops, the shutting down command is recom-
mended.
A new layer is added or removed from its corresponding Service Layer List by means of
the SET command launched from the LMT Evolution or from the Radio Commander
without service interruption. Also the priority of one Layer inside the SLL can be
increased or decreased by means of the SET command without service interruption. In
case a new layer is added to the SLL or it has changed its priority within the SLL, the
resource reallocation process shall be informed of the operation, in order to take it into
account and to try to rearrange the distribution of the active services in the right Layer
when it is periodically activated. The resources reallocation process in the BSC uses the
forced intracell handover in order to rearrange the resources inside the cell.
Within a Layer all channels that shall be assigned to the EDGE services shall be allo-
cated on carrier unit that are EDGE capable. For the purpose the user shall check the
existing attribute “TRXMD” of the corresponding TRX Managed Object indicating the
EDGE support in order to be sure that a layer is really compatible with the service. For
example it contains at least one EDGE TRX if the layer is not exclusive for the EGPRS,
or all the TRXs in the layer are EDGE capable if the service is exclusive for the EGPRS.
For the Packet Services (PS) the PCU is informed of the layers to which the TRXs are
related, as well as if a TRX is reserved for the packet services only, and it knows also
the Service Layer Lists for the packet services, for resource allocation proposals to the
TDPC processor.
When a downgrade of an ongoing packet call is requested, the PCU receives in the
request for downgrading the information about the preferred layers in order to be able
to optimize the downgrading, when possible.
As far as the number of reserved PDCH per cell are concerned, for GPRS service they
are indicated by the attributes GMANPRESPRM (Maximum Number of traffic channels
reserved for packet connections, exclusively on the first layer shared by GPRS and CS
service in Primary Area. It is related to far area in extended cell) and GMANPRESCOM
(Maximum Number of traffic channels reserved for packet connections exclusively on
the first layer shared by GPRS and CS service in Complementary Area. It is related to
near area in extended cell) related to the PTPPKF Managed Object. In case of standard
cell, only GMANPRESPRM is meaningful. For EDGE service, they are indicated by the
attributes EMANPRESPRM (Maximum Number of traffic channels reserved for packet
connections, exclusively on the first layer shared by EDGE and CS service in Primary
Area. It is related to Far area in extended cell) and EMANPRESCOM (Maximum
Number of traffic channels reserved for packet connections, exclusively on the first layer
shared by EDGE and CS service in Complementary Area. It is related to Near area in
extended cell) related to the PTPPKF Managed Object. In case of standard cell, only
EMANPRESPRM is meaningful. These attributes substitute the current GMANPRES
and EMANPRES attributes. The traffic channels are on the first layer shared by Packed
Switched (PS) and Circuit Switched (CS) services. In case this first shared layer is
96 A30808-X3247-M24-5-7618
System
common to the CS and PS services, the number of reserved PDCHs per cell is calcu-
lated as the sum of the contribution given by the mentioned attributes.
In case the user reserves a layer for packet services only, these channels being already
not preemptable by the Circuit Switched shall not be count among the ones indicated by
the corresponding attributes. The user shall in any case guarantee that the layers dedi-
cated to the Packet Services (PS) only (as well as the ones reserved for CS data multi-
slot) are included as the first ones in the relevant Service Layer List.
With reference to the strategy to apply the Horizontal/Vertical allocation in the system,
the same concept as implemented for the previous releases applied, taking into account
that it is possible to have dedicated layers for packet services (for example statically
reserved channels) therefore the reserved (E)GPRS channels in the cell shall now be
considered as the sum of the “dynamically” reserved plus the “statically” reserved ones.
This means that the Vertical Allocation (VA) will never start till there are reserved chan-
nels available.
As a consequence of the introduction of SLL concepts, on TRX Level the attribute Gsup
(Gprssupported) that specifies if TRX is enabled or not to support GPRS is obsolete and
therefore has been removed. Also the attribute Cpolicy (CallPolicy) in BSC Basic
Package is obsolete and has been removed too.
All Managed Objects and attributes related to the enhancements of Service Dependent
Channel Allocation strategy are described in detail in the manual :BSS CML.
5.3 Multiband Operations

The Multiband operation enables a customer with licenses in more than one of the
frequency bands specified by GSM to support the use of multiband Mobile Stations. This
feature introduces additional handovers between the different frequency bands. A multi-
band mobile network distributes neighbor cell lists towards the Mobile Stations. The lists
contain a mixture of channels from different frequency band.
An example of Multiband GSM mobile network is represented in next Fig. 5.1.
A30808-X3247-M24-5-7618 97
System
BSC
BSC
MSC/VLR
BTS BTS BTS BTS

GSM 1800 GSM 900 GSM 900 GSM1900
BTS BTS
GSM 1800 GSM1900
BTS BTS
GSM 1800 GSM1900
Fig. 5.1 Multiband GSM mobile network
The multiband Mobile Station is able to monitor all channels within the neighbor cell list
which are within the bands of operation of the Mobile Station. The adjacent cell
measurements are transferred to the BSS which is then able to perform handovers
between the different bands. In conjunction with the enhanced traffic management
(Hierarchical Cell Structure) the user is able to retain or redirect the traffic to a preferred
band or a preferred layer. A multiband mobile network still supports single-band Mobile
Stations in each of the bands of operation.
A customer whose system is implemented in multiple frequency bands has the following
benefits:
• Capacity increase in hot spot areas through additional frequency spectrum alloca-
tion by adding for example a GSM 1800 BTS into a GSM 900 mobile network.
• Enhanced coverage by adding e.g. new GSM 900 cells to a GSM 1800 network.
• Capacity increase in hot spot areas through additional frequency spectrum alloca-
tion by adding e.g. GSM 1900 BTS into a GSM 900 mobile network.
• Enhanced coverage by adding e.g. new GSM 900 cells to a GSM 1900 network.
• Capacity/coverage gain without affecting the existing radio planning.
• Enhanced opportunity for roaming, using multiband Mobile Stations.
• Customer service enhancement due to the coexistence of single-band and multi-
band Mobile Stations.
• Cost-effective network expansion and flexible capacity rollout, resulting from infra-
structure and equipment sharing for BTS sites, BSC sites and transmission lines.
5.4 Dual Band Standard Cell

Multiband cells with a common BCCH channel based on the Concentric Cell configura-
tion are still supported in current BSS BR 8.0 release. It is based on one band for each
98 A30808-X3247-M24-5-7618
System
area, that means that the BCCH band is in the complete area and no-BCCH band is in
the inner area.
In the current SBS BR8.0 Release it has been introduced a new type of cell that supports
frequencies in two different frequency bands and the BCCH channel in one of these
bands (the channel is defined “Common BCCH”). The supported frequency bands are
GSM850/PCS1900, GSM900/DCS1800 and GSM850/DCS1800. The cell’s radius is
assumed to be the same for the two frequency bands, that means that both bands have
well-matching cell borders.The Common BCCH cell has its own cell identity defined as
any single band GSM cell. The new type of cell is defined: “Dual Band Standard Cell”.
This cell is supported only from BR 8.0 BTSs. Packet switched services (PS) can be allo-
cated in both the frequency bands.
The Dual Band Standard cell is very useful from the customer point of view for the main
reason that it can provide packet switched services (PS) allocated in both the frequen-
cies bands; instead with the exclusive support of the GPRS/EGPRS services in the
complete area of a multiband cell with a common BCCH channel, the network capacity
is highly limited.
The radio resource allocation for the “Dual band Standard” cell is performed respecting
the concept of “Service Dependent Channel Allocation Strategy” (see the chapter:
"5.2 Radio Resource Allocation Strategy" for more details) but with an unique Service
List (SLPA-Service Layer Primary Area list), like for the Standard cells, with layers
supporting the TRXs of BCCH frequency band and the TRXs of non-BCCH frequency
band. The search of the radio resources respects the order in the Service Layer List
(SLL) of the service’s type requested by the Mobile Station. For every layer, the poten-
tial channels are that less interferenced and compatible with the capability of the Mobile
Station.
In case the user needs to preserve the resources for single band Mobile Stations, he
/she must configure layers with an unique band (layers with BCCH band separated by
layers with non-BCCH band) and he/she shall assign the layers of the non-BCCH band
as least in the Service Layer List. If the value of the attribute “SysId” is: “GsmDcs” and
the user needs to preserve the resource for phase 1 Mobile Stations, he/she shall split
the TRXs with frequencies in the GSM base band and GSM extended band in different
layers. Then he/she shall assign in the Service Layer List (SLL) first the layers having
GSM extended band and then the layers with GSM base band.
For the configuration of the Dual Band Standard Cell, supporting frequencies in two
bands with a common BCCHl, the range of the attribute: “Celltyp” related to the Func-
tional Managed Object “BTS” includes the value: “DbstdCell (Dual band standard Cell)”.
Besides the specific attribute: ”Gext” related always to the Functional Managed Object
“BTS” specifies if GPRS/EGPRS services can be allowed also in no-BCCH-bands. Its
values are: “Null = GPRS/EGPRS services can be provided only on the BCCH band
frequencies”, “All900 = GPRS/EGPRS services can be provided on 900 Mhz frequen-
cies”, “Allfreq = GPRS/EGPRS” services can be provided on all the bands supported by
the cell”.
A multiband mobile network needs the “2-ter” and “5-ter” System Info messages. These
messages enable the multiband Mobile Stations for accessing the network and, at the
same time, they maintain the compatibility with single band Mobile Stations. The mobile
network shall be notified about the frequency and the related power capabilities of the
multiband Mobile Stations, on each frequency band, to ensure a reliable functionality at
call setup. The Classmark Sending adopted in BR7.0 release is still used in current
BR8.0 release for supporting multiband operations. As soon as the connection is
A30808-X3247-M24-5-7618 99
System
successfully established on the radio interface, a message: “Classmark Change” is sent

in the Uplink direction. This message informs the network about all frequency bands and
related power supported by the Mobile Stations.
For a Dual Band Standard Cell the Service allocation across the radio resources can be
executed with the same procedure specified for the Service Dependent Channel Alloca-
tion, as described in the chapter: "5.2 Radio Resource Allocation Strategy".
The Service List (list of services supported by the cell) stores for each entry a reference
to one type of service. For a Dual Band Standard cell, the Service List (SL) is unique,
that means it is common to both the frequency bands. A list of service layers (SLL), in
decreasing priority order, to be used is then associated to each service supported by
the cell. A layer can support TRXs of either of the frequency bands. As a consequence,
the user can choose the appropriate layers for each service on the basis of the radio
planning and on his/her own considerations.
The radio resources shall be assigned to an incoming mobile within a dual band stan-
dard cell according to the Service Layer List and its capabilities, for example dual band
Mobile Stations shall be allocated on either of the frequency bands, whereas single
band Mobile Stations shall be allocated only on the BCCH frequencies. When a
GPRS/EGPRS Mobile Station accesses the network, the mobile frequency bands of
operation and relative power capabilities are notified to the mobile network within the
“Packet Resource Request” message during the two phase access and within the “Addi-
tional Mobile Station Radio Access Capabilities” message during one phase access.As
a consequence the GPRS/EGPRS Mobile Stations shall be allocated within a Dual Band
Standard Cell depending on the operator policy and again according to the procedures
described in the chapter: "5.2 Radio Resource Allocation Strategy". The Packet data
services (PS) on the non-BCCH frequency band are allowed by associating the
EGPRS/GPRS service with a service layer comprising TRXs of the non-BCCH
frequency band and setting the attribute “Gexts” to its right value.
In case the user needs to prioritize a specific frequency band for any assigned service,
the following actions shall be executed:
• Definition of dedicated layers, with BCCH or non-BCCH band frequency only;
• Definition of mixed layers (mixed means in this context layers composed of BCCH
and non-BCCH frequencies) by means of a specific order of layers within the list
associated to that service. In case a layer stores TRXs of both frequency bands
belonging to the Dual Band Standard cell, the resources are ordered in this layer on
the basis of the interference band they belong to and kept with regards both with this
criteria and with also the Mobile Station capability.
The following example clarifies this concept:
A given service is supported both in 900 MHz and in 1800 MHz band. In this case, the
unique (for both bands) Service Layer List may have in the early positions the 900 MHz
layers (if the user needs to prioritize the 900 MHz band) ordered according to a radio
quality criterion and in the remaining positions the 1800 MHz layers still ordered
according to the same criterion.
In case a layer stores TRXs from both frequencies band of the Dual Band Standard Cell,
the resources are ordered on the basis of the interference band they belong to,
according to the same rules adopted in the previous BR7.0 release.
100 A30808-X3247-M24-5-7618
System
5.5 Enabling Packet Switched Services in a Cell

To enable Packed Switched Services (PS) in a Cell (both EGPRS and GPRS), the first
configuration is related to the setting of the Service Layer List (SLL) for that cell. This list
is created on cell basis in the BTS Managed Object during the configuration phase.
If GPRS service is supported and the list is SLPA (Service List in Primary area) the user
shall set the attribute GLLPRM related to the BTS Managed Object. It is a list (sequen-
ceOf) of max 12 items and each item is trxlayer: LY0..LY11. In case the list is SLCA
(Service List Complementary Area, only for extended cell) the user shall set the attribute
GLLCOM related to the BTS Managed Object.
If EGPRS service is supported and the list is SLPA (Service List in Primary area) the
user shall set the attribute ELLPRM related to the BTS Managed Object. It is a list
(sequenceOf) of max 12 items and each item is trxlayer: LY0..LY11. In case the list is
SLCA (Service List Complementary Area, only for extended cell) the user shall set the
attribute ELLCOM related to the BTS Managed Object.
PS services are then added to the SL list using the SET command. If one service is not
present in the list, it is assumed as not supported in that cell.
For each layer specified in the service layer list, at least one TRX shall be created for it.
For this purpose, the user configures the attribute LAYERID related to the TRX
Managed Object that specifies the group of radio resources to which the TRX belongs.
Up to 12 layers are supported in the cell (LY0..LY11) and each TRX belongs to one layer
only. The layer is inherited by all channels configured in the TRX. During the creation of
the TRX, the user shall also specify if the TRX is enabled to support in general both
packet data services or not. To indicate how the TRX has to be exploited, the TRXMD
attribute is used. It assumes the following values:
• GSM: The TRX supports GSM services and also GPRS if the corresponding layer
has been configured for this service. GSM is the default value;
• EDGE: The TRX supports GSM services and also EGPRS/GPRS if the corre-
sponding layer has been configured for these services.
Besides the PCU shall be informed about the layers the TRXs belong to and also if a
TRX is reserved for Packed Switched only. Also the SLLs for packed services have to
be known by PCU for resource allocation proposals to the TDPC. The attributes GMAN-
PRESPRM (Maximum Number of traffic channels reserved for packet connections,
exclusively on the first layer shared by GPRS and CS service in Primary Area. It is
related to far area in extended cell) and GMANPRESCOM (Maximum Number of traffic
channels reserved for packet connections exclusively on the first layer shared by GPRS
and CS service in Complementary Area. It is related to near area in extended cell)
related to the PTPPKF Managed Object support the number of reserved GPRS PDCH
per cell in Primary and Complementary Area.
The attributes EMANPRESPRM (Maximum Number of traffic channels reserved for
packet connections, exclusively on the first layer shared by EDGE and CS service in
Primary Area. It is related to Far area in extended cell) and EMANPRESCOM (Maximum
Number of traffic channels reserved for packet connections, exclusively on the first layer
shared by EDGE and CS service in Complementary Area. It is related to Near area in
extended cell) related to the PTPPKF Managed Object support the number of reserved
EDGE PDCH per cell in primary and complementary Area.
It is recommended to execute these configuration actions in low traffic conditions in
order to avoid that several calls are not allocated in the preferred layer to be moved, or
A30808-X3247-M24-5-7618 101
System
to avoid to have calls queued that instead should be released because the correspon-
dent service is not more configured in the cell.
The channels reserved for specific packed services shall be on the first layer shared by
EGPRS/GPRS services and Circuit Switched (CS) services. In this case the number of
reserved PDCH per cell is calculated as the sum of the contribution given by both
attributes. In case the user reserves a layer to support PS services only, these channels
being already preemptable by CS services are not counted among the ones related to
gmanpresprm,gamnprescom/emanpresprm,emanprescom attributes. It shall be guar-
anteed that the layers reserved for PS services only are included in the relevant Service
Layer List (SLL).
The Gsup attribute on TRX level that specifies if the TRX is enabled or not to support
GPRS services is not more used in current BR8.0 release due to the fact that all TRXs
whose layers have been configured as usable for supporting EGPRS/GPRS services
are to be GPRS supporting. Consequently GSUP has been removed from BSS Informa-
tion Model.
To disable the packet data services on a specific TRX, the user shall change the layer
of TRX (this operation could disable also some CS services supported by that TRX). He
could also delete the layer of the TRX from the SLL supporting EGPRS/GPRS services
(this operation disables PS service for all TRXs of removed layer).
5.5.1 Aspects Related to Carrier Configuration

The EDGE capability of a Carrier Unit(CU) is modeled with the read only attribute Trx
Capability. It reflects the real capabilities of the TRX independently of the TRXMD
parameter setting. The attribute can be configured bu the user by means of the
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;
– Unknow: the BSC has no knowledge about the carrier Unit associated to TRX.
The following combinations of Trxmd and Trx Capability are permitted as reported in the
following table:
TRXMD TRX CAPABILITY Meaning
GSM GSM The TRX is working with GSM functionality.

GSM EDGE The TRX is working with GSM functionality
even if the TRX could work with EDGE func-
tioality.
GSM UNKNOWN No CU is related.
EDGE GSM The TRX is working with GSM functionality
since no E-CU is available.
EDGE EDGE The TRX is working with EDGE functionality.
EDGE UNKNOWN No CU is related.
Tab. 5.2 Example of Combinations of Trxmd and Trx Capability values
TRX-CU assignment procedure:
102 A30808-X3247-M24-5-7618
System
The BTSE tries to find an optimal allocation between the required TRX operation modes
and the available CU types according to the following rules:
1. Try to allocate the BCCH TRX to the appropriate CU type;
2. Try to allocate all EDGE-TRX to E-CUs;
3. Try to allocate all GSM-TRX to GSM-CUs;
4. Try to allocate all remaining GSM-TRX to E-CUs;
5. Try to allocate all remaining EDGE-TRX to GSM-CUs (the state of the TRX changes
to enabled-degraded).
Reconfiguration of TRXs due to a change of Functional Configuration:
When TRXs 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 can be caused by:
– creation/deletion of a TRX;
– modification of the TRXMD attribute of a TRX;
– breakdown of CU allocated to BCCH-TRX;
– breakdown of CU allocated to complete area TRX in case of concentric cells;
– commissioning of TRX after breakdown.
In some cases, the changes of the TRX configuration can cause the loss of traffic for
one or two TRX. The user shall avoid the loss of traffic by taking the corrective actions.
Therefore the appropriate configuration procedures have to be performed: Shut-
down/Create/Unlock command sequence.
If the BCCH-TRX is involved in the TRX-CU assignment procedure (it can happen,if an
! EDGE characteristic of BCCH-TRX is modified or if the BTSE-internal optimization algo-
rithm affects the BCCH-TRX), also the whole Cell involved.In this case, a shut-
down/create/unlock procedure can be applied to the whole cell and not only to the single
TRX involved.
In case of Baseband frequency hopping all TRXs involved in the same hopping proce-
i dure must be homogeneus, for example they must have the same Trxmd value. If a TRX
with Trxmd = EDGE gets Trx Capability = GSM (for example due to a reconfiguration)
the hopping for the TRX related to this hopping procedure is stopped in the cell, and the
user is informed with the message: Synthesizer frequency hopping is not affected.
Configuration of BCCH Transceiver for EGPRS:

The message: Egprs Packet Channel Request EGPRS, specific for EDGE Mobile
Stations (see the chapters: "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 this message can be forced by configuring the BCCH-TRX in
EDGE mode, which implies the allocation of an EDGE-CU to the TRX, using the Trxmd
attribute.
The BCCH carrier is continuously transmitted on all timeslots and without variation of RF
level; however, the RF power level can be ramped down between timeslots to facilitate
the switching between RF transmitters. If the 8PSK modulation is used for timeslots of
the BCCH TRX, these timeslots may use an 8PSK mean power which is at most 4 dB
lower than the power used for the GMSK modulated timeslots. So, the use of the 8PSK
modulation on the BCCH carrier is critical and the operator can enable/disable it.
A30808-X3247-M24-5-7618 103
System
By means of the Ebcchtrx attribute, the user 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 the attribute Ebcchtrx is set to FALSE, it means that only
GMSK modulated coding schemes of EDGE is supported on the BCCH-TRX (besides
GPRS coding schemes).
Even if the BCCH TRX is created in EDGE mode for supporting the 8PSK modulation,
i the timeslot 0 is not allowed to use this modulation. This is necessary for compatibility
with Mobile Stations that do not support EDGE, in fact:
- the timeslot 0 is used to transmit system information and signaling.
5.6 Configuration of GPRS Channels in a Cell

After having configured the TRXs supporting GPRS and EGPRS services, the user indi-
cates in which way the slots belonging to these TRXs shall be managed; the following
statements describe in which way the user can configure GPRS/EGPRS services on
TRXs assigned to the corresponding layers:
1. the user can reserve, on a channel basis, some slots to packet switched services
only; these slots are statically allocated to GPRS/EGPRS signaling (PBCCH and
PCCCH) and are not used for circuit switched services. The user can define these
“only GPRS/EGPRS slots” on a channel basis, by setting the GDCH attribute of the
related CHAN Managed Object;
The GDCH attribute can assume the following values:
– PBCCH: the related channel is reserved for packet switched services, and
supports GPRS/EGPRS system information, common signaling, and data;
– PCCCH: the related channel is reserved for packet switched services, and
supports GPRS/EGPRS common signaling, and data.
Only one physical channel can be configured to carry the PBCCH logical
i channel (only one channel can be configured as the PBCCH); if the oper-
ator then needs more PCCCHs, he must configure another channel as
PCCCH.PBCCH and PCCCH channels can be defined on BCCH TRX
only.
2. the user can then configure, among the remaining timeslots, other static timeslots
for PS services (for example not shared with CS services); the user can indicate this
number of traffic channels reserved for packet connections using the GMANPRE-
SPRM/GMANPRESCOM attributes (exclusively on the first layer shared by GPRS
and CS service in Primary and Complementary Area) and EMANPRE-
SPRM/EMANPRESCOM attributes (exclusively on the first layer shared by EDGE
and CS service in Primary and in Complementary Area). All attributes are related to
the PTPPKF Managed Object.
The difference, with respect to the configuration of static slots using the GDCH
attribute is that with GDCH the configuration is made on a channel basis and regards
GPRS/EGPRS signaling channels only, whereas using the GMANPRE-
SPRM,GMANPRESCOM/EMANPRESPRM,EMANPRESCOM attributes the
configuration is made without indicating the channel, but only a “number of reserved
channels for GPRS/EGPRS SLL”, and regards GPRS/EGPRS traffic channels only;
3. the user can choose among the remaining available slots (on TRXs’ layers on which
EGPRS/GPRS is supported) the maximum number of dynamic GPRS/EGPRS
104 A30808-X3247-M24-5-7618
System
channels; these channels are shared between PS and CS services, according to the
current request of resources.
To configure this number of shared slots, the user sets the GPDPDTCHA attribute
related to the PTPPKF Managed Object.
It indicates a percentage applied to the total number of available slots (on TRXs
where GPRS/EGPRS services are supported) decreased by the number of both
static GPRS/EGPRS slots and slots reserved for GSM signaling. The percentage
indicates the maximum number of dynamic GPRS/EGPRS slots.
To clarify previous concepts, it is considered the following example: three TRXs of a cell
are related to layers supporting Packed Switched services as follow:
– TRX0 and TRX4 support GPRS and EGPRS;
– TRX3 supports GPRS only.
Besides, the first TRX (TRX0) is the BCCH one and contains one SDCCH timeslot; the
second and the third TRXs (TRX1 and TRX2) are completely dedicated to circuit
switched services .
Then, on the TRXs where packet switched services are supported, the total number of
available slots for PS and CS services is 22 because:
– 6 slots are available on TRX0;
– 8 slots are available on TRX3;
– 8 slots are available on TRX4.
GDCH=PBCCH
TDMA frame
TRX0 supports
TRX 0 BCCH SDCCH EGPRS/GPRS
0 7
TDMA frame
TRX 1 SDCCH TRX1 does not

support EGPRS/GPRS
0 7
TDMA frame
TRX 2 SDCCH TRX2 does not

support EGPRS/GPRS
0 7
TDMA frame
TRX3 supports
TRX 3 GPRS only
0 7
TDMA frame
TRX4 supports
TRX 4 EGPRS/GPRS
0 7
Fig. 5.2 Example of GPRS/EGPRS configuration.
If the user sets:
A30808-X3247-M24-5-7618 105
System
– GPDPDTCHA= 50 (i.e., 50%);

– GDCH= PBCCH for one CHAN object (CHAN:6) of the BCCH TRX (see Fig. 5.2);
– GMASNPRESPRM=1
then, the maximum number (N) of GPRS channels shared with Circuit Switched (CS)
services is calculated by the following formula:
N= [Total number of available timeslots- Number of GPRS static slots(defined by GDCH
and GMANPRESPRM)]* GPDPDTCHA/100 =
= ( 22 - 2 ) * 50/100 = 10
So, in this cell (on TRXs assigned to layers supporting GPRS) there will be:
– 2 slots statically allocated for packet switched services (one signaling slot defined
on a channel basis using GDCH attribute and the other one defined on a cell basis
using aGMANPRESPRM attribute);
– 10 slots shared between the PS and CS services (according to the previous formula
and the GPDPDTCHA setting);
– 10 slots reserved for CS services (for example the remaining slots on the TRXs
assigned to layers supporting EGPRS/GPRS services).
The TRX1 and the TRX2 will be used for circuit switched services only.
It is important to put in evidence that this example is only valid if HOPMODE=SYNHOP.
i As soon as HOPMODE=BBHOP (independently of whether or not frequency hopping is
enabled), the timeslots 0 of all the non-BCCH TRX are never allocated for
GPRS/EGPRS.
Besides the GMANMSAL attribute related to PTPPKF Managed Object is configured for
defining how many users can be multiplexed in a PDCH channel. It defines the
maximum number of GPRS/EGPRS users that can share the same timeslot (PDCH); it
is structured into two fields: the first field indicates the maximum number of users in the
uplink direction, the second one specifies the maximum number of users in downlink
direction.
5.7 Management of Packet Data Channels
5.7.1 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 the co-operation between
the PPXU processors (involved in the PDCH management and scheduling functions for
UL and DL data transfer, see the chapter "6 Hardware and Software Architecture") and
TDPC processor (dedicated to resource management).
When a new GPRS/EGPRS request arrives at the BSC the PPXU estimates the number
of radio resources (for example the number of PDCHs) requested for TBF establishment
starting from the MS multislot class and the required peak throughput.
In order to provide the best possible throughput for each user, the BSC 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, for example:
a) MS Multislot Class (it is sent from the MS to the network during the GPRS attach
procedure, see the chapter: "9.3.2.1 Attach Function");
b) Peak Throughput:
106 A30808-X3247-M24-5-7618
System
– when the uplink TBF is derived from the Channel Request description inside the
Packet Resource Request or Packet DL Ack/Nack;
– when downlink TBF is derived from the Qos Profile IE of the DL-UNITDATA;
c) Coding Scheme to apply, given in throughput per timeslot.
Maximizing the throughput is the most important criteria in radio resource search.
i
After the calculation of the number of requested resources. the PCU checks if the actual
used strategy is the vertical one or the horizontal one (see the chapter:
"5.7.2 Horizontal/Vertical Allocation Strategies"). According to the used strategy and to
the needed resources, it then sends the correct request to TDPC processor.
According to the requests received by the 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.
When the TDPC receives the PCU it tries to satisfy the request.
If required channels are found, the TDPC sends the ACK message to the PCU, other-
wise other actions are executed (see the chapter: "5.7.4.2 TDPC Algorithm").
On a cell basis the PPXU knows:
1. the number of PDCH channels in use at a given time; for example:
– the timeslots (PDCHs) with at least one TBF assigned;
– PDCHs for which the Empty Channel Timer is running.
In fact, when the last Mobile Station associated to a PDCH channel 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 attribute TEMPCH , to avoid continuous requests
(in cases of high GPRS/EGPRS traffic) from the PPXU to the TDPC.
When the timer is still active, the allocated PDCH channels for the “released” TBF
are still seen as allocated even if they are no longer active.
2. the number of PDTs (equal to the number of Abis subslots) related to the PDCHs
still in use.
From this point, it could happen that (according to the chapter: "6.3.1 Concatenated
PCU Frames") for a PDCH channel one or more corresponding PDTs are useless,
for example they are filled with idle PCU frames due to downgrade to a coding
scheme needing less PDTs than the initial ones. When a PDT is filled with idle PCU
frames, the PCU waits until a timer defined by the attribute TEMPPDT expires before
releasing it.The timer is used to avoid continuous requests of Abis resources from
the PPXU to the TDPC.
The management of the PDCH channels includes the time alignment procedure. This
procedure is necessary whenever an idle PDCH channel is allocated or in case of Link
Adaptation an additional PDT is added to a PDCH channel in case of CS/MCS upgrade.
This leads to delay in case of GMM and SM signaling, larger First Pings and some
throughput degradation by slower Link Adaptation. In BR7.0 release the procedure
requires a time period of 230ms. In the current BR8.0 release the time period has been
decreased to 150ms.
Considering that the BTS executes one alignment adjustment in 99.9% of the cases, on
PCU side it is possible to pass into data state immediately after this command, without
waiting for the Time Alignment PCU frame with Adjustment = 0, that usually is sent with
the Sequence Number = 2. Hence the time alignment procedure ends already with SN
A30808-X3247-M24-5-7618 107
System
= 1. This means that as soon as the BTS sends SN=1, the BSC starts the data trans-
mission.
The time alignment procedure is applied for all the PDCH bring-up and all the PDT
synchronization case of LA in a cell. It provides the following benefits:
• Faster Link Adaptation procedure;
• Faster GMM and SM signaling;
• Better First Ping in order of roughly 2*80 =160ms leading to first PINGs around or
less than 1 second in the worst case.
Unused PDTs of a PDCH channel are released by BSC after the expiration of
TEMPPDT timer (typical value: 15 seconds). This happens for example during an active
packet data transfer after the execution of a link adaptation procedure to a more robust
codec as well as at the end of the packet data transfer, in case no further data is avail-
able. Besides a single PDT is maintained open up to TEMPCH timer expiration (typically
90 seconds), afterwards complete PDCH is closed. With this solution PDT(s) of PCU
can be reused by other cells and or PDCH channels.
In current BR8.0 Release this behaviour has been improved. EMPTY timer of second
subframe counter can be set to the same value of EMPTY PDCH timer instead of
EMPTY PDT timer depending on the setting of one bit of BSC Maintenance Bit Mask.
As a consequence there is the possibility to maintain active one PDT (current proce-
dure) or two PDT(s) per PDCH channel up to the expiration of TEMPCH attribute (new
procedure). All additional PDT(s) of a PDCH are maintained active up to the expiration
of TEMPPDT timer. Bit #23 within Maintenance Bit Mask (MNTBMASK) supports the
switch between the two procedures. Default behaviour is current procedure (one PDT).
For the reason that MNTBMASK is unique for whole BSC, the new procedure (two
PDT(s)) cannot be activated for specific cells within a BSC area only.
Two PDT(s) carry any GPRS traffic up to CS4 as well as EDGE traffic up to MCS5. It is
recommended to activate the new procedure in field only if sufficient Abis/PCU
resources are available in BSC. In case of Abis/PCU bottlenecks (for example in case
user activates new PDT release procedure in BSC areas with insufficient Abis/PCU
resources), Packet Service (PS) in BSC area could be affected and degraded.
This procedure improves GPRS/EDGE performance giving a significant improvement
potential for gaps in data transfer exceeding TEMPPDT timer. More in detail:
• Signaling is improved by 150ms, since it is performed on single PDCH only;
• First Ping is improved by typically 200-250ms, since due to not symmetric
Uplink/Downlink PDCH assignment. PDT(s) for both Uplink and downlink shall be
synchronized;
• Upload and Download times are improved especially in presence of small File Sizes
(of dimension smaller than 50 Kbyte size).
5.7.2 Horizontal/Vertical Allocation Strategies

When a new request of GPRS/EGPRS resources is received by 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 the
GPRS/EGPRS service, the already used slots must be filled as much as possible,
according to the configured value of the GMANMSAL attribute;
108 A30808-X3247-M24-5-7618
System
• the HORIZONTAL ALLOCATION (HA) strategy: it has been introduced in the BSS
system to allow higher bit data rates when the cell is not congested.
This strategy distributes the incoming GPRS/EGPRS calls on all the available PDCH
channels. In this way not too many users are multiplexed on the same PDCH
channel, increasing the data transfer throughput for all the involved mobiles.
The user can manage the allocation strategy according to his/her own needs, setting
specific attributes. It is important to underline how the chosen strategy depends upon
both from Abis and radio resources availability.
The chapter "5.7.2.3 Switching between VA and HA According to Radio Conditions"
describes how the radio interface situation triggers the switching from Horizontal Alloca-
tion to Vertical Allocation and vice versa, according to the parameter settings; whereas
the chapter "5.7.2.4 Switching between VA and HA" describes the analogous topics for
what concerns the Abis interface. The complete allocation algorithm is detailed in the
chapter "5.7.2.5 Allocation of Resources".
5.7.2.1 Vertical Allocation Strategy

When GPRS/EGPRS channels are handled using the Vertical Allocation (VA) algorithm,
the criterion is to multiplex the maximum number of Mobile Stations on each channel,
before assigning a new PDCH channel. This is obtained by filling an already used PDCH
channel taking into account:
• The settings of the GMANPRESPRM/GMAPRESCOM, EMANPRESPRM/EMAN-
PRESCOM, GPDPDTCHA and GMANMSAL attributes;
• The multislot capability of the Mobile Station.
If two Mobile Stations perform 3DL+1UL GPRS/EGPRS calls, the BSC assigns 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 represented in the Fig. 5.3 below.
TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7
BCCH TRX bcch sdcch
MS1DL MS1DL MS1DL

MS1UL
MS2DL MS2DL MS2DL

MS2UL
Fig. 5.3 Example of Vertical Allocation strategy
When the vertical allocation strategy is used, the BSC tries to multiplex, in a fair way,
the mobile requests, using “flat distribution”. With flat distribution, if the BSC is in VA
condition and over each radio timeslot is multiplexed only one Mobile Station, the BSC
will multiplex the 3 MSs over 3 different radio channels trying to uniformly distribute the
resources if three GPRS/EGPRS mobile requests (single slot) arrive to the BSC.
A30808-X3247-M24-5-7618 109
System
If flat distribution has not been used all the three Mobile Stations would be multiplexed
in the same timeslot (in accordance with the value of the attribute:GMANMSAL ).
5.7.2.2 Horizontal Allocation Strategy (HA)

The Horizontal Allocation (HA) strategy distributes the incoming GPRS/EGPRS calls on
all the available PDCH channels. In this way not too many Mobile Stations are multi-
plexed on the same PDCH channel increasing the data transfer throughput for all the
involved Mobile Stations.
When a new request of PDCH channels arrives at the BSC and radio channels for
supporting the GPRS service are still available, the BSC assigns new radio channels to
the GPRS/EGPRS mobiles instead of increasing the number of mobiles multiplexed on
the already busy channels.
If two MSs perform 3DL+1UL GPRS/EGPRS calls, the BSC assigns timeslots number
2, 3 and 4 to the first call, then the timeslots number 5, 6 and 7 to the second call.
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 represented in next Fig. 5.4.
TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7
BCCH TRX bcch sdcch
MS1DL MS1DL MS1DL MS2DL MS2DL MS2DL

MS1UL MS2UL
Fig. 5.4 Example of the Horizontal Allocation Algorithm
5.7.2.3 Switching between VA and HA According to Radio Conditions

Taking into account the radio interface, the BSC switches autonomously from the
Vertical Allocation to the Horizontal Allocation (and vice versa) in relation to the traffic
load in the cell (for example 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 is the vertical one.
To avoid the frequent changes between Horizontal and Vertical strategies, two thresh-
olds have been defined:
– one threshold (attribute: ThresholdIdleChannelHV) represents the transaction from
the horizontal allocation to the vertical one;
– the other threshold (attribute: ThresholdIdleChannelVH) represents the transaction
from the vertical allocation to the horizontal one.
These thresholds used to activate the horizontal/vertical allocation are managed by the
attribute GASTRTH (PTPPKF Managed Object).
The attribute GASTRTH contains a further field called: ThresholdIdleChanEU; this field
i represents a threshold that it is used in the radio resource upgrade strategy. See the
chapter: "5.7.5.1 Upgrade of Radio Resources".
110 A30808-X3247-M24-5-7618
System
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 (TCH or PDCH channels; slots containing
GSM signaling, such as BCCH or SDCCHs slots, and also slots statically reserved to
GPRS/EGPRS are not considered).
The number of available channels in the cell is calculated as follow::
Available Channels = Total number of configured channels - Number of OUT OF
SERVICE channels - Number of GPRS/EGPRS static channels (defined by GDCH,
GMANPRESPRM/GMAPRESCOM, EMANPRESPRM/EMANPRESCOM attributes) -
Number of GSM signaling channels
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 attribute GASTRTH) is calculated as follow:
Percentage of Idle Channels in the cell = Idle Channels / Available Channels
The evaluated value, that represents the percentage of idle channels in the cell, is trun-
i cated, so the decimals are not taken into account in the comparison with the thresholds.
For example, 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%).
A cell with five configured TRXs of which three support the GPRS/EGPRS is configured
as follow (see next Fig. 5.5):
– TRX0 contains BCCH and SDCCH logical channels;
– TRX1 and TRX2 are assigned to layers that do not support GPRS/EGPRS;
– TRX3 is assigned to a layer that 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 defined as TCHF_HLF; then each timeslot represents two available channels
from the circuit switched services point of view,.
A30808-X3247-M24-5-7618 111
System
TDMA frame
TRX 0 BCCH SDCCH
0 7
TDMA frame
TRX 1 SDCCH
0 7
TDMA frame
TRX 2 SDCCH
0 7
TDMA frame
TRX 3
0 7
TDMA frame
TRX 4
0 7
Fig. 5.5 Example of a Cell Configured with Five TRXs.
In this case:
• The total number of configured traffic channels = (6 + 7 + 7 + 8 + 8 ) * 2 = 72;
BCCH and SDCCH signaling channels are not considered, only traffic chan-
i nels are taken into account.
• Number of OUT OF SERVICE channels = (8 * 2) = 16;

• if the value of the attribute GMANPRESPRM and EMANPRESPRM is set to 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 signaling channels) the
above channels are the following:
Available channels = 72 - 16 - 6 = 50.
If, for instance, the GASTRTH attribute’s values have been set with the following values:
ThresholdIdleChannelHV=30%, for the transaction from HA ---> VA;
– ThresholdIdleChannelVH=40%, for the transaction from VA ---> HA.
112 A30808-X3247-M24-5-7618
System
when the percentage of idle slots is over 40%, the horizontal allocation (HA) is used. In
this case:
(100 * Idle channels) / Available channels > 40 ----> Idle channels = 21.
So, when in the cell the number of idle channels equals 21, the Horizontal Allocation
strategy is used.
If the percentage of idle slots falls under the 30%,the vertical allocation (VA) 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 14, the vertical Allocation
strategy is used.
If the percentage again exceeds the 40% threshold, the horizontal allocation algorithm
is triggered.
The difference between the two thresholds of the attribute GASTRTH should not be too
i high, but the thresholds have to be set to reasonable values (also taking into account
the number of configured TCH channels in the cell). Otherwise it could happen that,
when the Vertical Allocation (VA) is used, a return back to the Horizontal Allocation (HA)
one is applied only when the cell is completely idle, and this is not a real hysteresis
behavior.
It is important to underline that when the horizontal allocation is used for assigning the
i GPRS/EGPRS resources, two conditions, related to the 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 GASTRTG parameter; the second
one occurs when the number of channels assigned to the GPRS/EGPRS users reaches
the maximum number of channels configured for the PS services by means of the
GMANPRESPRM, EMANPRESPRM, GDCH and GPDPDTCHA parameters.
5.7.2.4 Switching between VA and HA

Considering the Abis interface, the BSC switches autonomously from VA to HA (and
vice versa) in relation to the number of Abis configured resources (for example in rela-
tion to the number of busy Abis subslots).
According to the flexible Abis allocation strategy 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, 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.
To manage the resource allocation process, a set of thresholds have been introduced.
The user can set these thresholds configuring the attribute: GASTRABISTH (gprsAllo-
cationStrategyAbisThresholds) of the BTSM Managed Object.
The attribute GASTRABISTH is structured into four fields. Two of them allow the
management of the vertical/horizontal allocation strategy. The remaining two are related
to the upgrade of the Abis resources and they are described in the chapter:
"5.7.5.2 Upgrade of Abis Resources":
• the first threshold (thresholdIdleAbisHV) defines the percentage of idle Abis subslots
of the BTSM (over the available Abis subslots of the BTSM) under which the vertical
A30808-X3247-M24-5-7618 113
System
allocation strategy is activated on the radio interface (for all the cell of the BTSM).
The Vertical Allocation activation is useful to re-use in multiplexing the already allo-
cated Abis subslots, slowing down the allocation of new Abis resources;
• the second one (thresholdIdleAbisVH) defines 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 the thresholds on the radio
resources (on a cell basis) also allow that.
The thresholds satify the relationship:
ThresholdIdleAbisHV < ThresholdIdleAbisVH
5.7.2.5 Allocation of Resources

The switching to the vertical (VA)/horizontal (HA) allocation is also driven by the avail-
ability/unavailability of PDTs on PCU (with the BSC/72, BSC/120 the maximum number
of GPRS channels manageable by the single PCU, for example the maximum number
of PDT manageable by the single PCU, is fixed to 256. (See the chapter "6.1 Supported
BSC Types" for more details).
Then according to the availability/unavailability of PDTs on the PCU side the following
actions are executed:
– when the percentage of busy PDTs on a PCU is 100%, then the vertical allocation
is applied;
– when the percentage of busy PDTs on a PCU is less than100%, then the horizontal
allocation is applied (provided that thresholds of GASTRTH and GASTRABISTH
attributes do not lead to vertical allocation).
In summary, in cells belonging to a BTSM with dynamic Abis management, the following
situations are possible during the allocation of radio resources, according to different
contexts:
a) horizontal allocation in a cell is used if at the same time the following conditions are
verified:
– there is no radio scarcity in the cell, for example the percentage of idle air
timeslots in the cell is greater than the ThresholdIdleChannelHV field of the
attribute: GASTRTH.
– there is no Abis resources scarcity, for example the percentage of idle Abis
subslots of the BTSM managing the cell is greater than the thresholdIdleAbisHV
field of the attribute GASTRABISTH;
– there is no PDT exhaustion for the PCU that manages the cell.
b) starting from the horizontal allocation, if there is radio scarcity, for example the
percentage of idle air timeslots in the cell becomes lower than the Threshold-
IdleChannelHV field of the attribute GASTRTH, than the vertical allocation is trig-
gered.
c) starting from horizontal allocation, if there is Abis scarcity, for example the
percentage of idle Abis subslots in the BTSM becomes lower than the Threshold-
IdleAbisHV field of the attribute GASTRABISTH, than the vertical allocation is trig-
gered; the PCUs that are handling the cells belonging to the impacted BTSM are
informed.
d) starting from the horizontal allocation, if there is PDT exhaustion in the PCU, than
the vertical allocation is triggered.
114 A30808-X3247-M24-5-7618
System
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 greater 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 greater than the ThresholdIdleAbisVH field
of the GASTRABISTH attribute, than the horizontal allocation is triggered; the PCUs
that are assigned cells belonging to the impacted BTSM are informed.
The allocation strategy is supported by the TDPC processor. The TDPC informs the
PCU about the used strategy via the allocation flag (Horizontal/Vertical Allocation). This
flag is updated each time the TDPC replies to the PCU requests for resources.
To avoid possible misalignment between the TDPC and the PCU, as regards the allo-
cation flag, a mechanism has been implemented 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 TDPC side.
5.7.3 Extended Dynamic Allocation

In this chapter the enhancements of the current resource allocation algorithm requested
by the Extended Dynamic Allocation (EDA) and Overheating Management features are
described. Overheating Management is detailed in the chapter: "10.6 Mobile Station
Overheating Management".
Extended Dynamic Allocation (EDA) has been implemented in the current BR 8.0
Release with the following limitations:
• TBF can be allocated when in horizontal status only;
• TBFs multiplexing is not supported;
• EDA is not supported in far area of the extended cell.
Besides EDA supports the management of up to multislot class 12 Mobile Stations.
Resource Allocation is related to the situation for which new radio resources have to be
searched for a new incoming PFC (for example: additional PFC or current PFC modifi-
cation). Resource Allocation can be executed when pre-allocation is performed or when
a new TBF is opened with PFI/PFC information or without it.
Resource Re-allocation refers to the situation for which already configured radio
resources shall be modified (for example: overheating, switching from Extended
Dynamic Allocation to Dynamic Allocation, Quality control Function, etc).
Allocation and Re-allocation procedures can be applied to prerel99 and rel99 onwards
Mobile Stations.
The Channel allocation algorithm’s logical flow chart is represented in next Fig. 5.6:
A30808-X3247-M24-5-7618 115
System
Fig. 5.6 Channel Allocation Algorithm’s Flow Chart (CAA)
The Service Selection block defines the service type for the Mobile Station. In case MS
supports the EDGE service, EDGE Service is preferred to the GPRS one.
In case EGPRS service has been selected, the procedure checks that EGPRS Service
Layer List is available in the cell/area, otherwise the service is downgraded to GPRS. A
specific algorithm has been implemented for “Service Selection”, but its description is
out of the scope of this manual.
When EGPRS SLL has been chosen, it is recommended to check that at least one TRX
i is available to support EGPRS service (for example: TRXs could be not usable because
“Failed” or “Locked”). Otherwise, GPRS service has to be selected.
In case a TBF or a concurrent TBF has been already opened for the MS (for which the
algorithm is running), TBF MAC MODE (GPRS or EGPRS) will be preserved, for
example, when a radio resource needs to be reconfigured.
The Mobile Station (MS) Configuration block is responsible for choosing the configura-
tion (in term of downlink and/or uplink configuration in MS Multislot Class) of the related
MS.
According to the Mobile Network Release (Rel 97/98), MS Release and Packet Flow
Management Feature status (Enabled/Disabled), two different MS Configuration Algo-
rithms are triggered: MS CONFIGURATION R<99 or MS CONFIGURATION R>=99.
The description of each algorithm is out of the scope of this manual. The flow chart for
the selection of the specific algorithm is represented in the Fig. 5.7 below:
116 A30808-X3247-M24-5-7618
System
Fig. 5.7 Algorithm for MS configuration
The Mobile Station Allocation block evaluates the couple (TimeSlot, TRX) that shall be
assigned to a MS configuration.
The configurations of the Mobile Station are got by the MS_Configuration_List. It
ensures that MS Configurations have been ranked from the best one to the worst one
according to a specific strategy.
In case of Dual Band Standard Cell, the preferred band is intrinsic in
MS_Configuration_List: for example, if the first MS Configuration in
MS_Configuration_List is available only for Band X (X=1 or 2), an allocation is triggered
for the MS Configuration on TRXs that belong to Band X. If the first MS Configuration
in MS_Configuration_List is available for Band 1 and Band 2, an allocation is triggered
for the MS Configuration on all the TRXs.
In case the MS_Configuration_List is empty, the following situations can happen:
- If none TBF/concurrent TBF is already opened for this MS then if service is EGPRS,
then EGPRS service can be allocated otherwise none new allocation is available;
- If the MS_Configuration_List is not empty, the MS configuration from the top of
MS_CONFIGURATION_LIST is available.
All the possible allocation for that MS Configuration are searched within the Service SLL
and in case of Extended Cell in right area (Far or Near). All allocations are stored in
Allocation_list. The search in the Service SLL is restricted only to the TRXs supporting
the required type of service. Allocation Criteria are applied to the Allocation_List.
The allocations in Allocation_List are valued according to Allocation Criteria that are all
applied to each allocations. The allocation which satisfies better all criteria is the best
one and as a consequence it is also the first that is selected. In case the selected allo-
cation fails (for example because some TS belonging to allocation are not granted by
A30808-X3247-M24-5-7618 117
System
TDPC processor), the successive allocation will be attempted, and so on. The same
strategy is adopted in case of resource allocation and resource reallocation. The
number of attempts could be restricted by Real Time constrains.
The Allocation Criteria are the following:
• Maximize the throughput of the TBF;
• Maximize the reuse of Empty Channels;
• If in Vertical Allocation mode, minimize the number of new idle TS;
• Minimize the weight of the affected TBF (Overall Weight);
• If TBF is EGPRS, EDGE BCCH TRXs shall not be preferred when supporting only
GMSK;
• If the allocation requires some new timeslots then maximize the number of adjacent
packet timeslot;
• If resource re-allocation then prefer “upgrade/downgrade like reconfiguration”.
In case of Dual Band Standard Cell, the Layer in the Service Layer List (SLL) shows the
i band user preference.
The Resource Reallocation process for current Uplink and/or Downlink TBF can be trig-
gered by RRM application due to occurrence of some events, for example the following:
• QCF Resource Reallocation Message (QCF_RR_MSG);
• Overheating Resource Reallocation Message (OH_RR _MSG);
• RAU Resource Reallocation Message (RAU_RR_MSG);
• NRT EDA Resource Reallocation Message (NRT_EDA_RR_MS);
• NRT EDA Resource Reallocation Message (NRT_EDA_RR_MSG);
• Update BR7.0 Upgrade Trigger Events to BR8.0 Strategy
It is out of the scope of this manual the detailed description of each event; The Resource
Reallocation model and the Functional Entities affected are represented in next Fig. 5.8
below:
Fig. 5.8 Resource Reallocation Process and Functional Entities affected
Extended Dynamic Allocation is supported when the system is on HORIZONTAL

STATUS and without TBF multiplexing. When the system switches from HORIZONTAL
118 A30808-X3247-M24-5-7618
System
Status to VERTICAL Status, Extended Dynamic Allocation TBF cannot more be config-
ured.
When the system is in VERTICAL Status, a procedure “downgrades” NRT EDA Uplink
TBF to NRT DA uplink TBF because NRT EDA TBFs are running in “virtually dedicated
mode” (no multiplexing): NRT EDA TBFs are prioritized on the their MAC TBF mode
(EDA) basis, regardless their QoS parameters, while the system manages QoS Traffic
Class (Streaming) basis only.
NRT EDA TBF procedure runs when the system switches to VERTICAL STATUS until
the system switches again to HORIZONTAL Status or none NRT EDA TBF is still config-
ured.
In case GPRS NRT EDA TBFs are configured then a message: “NRT EDA TBF
Resource Reconfigure” is sent to RRM application for a (GPRS) EDA TBF configured
on the highest Layer of the SLL where EDA NRT TBFs are still configured.
In case EGPRS NRT EDA TBFs are configured then a message: “NRT EDA TBF
Resource Reconfigure” is sent to RRM application for a (EGPRS) EDA TBF configured
on the highest Layer of the SLL where EDA NRT TBFs are still configured.
The RRM application activates the TBF Reconfigure Procedure at the reception of the
message: “NRT EDA TBF Resource Reconfigure” (NRT_EDA_TBF_RR_MSG).
Extend Dynamic Allocation (EDA) feature can be enabled/disable by the user from the
LMT Evolution or from the Radio Commander setting the value “Enabled/Disabled” of
the specific attribute: “Edasup” related to PTPPKF Managed Object.
If EDA has been enabled in a cell, RRM application decides if an Uplink TBF shall be
EDA or not EDA. If EDA has been disabled in a cell, no Uplink TBF can be EDA.
The “Edasup” attribute can be modified only if the PTPPKF Managed Object has been
locked by the user. The Lock command is necessary to simplify the management of the
transitory phase during the change setting that happens not so frequently. When a PDT
alignment is activated, the BSC can know if some Timeslots belonging to the same TRX
shall be scheduled together in Uplink for possible EDA UL TBFs (EDA enabled) or each
Timeslot shall instead be scheduled alone (EDA disabled).
5.7.4 Management of Incoming GPRS/EGPRS Requests

With the introduction of packet switched data calls, a clear and flexible strategy for the
channel allocation has been required. The introduction of the channel allocation strate-
gies has required a mechanism for using/reusing the system resources, in order to
better comply with the operator’s 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’ needs (both for Data and for Speech
calls).
Regarding the management of different services, the operator can configure in the cell
static and dynamic GPRS/EGPRS timeslots (see the chapter: "5.6 Configuration of
GPRS Channels in a Cell").
When the BSC receives a new GPRS/EGPRS request, it starts a process that is respon-
sible for the management of all the incoming requests: the PCU asks to the TDPC to set-
up new channels for supporting the packet switched (PS) services. The aim of the task
in the PCU/TDPC is to allocate the requested resources according to the configurations
executed by the operator and to the Mobile Station preferences.
A30808-X3247-M24-5-7618 119
System
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).
For distinguishing EDGE TRXs from non-EDGE TRXs, both on the TDPC and PCU, the
Resource Manager application looks at the specific dynamic attribute of the TRX (see
the chapter: "5.5.1 Aspects Related to Carrier Configuration"): TRX not available for
service are not considered.
Both on TDPC and on PPXU, the radio resource research algorithm takes into account
the attribute: EBCCHTRX. It specifies whether the 8PSK modulation is allowed on the
BCCH TRX.
The aim of the algorithm is the following: “maximize the throughput in the limits of the
specified peak throughput (if specified), minimizing the number of the allocated radio
resources.
Therefore EDGE TRXs are preferable for MSs supporting EDGE, 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 (for example CS4 versus MCS4)
better performances from a TBF operating in EGPRS mode (instead of GPRS mode)
are expected, due to specific retransmissions rules and incremental redundancy (see
the chapter: "9.9.1.2 EGPRS Acknowledged Mode").
For an EGPRS TBF, when the multislot capability of a mobile is high, and if the radio
resources are insufficient on EDGE TRXs and available on non-EDGE TRXs, a non-
EDGE TRX could be preferable. In fact the most important criteria in the radio resource
research is trying to maximize the throughput. As example, it is considered a request at
the BSC for establishing a TBF with the following characteristics:
Peak throughput = 80 kbit/s

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 timeslots on the EDGE TRX, because the peak
throughput is supported with the minimum number of radio resources.
But if only 1 radio resource (NE) is available on an EDGE TRX, the supported
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 the management of 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 operator’s strategies, a specific attribute has been introduced. This
attribute allows the user to indicate on which TRX (BCCH or not BCCH) a certain type
of service (voice or data service) will be preferably allocated. In this way, a clear usage
policy for the BCCH TRX channel allocation is guaranteed.
120 A30808-X3247-M24-5-7618
System
The horizontal/vertical allocation algorithm on the TDPC receives in input a message:

PDCH_Request from the PCU containing, among other information, a list of suggestions
for the channels to be granted by TDPC itself. The “already busy for GPRS/EGPRS”
channels can be assigned only by PCU, while idle channels can be assigned only by
TDPC.
If the incoming GPRS request cannot be satisfied (because some timeslots shall be free
for the GPRS multislot calls, or because the cell is congested), the request is inserted in
a waiting queue (for example a ‘stand by’ queue), and it will be served as soon as the
proper actions have been performed (see the chapter: "5.7.7 Waiting Queue Manage-
ment").
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
The
switched calls only, and the related queue is defined queuing list.
The algorithm used to assign GPRS resources is splitted in two parts: one is performed
on the PCU and the other one on the TDPC. The algorithm is described in the next
chapter.
5.7.4.1 PCU Algorithm

When the BSC receives a new request of GPRS resources the first actions are executed
by the PCU that handles the cell from which the request has been sent.
This chapter describes the PCU algorithm in cases of new GPRS/EGPRS calls. The
i upgrading procedure, in cases of new resources requested for already established
calls, are described in the chapter "5.7.5 Upgrading Strategies".
When a new request is sent to the PCU, the following information is provided:
• Mobile capability (GPRS/EGPRS);
• Required Peak throughput;
• Multislot class;
• Candidate Initial Coding Scheme (CS/MCS); as it has been described in the
chapter: "4.2 Channel Coding", the user can set the preferred initial coding scheme,
for both GPRS and EGPRS services, to be used when a new TBF starts. The O&M
configured initial coding schemes are only used if no information about a Mobile
Station in a cell is available when a new TBF starts. In fact, the PCU holds in
memory, for each Mobile Station, the last coding scheme (either CS or MCS) used
in the uplink/downlink directions for TBFs associated to the MS; nevertheless the
PCU maintains this information only for a specific period of time. So the Candidate
Initial Coding Scheme is the following:
– the coding scheme stored in the PCU memory, if this information is still available;
– otherwise the O&M configured value.
More detailed information about the initial coding scheme handling are
i described in the chapter: "10.7.3 Selection of the Candidate Initial Coding
Scheme".
The aim of the search on the PCU side is to find a number of adjacent PDCH channels
in order to maximize the throughput of the TBF.
Before starting to search radio resources on the TRXs the PCU calculates the optimal
number (N) of radio resources that allow the maximum “initial target throughput” of the
data transmission.
A30808-X3247-M24-5-7618 121
System
The general formula to calculate the number of “optimal” number of radio resources (N)
is the following:
Peak Throughput Available Peak Throughput

NOT Available
N Min(ceil ( PT / (T_I_CS x (1-BLER) ), Multislot Class) 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 acknowl-
edged blocks) versus the number of transmitted radio blocks in total (for example the
sum of the acknowledged blocks and the not acknowledged one, see the chapter:
"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,
via the attribute: INIBLER.
The O&M configured initial BLER is only used if no information about a Mobile Station
in a cell is available when a new TBF starts. In fact, the PCU stores in memory, for each
Mobile Station, besides the last coding scheme, the last measured BLER value (histor-
ical BLER) associated to the Mobile Station; nevertheless the PCU maintains this infor-
mation only for a specific period of time. 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, for example if the Mobile Station is EGPRS capable or
not.
The different possibilities are described:
a) In cases of mobiles with EGPRS capability and in cases where 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 cases where a concurrent TBF is in progress with TBF mode EDGE, only NE
will be calculated; in cases where 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 will be in the same TBF mode.
b) In cases of mobiles without EGPRS capability and in cases where the peak
throughput is available, only the calculation for NG is performed;
c) When 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:
122 A30808-X3247-M24-5-7618
System
Initial target throughput per timeslot = throughput (maximum data rate) of the candi-
date 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 that which provides the highest Initial Target Throughput.
When the initial target throughput per PDCH on GPRS TRXs is slightly better than the
i 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 retrans-
mission 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). For example, 3 radio
timeslots 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
i 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 cases of Abis/PDT resources scarcity it is not guaranteed that the resource
assignment will result in the best solution in terms of throughput (see the chapter:
"5.7.4.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. 5.9).
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. Maximize the throughput of the TBF;
2. Maximize the reuse of Empty Channels (for example the channels already allocated
in packet transfer mode, but without assigned TBF);
3. Minimize the weight of the affected TBF (Overall Weight);
4. If TBF is EGPRS, prefer EDGE BCCH TRXs when supporting only GMSK
(EBCCHTRX = False);
5. If the allocation requires some new timeslots then maximize the number of adjacent
packet timeslot;
A30808-X3247-M24-5-7618 123
System
6. If resource re-allocation then prefer “upgrade downgrade like reconfiguration.

The following QoS parameters are taken into account in the resource allocation process
i on PCU side:
- Radio Priority in the uplink direction;
- Service Precedence in the 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
the chapter "9.9.7 GPRS/EGPRS TBF Scheduling" to read how Qos attributes are
mapped to scheduling priority).
According to its priority, each TBF is assigned a ‘weight’; as described in the chapter:
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 to pre-search the radio resources, in addition to the other criteria,
tries then to minimize the total weight of the suggestions to be sent to the TDPC.
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 the 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; this is because e.g., the current Abis allocation is not enough to
support the candidate initial coding scheme. In this case, the PCU will sent a request
to the TDPC for additional Abis resources using the PDCH_Abis_Upgrade message
(see "5.7.5.2 Upgrade of Abis Resources").
It must be noted that when horizontal allocation is used, the timeslots already avail-
able 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 the PCU side, a PDCH_request message is sent to the TDPC indi-
cating this configuration as a suggestion (the request also notifies the TDPC of the
“Initial Target Throughput per timeslot). The request also contains 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 the TDPC answers
(positively or not) or a protection timer expires.
In case of Vertical Allocation strategy, the idea is to reduce the number of new
timeslots to asked of the TDPC for the incoming request.
When the Vertical Allocation strategy 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 by multiplexing the new TBF on the timeslots already in packet
mode that are not in the busy state (the busy state is set when the number of TBFs multi-
plexed on a PDCH reaches the GMANMSAL value).
The criteria used to find resources are the following (in order of priority):
124 A30808-X3247-M24-5-7618
System
1. prefer EGPRS on EDGE TRXs and GPRS on non EDGE TRXs;

2. maximize the initial target throughput;
3. maximize the number of empty channels;
4. minimize the overall weight on the affected PDCHs;
5. choose the preferred TRXs.
The output of this algorithm is a possible configuration on one TRX. If all the chosen
timeslots are already available at the PCU side, they are assigned immediately.
It must be noted, that when 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 send a request to TDPC for addi-
tional Abis resources by the PDCH_Abis_Upgrade message (to have more details about
upgrade of Abis resources, see "5.7.5.2 Upgrade of Abis Resources").
In case some timeslots are not immediately available, a PDCH_request message is sent
to the 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-M24-5-7618 125
System
MS/SGSN
request
Calculate the number of

requested PDCHs according to:
- Multislot Class
- Peak Throughput
-Mobile Station Capability
-Candidate Initial Coding Scheme
Horizontal Allocation Vertical

type?
Find channels Find channels

according to HA according to VA
criteria criteria
PCU PCU
needs new YES NO needs new
NO YES
PDCH PDCH
channels? channels?
Send PDCH_Request Send PDCH_Request

to TDPC to TDPC
PCU PCU
needs new YES needs new YES
PDT? PDT?
NO NO
Assign channels Send Assign channels Send

already in PDCH_Abis_Upgrade already in PDCH_Abis_Upgrade
Packet Mode to TDPC Packet Mode to TDPC
Fig. 5.9 Allocation Algorithm implemented in PCU
126 A30808-X3247-M24-5-7618
System
5.7.4.2 TDPC Algorithm

PCU can send to TDPC two kinds of messages:
a) the PDCH_Request message, when new PDCHs on the air interface must be
assigned; this message also specifies the number of Abis resources needed to
support the TBF. New PDCHs can be required in the cases that follow:
– when a new PS call must be established;
– when a PS call already established needs more radio resources (i.e., in cases of
upgrade of radio resources);
b) a PDCH_Abis_Upgrade message, when new PDCHs on the air interface must not
be assigned, but new Abis resources are needed. This message is sent in the
following cases:
– when a new TBF, which uses a coding scheme requiring a certain number of Abis
resources, is allocated with the vertical allocation on PDCHs already filled with
TBF requiring less Abis resources;
– when the upgrade of the coding scheme of one TBF requires that more Abis
resources are assigned.
The cases requiring the upgrade of already assigned resources (PDCHs or Abis) are
discussed in "5.7.5 Upgrading Strategies"; the case regarding new incoming PS calls 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 informa-
tion:
• 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 configura-
tion);
– 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
i mode, but without assigned TBF; i.e., they are the channels for which the
TEMPCH timer is still running (see "5.7.4.1 PCU Algorithm").
• The HA/VA indicator. This indicator is used to indicate 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 first try 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, the 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: 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
A30808-X3247-M24-5-7618 127
System
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 field of the
GASTRABISTH parameter (see "5.7.5.2 Upgrade of Abis Resources"), the TDPC
will allocate new PDCHs trying to assign them the requested number of Abis/PDTs
per PDCH and, if necessary and possible (see "5.7.5.2 Upgrade of Abis
Resources"), upgrade up to the requested number of PDTs per PDCH the already
allocated PDCHs in the configuration.
When Abis/PDT resources are not enough to completely satisfy the request (activa-
tion of new PDCHs and possible upgrade of already allocated PDCHs), the number
of PDTs per PDCH specified in the request is downgraded.
– a PDCH_KO message, if no idle channels have been assigned (even if some pre-
allocated channels were present in the PCU request); also in this case, if necessary
and possible (see "5.7.5.2 Upgrade of Abis Resources"), upgrade up to the
requested number of PDTs per PDCH the already allocated PDCHs in the configu-
ration.
The TDPC algorithm is described in Fig. 5.10.
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 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
i GPRS/EGPRS services. So if the incoming request can be satisfied using the timeslots
reserved exclusively for PS services (fixed by the user by means of GMANPRESPRM,
GMANPRESCOM attributes) 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 first.
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.
128 A30808-X3247-M24-5-7618
System
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 sugges-
tions);
4. minimizing the number of forced intracell handovers of circuit switched calls;
5. choosing the preferred TRX.
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 always
contains 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
"5.7.7 Waiting Queue Management").
Note that for the previous algorithm, the search including forced intracell handovers is
i applied only if forced intracell handovers have been enabled by the operator (see
"5.7.7.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 has a field as a bit map containing the HA/VA indi-
cator.
The HA/VA indicator is set to horizontal allocation or vertical allocation depending on the
situation of radio interface and Abis interface, described in "5.7.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 no 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 configurations, the allocated PDCHs must have (see
also "4.7 Multislot Configuration"):
– same frequency hopping law;
– same training sequence code (TSC);
– same MAIO;
A30808-X3247-M24-5-7618 129
System
– adjacent time slot numbers.

The first three rules have to be followed during the configuration 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 allo-
cated to GPRS/EGPRS users.
• if the TDPC answers with PDCH_KO to the PCU because no GPRS/EGPRS chan-
nels are available or because no idle channels are assigned and there are no pre
allocated ones, the 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 has expired.
If what is assigned by the TDPC does not fit what is 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 sugges-
tion).
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 these two
channels and also sets the VA/HA flag to VA.
The PCU then 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 allo-
cated channels).
130 A30808-X3247-M24-5-7618
System
Reception of
PDCH_Request
from PCU
YES Is the Cell NO YES

Are queues
congested?
empty?
NO
Put the call in

Waiting Queue
Upgrade New call
New call or Are there
NO available YES
Upgrade? resources
immediately?
Assign the resources

Downgrade the (E)GPRS
call to 1 timeslot Is it
NO possible to free
resources using
Intracell Handover? Calculate HA/VA
Send PDCH_KO threshold
Put the downgraded
to PCU
call in Waiting Queue YES
(if necessary set VA)
Put the multislot YES NO

Threshold
call in Waiting Queue overcome?
Were there
Set VA
YES pre-allocated channels NO
in the PCU request?
Assign pre-allocated Calculate HA/VA

PDCHs threshold
Send PDCH_KO Send PDCH_Setup
to PCU to PCU
(Set VA)
YES Threshold NO
overcome?
Set VA
Send PDCH_KO
to PCU
Fig. 5.10 Allocation Algorithm implemented in TDPC
A30808-X3247-M24-5-7618 131
System
5.7.5 Upgrading Strategies

The following upgrading strategies have been defined according to different situations:
1. Upgrading of radio resources: additional radio resources are requested to support
the peak throughput;
2. Upgrading of Abis/PDT resources: it can be required by the Link Adaptation proce-
dure when the conditions get better, or by the PCU when in the same PDCH channel
has to fill a TBF with an higher coding scheme with respect to those already
supported.
The upgrading of the radio resources is different from the upgrading of the Abis/PDTs,
that occurs under completely different conditions.
5.7.5.1 Upgrade of Radio Resources

After the first allocation of radio resources, additional radio resources could become
necessary for supporting 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 the 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
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 shall belong to the same TRX and shall be adja-
cent 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 the radio resources.
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/PDT as describe
din the chapter; "10.7 Link Adaptation") and to upgrading of radio resources, the down-
grading 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 Mobile Station 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 the TDPC.
As long as the vertical allocation is in progress, the PCU is not allowed to request new
PDCH channels to TDPC for upgrading reasons.
The additional PDCH channel can be requested only if both the following conditions are
verified:
1. the horizontal allocation is in progress;
132 A30808-X3247-M24-5-7618
System
2. the number of idle radio timeslots in the cell is higher than the thresholdIdleChanEn-
ableUpgrade field of the attribute: GASTRTH.
The number of idle timeslot is calculated as described in the chapter: "5.7.2.3 Switching
i between VA and HA According to Radio Conditions".
The check is performed on the TDPC. The PCU is informed by a flag (enableRadi-
oUpgradingFlag) added in all the messages containing the allocation status flag. At
system initialization, 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 thresh-
oldIdleChanEnableUpgrade 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 allo-
cated 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 upgrade is not possible, the upgrading
request is dropped. 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-M24-5-7618 133
System
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). More-
over, 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 maximum sustainable throughput becomes lower than the maximum toler-
able degradation of the peak throughput, the upgrade is performed.
As long as the ‘one radio resource a time’ algorithm is implemented, the ACCEPT-
i GDEGR 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.
5.7.5.2 Upgrade of Abis Resources

According to the flexible Abis allocation strategy, for already assigned radio channels,
new Abis resources could become necessary, for example:
– it can be required by the Link Adaptation when the radio conditions gets better (see
the chapter: "10.7 Link Adaptation");
– it can be required by the PCU when in the same PDCH has to set up a TBF with a
higher coding scheme with respect to those already multiplexed on the PDCH (see
the chapter: "5.7.4 Management of Incoming GPRS/EGPRS Requests").
134 A30808-X3247-M24-5-7618
System
The user can manage the upgrade strategy of Abis resources by configuring the two
fields of the GASTRABISTH parameter. The two fields are:
• thresholdIdleAbisStopUpgrade: it defines 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 signaling 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 addi-
tional 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: it defines 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.
The Abis thresholds shall satisfy the following relationship:
thresholdIdleAbisStopUpgrade < thresholdIdleAbisRestoreUpgrade
There is no constraint between the Abis threshold to switch to vertical allocation (see
i the chapter: "5.7.2.4 Switching between VA and HA") 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 is related to the relative preference given from the operator to
circuit switched calls versus packet switched TBFs, and to running TBFs versus
incoming TBFs.
5.7.6 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 algo-
rithm is applied:
A30808-X3247-M24-5-7618 135
System
1. if the incoming CS call finds the cell in a congested state, the first attempted task is
to preempt one vulnerable CS call;
2. if preemption cannot be started for whatever reason (for example the feature is not
enabled), the Directed Retry procedure is started;
3. if also the Directed Retry cannot be started (for example the feature is not enabled
or the feature is enabled but the Handover Condition Indication message does not
contain any cell) the queuing procedure is started, if enabled;
The queuing procedure puts the CS call in the Queuing List that is different
i 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 cases 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 the
chapter: "5.7.7 Waiting Queue Management").
According to the flexible Abis allocation strategy it could also happen that when the CS
calls have 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.
5.7.7 Waiting Queue Management

As it has been described in the chapter "5.7.4.2 TDPC Algorithm", there are some cases
for which the TDPC inserts the incoming requests in the waiting queue; then the TDPC
must analyze a second time these 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 one 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 cases, the multislot
call is inserted in the waiting queue.
CS calls that arrive under the following conditions:
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 the chapter: "5.7.6 Incoming CS Calls")
b) when no Abis resources are available in the BTSM that manages the BTS.
could also be put in the waiting queue.
Before checking the waiting queue the TDPC analyses the queueing list. If the queueing
list contains some pending request (for example some CS calls), the TDPC will imme-
diately manage resources of the queueing list.
136 A30808-X3247-M24-5-7618
System
After this procedure, or if the queueing list is empty, the process analyzes the waiting
queue.
The released resources are used first by the Queuing process and only later on by the
i Waiting Queue process. So the classic Queueing procedure already implemented
always has an higher priority than the waiting queue management.
Three types of actions 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 has released any
system resources, these have been included in the Idle List structure. Then the
system finds the released resources which are available for the specific 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 the chapter:
"5.7.6 Incoming CS Calls");
The downgrade of an already active HSCSD call is executed only if the number of
used timeslots is greater than one (for example at least one timeslot shall 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 the chapter: "5.6 Configuration of GPRS Channels in a Cell"). The downgrade of
already active PS multislot calls is performed to serve incoming CS requests in the
waiting queue.
No active GPRS/EGPRS calls are downgraded to free resources for incoming
i GPRS/EGPRS 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 down-
grade strategy setting the attribute: (DGRSTRGY). This attribute allows the user to
choose among the following five different strategies:
– Downgrade of HSCSD calls first;
– Downgrade of GPRS/EGPRS calls first;
– Downgrade of HSCSD calls only;
– Downgrade of GPRS/EGPRS calls only;
– No Downgrade.
5.7.7.1 Pre-emption of PDCH Channels

The preemtpion of a PDCH channel is executed to serve an incoming CS call (see the
chapter: "5.7.6 Incoming CS Calls"); the TDPC can send to the PCU the order to release
one or more PDCH channels in a cell (PDCH_preemption_order), due to the unavail-
ability of radio resources in a cell.
A30808-X3247-M24-5-7618 137
System
On the PCU, PDCH pre-emption orders are sent:

1. first to PDCHs with the ‘PDCH empty timer’ still active; as described, the “PDCH
empty timer” can be defined by the user setting the attribute: TEMPCH;
2. then to PS dynamic channels.
Besides:
– 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 first;
– independently on the value of the attribute: DGRSTRGY, if there are some empty
channels (for example PDCH channels for which the PDCH empty timer is running),
they are used to serve the CS call; if no empty channels exists, then the rules
defined by the attribute: DGRSTRGY are followed to free resources for the CS call.
The downgrade of the PDCH channels is applied, until the number of the reserved
channels for PS services is reached in the cell (reserved PS channels cannot be
downgraded).
The preemption of some PDCH channels can result in the reconfiguration of some TBFs
(also partially allocated on ‘residual’ PDCHs) and in the release of some other TBFs
(completely allocated on the preempted PDCHs).
5.7.7.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/PCCCH activation, or in case no Abis resources are
available to serve incoming CS requests put in the waiting queue.
Cells belonging to the ‘exhausted’ BTSM are spread over several PCUs (see the
chapter: "8 Load Control for Packet Switched Services"), so, in case of unavailability of
the 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 when radio
resources unavailability is applied. For example, in case of CS pre-emption due to
unavailability of Abis resources, the pre-emption management will not cause the release
of PBCCHs and PCCCHs (or the pre-emption of static GPRS/EGPRS channels). That
is: only PDTs with SFC=1..4 can be removed from PBCCH and PCCH channels.
On PCU, PDT pre-emption orders are managed with the aim to balance the distribution
of PDTs among cells and to disturb as little as possible the 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 the chapter:
"5.7.1 Generalities about Resource Assignments", the “PDT empty timer” can be
defined by the user setting the attribute: TEMPPDT);
2. starting from the first TRX and highest timeslot number and removing one PDT per
timeslot, then moving on the next TRX; this step is repeated until the required
number of PDTs is found.
Since the PDT pre-emption management can result in the release of some PDCH chan-
nels, 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
138 A30808-X3247-M24-5-7618
System
involved PDTs. Otherwise (release of the whole PDCH channel), the same behavior
implemented in case of PDCH pre-emption is ensured.
5.7.7.3 Forced Intracell Handovers of already established CS Calls

When the TDPC receives a request for a new PDCH channel coming from the PCU, the
TDPC tries to allocate it.
It could happen that in the transceivers supporting GPRS/EGPRS there are not free and
consecutive timeslots, for example 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
the GPRS users. The forced intracell handover allows the moving of 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
i by the TDPC, causing a forced intracell handover for circuit switched calls.
To enable the forced intracell handover, the user shall set the attribute: ENFOIAHO
(Enable Forced Intracell Handover) attribute to the value: TRUE
5.7.8 Flexible USF Granularity

USF Granularity 0 and USF Granularity 1 are supported in current BR8.0 release.
Whenever the Mobile Station detects an assigned USF value on an assigned PDCH, the
Mobile Station can transmit either a single RLC/MAC block or a sequence of four
RLC/MAC blocks on the same PDCH. The time relation between an uplink block, which
the Mobile Station shall use for transmission, and the occurrence of the USF value has
been defined in 3GPP TS 45.002 Recommendation. The number of RLC/MAC blocks
to transmit is supported by the attribute: USF_GRANULARITY related to the uplink TBF.
The Support of USF Granularity 0/1 has been implemented with the purpose to minimize
the impacts on the scheduler application (scheduler is described in the chapter:
"9.9.8 EGPRS/GPRS Scheduler Enhancements for Rel5 Qos Support" and to optimize
the relations with other new features like for example: “Extended Dynamic Allocation”
(EDA is detailed in the chapter: "5.7.3 Extended Dynamic Allocation").
Flexible USF Granularity supports the following topics:
• TRX-Based USF Granularity Management;
• USF Granularity 1: UL_Expected_List filling rules modification;
• USF Granularity 1 and Extended Dynamic Allocation (EDA) joint management;
• USF Granularity 1 & Far Area Mobile TBFs joint management;
• USF Granularity 1 & Safety Timers (T3180, T3190);
• USF Granularity 1 on TSs on which Traffic and signaling channels are multiplexed.
TRX-Based USF Granularity Management:
The USF Granularity for an uplink TBF is evaluated by the network by means of the
“USF_GRANULARITY” bit in the message: “Packet Uplink Assignment”.
The USF Granularity for uplink TBF is on TRX basis. All uplink TBFs for a configured
TRXi are managed according to USF Granularity 0 or USF Granularity 1 depending on
the parameter: “TRXi_USF_GRANULARITY” set by the user.
A30808-X3247-M24-5-7618 139
System
In case of USF Granularity 0, the scheduler application is not affected. Scheduler has
instead been modified for supporting USF Granularity 1.
USF Granularity 1; UL_Expected_List filling rules modification:
Every time a USF token is sent in a downlink radio block for an UL TBF of a Mobile
Station, UL_Expected_List shall be updated as follows: the three lowest positions of the
UL_Expected_List are filled with three dummy USF values. In this way a sequence of
four consecutive radio blocks is sent from the UL TBF to which the USF token is sent to.
The DL radio block “on air” carries the USF for the given UL TBF (UL TBF can therefore
send the first radio block). The three next DL radio blocks carry dummy USFs and this
allows the same UL TBF to send other 3 radio blocks without collision with additional UL
TBF.
When a MS shall be polled, TBF manager sends a request to the scheduler. The request
contains a reference to the MS and the Timeslots that fulfils the multislot class
constraints. The scheduler chooses the timeslot whose DL_Scheduled_List has the
shortest queue. Then inserts the reference to the MS in the first free position (for
example, position: “x”) of the chosen DL_Scheduled_List. At the same time, the corre-
sponding UL_Expected_List are updated according to specific rules.
The rules’ description is out of the scope of this manual.
USF Granularity 1 and Extended Dynamic Allocation (EDA) joint management:
EDA TBFs multiplexing has not been implemented in the current BR8.0 release. For this
reason the joint management of EDA TBFs and USF Granularity 1 does not introduce
any additional enhancement. Of course in case of USF scheduling, the rules for the
UL_Expected_List shall be applied jointly to all TSs the TBF is allocated on.
USF Granularity 1 and Far Area Mobile TBFs joint managemement:
If a Mobile Station is in a near area, then its TBFs are treated as the TBFs of ordinary
Mobile Stations. In case a MS is in a Far Area, the filling rules implemented for USF
granularity 1 have to be applied jointly to the allocated and to the spill over timeslots,
each time USF or Polling has been scheduled.
USF Granularity 1 and Safety TImers (T3190, T3180 parameters):
Safety timers (T3190, T3180 parameters ) are still needed to be sure to keep alive
DownLink and Uplink TBFs. USF Granularity 1 relaxes on time scale tokens scheduling
among TBFs; in case Timeslots with an high number of TBFs are allocated on them, low
weight TBFs may remains inactive for periods of safety timers magnitude orders.
USF Granularity 1 on Timeslots on which Traffic and signaling channels are multi-
plexed:
In case PCCCH channel is allocated on a certain Timeslot, some radio blocks in a multi-
frame shall be reserved for PCCCH. The multiplexing on PDCH and PCCCH is
described in the chapter: "9.9.8 EGPRS/GPRS Scheduler Enhancements for Rel5 Qos
Support".
Flexible USF granularity feature can be enabled/disabled by the user in a carrier setting
the new attribute: “Usfgran” related to the TRX Managed Object. This attribute can be
configured by the user only if the TRX Managed Object has been locked in order to
support the management of the transitory phase during the change settings that happen
rarely.
140 A30808-X3247-M24-5-7618
System
In case USF granularity 1 has been enabled on a carrier (Usfgran = enabled) all the
Uplink TBFs on that carrier use USF granularity 1. On the contrary all TBFs have USF
Granularity 0 as in the previous BR7.0 Release.
As a consequence the following situations are avoided:
• Several UL TBFs with USF granularity 0;
• Several UL TBFs with USF granularity 1.
These situations imply that TBF weight is not respected as in the previous BR7.0
Release.
System performances are improved when USF Granularity is set to 1 and when on a
Timeslot coexist only 8PSK Downlink TBF and GPRS Uplink TBF. In any case System
Performances are not affected configuring USF Granularity = 0.
The description of the BSS system’s performances is out of the scope of this manual.
A30808-X3247-M24-5-7618 141
System
6 Hardware and Software Architecture

For the management of the Packet Switched Services (PS) in the BSS system, the
Packet Control Unit (PCU) has been implemented in the BSC. It supports the packet
data interworking between “Gb” and “Abis” interfaces.
PCU functionalities are supported by the Channel Codec Units (CCUs) in the BTS(s) as
represented in Fig. 6.1. The CCU software is downloaded to the BTS from the BSC.
, HS Gb
Fig. 6.1 EGPRS/GPRS BSS Hardware and Software Entities

The PCU unit within the BSC provides the following functions:
– Channel Access Control functions, for example access requests and grants;
– PDCH scheduling functions for uplink and downlink data transfer;
– Radio Channel Management functions, like 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 the protocols supporting the “Gb” interface.
CCU unit within BTS provides the following functions:
– 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 Managed Object (FMO) models the physical packet control unit
supporting Packet Switched (PS) services in BSS system.
PCU This Functional Managed Object (FMO)

models the Packet Control Unit designed to
support GPRS services in the BSS system. It
is supported by PPXU board in BSC/72 and
BSC/120.
Tab. 6.1 PCU Functional Managed Object (FMO)
FRL is the Functional Managed Object that models the physical link connection on the
“Gb” interface. The connection can be realized through the A interface (PCMA link) or
directly to the SGSN through the PCMG link. The Packet Data Terminal (PDT) repre-
142 A30808-X3247-M24-5-7618
System
sents a basic 16 kbit/s resource for the packet switched services manageable by the
PCU.
Each PCU can handle up to 256 PDTs on the Abis interface and up to 64 FRLs on the
Gb interface.
In the next chapters it is described in detail the difference that the support of the
GPRS/EGPRS technology requires in terms of hardware supported and software appli-
cations to BSC/72, BSC/120 and also to different BTS(s)’ types.
6.1 Supported BSC Types

In current BR 8.0 release the BSC(s) that can be installed in the Siemens mobile
networks are the following:
1. BSC/72 (also known as “Standard BSC”) equipped with SNAP switching matrix.
(see the chapter: "6.1.1 BSC/72 (Standard BSC)", that provides better perfor-
mances in terms of:
– connectivity (for example number of supported PCM lines);
– packet data handling capability;
– LAPD signaling.
2. BSC/120 (also known as “High capacity BSC step II”), see the chapter:
"6.1.2 BSC/120 (High Capacity BSC Step II)"), that provides additional capabilities
with respect to BSC/72.
Due to PPXX connectivity of 8 Mbps, maximum number of configurable links at 64 Kbit/s
i is SS7 + LAPDS + LAPDB = 127.
In the next paragraphs the two BSC types are described, taking into particular account
i their hardware and software resources configured for supporting EGPRS/GPRS
services. It is also 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 the chapter: "4 Radio
Interface Description", is the radio timeslot associated to the packet switched services
(that means when the timeslot is associated to the packet switched services, it is called
PDCH).
The Packet Data Terminal (PDT) represents a basic 16 kbit/s resource for the packet
switched services manageable by the PCU. The capacity of the PCU, from packet
switched data services point of view, is assigned in terms of Packet Data Terminals, that
means that 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/s)
manageable by the PCU. For example, when a single PDCH is associated to a GPRS
user using the CS1 coding scheme, it is also associated to 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 GPRS user adopting MCS9 coding scheme, five Abis subslots are associated to this
PDCH (see the chapter: "6.3 PCU Frames and Dynamic Allocation on the Abis Inter-
face") , and so five PDTs are busy in the PCU that manages this PDCH (in this case,
there is a one to five relationship between PDCH and PDT).
For more details about BSC/72 and BSC/120 hardware and software architecture, see
the manual: “TED:BSS Common”.
A30808-X3247-M24-5-7618 143
System
6.1.1 BSC/72 (Standard BSC)

BSC/72 (also known as “Standard BSC”) rack is represented in Fig. 6.2 below:
Fig. 6.2 BSC/72 (standard BSC) Rack.
Main BSC/72 boards are the following:

• The SNAP switching matrix;
• The peripheral processor board:
– PPXL board to manage both LAPD and SS7L signaling;
– PPXU board for supporting the GPRS and EGPRS services. It supports GPRS,
SS7/MTP2 and LAPD services (layer 2 protocol handling). Basic functions of the
board are resource allocation and protocol conversion between Abis and Gb inter-
face. The control and administration of the board is supported by the central
processor. It is realized with a standard intel Pentium running at 400 Mhz
supported by 440BX Intel chip set. Two devices constitute the chip set: The north
bridge that controls the SDRAM and the south bridge that allows the ISA bus
interfacing and houses the interrupt logic.The SDRAM is realized by a double
sided DIMM for a total amount of 256 Mbytes organized in two rows of 128 Mbytes
each one. The operation clock frequency is 100 Mhz. PCI bus is main communi-
cation bus on which data exchanged between central processor and peripheral
144 A30808-X3247-M24-5-7618
System
devices run. HDLC controller is located on PCI bus: on the GPRS application it
handles FR, and in L2 protocol handling it manages LAPD/SS7 links. The HDLC
controller has the capability to handle up to 256 physical channels but, for
supporting GPRS application, a reduced number is required The same band-
width can be used with a smaller number of channels but at higher bit rate; the
super-channeling is supported in the hardware by the HDLC controller itself. The
device, for GPRS application and for the LAPD/SS7 application is always
connected to the SNAP. On PCI there are also two common devices used in both
GPRS and L2 protocol handling: the asynchronous serial communication
controller and the bus converter logic, that converts the PCI bus to a parallel bus
fitting the Dual Port interface. The asynchronous serial communication controller
is used to implement a RS232 interface, whose main applications are for software
debugging and for updating the firmware stored in the Flash EPROM;
The main function that is necessary to add on PPXU board in order to interface
to the duplicated Ethernet switch planes (ESAM boards) is that of a dual Ethernet
port. Moreover a FPGA integrating four processing unit has been introduced in
place of the DSPs of current PPXX board. In addition FPGA provides a perfor-
mance increase (in term of managed channels). PPXBV2 is the Baby board that
is mounted over PPXX board thus constituting the PPXUV2 board used in BSC
to support High Speed Gb over Ethernet feature;
• The Ethernet Switch and Expansion Alarms board (ESAM). This board is installed
only to support the High Speed Gb interface. In this case it replaces the DK40 board.
In comparison with SN16 (the switching matrix of the BSC/46 (Regular BSC) not more
supported in BR8.0 release), the SNAP board allows the interface of 48 lines at 8 Mbit/s
coming from LICD and PPXX (double bandwidth in comparison with the SN16, which
can interface 24 lines).
This doubled number of lines increases independently (for example without trade-off)
both GPRS/EGPRS and LAPD channels.
The SNAP switching matrix has been introduced in the BSS system through the
handling of the NTWCARD attribute; it can assume the values:
– NTWSN16, when SN16 switching matrix is used (only for BSS releases < 8.0);
– NTWSNAP, when the SNAP switching matrix is used (BSC/72, BSC/120).
When NTWCARD is set to NTWSN16, BSC works with PPCC, PPLD and PPCU boards
i (only for BSS releases < 8.0). When the attribute value is NTWSNAP, only SNAP and
PPXU and PPXL boards are managed. Mixed configurations are not supported.
ESAM board that replaces DK40 board to support High Speed Gb interface provides 20
fast Ethernet internal Ports. It supports also 2 Gigabit Ethernet external ports: one port
is reserved for SGSN and the other for future use and processor on board to configure
and to manage the switch devices. High Speed Gb interface is described in chapter: 7.4.
For getting more GPRS/EGPRS channels it has been necessary to increase the number
of boards assigned to the packet switched functionality and to increase also their capa-
bility. This is allowed by SNAP switching matrix, which provides 8 lines at 8 Mbit/s
towards PPXX boards. Two lines are used for handling LAPD and SS7 level 2 signaling
protocols; the remaining six are used for the PPXU boards (each PPXU board has its
own 8 Mbit/s line).
To handle the packet switched services, up to six instances of the PCU Managed Object
can be created.
A30808-X3247-M24-5-7618 145
System
The creation of one PCU object implies the consequent creation of one PPXU board: for
example 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 board is automatically created when the PCU object with the same instance is
i created, if NTWCARD= NTWSNAP. Otherwise (if NTWCARD=NTWSN16, only for BSS
releases < 8.0), a couple of PPCUs are created (PPCU 0,1 for PCU-0; PPCU 2,3 for
PCU-1).
Tab. 6.2 shows the correspondence between the boards of BSC/46 (only for BSS
releases < 8.0) and BSC/72.
BSC/46 BSC/46 (full GPRS BSC/72

(no GPRS) configuration)
PPLD-3 PPLD-3
PPLD-4 PPLD-4 PPXU-0
PPLD-5 PPLD-5
PPLD-6 PPLD-6 PPXU-1
PPLD-7
PPLD-8 PPCU-2 PPXU-2
PPLD-9 PPCU-3 PPXU-3
PPLD-10
PPLD-11 PPXU-4
PPLD-12 PPCU-1
PPLD-13 PPXU-5
PPLD-14
PPCU-0
Tab. 6.2 Correspondence between the BSC/46, BSC/72 boards
Since each PPXU is connected to the SNAP matrix with a 8 Mbit/s line, each PPXU
board, and as a consequence each PCU, is able to handle at most a data rate of 8
Mbit/s.
Data rate is split into 128 time slots of 64 kbit/s each. Since one of these time slots is
used to transmit the CRC related to the others, then 127 timeslots can be used effec-
tively.
This data flow is divided into two data rates:
1. a data rate constituted of 64 time slots of 64 kbit/s towards the Abis interface; this
flow allows the management of Abis interface at most 64 X 4 = 256 GPRS/EGPRS
channels (16 kbit/s each one), for example 256 PDTs.
If either GPRS CS3, CS4 coding schemes or EGPRS coding schemes are used, 256
i PDTs do not strictly correspond to 256 PDCHs.
2. a data rate constituted of 63 time slots of 64 kbit/s towards the Gb interface; this flow
allows the management of the Gb interface at most 63 Frame Relay Links (64 kbit/s
each one, see the chapter "7 Gb Interface").
146 A30808-X3247-M24-5-7618
System
Each PPXU board and, as a consequence, each PCU can handle up to 256 PDTs; to
reach 1280 PDTs (that is the number of packet switched resources supported by
BSC/72), 5 boards (1280/256 boards) have to be considered in service simultaneously;
this means that the concept of “1+1” redundancy is no longer supported and a different
redundancy schema has been provided.
The redundancy schema used is the “load balancing”: with this schema all six boards
are simultaneously in service and the packet switched traffic is distributed among all six
boards (see the chapter "8 Load Control for Packet Switched Services"); this implies
that each board normally runs without problems (the required real time traffic can be
spread over 6 boards instead of 5).
When BSC is fully equipped with six PCUs, it can handle up to 1536 PDTs (256 X 6) and
378 Frame Relay Links (63 X 6). If the sixth board is used for redundancy purposes, the
number of handled PDTs becomes 1280 (256 X 5).
With BSC/72 it is possible to configure up to 250 cells and, as a consequence, up to 250
PTPPKF Managed Objects.
A30808-X3247-M24-5-7618 147
System
6.1.2 BSC/120 (High Capacity BSC Step II)

BSC/120 (also known as “High capacity BSC step II”) rack is shown in next Fig. 6.3.
The rack contains the SNAP matrix and the PPXU, PPXL boards that can be installed
also in BSC/72; these boards are described in chapter: "6.1.1 BSC/72 (Standard BSC)".
BSC/120 has the following characteristics:
• It supports STLP board which is used in place of QTLP board; LICD instances have
been increased from 9 to 10 and the LICD circuit number on which a PCM line can
be created from 4 to 6;
• It supports up to 12 PCUs and PPXU boards;
• It provides a new rack configuration and a new back plane: this allows the doubling
the number of used PPXU (PPXX supporting GPRS/EGPRS) from 6 to 12; it also
allows housing 10+2 STLP(s), for example one more board than QTLPs equipped
in the old rack.
• It supports the Ethernet Switch and Expansion Alarms board (ESAM). This board is
installed only to support the High Speed Gb interface. In this case it replaces the
CPEX board.HS Gb interface is described in the chapter: 7.4.
• It supports an enhanced fan box for heat dissipation.
ESAM board that replaces CPEX board only if High Speed Gb interface shall be
supported provides 20 fast Ethernet internal Ports reserved for 12 PPXU boards, 2
PPCL boards and 1 Debug. It supports also 2 Gigabit Ethernet external ports: one port
is reserved for SGSN and the other for future use and processor on board to configure
and to manage the switch devices.
In order to achieve the enhanced performances the following additional changes have
been introduced:
• Two EPWR (power supply devices in the expansion module) are removed to make
room for PPXU and STLP boards. For this reason, PPXX and STLP are provided
with an internal power supply, directly fed by 48 V;
• on the top of the BSC, a box containing 6 fans has been introduced, powered by the
48 V, to cope with the increased heat generated by BSC;
• sense points in the new board CPEX for monitoring the fan alarms have been intro-
duced.
As previously described (see the chapter: "6.1.1 BSC/72 (Standard BSC)", the attribute
NTWCARD specifies the BSC type. If NTWCARD is set to NTWSN16, BSC is equipped
with SN16, PPCC, PPLD and PPCU boards; if the attribute is set to NTWSNAP, then
BSC/72 is used with SNAP matrix, PPXU and PPXL boards.
If BSC/120 is used with STLP boards (and also with SNAP and PPXU/PPXL boards),
NTWCARD attribute is set to: “NTWSNAP_STLP”.
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 the chapter: "8 Load Control for Packet
Switched Services"); as a consequence each board normally runs without heavy traffic
(the required real time traffic can be spread over 12 boards instead of 11 boards).
When BSC is fully equipped with twelve PCUs, it can handle up to 3072 GPRS/EGPRS
PDTs (256 X 12) and 756 Frame Relay Links (63 X 12). If the 12th board is used for
redundancy purposes, the number of handled PDTs decreases to 2816 (256 X 11).
In case either GPRS CS3 and CS4 coding schemes, or EGPRS coding schemes are
i used, 756 PDTs do not strictly correspond to 756 PDCHs.
148 A30808-X3247-M24-5-7618
System
BSC/120 supports up to 400 cells and, as a consequence, up to 400 PTPPKF Managed

Objects can be configured.
Fig. 6.3 High Capacity BSC with the New Rack
6.1.3 Redundancy and Configuration Rules

PPCU boards support GPRS service in BSC/46 for BSS releases < BR8.0. For safety
reasons both boards are configured with a spare copy. No dynamic data is present on
the spare board so the redundancy rule implemented is the “cold” standby. The creation
of one PCU object implies the consequent creation of two related PPCU boards (one
active, the other standby).
For BSC/72, BSC/120 six/twelve PPXU boards provide the support for managing GPRS
and EGPRS services. For PPXU board the “load balancing” redundancy is supported.
A30808-X3247-M24-5-7618 149
System
For the different BSC types it results:

• BSC/46 can manage up to 150 GPRS cells, so the user can configure only up to 150
PTPPKF Managed Objects (only for BSS releases < BR 8.0);
• BSC/72 can manage up to 250 GPRS/EGPRS cells, so the user can configure up
to 250 PTPPKF Managed Objects instances;
• BSC/120 can manage up to 400 GPRS/EGPRS cells, so the user can configure up
to 400 PTPPKF Managed Objects instances.
It is important to underline that when the user configures a cell for supporting the packet
switched services, for example when the user creates a PTPPKF Managed Object
instance, he /she does not have to assign the GPRS (or EGPRS) cell to a specific PCU;
It is the system that assigns the cell dynamically to one of the available PCUs.
This behavior is a direct consequence of the load balancing redundancy of the PPXUs
during the creation of a PTPPKF Managed Object:
– when a new cell is created, the system assigns 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 applies also to the PPCUs even if they implement the cold stand-by redun-
dancy.
In fact, for BSC/46 (for BSS releases < BR8.0):
– 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 replaces the faulty one (according
to the stand-by redundancy); if a couple of PPCU boards fails (for example if a PCU
becomes unavailable), all the GPRS/EGPRS traffic of the PCU is managed by the
other couple of PPCU boards (for example by the other PCU) according to the load
balancing criteria (as it happens for the BSC/72, BSC/120).
The algorithm that distributes GPRS/EGPRS cells of one BSC on available PCUs, is
described in chapter: "8 Load Control for Packet Switched Services".
In case High Speed Gb interface is supported (see the chapter: "7.4 High Speed Gb
Interface"), following additional considerations shall be taken into account:
- Gb over FR is managed on the PPXXV2 board;
- Parallel operation of ‘old’ PPXUs and PPXUV2s are supported by BSC in the following
combinations:
1) PPXU supporting Gb over FR and PPXUV2 supporting Gb over IP over Ethernet;
2) PPXU + PPXUV2 supporting both Gb over FR.
- It is possible to use PPXUV2 board also for PPXL applications to be able to phase out
the production of PPXU board. In these cases the new functions of the board (Ethernet
interfaces, new DSPs etc.) are implemented but not used. When upgrading existing
BSCs for supporting High Speed Gb interface, existing PPXL boards can be re-used
without hardware changes.
Integrated WAN interfaces for Gb within the BSC, for example STM-1 are foreseen as
a potential future migration step.
For these features additional processing is required on a centralized board. ESAM
provides the possibility to add additional hardware like for example a network processor
and/or line terminations on a additional baby board.
150 A30808-X3247-M24-5-7618
System
6.2 BTS Equipment Supporting GPRS and EGPRS

Regarding BTS equipment, different solution can be adopted according to the operator’s
needs. In fact considering the GPRS and EGPRS services different kind of features are
provided according to the equipment used; 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 EDGEcoding schemes.
EDGE is supported by BTSplus only. To provide EDGE services, BTSplus is upgraded
with EDGE capable carrier units (E-CU) featuring 8-PSK modulation technique. E-CU
hardware can handle:
– GSM, HSCSD and GPRS (with all its coding schemes) services;
– EGPRS service.
To support 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 however supported.
Regarding GPRS coding schemes, the following considerations shall be taken into
account:
• BTS-2x/6x supports GPRS CS3/CS4 coding schemes;
• BTSplus, e-microBTS support GPRS CS3/CS4 coding schemes (also if a mixed
configuration of GSM-CU and EDGE-CU boards is present);
The user shall ensure the consistency between the software configuration and the BTS
i hardware.
6.3 PCU Frames and Dynamic Allocation on the Abis Interface

This chapter describes the distribution of the 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 neces-
sary 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 supports the flexible
Abis allocation strategy:
• all the possible BSC configurations, see the chapter: "6.1 Supported BSC Types";
• the BTSplus with GSM-CU and EDGE-CU; enhanced micro BTS; BTS-2x/6x.
The introduction of CS3 and CS4 coding schemes for GPRS, and the EDGE feature
also have big impacts on the existing Abis interface. The following enhancements have
been implemented:
• the Abis configuration of standard PCU frames (used for GPRS CS1/CS2 coding
schemes), which is based on a single 16 kbit/s slot, is not sufficient 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" as well as the GPRS
data, in cases where the higher coding schemes (CS3/CS4) are enabled. Hence the
flexible Abis allocation strategy provides the opportunity to assign to each air inter-
A30808-X3247-M24-5-7618 151
System
face timeslot, from one to up to five 16 kbit/s Abis subslots (16 kbit/s each one), in a
flexible way;
• in cases where the capacity of each air interface timeslot can vary during runtime;
for GPRS CS3/CS4 or EGPRS, the flexible Abis allocation strategy adapts the Abis
capacity to the required air interface capacity (in cases of Link Adaptation/new TBF
establishments/old TBF releases). Besides the flexible Abis allocation strategy is a
slow process compared to the GPRS/EGPRS Link Adaptation procedure (see the
chapter: "10.7 Link Adaptation"), hence the two processes shall be synchronized;
• the total Abis capacity per BTS increases with the introduction of higher data rates
at the Um interface. Then, the flexible Abis allocation strategy must be coupled with
the management of up to 4 Abis PCM lines per BTS.
The table below shows how packet switched services can be mapped in 16 kbit/s, or
N*16 kbit/s Abis resources (per radio timeslot).
16 kbit/s N x 16 kbit/s
GPRS channels supporting EGPRS (up to 5x16 kbit/s)

CS1 and CS2 only GPRS channels supporting
CS3/CS4 (up to 2x16 kbit/s)
Tab. 6.3Mapping of Services onto Abis Resources
The flexible Abis allocation strategy coupled with the concept of concatenated PCU
frames has the following characteristics:
– the Abis interface handling is more efficient: a common pool of Abis timeslots is
associated to a BTSM; then these Abis resources are 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.
The flexible Abis allocation strategy is managed by two different processes:
1. the first task is the configuration of the Abis timeslots: the operator can assign to
every BTSM a pool of Abis timeslots. These timeslots will be used to transfer infor-
mation between the BTSM and the BSC;
2. the second task relies on the flexible allocation and release of resources taken from
the Abis pool. The Abis allocation algorithm is able to:
– assign sufficient Abis bandwidth to an air interface timeslot during run time;
– release bandwidth in case of congestion, according to service priorities and QoS
constraints.
Traditional Static Abis management is maintained for backward compatibility with
i previous releases to harmonize O&M Management of flexible and static BTSM.
Besides:
• flexible abis allocation means that the association between radio timeslots and
Abis timeslots is performed by radio signaling procedures. There is not a fixed
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;
152 A30808-X3247-M24-5-7618
System
• static abis allocation means that the association between radio timeslots and Abis
timeslots is performed during O&M procedures, stored into BSC database and
signaled to BTSM by O&M signaling procedures. The association is fixed during
runtime and can only be changed via O&M reconfiguration.
To simplify the configuration procedures, the operator commands used to configure both
“flexible” and “static” allocations for a BTSM are the same. In cases 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;
– hardware supporting the flexible Abis allocation and concatenated PCU frames;
– configuration of the Abis interface;
– algorithms supporting the flexible Abis allocation.
6.3.1 Concatenated PCU Frames

The PCU frame is used to transmit packet data traffic on the Abis interface, whereas the
similar TRAU frames are used for transmitting voice traffic,
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 (for example with 32 kbit/s,
48 kbit/s, 64 kbit/s and even 80 kbit/s) than the current 16 kbit/s ones. This higher band-
width is achieved by concatenating several 16 kbit/s subframes (1 up to maximum 5
EDGE subframes). In total, 5 subframes (instead of 4) are necessary for 60 kbit/s
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. At the moment, a PDCH with a MCS9 TBF on it requires
16 kbit/s*5 = 80 kbit/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 the future.
The Sub-Frame-Counter (SFC) indicates the sub-frame number and provides the
sequence order of the 16 kbit/s channels. The SFC is coded by 5 bits, which allow a
maximum chain of up to 32 concatenated PCU subframes as represented in the
"Fig. 6.4 Fundamental Principle of Concatenated PCU Frames".
The receiving side (either PCU in uplink or BTS in downlink direction) is able to reas-
semble the subframes to achieve the original complete RLC/MAC block.
A30808-X3247-M24-5-7618 153
System
SFC=00000 SFC=00001 SFC=00010 SFC=000100
MCS/CS
Data Data
1st Subframe Following Subframes Last Subframe
Fig. 6.4 Fundamental Principle of Concatenated PCU Frames
Concatenated PCU frames transport, for each coding scheme of GPRS/EGPRS

services, the following number of bits, in the downlink and in the uplink direction respec-
tively as represented in the following table below:
Coding Number of bits transmitted in DL/UL

scheme (corresponding to the total size of the
RLC/MAC block)
CS1 184
CS2 271
CS3 315
CS4 431
MCS1 209
MCS2 257
MCS3 329
MCS4 385
MCS5 478/487
MCS6 622/631
MCS7 940/946
MCS8 1132/1138
MCS9 1228/1234
Tab. 6.4 Coding scheme and number of DL/UL transmitted bits
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.
154 A30808-X3247-M24-5-7618
System
Header Check Sequences (HCS), Block Check Sequences (BCS) and Tail Bits are
added by the BTS coder.
Mobile Stations 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 (for
example 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 know how many Abis subslot are allocated to an air interface
channel and both know which PCU subframe with which SFC is mapped on each 16
kbit/s Abis subslot. That means: in cases 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 are arbitrarily distributed over PCM
24/30 Abis lines: they are not necessarily allocated 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 for a given PDCH, all the allocated TBFs use the same Abis subslots for concate-
nated PCU frames with the same SFC.
Although all the subframes have an equal size of 40 Octets = 320 bit (16 kbit/s bit rate),
the shape of the first subframe and the other consecutive subframes is a little bit
different.
The next Fig. 6.5 shows an example of the Abis mapping for a DL MCS9 radio block
requiring 5 Abis subslots; the first subframe in the figure has a payload of maximum 216
bits, 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 are filled with a
predefined bit pattern, for example: 11111111...... In cases of a coding scheme, which
requires less subframes than the PDCH has allocated, those completely unused
subframes are idle subframes also filled with the bit pattern 111111.... . These idle
subframes are based on the coding of the additional subframes.
A30808-X3247-M24-5-7618 155
System
Concatenated PCU Frames

SFC=00000 SFC=00001 SFC=00010 SFC=00011 SFC=00100
216 bits 272 bits
174 272 146 124 272 196

Data Data Data Data Data Data
Bits Bits Bits Bits Bits Bits
2 bits 2 bits 76 bits

40 Bits E, FBI E, FBI (11111..11)
RLC/MAC Filling Pattern
Header
(incl. USF)
1st RLC Data Block 2nd RLC Data Block
Fig. 6.5 Abis Mapping for a DL MCS9 radio block
Since users multiplexed on the same PDCH can not use a different number of PCU sub-
frames 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 Mobile
Station using the MCS9; in this case, Mobile Stations using MCSs lower than MCS9
have some idle PCU frames with a filling pattern (e.g. 1111111...), due to the require-
ment that all the 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 (for example,
156 A30808-X3247-M24-5-7618
System
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 signaling overhead, the release of allocated Abis capacity is
not executed immediately.
Standard PCU frames can be still be used even combined with flexible Abis allocation
i strategy. Dynamic Abis allocation does not imply the usage of concatenated PCU
frames. Standard PCU frames are used whenever BTS does not support concatenated
frames.
6.3.2 Flexible Abis Allocation and Concatenated PCU Frames

As it has been described, the dynamic Abis allocation does not imply “concatenated
PCU frame” usage in packet flows.
The next figures show the relationship among standard/concatenated PCU frames and
flexible/static Abis allocation, depending on the BTSE type and on the BSC type.
BSC/72,BSC/120
BTSplus, E-microBTS II
Both standard and
- Standard/Concatenated PCU frames supported
concatenated PCU frames
- CS1...CS4 supported Concatenated PCU frames are supported.
- MCS1...MCS9 supported on EDGE carriers
-Dynamic Abis allocation supported
BTS-2x/6x with BBSIG44, E-microBTS
- Standard/Concatenated PCU frames supported Concatenated PCU frames Dynamic Abis

- CS1...CS4 supported
- Dynamic Abis allocation supported
allocation
BTS-2x/6x without BBSIG44
- Only Standard PCU frames supported

- Only CS1 and CS2 supported
Standard PCU frames
Fig. 6.6 Relationship between PCU Frames and Abis Allocation
A30808-X3247-M24-5-7618 157
System
BSC/46
BTSplus, E-microBTS II
Only standard
- Standard/Concatenated PCU frames supported
PCU frames
- CS1...CS4 supported Standard PCU frames are supported.
- MCS1...MCS9 supported on EDGE carriers
-Dynamic Abis allocation supported
BTS-2x/6x with BBSIG44, E-microBTS
- Standard/Concatenated PCU frames supported Standard PCU frames Dynamic Abis

- CS1...CS4 supported
allocation
BTS-2x/6x without BBSIG44
- Only Standard PCU frames supported

- Dynamic Abis allocation supported Standard PCU frames
Fig. 6.7 PCU Frames and Abis Allocation Relationship (BSS < BR8.0)
It is important to underline what follows:

– 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 the static Abis allocation. The Fig. 6.8 represents an
example of 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 handling such kind of situations since:
– Static allocation and standard PCU frame format are implemented on the BSC;
– The operator commands for a release supporting the flexible Abis allocation strategy
have a “backward compatible” meaning and management (Abis pool definition 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.
158 A30808-X3247-M24-5-7618
System
BSC Hardware
Software Release
supporting Dynamic
Allocation
All BTS Hardware with Dynamic Abis

Static Abis Software Release allocation
- Only Standard PCU frames supported Standard PCU frames

Static Abis
- Only Static Abis allocation supported allocation
Fig. 6.8 BTSE not supporting the Abis Dynamic Allocation
6.3.3 Configuration of 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 cases 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 the Abis Subpool and the Abis Pool concepts have
been implemented.
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.
A BTSM can be connected to BSC by means of four PCMB lines. Each line shall contain
i at least one LPDLM related to BTSM.
This is an operator constraint, valid for all the supported 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 purposes, to
manage a correct fault propagation from the LPDLM to Abis resources.
In this way the user can create a certain number of subpools that will contain a specific
number of timeslots of the Abis interface for connecting the BSC to a specific BTSM.
To configure an Abis subpool the SUBTSLB Managed Object is used. SUBTSLB indi-
cates 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 conse-
quence the BTSM) that is related to this subslot.
A30808-X3247-M24-5-7618 159
System
The user shall create more instances of the SUBTSLB object, linking them to the same
LPDLM instance (for example to the same BTSM) by the ASSLAPD attribute for creating
on a PCMB line a subpool for a specific BTSM,
Referring to a BTSM, the Abis Pool is the amount of 16 kbit/s Abis subslots reserved to
the BTSM for traffic services (for example it is the amount of SUBTSLB instances,
configured on different PCMB lines and associated, through the ASSLAPD, to the
LPDLMs related to the BTSM).
It shall be noted that:
– in cases of BTS supporting dynamic Abis allocation, Abis subslots are selected from
the Abis pool and allocated to radio channels at channel activation. In cases of
GPRS and EGPRS, changes of the Abis resources assigned to an air interface
timeslot are possible during TBF-operation via the channel modification command;
– in cases 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
the radio channels and Abis subslots is sent to the BTS by O&M Abis signaling (at
the radio channel creation). The number of Abis subslots to be statically associated
to the air timeslot is always 1 for BTSs running with old software releases.
Abis pools and subpools have the following properties and features:
• different Abis subpools, belonging to the same or different Abis pools, can be
defined 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 neighbor 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.
6.3.4 Algorithms Regarding Flexible Abis Allocation

Regarding packet switched services, the BSC call processing (TDPC) handles dynam-
ically GPRS/EGPRS PDCHs which could require:
– 1 Abis subslot in case of CS1, CS2 (using standard PCU frames) and MCS1 coding
schemes;
– 2 Abis subslots in case of CS2 (using concatenated PCU frames) 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 the channel activation
procedure; then the BSC informs the BTS by the CHANNEL ACTIVATION message.
160 A30808-X3247-M24-5-7618
System
Changes of the Abis resources assigned to a PDCH are also possible during TBF oper-
ations by the MODIFY ABIS CHANNEL message.
In presence of Abis Allocation, Abis subslots are selected from pool and allocated to
i radio channels by means of O&M procedures. The relationship between Radio Channel
and Abis sublot is sent to BTS by means of Abis signaling.
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 cases 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 16 kbit/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 to each other. As far as possible, the
Abis subslots for the same PDCH are selected from the same PCMB. For each allocated
Abis subslot, one PDT is allocated. But each Abis subslot of a Radio Channel is coupled
with a specific SFC, such that in cases of multiplexing several GPRS/EGPRS TBFs on
the same PDCH, the data of each TBF is transported in a fixed, predetermined way. All
PCU frames with the same SFC must be transported with the same 16 kbit/s Abis
subslot.
In cases of packet switched services, the initial Abis assignment can be changed
dynamically during operation due to:
– radio propagation conditions of the channels (Link Adaptation);
– pre-emption of circuit switched services over packet switched services (see the
chapter: "5.7.7.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 resources 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 attribute: GUARMABIS related
to the BTS Managed Object.
The BSC informs the BTS about the Air timeslots/Abis subslots relationship by two
messages:
– the CHANNEL ACTIVATION message, when a new PDCH is set up;
– the MODIFY ABIS CHANNEL message, when for one or more already assigned
PDCHs a different number of Abis subslots is needed.
The following situations are analyzed:
CHANNEL ACTIVATION Message:

Both the air interface (carrier, timeslot) and the Abis resources (subslots from the Abis
pool) are included in the message: CHANNEL ACTIVATION sent from the BSC to the
BTS. After having received the message: CHANNEL ACTIVATION , the BTS connects
the indicated Abis resources with the Air interface timeslot.
The CHANNEL ACTIVATION message contains the following additional information:
• a list of 16 kbit/s Abis subslots assigned to the air interface timeslot; in cases of
multiple Abis subslots, information on the SFC numeration is given too;
A30808-X3247-M24-5-7618 161
System
• the PCU frame format type: it can be standard or concatenated.

If the message: CHANNEL ACTIVATION activates a GPRS or EGPRS PDCH, the BTS
connects the concatenated PCU frames depending on their SFC with the particular Abis
channel(s). If the activation is successful, the BTS sends the message: CHANNEL
ACTIVATION ACK to the BSC, otherwise it sends the message: CHANNEL ACTIVA-
TION NACK.
MODIFY ABIS CHANNEL Message:

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, first the coding scheme of (all) TBFs on the PDCH
is adapted by PCU RLC/MAC signaling messages, then the Abis capacity is
changed by the MODIFY ABIS CHANNEL message; however that superfluous 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, first the Abis capacity is changed by the MODIFY
ABIS CHANNEL message, then the Abis subslots are aligned and finally 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 message must submit - just like the CHANNEL ACTIVA-
TION message - as a parameter the list of Abis subslots and their corresponding
subframe counters (SFC). It must be guaranteed that the lists within CHANNEL ACTI-
VATION 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 cases of downgrading and adds subframes with adjacent
higher SFCs in case of upgrading. It is not allowed to modify the SFC to an already allo-
cated Abis subslot.
The MODIFY ABIS CHANNEL message contains the following information:
– the involved timeslot (specifying carrier and timeslot numbers);
– the new list of 16 kbit/s Abis subslots assigned to the air interface timeslot.
6.3.5 Abis over satellite links

Abis interface is supported over satellite links. This transmission mode is the most
common implementation and it is often used to extend the GSM and GPRS/EGPRS
services to new locations with minimal infrastructure costs. For the reason that GSM
traffic grows also at remote sites, additional BTSs or a BSC may be deployed to support
higher traffic loads and/or a larger geographical area.
The satellite Abis configuration has the advantage that a minimal expense is requested
for deploying the service. An existing MSC and BSC can be used, which could possibly
support the satellite connections to several remote locations.
The main disadvantage of the satellite Abis configuration is that the remote locations
relies heavily on the equipment located at the hub side so hand-offs and also eventual
subscriber to subscriber calls must go over the satellite link increasing load and traffic.
Besides “AMR Link Adaptation” is not supported in case of Abis satellite links. The
configuration’s parameters together with the related commands requested for the Abis
over satellite links are described in the manual: “CML:BSC”.
162 A30808-X3247-M24-5-7618
System
Besides the value of the attribute: “nRLCMAX” (this attribute determines the number of
the RLC data blocks before the Ack/Nack block is requested) of the PCU Managed
Object has been changed from “20” to “15” for reducing the problem related to the Abis
satellite’s delay. This attribute is not configurable.
6.4 Packet Switched Services Supported on CCCH/PCCCH

In the previous chapters it has been described in which way it is possible to support the
GPRS/EGPRS common signaling either on already existing CCCH channels (shared
CCCHs) or on dedicated CCCH channels (PCCCHs).
To avoid packet switched signaling 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 signaling traffic does not affect the normal signaling,
and the overall traffic capacity is improved.
These logical channels are mapped on different physical resources as represented in
next Fig. 6.9 below.
a) Dedicated CCCH: PCCCH is mapped in the multiframe of a Packet Data Channel
(PDCH); in this case, the common control signaling is carried in a logical channel
dedicated to the GPRS/EGPRS traffic.
b) Shared CCCH: no dedicated control signaling channels exist for the packet switched
data services, so that GPRS/EGPRS common control signaling packets access a
CCCH following its mapping rules. This mechanism is mandatory, whenever a dedi-
cated CCCH channel is not allocated.
TDMA frame
CCCH PCCCH
PDCH
PCMB line
0 31
LAPD
Fig. 6.9 Mapping of CCCH/PCCCH Channels on the Abis Interface.
In both cases signaling messages are processed in the PCU, which is realized in BSC
by means of the PPCU/PPXU boards (Peripheral Processors for GPRS/EGPRS).
A30808-X3247-M24-5-7618 163
System
A short description is given below about the message handling which is implied by the
described mechanisms as represented in next Fig. 6.10:
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
through the switching matrix directly to the PPCU/PPXU boards where the channel
is processed.
b) Shared CCCH: messages are carried in the LAPD channel related to the BTSE. The
channel is routed through the switching matrix to a PPLD where the LAPD protocol
is processed. The extracted messages are read by the TDPC via Telephonic Bus
from the PPLD Dual Port RAM.
In the TDPC, the messages are analyzed: The GPRS/EGPRS related messages are
written by the TDPC via a Telephonic Bus in the Dual Port RAM of the PPCU/PPXU
boards where they are processed.
Fig. 6.10 CCCH/PCCCH Message Handling.
The advantages of the first method (dedicated CCCH) are straightforward:

– on the air interface CCCH performances for normal GSM traffic 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 the LAPDs the messages received from the
PPCUs;
164 A30808-X3247-M24-5-7618
System
– the Telephonic Bus is not loaded (twice) by the exchange of messages among the
PPLD, PPCU/PPXU and the TDPC.
On the other side shared CCCH channels are supported in any case to provide the first
access when no specific GPRS/EGPRS signaling channels are allocated.
Shared CCCH channels are the only way to allow Class B Mobile Stations (see the
chapter: "9.1 Mobile Stations for Packet Switched Services") attached to GPRS/EGPRS
to listen to their circuit switched paging channel on the CCCH, when the optional Gs
interface between the MSC and the SGSN is not implemented (see the chapter:
"9.8.3.1 Network Operation Modes for Paging").
A30808-X3247-M24-5-7618 165
System
7 Gb Interface
Gb interface connects BSC to SGSN network node, transferring signaling information
and user data. Several BSCs can be interconnected to one SGSN through Gb interface.
Main characteristics of the Gb interface are the following:
a) The resources are assigned to an user upon activity (when data is sent or received)
and they are reallocated immediately thereafter; this behaviour is different respect
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 signaling and user data are sent in the same physical channel. No
dedicated physical resources are required to be allocated for signaling purposes
(like for example the A interface where SS7 links are used to transmit signaling
between the BSC and the MSC).
Gb Protocol stack is shown in next Fig. 7.1.
Fig. 7.1 Gb Interface: Protocol Stack

Layers provide the following functions:
• L1: it specifies the Layer 1 of the Gb interface. Frame Relay (FR) is used for
GPRS/EGPRS in a first phase.
• Network Service (NS): it performs transport of Service Data Units (SDU) between
the SGSN and the BSS Network Elements. The Gb interface is based on Frame
Relay (FR) as specified in the GSM 08.16 Recommendation.
FR supports high data rate transmission with low delay. Frames of different sizes
could 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 the following:
– providing connection-less links between the SGSN and the BSS (layer 2 level);
– providing tools for bi-directional control of data flow;
– handling paging requests from the SGSN to the BSS.
166 A30808-X3247-M24-5-7618
System
• LLC (Logical Link Control layer): This protocol provides logical links between a
Mobile Station and the corresponding SGSN network node. The transport of both
data and signaling is supported;
• SNDCP (SubNetwork Dependent Convergence Protocol): it supports a direct peer
to peer (for example point-to-point) communication between a Mobile Station and a
SGSN network node. User data is transported by a network layer protocol, for
example the IP or X.25 protocol.
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 realiza-
tion of the network, whereas the Sub-Network Service entity is the Frame Relay
protocol.
7.1 Physical Layer

Four types of configurations are supported for interconnecting the BSC and the SGSN:
1. a direct line (for example PCM30, PCM24) 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 the MSC, without using an intermediate frame relay network.
The different configurations are illustrated in the Fig. 7.2.
Fig. 7.2 Connection Types between BSC and SGSN
The Gb interface is realized by PCM lines:

• in cases of direct connections between the BSC and the SGSN, the related PCM
lines are called PCMG;
• in cases of connections through the MSC (and TRAU), the PCMA lines are used.
A30808-X3247-M24-5-7618 167
System
The PCMG object represents the PCM line used to connect the BSC and the SGSN,
without passing through the MSC.
PCMG This Functional Managed Object models the

direct physical connection between the BSC
and the SGSN network node.
Tab. 7.1 PCMG Functional Managed Object
On the PCMG line, 31 physical channels, of 64 kbit/s each one, can be handled (slot 0
is always use for synchronization purposes).
In case of BSC/46 (only for releases < BR8.0) , 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/s channels
(16 channels for each PCU) that can be equipped toward the Gb interface, also
providing the possibility to have fault redundancy.
When the BSC/72 (High Capacity BSC step I) is used, in order to completely exploit the
bandwidth that the six PPXU boards offer towards the Gb interface (in total 378 time
slots at 64 kbit/s), 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 most with the
BSC/72.
When the BSC/120 (High capacity BSC step II) is used, in order to completely exploit
the bandwidth that the 12 PPXU boards offer towards the Gb interface (in total 756 time
slots at 64 kbit/s), 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 with the
BSC/120.
As it has been described in the chapter "6 Hardware and Software Architecture", each
PCU manages the packet switched data traffic of a specific number of cells; to transmit
packet data (or signaling) 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 necessary for the PCMG configuration:
• PCML: this attribute identifies the LICD number (range 0 to 9), 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 the STLP boards are
i used in the BSC (for example when the BSC.120 rack), otherwise that
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;
168 A30808-X3247-M24-5-7618
System
• NUA: this attribute enables or disables handling of not urgent alarms on PCMG line;
• 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 the 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 the GSM 08.14 Recommendation; it is
called Frame Relay Link (FRL).
The Frame Relay Link is a n X 64 kbit/s 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
as represented in next Fig. 7.3.
FRL_1 (Channelized FRL))

PCM line
0 31
PCM line
0 31
FRL_2 FRL_3
(Fractional FRL) (Fractional FRL)
Fig. 7.3 Example of Frame Relay Links
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 Functional Managed Object represents the physical channel over the Gb
interface between the BSC and the SGSN network node.
FRL This Functional Managed Object models the

physical link connection on the Gb interface.
Tab. 7.2 FRL Functional Managed Object
In case of A interface connections, the 64 kbit/s time slots are reserved on PCMS (and
PCMA) lines and handled in the TRAU as transparent channel. In case of direct Gb inter-
face connections (for example connections built without passing through the MSC),
A30808-X3247-M24-5-7618 169
System
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 on the basis of the bandwidth required on the Gb interface (in case of a small
number of FRL links, it is advantageous to use A interface connections).
In case of A interface connections, with multislot links, the customer must 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 BSC/46 is used (for releases < BR 8.0), up to 32 frame relay links can be
created for each BSC (with range 0 to 31). As described in the chapter: "6 Hardware and
Software Architecture", each PCU is able to handle 1 Mbit/s data flow towards the Gb
interface. This flow corresponds to a flow obtained by 16 slots (64 kbit/s 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/s can be configured;
– or only a single FRL with 1Mbit/s can be configured.
When the BSC/72 is used, up to 378 frame relay links can be created for each BSC (with
range 0 to 377). As described in the chapter "6 Hardware and Software Architecture",
each PCU is able to handle a 4 Mbit/s data flow towards the Gb interface. This flow
corresponds to a flow obtained by 63 slots (64 kbit/s 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/s can be configured.
When the BSC/120 is used, up to 756 frame relay links can be created for each BSC
(with range 0 to 755). As described in the chapter "6 Hardware and Software Architec-
ture", each PCU is able to handle a 4 Mbit/s data flow towards the Gb interface. This
flow corresponds to a flow obtained by 63 slots (64 kbit/s 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/s can be configured.
When creating a Frame Relay Link the operator specifies which PCU it belongs to
configuring the PCUID attribute. This attribute indicates the pathname of the PCU
managing the FRL.
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 it allows the configuration of a 64 kbit/s Frame Relay link on the slot
number 3 of the PCM line which is specified by the GLK attribute as represented in
Fig. 7.4;
– setting GTS= 3&4&5&6 it allows the configuration of a 256 kbit/s Frame Relay link
on slots number 3, 4, 5 and 6 of the PCM line which is specified by the GLK attribute
as represented in Fig. 7.5;
– setting GTS= 3&4&7&8 it allows the configuration of a 256 kbit/s Frame Relay link
on slots number 3, 4, 7 and 8 of the PCM line which is specified by the GLK attribute
as represented in Fig. 7.6.
170 A30808-X3247-M24-5-7618
System
0 31
64 kbit/s Frame Relay Link
Fig. 7.4 Example of Frame Relay Link (GTS=3).
0 31
Fig. 7.5 Example of Frame Relay Link (GTS=3&4&5&6).
0 31
Fig. 7.6 Example of Frame Relay Link (GTS=3&4&7&8).

The operator, setting the FRSTD attribute, can also optionally indicate the frame relay
standard to be used (regarding the frame relay structure, see 7.2.1.2).
Considering the configuration for each PCU of 2 FRLs, these links can be distributed on
the Gb interface in different manners, by setting the GTS attribute, for example like
follow:
– it is possible to put the two links on the same PCMG line;
– it is possible to distribute them on two different PCMG lines (this situation is obvi-
ously 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 the connection between
the BSC and the SGSN to be maintained);
– 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 (for example the lines correspond to the same PCMS line), the FR
links shall have different timeslot values for the GTS attribute.
A30808-X3247-M24-5-7618 171
System
Instead, if the lines belong to different TRAU modules this problem does not exist. This
last solution is obviously better than the previous one, since it provides the redundancy
of FRLs.
The PCMG/PCMA lines are shared between the configured PCUs, whereas each
i 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 network node; this reliable connection is realized as follow:
a) within the FR network, when such network exists between the two entities;
b) with a direct link, in cases of point-to-point connections.
Error detection is performed, while error recovery is left to upper layers.
The Network Service entity is composed of the following services as represented in
Fig. 7.7:
1. the Sub-Network Service (for example the Frame Relay protocol), which is an entity
dependent on the intermediate Gb interface network;
2. the Network Service Control, for example 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 Perma-
nent Virtual Circuits have been 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 no call set-up or clearing: a connection to the frame relaying node
shall be in place from the configuration point of view.
The NSVC (Network Service Virtual Connection) Functional Managed Object
represents the end-to-end permanent virtual connection between the BSC and the
SGSN network node.
172 A30808-X3247-M24-5-7618
System
NSVC This Functional Managed Object models the

end-to-end communication between the BSS
and the SGSN network node.
Tab. 7.3 NSVC Functional Managed 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 (for
example for each Frame Relay physical link) more than one NSVC can be created.
Referring to the 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,
for example it is the link at the User Network Interface (UNI);
• the Data Link Connection (DLC) defines the entry point to the FR network. A DLC is
identified by a DLC Identifier (DLCI);
• the Network Service Virtual Link Identifier (NSVLI) is the DLCI together with the
bearer channel identifier (FRL). A physical link supports one or more NSVLs; each
one is identified by a NSVLI.
Frame Relay physical link
Fig. 7.8 Gb Interface with a Frame Relay Network
A30808-X3247-M24-5-7618 173
System
When creating a new PVC, for example when creating a new instance of the NSVC
Functional Managed Object, the user shall specify the following:
1. the Network Service Virtual Connection Identifier (NSVCI) of the NSVC, for example
the common and absolute identification of the virtual connection between the SGSN
and the BSS; to specify this value the NSVCI parameter shall be used;
2. the Network Service Virtual Link Identifier (NSVLI) to identify the NSVC on the local
(BSS) side. To specify this value the NSVLI parameter is used; this parameter is
composed of two fields:
– the first one (FRLN) indicates the Frame Relay physical link on which the perma-
nent virtual circuit is created;
– the second one (DLCIN) indicates the DLCI number; this identifier (that is the
address of the Frame Relay packets, see the chapter: "7.2.1.2 Frame Relay
Structure") allows a distinction between different NSVCs that belong to the same
physical Frame Relay link.
The mapping of the DLCI parameter is the following:
DLCI value Mapping

0 In band signaling
1-15 Reserved
16-511 Available for user information
512-991 Available for user information
Since Frame Relay Physical links are statically associated to a single PCU, even the
i 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
i identified by the Network Service Entity Identifier (NSEI).
The NSEI is the logical entity of the SGSN that manages a single PCU; as a conse-
quence 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 (for example if a Frame Relay Network is not used), the two values related to one NSVC
are the same; for example 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 irre-
spective of the exact configuration of the Gb interface, the concept of Network Service
174 A30808-X3247-M24-5-7618
System
Virtual Connection (NSVC) is used. At each side of the Gb interface there is a one-to-
one correspondence between the NSVCs and NSVLs.
The creation of a NSVC involves the following Managed Objects as represented in next
Fig. 7.9:
Database object instance: NSVC-3 It defines the end-to-end connec-

tion between the SGSN and the
BSC/PCU.
Parameters for NSVC-3: NSVCI=5 It is the Internal identifier of the
FR network connecting each side
of the network.
NSVLI=0-111 FRL object 0, DLCI 111.
Local connection at BSC/PCU
side.
Similarly a NSVLI value must be
defined at the SGSN side.
Fig. 7.9 Creation of a NSVC

To complete the previous concepts, some examples regarding the configuration of both
Frame Relay Links and Permanent Virtual Connections (NSVCs) are described. It is
considered a BSC that is connected to the SGSN network node with two direct PCMG
lines (PCMG-0 and PCMG-1).
EXAMPLE 1: BSC Configured with One PCU and Two Frame Relay Links of 64
kbit/s each.
Two frame relay links of 64 kbit/s each have been created for a BSC configured with a
single PCU. The PCU has been configured with a NSEI value equal to 2354
(see Fig. 7.10).
The PCU sees a total bandwidth of 128 kbit/s (64 kbit/s + 64 kbit/s).
A30808-X3247-M24-5-7618 175
System
FRL:0
NSEI = 2354
PCUID:PCU-0
GLK:PCMG-0
GTS:2
PCMG-0
PCU- 0
0 31
PCMG-1
0 31
FRL:1
PCUID:PCU-0
GLK:PCMG-1
GTS:5
Fig. 7.10 BSC Configured with One PCU and Two FR Links (64 kbit/s each).
A PVC for each FRL is now created; the 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 494
FRLN 0
NSVLI
DLCI 100
NSVC 512
FRLN 1
NSVLI
DLCI 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/s each.
Two frame relay links of 128 kbit/s each have been created for a BSC configured with a
single PCU. The PCU has been configured with a NSEI value equal to 2354
(see Fig. 7.11).
The PCU sees a total bandwidth of 256 kbit/s (128 kbit/s + 128 kbit/s).
176 A30808-X3247-M24-5-7618
System
FRL:0
NSEI = 2354 PCUID:PCU-0
GLK:PCMG-0
GTS:2&3
PCMG-0
PCU- 0
0 31
PCMG-1
0 31
FRL:1
PCUID:PCU-0
GLK:PCMG-1
GTS:5&8
Fig. 7.11 BSC supporting 1 PCU and 2 FR Links

A PVC for each FRL has now to be created; The 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 isn’t any difference
with respect to the previous example, even if the FRL:1 has been created using two non-
adjacent timeslots.
Obviously the network shall be enable to support one FRL created with two non-neigh-
boring slots.
EXAMPLE 3: BSC Configured with Two PCUs and Two Frame Relay Links of 128
kbit/s each.
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 identified by the NSEI= 7564 (see Fig. 7.12).
For each PCU, two frame relay links of 128 kbit/s each have been created; the PCU sees
a total bandwidth of 256 kbit/s (128 kbit/s + 128 kbit/s).
A30808-X3247-M24-5-7618 177
System
FRL:0 FRL:2
NSEI = 2354 PCUID:PCU-0 PCUID:PCU-1
GLK:PCMG-0 GLK:PCMG-0
GTS:2&3 GTS:8&9
PCMG-0
PCU- 0
0 31
PCU- 1
PCMG-1
0 31
FRL:1 FRL:3
NSEI = 7564 PCUID:PCU-0 PCUID:PCU-1
GLK:PCMG-1 GLK:PCMG-1
GTS:5&7 GTS:10&11
Fig. 7.12 BSC Configured with Two PCUs and Two FR Links each one.
A PVC for each FRL has to be created; The 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 the NSVCs used
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 the NSVCs used to support its traffic.

NSVCI 480
FRLN 0
NSVLI
DLCI 163
NSVCI 555
FRLN 1
NSVLI
DLCI 100
NSVCI 574
FRLN 2
NSVLI
DLCI 100
Tab. 7.5 Example of NSVC Values Setting for both PCU-0 and PCU-1
178 A30808-X3247-M24-5-7618
System

NSVCI 575
FRLN 3
NSVLI
DLCI 216
Tab. 7.5 Example of NSVC Values Setting 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 excludes those associated with sequencing, most forms
of error detection, error recovery and flow control.
Referring to the Frame Relay frame format as represented in next Fig. 7.14, the Sub
Network Service functionality provides the following functions:
a) Delimiting, alignment and transparency using the “Flag” field;
b) Multiplexing/De-multiplexing using the “Address” field. This function permits one
or more core connections to exist across a single physical connection;
c) Error detection using the “FCS” field (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 the data integrity is not
affected because error correction can be left to an higher-layer protocols running on
the top of Frame Relay.
d) Congestion control using the “FECN”, “BECN”, and ”DE” fields. This function
permits the 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-notification mechanisms:
– Forward-explicit congestion notification (FECN);
– Backward-explicit congestion notification (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 Eligi-
bility (DE) bit, which is used to identify less important traffic that can be dropped
during periods of congestion.
The FECN mechanism is initiated when a DTE device (for example in our case the
SGSN) sends Frame Relay frames in the network (see Fig. 7.13).
A30808-X3247-M24-5-7618 179
System
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 field
(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 higher-
layer protocol for processing. Depending on the implementation, flow-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 can then
relay this information to an higher-layer protocol for processing. Depending on the
implementation, flow-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 have the DE bit set. 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 configure the width of the observation
window used for the congestion detection. The congestion detection regards the
path from the SGSN to the BSC ( for example it regards the frame relay frames
sent by the SGSN to the BSS).
If, during the time defined 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 notification to upper layers, no other notifications
are foreseen for a length of time defined by TCONOFF. This timer is needed to
provide an hysteresis time in order to ensure that the traffic reduction at the
Mobile Station can be effective.
180 A30808-X3247-M24-5-7618
System
All data link peer to peer communications use frames conforming to the format shown
in the Fig. 7.14.
Fig. 7.14 Frame Relay Frame Structure
The basic Frame Relay fields are the following:

• Flags:it delimits the beginning and end of the frame. The value of this field is always
the same and it is represented either as the hexadecimal number 7E or the binary
number 01111110;
• Address: This field contains the following information:
– DLCI: the 10-bit DLCI is the essence of the Frame Relay header. This value repre-
sents 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 significance only, which means that
they are unique only to the physical channel on which they reside. Therefore
devices at the 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 the chapter:
"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 field. If the value is 1, then the current byte is
determined to be the last DLCI octet. Although current Frame Relay implementa-
tions 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 field is used to indicate the
EA.
– C/R: it is the bit that follows the most significant DLCI byte in the Address field.
The C/R bit is not currently defined.
– Congestion Control: it consists of the three bits that control the Frame Relay
A30808-X3247-M24-5-7618 181
System
– congestion-notification mechanisms. These are the FECN, BECN, and DE bits,

which are the last three bits in the Address field.
• Data: This field contains encapsulated upper-layer data. Each frame in this variable-
length field includes a user data or payload field that will vary in length up to 16,000
octets. This field serves to transport higher-layer protocol packets (PDUs) through a
Frame Relay network.
• Frame Check Sequence: This field ensures the integrity of transmitted data. This
value is computed by the source device and verified by the receiver to ensure the
integrity of the transmission.
7.2.1.3 Procedures for PVCs

For each group of PVCs belonging to a FRL, a periodic polling procedure is used for
acquiring the general status about the connection between the BSC and the SGSN
network node. 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) notification of the addition of a PVC: it notifies the users of newly added permanent
virtual circuits;
b) detection of the deletion of a PVC: it notifies the users of the deleted permanent
virtual circuits;
c) notification of the availability (active) or unavailability (inactive) state of a configured
PVC: it determines the changes in status of configured PVCs;
d) link integrity verification: it determines the in-channel signaling link DLCI-0. Estab-
lishing and releasing a logical connection is accomplished by exchanging messages
via DLCI-0. The Link Integrity verification 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 the
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 config-
ured PVCs is not changed, the network answers with a normal STATUS message;
it is used only to verify the link integrity (this message does not contain the state
of the configured 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 configured 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 (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 does not receive an answer from the SGSN, an “error counter”
is incremented;
182 A30808-X3247-M24-5-7618
System
5. if the “error counter” reaches the N392 value during the error observation window
defined by the following formula:
N393 * T391
the Frame Relay link goes into the Operational State: Disable , and all the contained
PVCs are, as a consequence, into the Operational State:Disable;
6. if the N392 threshold is not reached during the error observation window, the “error
counter” is restarted.
PCU SGSN
Expiration of STATUS_ENQUIRY
T391
STATUS
Reset,
restart T392
Expiration of STATUS_ENQUIRY
T391
STATUS
Reset,
Expiration of restart T392
T391
STATUS_ENQUIRY
N391 polling
cycles reached
FULL_STATUS
Fig. 7.15 Periodic Polling Procedure
The value of the T391 timer set on the BSC shall be lower than the value of the T392
i timer set on the SGSN.
7.2.2 Network Service Control

The Network Service Control entity is responsible for the following functions:
• NS SDU transmission: the NS SDUs are transmitted on the configured 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 trans-
ferred in order;
• Load sharing: the load sharing function distributes the NS SDU traffic among the
available (for example not blocked) NSVCs.
• NSVC management:
– a blocking procedure is used by a NS entity to inform an NS peer entity when an
NSVC becomes unavailable for NS user traffic;
– an unblocking procedure is used for the reverse operation;
A30808-X3247-M24-5-7618 183
System
– a reset procedure is used between peer NS entities in order to set an 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 the 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 where to send NS
SDUs among unblocked NSVCs of the addressed BVC,
Each BVC represents a GPRS/EGPRS cell in the PCU (see the chapter: "7.3 BSSGP
i Protocol"); the load sharing function allows transmission of 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 (for example 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 traffic (for example one or
more NSVCs become blocked or unblocked) results in a reorganization of the NS
SDU traffic among the unblocked NSVCs;
• for a BVC, when there are no unblocked NSVCs between a BSS and a SGSN, the
corresponding traffic is discarded by the NS at the sending side.
Load sharing applies only to NS SDUs, not to NS signaling, such as NSVC management
i PDUs (for example NS_BLOCK_PDU used in the NSVC block/unblock procedures, see
the next chapter: "7.2.2.2 Control Procedures").
7.2.2.2 Control Procedures

The procedures for the management of the NSVCs are the following:
• block/unblock of NSVCs executed by the operator;
• reset and test the status of NSVCs.
The Block Procedure inhibits an NSVC from carrying 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 the BSS side.
When the PCU has sent a NS_BLOCK_PDU, it waits TNSVCBLK seconds for an
acknowledgement from the SGSN network node. The NNSVCBLKR parameter speci-
184 A30808-X3247-M24-5-7618
System
fies the maximum number of performed retries by the PCU in the NSVC block proce-
dure; i.e., if the SGSN does not answer the block procedure, the PCU retries the
procedure at most NNSVCBLKR times.
The Unblock Procedure allows the return of a previously blocked NSVC back to
service. 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 attribute specifies the maximum
number of performed retries in the NSVC unblock procedure; i.e., if the SGSN does not
respond 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 the restart of a processor;
– 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 network node) sends the NS_RESET_PDU to its peer entity indi-
cating the NSVCI. The NS_RESET_PDU is sent on the NSVC being reset.
After the PCU sends the NS_RESET_PDU, it waits TNSVCR seconds for acknowledge-
ment. The NNSVCRR parameter specifies the maximum number of performed retries in
the NSVC reset procedure, before generating any alarm; for example if the SGSN does
not respond to the reset procedure, the procedure is retried infinitely times, but after
NNSVCRR times an alarm message is generated.
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 proce-
dure (as specified in the sub-clause "Reset procedure") and will then be periodically
repeated. After unsuccessful attempts, the procedure is stopped; the NSVC is marked
as dead and blocked and 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; for example 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 considered not more
available.
7.3 BSSGP Protocol

The Gb interface allows many users to be multiplexed over a common physical
resource. Both GPRS/EGPRS signaling and user data can be transmitted on the same
physical resource.
The primary functions of the BSSGP protocol include the following:
A30808-X3247-M24-5-7618 185
System
• Transmission of LLC frames from the SGSN to the BSS system, with radio related
information (such as Quality of Service and routing information) which is used by the
RLC/MAC function;
• Transmission of LLC frames from the BSS to the SGSN, with radio related informa-
tion (such as Quality of Service and routing information) which is derived from the
RLC/MAC function;
• Support of the functionalities for enabling both the SGSN and the BSS to perform
management control functions (for example: 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 shall be
taken into considerations:
• each BVC is identified by a BVCI (Virtual Connection Identifier);
• each BVCI identifies univocally a GPRS/EGPRS cell in the PCU;
• each PCU is identified by the Network Service Entity Identifier (NSEI) in the SGSN;
• the couple BVCI and NSEI identifies univocally a GPRS/EGPRS cell in the SGSN;
In the GSM 08.18 Recommendation – for point-to-point packet transfer – it is specified
that a cell is identified by a BVCI, so there is a one to one relationship between a cell
and its own BVCI.
In Siemens implementation, the PTPPKF Functional Managed Object represents the
presence of packet switched data services in a specific cell and the state of this object
allows or disallows the service in the cell.
The dependency from the BTS Managed Object is one to one; this means that all the
state changes related too the BTS Managed Objects are reflected on the PTPPKF
Managed 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, for example the group of all the NSVCs that provide service for a PCU: to
one PCU corresponds only one NSVC group and vice versa.
The PTPPKF state can be affected by:
– BTS state changes;
– specific commands executed on the object;
– state changes on subordinated NSVC objects.
The PTPPKF state transition, due to the NSVC state change, is handled by the system
that puts the PTPPKF object into the disabled state when the associated BVCI is no
longer accessible. All state transitions for the PTPPKF Managed Object are notified to
the remote end via the BVCI Block/Unblock procedure (see 7.3.1.1). The PCU restart or
the BSS initialization are handled generating a reset procedure with the SGSN. Needed
timers for handling Block/Unblock and Reset procedures are defined in the PCU object
(see the chapter: "7.3.1.1 BVC Procedures").
The PTPPKF Managed Object is always created with the instance equal to 0 since it is
subordinate to the BTSM and BTS object following the path:
BTSM:m/BTS:n/PTPPKF:0
186 A30808-X3247-M24-5-7618
System
The BVCI number associated to a PTPPKF Managed Object instance is fixed, and the
relation is:
BVCI number = (number of creation of the PTPPKF in the database) + 2
The 0 and 1 values are reserved respectively for signaling and PTM links.
When an upgrade from the Release BR5.5 to BR7.0 has been executed, some changes
i in the SGSN database occurred. This is due to the fact that, according to the load
balancing schema that is used for the PCUs (see the chapter: "6.1 Supported BSC
Types"), the PTPPKFs (i.e., the BVCIs) are no longer statically assigned to a single
NSEI (for example, to a single PCU) but they can be moved from one PCU to another
one following the PTPPKF distribution algorithm (see the chapter: "8 Load Control for
Packet Switched Services"); so in the SGSN, the BVCIs of one BSC have to be config-
ured 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 configured on the BSC:1;
• PCU:0 configured on the BSC:2.
As represented in the Fig. 7.16, it can be seen that:
a) each PCU is identified in the SGSN by the NSEI attribute:
– the PCU:0 of the BSC:1 is identified by the NSEI_A value;
– the PCU:1 of the BSC:1 is identified by the NSEI_B value;
– the PCU:2 of the BSC:1 is identified by the NSEI_C value;
– the PCU:0 of the BSC:2 is identified by the NSEI_D value;
b) the NSEI attribute also identifies all the configured NSVCs for each PCU:
– the NSEI_A value identifies NSVC:0, NSVC:1 and NSVC:2 connections (related
to PCU:0 of BSC:1);
– the NSEI_B value identifies NSVC:3 and NSVC:4 connections (related to PCU:1
of BSC:1);
– the NSEI_C value identifies NSVC:5, NSVC:6 and NSVC:7 connections (related
to PCU:2 of BSC:1);
– the NSEI_D value identifies 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
i the four PCUs must be different from each other.
c) each cell is identified in the PCU by its own BVCI value;

d) each cell is identified in the SGSN by the couple BVCI and NSEI;
e) the traffic of all the cells (BVCIs) configured for a PCU is distributed among all the
NSVCs configured for the PCU.
A30808-X3247-M24-5-7618 187
System
NSVC group identified by NSEI_A

GPRS
Cell
FRL:0
BVCI= 2
NSVC:0
BVCI=2
GPRS BSC:1\PCU:0 NSVC:1
Cell NSEI_A
NSEI_A BVCI=6
BVCI= 6 NSVC:2
FRL:1
NSVC group identified by NSEI_B

GPRS FRL:2
Cell
BVCI= 5 BSC:1\PCU:1 NSVC:3 BVCI=4
NSEI_B NSVC:4 NSEI_B
BVCI=5
GPRS
Cell
BVCI= 4 FRL:3
NSVC group identified by NSEI_C SGSN

GPRS FRL:4
Cell
BVCI= 3 NSVC:5
BVCI=3
BSC:1\PCU:2 NSVC:6 NSEI_C
NSEI_C BVCI=7
GPRS NSVC:7
Cell
BVCI= 7
FRL:5
GPRS NSVC group identified by NSEI_D

Cell FRL:0
BVCI= 3
NSVC:0 BVCI=2
GPRS BSC:2\PCU:0 NSVC:1
Cell BVCI=3 NSEI_D
NSEI_D
BVCI= 2 NSVC:2
BVCI=4
GPRS FRL:1
Cell
BVCI= 4
Fig. 7.16 Distribution of Packet Switched Data Traffic among Different Cells
188 A30808-X3247-M24-5-7618
System
7.3.1.1 BVC Procedures

For BVCs associated to PTPPKF Managed Objects, the following procedures with
remote end have been implemented:
• BLOCK;
• UNBLOCK;
• RESET.
The BLOCK Procedure inhibits a BVCI from carrying traffic. It is 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, is sent in the BCCH or the PBCCH
channel.
If the PCU does not receive a response from the SGSN after a Block Procedure attempt,
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 the
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 Managed Object is put in enabled state. System information, reporting
GPRS/EGPRS service allowed in the cell, is sent in the BCCH or the PBCCH channel.
If, after an Unblock Procedure attempt, the PCU doesn’t receive a response 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 the acknowledgement. After NBVCUR consecutive repetitions without any answer
from the SGSN an alarm message is generated.
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) that needs to clear and to
synchronize the BVCI status on both sides. Both sides must initiate the procedure inde-
pendently.
If, after a Reset Procedure attempt, the PCU does not receive a response 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
the acknowledgement. After NBVCRR consecutive repetitions, without any answer from
the SGSN network node, an alarm message is generated and sent to the Network
Management System
(Radio Commander).
7.3.2 Quality of Service (QoS)

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

Packet switched data traffic exhibits large statistical fluctuations both for the flow-in into
the PCU as well as for the flow-out over the air interface. The former depends on the
volatility of Internet traffic; the latter is caused by the speciality of the air interface. Vari-
ations to C/I leads to variations of the RLC blocks re-transmission rates. GSM voice calls
have pre-emptive priority and may thus steel time slots allocated to PS services (but not
the GPRS/EGPRS reserved timeslots).
For these reasons two different types of flow control are implemented in the BSS
system:
– BVC Flow Control: the variance both of the inter-arrival times of arriving frames and
deleted RLC blocks causes waiting time in the BVC buffer; as a consequence rate
control schemes are used to smooth traffic and thus reduce variance. This reduces
transmission delays for the user. Additionally, flow control should minimise the prob-
ability of BVC buffer over flow.
– Mobile Station Flow Control: without mobile specific flow control, mobiles with low
individual flow rate (caused for example by being capable of only one timeslot, multi-
plexed with other TBFs on the same timeslot, and large retransmission rates) might
slow down all the other mobiles within the same cell. Because these mobiles cannot
get their data out of the common BVC buffer fast enough, the buffer filling might
increase above a threshold, and the mean BVC flow rate R might slow down. Thus,
the SGSN might narrow the throttle for all other mobiles, too.
For packet transfer from the SGSN to the BSS, the BSSGP protocol uses an address
which is composed of three parts:
• cell Identity (BVCI);
• QoS profile;
• MS identification (for example TLLI).
The Temporary Logical Link Identity (TLLI) identifies univocally a GPRS/EGPRS user,
i who is engaged in the data transfer, inside a cell (see also the chapter:
"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 for each Mobile Station. The SGSN sends the
PDUs to the LLC layer as a function of the requested service type and the Mobility
Management state (see the chapter: "9.3.1 Mobility Management States");
b) in the BSS system, queues per cell (BVC) and per Mobile Station (TLLI) are
provided at the BSSGP level;
c) signaling has its own queue.
190 A30808-X3247-M24-5-7618
System
The BSS controls the flow of packet data units (PDUs) to its BVC buffer for an individual
Mobile Station, by indicating to the SGSN the maximum allowed throughput for a certain
TLLI.
The BSS system 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 trans-
ferred across the Um interface before the PDU lifetime expires; in this case, the PDU is
deleted from the BSS system and the deletion is signaled to the SGSN by the message:
“LLC-DISCARDED PDU” .
It is foreseen a cascaded mobile (MS) and cell (BVC) oriented “flow control scheme”
(see the Fig. 7.17) for the downlink transmission of LLC frames from the SGSN to the
PCU (in uplink transmission the problem does not exist since it is the BSS itself which
schedules the Mobile Station accesses, according to its own radio capacity). A LLC PDU
shall first obtain the permission of the mobile flow control before it is submitted the cell
(BVC) specific flow control.
Fig. 7.17 Cascaded Flow Control
The Token Bucket Algorithm used in the Flow Control procedure works as follow (see
the Fig. 7.18): there is a queue of LLC frames without a permission for the transmission
to the PCU, and a bucket of permits (“tokens”). The LLC frame at the head of the frame
queue obtains a permit if at least one token is available in the permit bucket. In this case,
it joins the buffer of LLC frames with permits waiting to be transmitted, and the token is
deleted. Permits are generated at the rate R as long as the number in the permit bucket
does not exceed a certain threshold “Bmax”. When frames have different sizes, a token
should be thought as the permission to transmit one byte. A frame p of size L(p) will
obtain the permit for transmission, if at least L(p) tokens are available in the bucket.
A30808-X3247-M24-5-7618 191
System
Fig. 7.18 Token Leaky Bucket (in the SGSN network node)
On the PCU side, there is for each BVC or Mobile Station a buffer which is filled by the
segmentation of the arriving LLC PDUs and empties when these blocks are transmitted
over the air interface. The PCU calculates the control variables R and Bmax and trans-
mits them with flow control commands to the SGSN at every expiration of the TF1 timer.
Thus a closed-loop control is realised (see the Fig. 7.19). In the PCU the real rate Rpcu
(towards the Abis interface) can be different from the value R sent to the SGSN.
In other words, the SGSN uses parameters sent by BSC in order to decide if it can send
data or not. The principle is that periocally the BSC can send new parameters and the
SGSN updates the internal values related.
192 A30808-X3247-M24-5-7618
System
Fig. 7.19 Closed Loop Control
Every TF1 timer expiration, the BSC can send a new BVC or MS Flow Control with the
following parameters updated:
– Bucket Size (Bmax);
– Bucket Leak Rate (R);
– Bucket FullRatio.
PCU and SGSN are provided with two different types of buffer, one for the BVC Flow
Control and another one for the MS Flow Control. As a consequence, the following
parameters are defined:
– BmaxPCUBVC is the maximum size of the buffer in PCU for the BVC Flow Control;
– BmaxPCUMS, is the maximum size of the buffer in PCU for the MS Flow Control;
– BmaxBVC is the maximum size of the buffer in SGSN for the BVC Flow Control;
– BmaxMS is the maximum size of the buffer in SGSN for the MS Flow Control.
The Bucket Leak Rate (R) is the rate at which the permits for transmission are gener-
ated.
The Bucket full ratio represents the percentage of the Current Bucket Level (Buck-
etLevelPcu) compared to Bmax.
The BSS has to trigger the Flow Control message in a way that the BSS can guarantee
a continuous data flow to the Mobile Stations.
It is important to put in evidence what follows:
– a too low Leak rate respect to the maximum rate possible prevents the SGSN from
sending data to the BSC;
– Bmax has to be high enough in order to guarantee that the BSC has always “some-
thing to send”;
– Bmax has to be low enough due to PDU-lifetime, for this reason it is better to have
a little Bucket in order to have a minimum permanence in the BSC Bucket;
A30808-X3247-M24-5-7618 193
System
– the discarding of packets because of lifetime expiration will be an exceptional case.

The current Bucket Level procedure is used only if SISGSNREL99 attribute (related to
i PCU object) is set to the value: “TRUE”.
7.3.3.1 MS Flow Control Message

During active Downlink TBF, the BSC sends a message: “MS-FLOW-CONTROL” (see
the Fig. 7.19) in order to inform the SGSN network node about the quantity of memory
reserved for that TBF and the rate at which bytes are sent.
At each TF1 timer expiration, the BSC computes the BmaxBasicMS value according to
the following formula:
BmaxBasicMS = f *(1s +TF1) * RmaxMS
in which:
f=1 if no large amount of LLC lifetime expiration occurs;

f =1/ ((nGPRS_TS +1) * TF1 * i) otherwise.
Besides:
• the value i represents the consecutive number of times that the LLC PDU lifetime
expiration threshold is found to be present. LLC PDU lifetime expiration threshold is
reached when in the previous interval the number of bytes related to expired LLC is
more than 30% of LLC bytes sent for that Mobile Station;
• nGPRS_TS is the number of timeslots assigned for GPRS/EGPRS services at timer
expiration at this Mobile Station;
• RmaxMS is the teorical MS Maximum Rate according to resources assigned to the
Mobile Station and to used coding scheme (CS/MCS); it is defined as:
K
RmaxMS = ∑ TSPercentageR TSk
k=1
where:
- K represents the Number of timeslots assigned to the MS;
- RTSK is the rate in case the entire timeslot is assigned to that MS;
- TSPercentage is a percentage that indicates how the timeslot is exploited (in
percentage) by the MS, when it shares the timeslot with other MSs. For example
TSPercentage=30% means that 30/100 * RTS is the rate for the MS in that timeslot.
In order to allow more flexibility in flow control management, some attributes have been
implemented.
The purpose of these attribute is for testing purposes and for special applications. It is
i not possible to guarantee that the BSC runs without error conditions with all the combi-
nations and it is strongly recommended to configure these attrfibutes with their default
value.
194 A30808-X3247-M24-5-7618
System
One of these attrinbutes is: MSBMAPER (MsBucketMaxPercentage), defined as:
BmaxMS = MSBMAPER * BmaxBasicMS

Through this parameter the operator can reduce the value of BmaxBasicMS automati-
cally computed by BSC.
Another attribute is called MSBSPPER (MsBucketSizePcuPercentage) and represents
a relationship between BmaxPCUMS and BmaxMS . The exact definition is:
BmaxPCUMS = MSBSPPER *BmaxMS
As can be seen in the Fig. 7.19, BmaxPCUMS must be higher than BmaxMS, so
MSBSPPER is greater than 100.
The states “congested” and “non-congested” are determined using two thresholds:
BhighMS and BlowMS. Starting from BmaxPCUMS the operator can define these two
thresholds through the parameters: MSBHIPER (MsBucketHighPercentage) and
MSBLPER (MsBucketLowPercentage). They are defined through the following formula:
BhighMS = MSBHIPER * BmaxPCUMS

BlowMS = MSBLPER *BmaxPCUMS
If the state is “non-congested”, and BucketLevelPCUMS (the current Bucket Level in

PCU) crosses BhighMS from below, the state is set to “congested”.
If the state is “congested”, and BucketLevelPCUMS crosses BlowMS from above, the
state is set to “non-congested”.
For what concerns the Mobile Station Bucket Leak Rate, different behaviours are fore-
seen, according to these two situations:
– Bucket_Full Ratio is not implemented in SGSN;
– Bucket_Full Ratio is implemented in SGSN.
The value of Bucket Full Ratio is the percentage of BucketLevelPCU compared to
Bmax. For example if BucketLevelPCU is 40% of Bmax, Bucket Full Ratio = 40. If
BucketLevelPCU is 150% of Bmax, Bucket Full Ratio = 150.
Bucket_Full Ratio is not implemented in SGSN

The Flow Rate out of the buffer in the SGSN (RMS) can be expressed in the following
way:
MS Bucket Leak rate = RMS*8/100
(8 is due to the fact that Bucket Leak rate is in 100 bits/s unit, Bucket size is 100 octet
increments).
In the normal case the BSC sends to SGSN the following value for RMS:
RMS= RmaxMS
A30808-X3247-M24-5-7618 195
System
Otherwise the BSC sends the following value:
RMS=f* RmaxMS
where the coefficient f is chosen according to the following situations:

1. if Leak Rate has not been already reduced for Bucket Congestion, then the leak rate
is reduced as following:
Retrasm_rate = Bytes retransmitted/ Byte transmitted
if Retrasm_rate < 10 % no correction.

if 10 % < Retransm_rate < 20 % then Leak rate = 0.9 * Leak Rate
2. If MS buffer is congested:
f = 1/((nGPRS_TS +1) * TF1 * i)

where:
– “i” is the consecutive number of times that the LLC PDU lifetime expiration
threshold is found to be present;
– “nGPRS_TS” is the number of TS assigned for GPRS/EGPRSD services at timer
expiration for this Mobile Station.
Bucket_Full Ratio is implemented in SGSN

In this case, the value MS Bucket Leak rate, is sent always without correction factor.
MS Bucket Leak Rate = RmaxMS
7.3.3.2 BVC Flow Control Message

BmaxBVC (see the Fig. 7.19 ) is a value not corresponding to the real BVC memory
capacity on the PCU, but a value to be communicate to the SGSN network node that it
can send downlink LLCs.
The same criteria and parameters will be applied as in BmaxMS case. More specifically,
BSC calculates the BmaxBasicBVC according to the following formula:
BmaxBasicBVC= f*(1s + TF1) * RmaxBVC
in which:
196 A30808-X3247-M24-5-7618
System
f=1 if no large amount of LLC lifetime expiration occurs;

f =1/ ((nGPRS_TS +1) * TF1 * i) otherwise.
Besides:
• the value i represents the consecutive number of times that the LLC PDU lifetime
expiration threshold is found to be present. LLC PDU lifetime expiration threshold is
reached when in the previous interval the number of bytes related to expired LLC is
more than the 10% of LLC bytes sent for all BVC;
• nGPRS_TS is the number of timeslots assigned for GPRS/EGPRS services at timer
expiration;
• RmaxBVC depends on the number of timeslots that can be assigned to
GPRS/EGPRS, and on the data rate on these timeslots, basing on initial CS or initial
MCS (see 10.7.3) or in case Link Adaptation is enable on the maximum CS or MCS;
it is defined as:
K N PCCH KEDGE KGPRS

Rmax B V C = ∑R TSk = ∑ RTSk + ∑ RTSk + ∑ RTSk
k=1 k=1 k=1 k=1
where:
K = NPCCH + KEDGE + KGPRS
NPCCH: is the number of configured packet control channels;
KEDGE: maximum number of channels (configured, unlocked and
enabled) can be assigned to EDGE after applying GPDPDTCHA
parameter.
KGPRS: maximum number of channels (configured, unlocked and
enabled) can be assigned to GPRS (but not to EGPRS) after
applying GPDPDTCHA parameter. In this number timeslots
belonging to EDGE capable TRXs are not considered (they are
counted in the KEDGE value).
Besides, the following definitions are necessary:
Ndinamic: maximum number of channels (configured, unlocked and enabled)

can be theoretically used to either PS services or CS services in the
cell;
NdinamicEDGE: maximum number of channels (configured, unlocked and enabled)
can be theoretically used for EGPRS service on EDGE capable
TRXs.
The number refers to timeslots without applying GPDPDTCHA
parameter.
NdinamicGPRS: maximum number of channels (configured, unlocked and enabled)
can be theoretically used for GPRS service on GPRS capable
TRXs.
The number refers to timeslots without applying GPDPDTCHA
parameter.
A30808-X3247-M24-5-7618 197
System
Nreserved : number of PDCH reserved for GPRS/EDGE services. It corre-

sponds to GMANPRES parameter.
GPDPDTCHA : percentage of channel available can be assigned to GPRS or EDGE
(if possible).
K_EG: maximum number of channels (configured, unlocked and enabled)
can be dynamically assigned to GPRS/EGPRS services. The
number refers to timeslots after applying GPDPDTCHA parameter.
To explain the previous definitions lit is supposed that a cell (BVC) has the configuration
shown in the Fig. 7.20.
TDMA frame
GPRS
TRX 0 BCCH SDCCH PBCCH
Capable
0 7
TDMA frame
EGPRS
TRX 1 SDCCH
Capable
0 7
TDMA frame
EGPRS
TRX 2 SDCCH
Capable
0 7
GMAPERTCHRES=4
GPDPDTCHA=50%
Configured Packet Control Channels=1
Fig. 7.20 Example Cell Configuration
In this case we have the following values:

– NPCCH = 1
– Ndinamic =19
– NdinamicEDGE =7
– NdinamicGPRS =12
For the RmaxBVC computation, the following information must be taken into consider-
ation:
– If Ndinamic is greater than Nreserved, the parameter K_EG is equal to GPDP-
DTCHA*(Ndinamic - Nreserved), otherwise if Ndinamic is lower or equal to
Nreserved, then K_EG is equal to zero.
– K = NPCCH + K_EG + Nreserved
– If K_EG + Nreserved is greater than NdinamicEDGE, then:
KGPRS = K_EG + Nreserved - NdinamicEDGE
KEDGE = K_EG + Nreserved - KGPRS
otherwise
KGPRS = 0
KEDGE = K_EG + Nreserved
Example 1:
198 A30808-X3247-M24-5-7618
System
Configuration as in Fig. 7.20, if all channels are enabled/unlocked (GPDP-

DTCHA=50%).
NPCCH = 1
Ndinamic =19
NdinamicEDGE =7
NdinamicGPRS =12
Nreserved =4
K_EG = 0.5 *(19-4)=0.5*(15)=8

KGPRS = K_EG + Nreserved - NdinamicEDGE = 8 + 4 - 7 = 5
KEDGE = K_EG + Nreserved - KGPRS = 8 + 4 - 5 = 7
K = 1 + 8 + 4 = 13
Example 2:
The TRX1 becomes disabled (GPDPDTCHA=50%).
NPCCH = 1
Ndinamic =12
NdinamicEDGE =7
NdinamicGPRS = 5
Nreserved =4
K_EG = 0.5 *(12-4)=0.5*(8)=4

KGPRS = K_EG + Nreserved - NdinamicEDGE = 4 + 4 - 7 = 1
KEDGE = K_EG + Nreserved - KGPRS = 4 + 4 - 1 = 7
K=1+4+4=9
Also in case of BVC flow control,the BVCBMAPER (BvcBucketMaxPercentage) and

BVCBSPPER (BvcBucketSizePcuPercentage) attributes have been implemented.
Through them the operator can modify the values automatically computed by the BSC.
These attributes are defined as follow:
BmaxBVC = BVCBMAPER * [(1+TF1) * RmaxBVC ]

BmaxPCUBVC = BVCBSPPER *BmaxBVC.
The states “congested” and “non-congested” are determined using the two thresholds
BhighBVC and BlowBVC of the BmaxPCUBVC.
Two further attributes allow the operator to express them as a function of BmaxPCUBVC:
BVCBHIPER (BvcBucketHighPercentage) and BVCBLPER (BvcBucketLowPer-

centage). These attributes are contained in the following formulas:
A30808-X3247-M24-5-7618 199
System
BhighBVC = BVCBHIPER * BmaxPCUBVC

BlowBVC = BVCBLPER * BmaxPCUBVC
If the state is “non-congested”, and BucketLevelPCUBVC (the current bucket level in

PCU) crosses BhighBVC from below, the state is set to “congested”.
If the state is “congested”, and BucketLevelPCUBVC crosses BlowBVC from above, the
state is set to “non-congested”.
For what concerns the BVC Bucket Full Ratio, the same criteria as in section 7.3.3.1 are
applied.
7.3.3.3 Flow Control sending criteria (for both BVC and MS)
A BVC Flow Control/MS Flow Control can be sent at each TF1 timer expiration. In order
to reduce the number of FLOW-CONTROL messages sent, they are sent only in these
cases:
– Bmax or R is changed compared to the previous parameter sent, for example, in
case of too many PDU lifetime expiration or resource increased/decreased;
– If Bucket Ratio is not implemented, in case of too many RLC retransmission or
BucketLevelPCU exceeds Bhigh or goes below Blow threshold;
– If Bucket Ratio is implemented:
- every time that BucketLevelPCU is more than 70% of Bmax (this means conges-
tion at BSS side);
- every time that BucketLevelPCU is less than 5% of Bmax. This behaviour is
assumed in order to prevent possible loss of alignment between Bucket at SGSN
side and at BSC side; it is possible that bucket in BSC is more or less zero and
completely full at SGSN side due to eventual software error.
If the SGSN node does not answer to the BVC FLOW control, the PTPPKF Managed
Object is put in disable state and BVC RESET procedure starts.
If the SGSN does not answer to the MS Flow Control, the BSC stops sending the
message: “FLOW_CONTROL” for that TBF.
The Fig. 7.21 and Fig. 7.22 show the message flow related to MS-Control Flow for two
different cases: the normal case and the case in which the SGSN does not answer.
200 A30808-X3247-M24-5-7618
System
Fig. 7.21 Message:MS-FLOW-CONTROL
Fig. 7.22 SGSN does not answer with the message: MS-FLOW-CONTROL
A30808-X3247-M24-5-7618 201
System
It shall be noted that in case of redundant NSVC links are created on the Gb-interface,
the following rule shall be take into account for avoiding unnecessary GPRS/EGPRS
blocking for certain cells (see the chapter: "7.2.1.3 Procedures for PVCs"): if the
message: 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 Managed Object is put in the operational state: Disabled if the message:
FLOW-CONTROL-ACK is not received during the time defined by:
Time_2 = TF1* Number of Flow Control Retries
In case of link problems it could therefore happen that the PTPPKF Managed Object is
disabled while instead the NSVC is still enabled. To avoid this situation, the following
rule has to be followed:
Time_2 > Time_1
The “Number of Flow Control Retries” is not manageable by the user and its fixed value
necessary to satisfy the rule above is: 31.
The current Packet Flow Control procedure does not require modifications to support
the DTM feature. This means that, at the reception of the message: Create BSS PFC
for streaming service, when the MS is in dedicated mode (and all the conditions to enter
DTM are satisfied), a DTM allocation is searched and a DL TBF is established going in
DTM.
More details about the DTM feature are described in the manual: “TED:BSS Common”.
7.3.4 Multiple PCU Pooling

In this chapter network “overlay” scenarios with Radio Access Network “split” between
different BSS providers connected to one or more SGSN network nodes ports are
described. Each SGSN node manages a routing area and the ports could belong to one
or more SGSNs.
The number of PCU pools can be limited by the configured number of PPXU boards in
the related BSCs and the requested redundancy scheme, according to BSC types
(BSC/72, BSC/120) installed in the network.
The feature: :”Multiple PCU Pooling” is supported only by PCU functionalities imple-
mented on the PPXU cards (together with their redundancy rules).
Besides the network scenario to which it is applicable the multiple PCU Pooling feature
is based on the Gb interface over the Frame Relay (FR) Sub Network Service. It can be
supported also by the Gb interface over IP Sub Network Service independently from ho
w the Gb interface is supported (for example by means of a PCMG dedicated link, or a
Nailed Up connection through the MSC). The feature can be supported also on PCMG
and PCMA considering the limitations on the number of BSC NUC Managed Objects.
202 A30808-X3247-M24-5-7618
System
The current “NSEI” per PCU approach has not been modified (the PCUs in the pool do
not share the same NSEI but keep their individual ones: NSEI attribute is kept at PCU
object level). Besides NSEI information is a mandatory information element within IP
SNS protocol related messages (for example: “Size-Ack, SNS-Add”, etc). In case BSC
receives an unknown NSEI information from SGSN network node, an error handling
procedure is triggered. In this way BSS BR8.0 system is fully compliant to standard.
This overlay “GERAN” only or “GERAN plus SGSN” scenario is different from the “Intra
domain connection of RAN nodes to multiple Core Network nodes”. Application of any
of the features relevant to the “Intra domain connection of RAN nodes to multiple Core
Network nodes are out of the scope of Multiple PCU Pooling.
The redundancy rules implemented in the previous release for the PPXU boards are
based on the concept of all supported PPXUs usable as backup/redundancy of any
other: the Routing Area to which cells belong is respected at system initialization (but
this does not prevent the system to allocate to the same PCU cells belonging to different
routing areas in some cases, even if first an attempt is made in order to allocate cells
belonging to the same Routing Area on the same PCU). In case of errors affecting the
PCU functionality, the load balancing mechanism reconfigure cells independently from
their Routing Area (RA) code.
This feature does not modify the current system behaviour; 1 Common PCU pool is
automatically defined, including all equipped PCUs, irrespectively of their administrative
status . No check is forced on the number of PCUs in a pool; besides PPXU redundancy
(or no redundancy) is enforced by the user even if the inclusion of 2 PCUs per pool is
recommended; this means that one single PCU/PPXU is enough to define a specific
PCU.
“Common PCU” pool is defined as the pool of PCUs supporting one or more Routing
Areas by means of the same SGSN ports. Redundancy is provided only within the pool
area in case of faults causing the out of service of one PCU and the consequence loss
of the relationship between the Routing areas supported and the SGSN ports requested.
Besides this feature avoids delays in case of Inter SGSN Cell Reselection procedures
(this means cell reselections executed on cells connected to different SGSN ports),
which might occur very often in the specific network overlay configuration.
Currently the BSS system is able to establish an overlay network additionally to an
existing mobile network (for example a Nokia mobile network) to improve the network
coverage.
This leads to rather large Siemens BSC coverage areas since BSC can control a lot of
BTS(s) and the controlled BTS(s) would be spread over a large area. BSC area of other
vendors (for example: Nokia) would be rather small compared to the Siemens BSC
areas. The problem arises from the fact that Nokia SGSN node is slow in cases of inter
SGSN Cell Reselections and in case the Gb interface of the Siemens BSC and the Gb
interface of the Nokia BSC are connected to different SGSN ports (PAPU ports). One
PAPU port of a Nokia SGSN node can support only a certain amount of traffic as well
as it has a limited amount of maximal throughput. In case of large Siemens BSC areas
(BSC/72 equipped with PPXU boards in load sharing/balancing for redundancy),
Siemens Gb interface cannot always be combined on the same Nokia SGSN PAPU port
with the according Nokia Gb interface(s) covering the same area. This causes not negli-
gible delay during the execution of cell reselection procedures.
The load sharing/balancing mechanism allocates cells supporting GPRS services
possibly not over PCU boundaries for the same routing area only at system start up; In
case of fault, cells are reallocated to the available PCU without taking into account the
A30808-X3247-M24-5-7618 203
System
Routing Area information. On recovery of the faulty PCU/PPXU, the cells are reallocated
according to previous allocation information (on failure, re-allocated cells are function-
ally marked with the failed PCU “origin” information).
To overcome the limitations described above, the following functions have been imple-
mented to support the Multiple PCU Pooling feature:
• Each PPXU Managed Object can be associated to one (and only one) pool by
means of a specific command;
• A maximum of 6/12 pools can be configured (considering the BSC72/BSC120).
From 1 to 12 PPXU boards can be related to one pool;
• Each cell can be related to one Pool of the PPXUs by means of an user command:
according to this request a cell may be supported by only one PCU pool;
• The cells will be assigned dynamically by BSC to PPXU inside the Pool taking in
consideration load balancing concepts. For example, a load balancing algorithm is
applied separately for each configured pool;
• The concept of redundancy has not been modified.
• The default configuration is the following: all PPXU boards and cells are assigned to
a unique single pool (by the system);
• A cell as well as a PPXU board can be moved from one Pool to another Pool by
means of a “Set” command. This command is preceded by the “Lock” command
related to the Managed Object affected by the PCU pool change;
• More than one SGSN can be connected to the BSC. Only one SGSN can be
connected to the BSC per PCU pool;
• As specified in the TS 23.236 Recommendation, in case of multiple CN serving a
pool area, the usable NRI values (NRI value is included in the temporary identifiers
generated by the CN nodes, in this case TLLI is applicable) are splitted between the
CN nodes, each one using a specific subset of values. The number of NRI bits to be
used in the Ran for NAS and load balancing (BSSGP traffic level) is configurable
and the same NRI bit number that shall be used is defined at pool level; in case of
overlapping pool areas, the number of bits to be masked from the temporary identi-
fiers is defined with the same value for the pools. There may be also pools where
the NAS node selection and load balancing features of the TS 23.236 Recommen-
dation are no applied (for example the CN is not supporting Gb flex/ not aware of
support by other CN nodes in the pool); the described mechanism allows the RAN
to detect changes in pool areas for a Mobile Station, forcing selection of the new
applicable CN node supporting the new pool. All PS traffic originated from the Mobile
Station or from the Network is handled by the same PCU pool as far as the Mobile
Station is GPRS attached to a cell supported by the pool. The pool (CPCU) is
“connected” to only one SGSN node;
• The allocation of cells to PCUs and the load balancing procedures have been modi-
fied for supporting Multiple PCU Pooling feature: the allocation is not free between
all the configured and in service PPXU boards, but it is managed by the CPCU
index.
The following procedures have been affected by Multiple PCU Pooling:
- Paging;
- Suspend/Resume;
- Flush LL;
- BSS Context;
- Dynamic Cell Allocation and Load Balancing.
204 A30808-X3247-M24-5-7618
System
These features are described in the next chapters.

Multiple PCU Pooling feature is supported by CPCU Managed Object. Its meaning and
the main attributes are described in the chapters: "9.10 Quality of Service Support for
PS Services" and: "11 Managed Objects and attributes".
7.3.4.1 Paging
The address keys for paging are the following: “IMSI (P-TIMSI/TMSI/TLLI)” and
“BVCI/RAI/LAI”: for the reason that IMSI is not related to temporary identifiers generated
by the core nodes, which could have local and not global significance, IMSI can be
considered independent of single or multiple CN nodes connectivity. In any case the
identifiers related to the area where the IMSI has to be paged can be interpreted
correctly, when paging is requested on all BSS area cells, it is interpreted as paging to
be performed on the pool area (PCU pool) connected to the SGSN from which the
paging request was received. In case the Mobile Station is moving from one pool area
to another area supported by a different SGSN node, the procedure has to be performed
by CN nodes controlling both areas through coordination from Core Network side.
SGSN network node provides an indication of the cells within which the BSS system
page the Mobile Station. The levels of resolution within one BSS are the following:
- All cells within the BSS;
- All cells on the BSS within one location area;
- All cells on the BSS within one routing area, and one BVCI (for example: cell).
A routing area, a location area, or a BSS area is associated with one or more NSEI(s).
If the cells in which to page the Mobile Station are served by several NSEIs, then one
paging PDU shall be sent to each of these NSEIs.
A paging PDU is used to generate the corresponding radio interface paging request
message(s) to be transmitted at the appropriate time.
It is important to put in evidence that each paging PDU relates to only one Mobile
Station; as a consequence a BSS can pack pages for different Mobile Stations into the
relevant radio interface paging request messages specified in the TS 24.008 or TS
44.060 Recommendations.
If a SGSN node provides a P-TMSI in a PAGING-PS PDU, then BSS system uses the
P-TMSI to address the Mobile Station. If the SGSN node does not provide the P-TMSI
in the PAGING-PS PDU, then BSS system adopts the IMSI to address the Mobile
Station.
In case the DTM feature is enabled in the network, depending on the availability of the
Gs Interface, the paging for CS could arrive to PCU both from MSC or SGSN nodes.
The Paging CS from SGSN node is already managed in PCU, while the paging (for CS
obviously) from MSC, arrives to TDPC that routes it to PCU.
For more details about the DTM feature and related paging modifications, see the
manual:” TED: BSS Common”.
7.3.4.2 Suspend/Resume
The Address key for the suspend/resume procedure is: “TLLI plus Routing Area”. If the
Mobile Station informs the BSS that its GPRS service shall be suspended, the BSS
sends a message: SUSPEND PDU to the SGSN node and starts the timer T3. The
message: SUSPEND PDU contains the following information:
A30808-X3247-M24-5-7618 205
System
• Mobile Station TLLI;

• Routing Area of the MS as received in the message: GPRS Suspension Request
(see the 3GPP TS 44.018 Recommendation) of the Layer 3 Um interface.
For each message: SUSPEND PDU received by a SGSN node, a SUSPEND-ACK PDU
is sent back to the BSS system. At the reception of the SUSPEND-ACK PDU, the BSS
system stops the timer T3. The message: SUSPEND-ACK PDU contains the following
information:
- The Mobile Station TLLI as received in the message: SUSPEND PDU;
- The Routing Area of the Mobile Station as received in the message: SUSPEND PDU;
- The Suspend Reference Number.
SGSN network node generates the Suspend Reference Number in a manner that
enables it to differentiate between different SUSPEND PDUs relating to the same
Mobile Station.
If a message: SUSPEND-ACK PDU is not received for a SUSPEND PDU within the
timer T3 (in seconds), then the SUSPEND PDU procedure is repeated for a maximum
of SUSPEND-RETRIES attempts. After SUSPEND-RETRIES attempts the procedure is
stopped and a notification for the Network Management system (Radio Commander) is
generated.
If a message: SUSPEND-ACK PDU is received for a Mobile Station that is already
marked as suspended, then the message is not considered.
If a SUSPEND PDU refers to a Mobile Station which is unknown in the SGSN, then a
SUSPEND-NACK PDU is returned containing a cause value (Cause value: Unknown
Mobile Station). BSS system stops the SUSPEND procedure.
If the Suspend procedure is supported on the Gn interface, in case of an inter-SGSN
suspend procedure the Mobile Station is not more treated as unknown in the SGSN
when the RA indicated in the message: SUSPEND PDU is not served by the SGSN
itself.
7.3.4.3 Flush LL
The Address Key for Flush LL is: BVCI / NSEI.
SGSN sends a FLUSH-LL PDU to old BVC to initiate the following procedures: (if it is
still the same SGSN due to PCU pool change, all the other cases not related to PCU
pool change involve only one controlling SGSN node):
• At a cell change within one NSE (for example PCU is a NSE) and within one routing
area, LLC-PDU(s) for a given TLLI stored at an "old" BVCI (corresponding to the old
cell) are either deleted or transferred to a "new" BVCI (corresponding to the new cell)
with which the TLLI is currently associated. Cell updates not involving a RA update
is handled in the same PCU pool and by the same SGSN node (in case of RAN
overlay and CN overlay);
• t a cell change between two NSEs within one routing area, LLC PDU(s) for a given
TLLI stored at an "old" BVCI (corresponding to the old cell) are either deleted or
transferred to a "new" BVCI (corresponding to the new cell) with which TLLI is
currently associated. In that case, transferring of LLC PDU(s) is not possible , for the
reason that "Inter-NSE re-routing" is not supported;
• At a cell change between two routing areas, LLC-PDU(s) stored at the "old" BVCI for
TLLI are deleted.
206 A30808-X3247-M24-5-7618
System
7.3.4.4 BSS Context

The BSS context is stored local to the PCU serving the TLLI. The related access key is
normally the TLLI according to the PFM procedures. With a one to one relationship
between the PCU pool and the SGSN node on the other side there is no addressing
problem, as the Mobile Station moving is managed according to FLUSH-LL procedures
described in the chapter "7.3.4.3 Flush LL".
7.3.4.5 Dynamic Cell Allocation and Load Balancing

The redundancy within one CPCU Managed Object has been restricted. As the CPCU
enforces the relationship between cells belonging to a Routing Area and a set of PPXUs
and FRL bearers/NSVCs serving it, dynamic allocation algorithm and load balancing
mechanism are affected, as follow:
1) At init time, cells are distributed by PTPPKF distribution process (GPRS Load Control,
GLC) according to the CPCU-x attribute set by the user. The CPCU-x index selects
PCU(s) belonging to PCU pool-x as target; different data bases have been defined on a
per CPCU-x.
2) GPRS load control algorithm for allocation of cells to the PCU Managed Objects has
been modified.
3) The load balancing algorithm is triggered by events that trigger the following actions:
– make out of service the related board (PPXU: LOCK or fault);
– make out of service the Gb Interface (last NSVC connecting to the peer SGSN
port/PAPU/NSEI);
– start up Gb interface (first NSVC goes up);
– cause the deletion of PTPPKF Managed Object;
– The load balancing algorithm is triggered on UNLOCK when the LOCK and SET
commands have been issued to change CPCU index. When SET PTPPKF has
been issued, the balancing algorithm runs on the old PCU pool from where the
PTPPKF was “deleted”. In the new PCU the moved PTPPKF is equivalent to a
“created” one. When the UNLOCK is related to a PCU, if the LOCK and SET
commands had been used before, the trigger for load balancing is applied to the old
PCU pool and to the new PCU pool.
The algorithm is not triggered by PTPPKF, PCU creation and PCU real Time overload.
7.3.5 Enhanced Flow Control

This chapter introduces enhanced Flow Control (eFC) feature together with related
message flow and main structure of related algorithm.
Mobile Stations supporting GPRS/EGPRS services can support used also WAP or I-
mode pages or can be used to send/receive messages (SMS, EMS, MMS). In addition
GPRS operators intend to provide also streaming services over GPRS. For example, an
user connected to a “WAP” or “I-mode” page, could start a video by clicking a button and
streaming service is triggered in addition to browsing session.
To support this service efficiently, several parallel data flows with different QoS shall be
supported between core network and Mobile Station (in the example: one interactive
session for browsing on WAP/I-mode pages and one for streaming session). Besides it
is important that a streaming user is not affected by interruptions of audio and video
stream.
A30808-X3247-M24-5-7618 207
System
Generally end users (for example: Mobile Stations, PC) exchange packets (typically IP
packets) via SGSN node. Packets are sent to SGSN and put into LLC.
LLC are queued either in SGSN or in BSC before they are sent to the MS (air interface
can cause a bottleneck).
In case BSC or also SGSN internal queuing introduces too much latency, this may result
in a perceived delay in the Mobile Station (for example streaming is interrupted).
If air congestion does not occur, the resources are assigned according to the required
throughput; in this case Flow Control procedure is not executed.
If air congestion occurs, the assigned resources are lower than required; as a conse-
quence the Flow Control procedure is triggered to avoid heavy queues in the BSC, to
maximize the air resource utilization and to reduce queues in the BSC for avoiding waste
of data when cell reselection procedure is executed.
Enhanced Flow Control (eFC) feature has been introduced in 3GPP R5 in order to
inform SGSN about the rate that can be used for a specific Packet Flow Control (PFC)
especially in case of congestion. This mechanism is not supported triggering only Mobile
Station Flow Control.
With the support of the eFC (PFC Flow Control) the traffic for background PFCs can be
reduced while allowing RT traffic for the same user.
Although the enhanced Flow Control (eFC) is a R5 feature, it is applicable for all the
Mobile Stations > = R99
The flow control mechanism manages the transfer of BSSGP UNITDATA PDUs sent by
SGSN to BSS system on Gb interface.
BSS system manages the flow of BSSGP UNITDATA PDUs in its BSSGP Virtual
Connection (BVC) buffers by indicating to the SGSN the maximum allowed throughput
for each BVC. Then BSS controls the flow of BSSGP UNITDATA PDUs to the BVC
buffer for an individual Mobile Station by indicating to SGSN the maximum allowed
throughput for a certain TLLI.
In case a Mobile Station supports several parallel data flows in the same time (for
example web browsing and e-mail, background and streaming), it maintains active more
than one Packet Flow Context (PFC).
Enhanced Flow control (eFC) refers to a third level of Flow Control over Gb interface.
In case the PFC Flow Control feature is enabled, the BSS system may control the flow
of BSSGP UNITDATA PDUs to BVC buffer for a certain PFC (=“flow”) of an individual
Mobile Station by indicating to SGSN the maximum allowed throughput for a certain
flow.
For the flow control mechanism, a closed-loop control has been implemented as repre-
sented in next Fig. 7.23:
208 A30808-X3247-M24-5-7618
System
Fig. 7.23 Closed-loop control

On BSS side, there is a BucketLevelPCU for each BSSGP Virtual Connection (BVC),
Mobile Station and PFC. BucketLevelPCU value is equal to the bytes stored in the BSS
system for BVC, TLLI and PFC.
For the BucketLevelPCU the following behaviour occurs:
• It is incremented at LLC PDU arrival (increment is equal to LLC bytes length);
• It is decremented when related RLC blocks are transmitted over the air interface
(decrement is equal to RLC data part length).
PCU calculates the control variables “R” and “Bmax” and transmits them to SGSN with
the flow control commands. “R” is the real flow rate, “Bmax” is the maximum size of the
Buffer.
“C-Timer” is the minimum interval between sending of subsequent Flow Control PDUs.
For example a new Flow Control message can be sent by the BSC to SGSN at C timer
expiration.
At SGSN side a buffer for each BSSGP Virtual Connection (BVC), Mobile Station and
PFC has been implemented. How the algorithm proceeds after “Delay LLC PDU” and
how long has LLC PDU to be delayed is not in the scope of this manual because it is
related to specific SGSN architectural choices.
Within PCU the real rate “RPCU” is different from the value “R” sent to SGSN. In principle
BSC informs SGSN about the value of rate ”R” that can be used in the next period.
RPCU is the real rate in BSC Bucket; it is not possible to know the exact RPCU value in the
next C period.
A cascaded PFC, Mobile Station and cell (BVC) oriented flow control scheme for the
downlink transmission of LLC frames from SGSN to PCU has been implemented,
aligned to GPP Release TS 48.018 Recommendation. It is represented in next
Fig. 7.24.
A30808-X3247-M24-5-7618 209
System
Fig. 7.24 BSSGP Flow Control Level

Up to the BR 7.0 Release the BSC supported BSSGP Virtual Connection and MS Flow
Control. but no PFC Procedure and any PFC. This means that the BSC allocated
resources on the basis of QoS peak throughput in message: “DL UNITDATA”.
As a consequence scheduler has been configured in order to guarantee a specific rate.
If a LLC requiring greater throughput was received, assigned resources were increased
(TBF upgrade). BSC informed SGSN via the MS Flow Control about Rate. This rate was
equal to the one guaranteed by the scheduler.
This behaviour has been modified in current BR8.0 release to support the enhanced
Flow Control mechanism, as follow:
• Mobile Station can exchange LLCs for different purposes. PFI is contained in the
DL_UNITDATA (but only for Mobile Station >= R99). “Requested QoS” is negotiated
during “Activate PDP context” procedure transparent to BSC;
• QoS Profile Information element, contained in BSSGP message: DL-UNITDATA
stores only peak throughput and radio priority;
• ABQP Information element contains all QoS parameters and it is stored in the
message: CREATE-BSS-PFC.
The conditions triggering the support of the enhanced Flow Control are the following:
• eFC disabled: The feature can be disabled by the user by means of specific O&M
parameters. BSC does not support eFC;
• eFC enabled: The feature cannot be enabled by the user by means of specific O&M
parameters if PFC support is disabled (semantic checks). The application in the
BSC is aligned to the content of the following table associated to SGSN node:
SGSN Network Node MS Release 97 MS Release 99
PFC enabled, PFC-FC enabled eFC not used eFC used
Tab. 7.6 Conditions enabling/disabling eFC feature
210 A30808-X3247-M24-5-7618
System
SGSN Network Node MS Release 97 MS Release 99
PFC enabled, PFC-FC disabled eFC not used eFC not used
PFC disabled, PFC-FC enabled Not possible Not possible
PFC disabled, PFC-FC disabled eFC not used eFC not used
Tab. 7.6 Conditions enabling/disabling eFC feature
The introduction of the third level of Flow Control has also required the implementation
of the message: “FLOW-CONTROL-PFC” as described in TS 48.018 Recommendation.
An example of message flow related to TBF establishment and TBF reconfiguration due
to incoming services having not pre-defined PFI is represented in next Fig. 7.25.
Fig. 7.25 Example of TBF Establishment and TBF Reconfiguration
In the figure the following messages are exchanged:

1. TBF is opened due to message: “DL UNITDATA” from SGSN to BSC having PFI pre-
defined, but not the best effort one, coming;
2. The message: MS FLOW CONTROL is sent from BSC to SGSN when the first C timer
expiration occurs;
3. Then during packet transfer mode, the message: “DL UNITDATA” sent from SGSN
to BSC with PFI not pre-defined or best effort predefined PFI causes a reconfiguration
A30808-X3247-M24-5-7618 211
System
of TBF in order to manage new services or in any case internal scheduler reconfigura-
tion. It is not strictly necessary to have a TS reconfiguration and only a scheduler recon-
figuration could occur;
3a. If BSC does not support valid PFC parameters, PFC Download procedure starts
(this does not apply if the best effort pre-defined PFI has been received);
4. At next C timer expiration the message: “PFC Flow Control” with the parameter for
PFI1 is sent from BSC to SGSN;
5. Then during packet transfer mode, the message: “DL UNITDATA” sent from SGSN
to BSC with PFI2 not pre-defined could cause a reconfiguration of TBF in order to
manage new services or in any case an internal scheduler reconfiguration can occur;
6. At next C timer expiration a PFC-FC is sent from BSC to SGSN including PF1 and
PF2 parameters.
As further example of message flow, in next Fig. 7.26 the messages exchanged
between SGSN node and Mobile Station in case of TBF Release are represented.
Fig. 7.26 Example of messages in case of TBF Release
In figure above the following messages are exchanged:

1. TBF Reconfiguration: Exchanged between MS and BSC. Temporary Block Flow is
reconfigured (or at least scheduler is reconfigured) if the queue related to PF1 is empty
for a long time;
2. PFC FLOW CONTROL: This message is sent from BSC to SGSN when “C” timer
expires. It contains reference also to PF1 even if it is not managed in the scheduler but
PF1 is stored and is still valid in the BSC;
212 A30808-X3247-M24-5-7618
System
3. DL_UNITDATA: Data transfer from SGSN to BSC related to PFI2 continues;

4. PFC_FC: This message is sent from BSC to SGSN when PFT timer related to PF1
expires. In case a PFC-FC shall be sent, PFC1 is not included.
5. TBF RELEASE: This message is sent from BSC to MS. As a consequence TBF is
then released because the queues related to TLLI are empty for a long time.
To support enhanced Flow Control (eFC) feature, BSC computes “Bmax”, “R” and
“Current Bucket Level” at each “C” timer expiration. “Flow Control Command” is sent
when necessary.
Besides additional attributes have been implemented. It is out of the scope of this
manual their description. For the purpose see the manual: “CML:BSC”.
The list of all attributes and related Managed Objects specific for supporting
GPRS/EGPRS services is described in chapter: "11 Managed Objects and attributes".
7.3.6 Quality Control Function

Quality Control Function (QCF) process has improved the QoS management for
streaming traffic class. Considering that the delay requirements are going to be fulfilled
once the required bandwidth resource has been reserved, Quality Control Function
assures that QoS provision is aligned with the negotiated one.
Besides QCF triggers specific processes to respect the negotiated QoS system’s
requirements and to overcome possible degradation of the guaranteed parameters’
value.
Considering that RLC/MAC protocol runs only in “ACK” mode, above considerations
regarding Transfer Delay and Siemens implementation to support Streaming PFC (no
multiplexing), Downlink Guarantee Bitrate (GBR) parameter (Uplink and/or Downlink)
shall be monitored.
New QoS needs to be renegotiated in case degradation does not end after the recovery
process.
GBR QoS parameter shows mobile network the maximum bitrate that shall be guaran-
teed. That means, when the traffic source is sending packets at incoming rate up to
reach GBR value, this bitrate will be ensured. When incoming traffic rate exceeds GBR,
the network ensures the transfer respecting GBR value.
Packet Flow Control (PFC) function supervises at BSS side the incoming traffic rate
(LLC Frame) coming from SGSN node. The Flow control mechanism between SGSN
node and BSC provides two buckets in each entity. A closed-loop control has been
implemented. PCU calculates the control variables RPCU and Bmax and sends them to
SGSN node by means of flow control commands.
SGSN checks “permitted LLC Frame” to maintain the BSC Buffer Level into Blow and
Bhigh Levels. In case of Streaming Packet Flow Context, respective BSC Buffer
(Streaming LLC Buffer) emptying rate has to reach at least the value:
Rpcu = min {incoming traffic Rate, Guaranteed Bitrate}.
QCF process supervises the RPCU parameter; a period of degradation is possible if the
throughput does not achieve the target one. When the degradation takes place, actions
to control such situation are triggered.
To minimize the monitored parameters Flow Control Measurements are taken as input
parameters for QCF as far as Guaranteed Bitrate Controlling. New monitored parame-
A30808-X3247-M24-5-7618 213
System
ters have not be defined for handling Guaranteed Bitrate control. The process is repre-
sented in next Fig. 7.27:
Fig. 7.27 QCF and PFC Flow Control processes
In the figure above abbreviations have the following meaning:

- QCF: Quality Control Function:
- RRM: Radio Resource Manager;
- PFM: Packet Flow Management;
- Bandwitdth: Bandwidth available -> number of assigned Time Slot;
- RGUA = Guaranteed Bitrate (Target value for controlled variable);
- RPCU = Streaming PFC Rate (Controlled Variable);
- CongBuffer = 1 (True): Streaming LLC Buffer is congested (Level >= Bhigh) / 0
(False): If Streaming LLC Buffer is not congested ;
Cmd = Command towards RRM application to update physical available bandwidth.
Guaranteed bit Control is evaluated in QCF process by a specific algorithm. According
to it the following system’s behaviour has been implemented:
• In case Streaming LLC Buffer Serving Rate (RPCU) is greater than the guaranteed
one (RGUA), no action is triggered;
• In case Streaming LLC Buffer Serving Rate (RPCU ) is lower than the guaranteed
one (RGUA ) and Streaming LLC Buffer Congestion State is not signaled (Cong-
Buffer = False) again no action is triggered. That means that RPCU value is deter-
mined by the incoming traffic rate (data incoming rate is less then guaranteed one)
and not by insufficient physical bandwidth;
• In case Streaming LLC Buffer Serving Rate (RPCU) is lower than the guaranteed
one (RGUA ) and Streaming LLC Buffer Congestion State is signaled ( CongBuffer
= True ), an action is triggered. In this case RPCU value is determined by an insuf-
ficient physical bandwidth.
When a recovery action is needed, a Resource Reconfiguration is requested from QCF
to RRM in the message: “Resource Reconfigure”. RRM informs QCF on Resource Real-
location result with the message: “QCF Resource Reallocation Result (QCF RRR
MSG)”. If RRM was not able to reconfigure radio resources, QCF can inform PFM. QoS
parameter could be also renegotiated, Streaming PFC could be released or could be left
in anomalous state.
214 A30808-X3247-M24-5-7618
System
Considering the uplink guaranteed bandwidth, BSC is not informed about incoming
application traffic data rate. Measuring uplink reassembling LLC data rate in BSC is not
sufficient: measured rates less than the guaranteed one are not necessary due to insuf-
ficient physical bandwidth.
In this case the minimum rate between the Application Rate and the guaranteed one is
guaranteed by QCF application. Only an uplink TBF Resource Reconfigure is eventually
triggered and no PFM action because the network can not be completely aware of
needed uplink application incoming rate. QoS Parameter re-negotiated is in this case
demanded to the Mobile Station.
This strategy has the purpose to guarantee the minimum rate requested between the
Application Rate and the guaranteed one. Besides the uplink incoming traffic rate can
be calculated. In next Fig. 7.28 system’s model is represented:
Fig. 7.28 Uplink guaranteed bandwidth: system’s model
A specific algorithm evaluates:

1) Uplink Streaming PFC Throughput on Gb interface (UthGb parameter);
2) During each Uplink TBF, PCU calculates BLER per each TBF (BLERmeas).
The algorithm’s structure and the rules that drive its execution are implementation
specific and therefore out of the scope of this manual.
7.4 High Speed Gb Interface

High Speed (HS) Gb Interface, also defined also “Gb over IP over Ethernet” is an
enhancements of the current Gb interface but it does not substitute it. It is supported by
ESAM and PPXXV2 BSC72/120 boards. In case High Speed Gb is not configured,
current Gb interface is supported.
High Speed Gb supports the use of a broad spectrum of packet switched services (PS)
offered by an IP network as well as an optimized and efficient broadband access offered
by the physical interface provided by Ethernet. In Fig. 7.29 below it is represented the
logical network view of the High Speed Gb interface: -
A30808-X3247-M24-5-7618 215
System
Fig. 7.29 High Speed Gb interface: Logical Network view
High Speed (HS) Gb interface provides more bandwidth than current Frame Relay Gb
interface. It allows not only the use of external broadband links for supporting the Gb
interface, but it introduces also internal broadband access all the way up to the PPXU
boards. The broadband access is an essential prerequisite to provide all types of future
realtime services over the enhanced Gb interface with high QoS (for example a lower
delay). Broadband access to PPXU boards includes also the possibility of implementing
inter-PPXU communication in the future releases which could be required for example
for transfer of PFC (Packet Flow Context) and LLC buffer between PCUs for cell update,
for Packed Switched (PS) Handover procedures or possibly also for Multiband Broad-
cast Multicast Services (MBMS).
In addition, the used High Speed Gb protocol stack includes an IP transport layer, thus
allowing to use IP networks for carrying Gb instead of Frame Relay networks. IP based
transport reduces the operational effort required for setting up and maintaining the trans-
mission network (Frame Relay connections have to be configured in every node
whereas for IP connections only the endpoints shall be configured). IP based transport
is also a prerequisite for implementing the “multihoming” feature, allowing the connec-
tion of one BSC to multiple SGSN nodes for redundancy purposes.
The introduction of a Local Area Network interface at BSC for Gb interface enables flex-
ible solutions covering different network scenarios. For example when several BSCs are
co-located in one site their traffic can be concentrated by one external local router. Also,
when BSC(s) and SGSN are co-located, LAN interface is the most efficient way for inter-
connection. The use of an external router effectively de-couples BSC functions from
transmission functions, giving the user the freedom to configure the WAN interface
according to the traffic volume and independently from the interface options offered by
BSC (and SGSN) supplier(s). For example transport redundancy for WAN interface
module and the external line interfaces can be implemented in the external router
according to needs. The external Router management (for example for Operation and
Management purpose) is out of the scope of BSS system.
According to TS 48.016 Recommendation, when the BSS system and the SGSN node
are connected through an IP network with the support of a dynamic configuration, the
216 A30808-X3247-M24-5-7618
System
Network Elements are aligned by means of client/server concept. In this context, BSS
acts as client, SGSN assumes the role of server. It provides the required IP end-points
to the client to start the size and configuration procedures. The SGSN IP end-points
shall be preconfigured at BSS side. To act as server, SGSN shall use IP end-points
known to BSS NSE.
After the completion of the size procedure, the only SGSN IP end point known to the
BSS NSE are the pre-configured IP end-points.
This means that the SGSN shall send a SNS-config PDU to the BSS NSE from an end-
point known to the BSS NSE (for example pre-configured IP end-points at BSS side).
7.4.1 Gb over IP protocol Stack

In this chapter main characteristics of IP protocol Stack supporting HS Gb interface are
described.
Fig. 7.30 below shows the IP protocol Stack:
Fig. 7.30 Gb over IP protocol Stack

Network Service for Gb over IP differs significantly from Network Service for Gb over
Frame Relay (FR). The differences exist in the Sub-Network-Service and in the physical
layer. Instead of providing a set of shared parallel FR links for the transport of higher
layer data, Gb over IP uses a meshed IP network providing a transport medium between
two sets of IP endpoints at BSC and SGSN node respectively. The load sharing function
of the Network Service is controlled by using weights assigned to the remote IP
endpoints, where IP endpoint corresponds to the pair UDP Port Number, IP address.
Ethernet (Ethernet II or IEEE 802 network) is adopted as layer 2 for Gb over IP. Its
limited transmission range is surely sufficient if BSC and SGSN are co-located. Other-
wise the user shall ensure that the first router of the IP Network used for Gb (or a bridge
with a WAN interface) is located at the correct Ethernet distance from the BSC. This
A30808-X3247-M24-5-7618 217
System
router provides the WAN interfaces needed for spanning the distance to the SGSN
site/IP network as represented in the Fig. 7.31.
As it is not possible to known a priori whether an Ethernet II or IEEE 802 mobile network
is used on High Speed Gb interface between BSC and the external router, Ethernet
Switch (ES) on ESAM and PPXU boards supports both options. More details about this
are described in the: "6 Hardware and Software Architecture".
Fig. 7.31 Wan Interfaces
At least two external Ethernet links are necessary to provide link-level redundancy
supported by Network Service load sharing. As default an external router can access
different ports only if these ports have distinct IP addresses. In this way Network Service
Entities (NSE) attached to each external Ethernet link shall be assigned an own set of
IP addresses, preferably forming a subnet (for example the following: ”x.y.z.0,
x.y.z.1,…). Therefore, each Network Service Entity (NSE) within BSC shall be assigned
at least two IP addresses, one for each of the Ethernet links.
In case of failure of one of the Ethernet links, SGSN node is notified for not using the IP
addresses associated with the failed link. The notification is provided using NS/SNS
signaling, like for example “status indication”.
The UDP/IP over Ethernet encapsulation schema is represented in Fig. 7.32 below:
218 A30808-X3247-M24-5-7618
System
Fig. 7.32 IP over Ethernet Encapsulation schema
The versions of the Ethernet (possibly both intermixed) used on Gb interface are config-
urable by the user by means of specific O&M commands. All Ethernet interfaces work
in full-duplex mode. MAC addresses are associated either with the controller chip (in this
case they are delivered pre-configured) or they are written to the controller chip at
Siemens factory site. PPXUV2 boards are addressed by means of IP/MAC addresses.
Besides each PPXUV2 has two IP and two MAC addresses, one for each external
Ethernet link/Ethernet switch. Each of the redundant Ethernet switches is connected by
one Ethernet link to external IP router (the first Network Element in IP network with IP
routing function) respectively. IP addresses associated with each external link form a
subnet.
For Gb over IP over Ethernet for the maximum LLC frame length higher than 1500 Bytes
together with UDP and IP header, MTU of Ethernet (1500 Bytes) is exceed. For this
reason the enhanced version of PPXU board (PPXUV2) supports IP fragmentation.
MTU is configured per NSE.
GPRS/EGPRS security is generally performed via TFT (PDP context, transparent to the
BSC) and user plane (ciphering within LLC layer), as described in the 3GPP TS 23.060,
24.008 Recommendations. Virtual LAN (VLAN) concepts or even internal IP security for
screening BSC from ‘malicious users’ of IP network is out of scope of this manual. In
case a public IP network is used, all screening measures have place outside BSC.
However, BSC hardware supports IEEE 802.1p and 802.1q standards.
As defined in 3GPP 48.016 Recommendation the static configuration is provided in case
the customer needs to create a point-to-point configuration. Furthermore the static
configuration is also used if an IP network is located between SGSN node and BSS
system and the customer does not need to create a fully meshed connectivity. All config-
uration information like for example the local and remote IP endpoints, data and
signaling weights are configured by the user in SGSN as well as in all peer Network
A30808-X3247-M24-5-7618 219
System
Service Entities (NSE). No automatic check has been implemented to guarantee the
correctness of these parameters. Checks shall be executed by the user.
In case BSS and SGSN are connected via an IP network and a fully meshed connectivity
is adopted, dynamic configuration is used to create NS-VCs. The dynamic configuration
(autoconfiguration) presupposes a fully meshed connectivity that means that every
IPv4-endpoint of BSS-NSE can communicate with every IPv4-endpoint of the SGSN-
NSE.
The user creates all local IP endpoints by means of specific commands and defines local
data and signaling weights. For the initial communication the user has to make known
one SGSN IP endpoint in BSC NSE.
An initial configuration information exchange with peer NSE is done using ‘size’ and
‘configuration’ SNS procedures. With their support, SGSN and BSS exchange data
concerning the number and address of their IP-endpoints to build NS-VCs between
them and the signaling and data weight for load sharing. Later the configuration can be
modified by the user using ‘add’, ‘delete’ and ‘change weight’ SNS procedures.
7.4.2 BSC Hardware and Upgrade Strategy

Some BSC/72 and BSC/120 boards have been enhanced to support High Speed Gb
interface. The modified boards are the following:
• CPEX board (Control Point and Expansion Alarms) has been enhanced to provide
Ethernet switching. It has been called: “ESAM” (Ethernet Switch and Expansion
Alarm Module);
• PPXX Board (Peripheral Processor XX) has been enhanced to provide a duplicated
Ethernet direct interface to ESAM Board. The new version is called: “PPXXV2”.
More details about ESAM and PPXXV2 boards together with their redundancy rules are
described in chapter: "6 Hardware and Software Architecture".
For backward compatibility Gb over FR is still supported by PPXUV2. Simultaneous
operation of PPXUs and PPXUV2s are supported as follow:
• Standard PPXU with Gb over FR and PPXUV2 supporting Gb over IP over Ethernet.
This configuration allows smooth migration from Gb over FR to Gb over IP over
Ethernet;
• Standard PPXU and PPXUV2 both supporting Gb over FR: This configuration
enables the support of single, common PPXUV2 production line; besides an higher
throughput also with Gb over FR is provided.
A smooth migration is allowed from Gb over FR to Gb over IP over Ethernet for PCU
supported by PPXUV2 boards.
Additional details about BSC configuration are described in chapter: "6 Hardware and
Software Architecture".
High Speed Gb interface has also affected BSS information model for the implementa-
tion of additional Managed Objects and attributes.
Objects and attributes are listed in chapter:"11 Managed Objects and attributes".
220 A30808-X3247-M24-5-7618
System
8 Load Control for Packet Switched Services

As described in the chapter: "6.1.3 Redundancy and Configuration Rules", when the
user configures a GPRS/EGPRS cell, for example when the user creates a PTPPKF
Managed Object, he/she does not have to assign the cell to a specific PCU, but it is the
system that dynamically assigns the cell to one of the PCUs. This is a direct conse-
quence of the load balancing redundancy mechanism implemented in the BSS system.
When one PCU fails (for example when a PPXU configured in a BSC/72,BSC/120 fails),
the system redistributes the PS traffic on the remaining PCUs.
In the BSC there is a load control system mechanism that manages the PTPPKFs distri-
bution among the PCUs available in the system.
The calculation is executed 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 the PTPPKFs belonging to
that PCU are moved to other PCUs; the algorithm evaluates new PTPPKFs distribution
considering the number of PTPPKF already present on each PCU and the number of
resources reserved to the packet switched services for each PTPPKF. This procedure
is described in detail in the chapter: "8.1 Dynamic PTPPKF Reconfiguration".
If 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 dynamic PTPPKF distribution process is based on a guard timer, in order
to avoid oscillation in case of fast PCU state changes (see the chapter: "8.1.5 Time
Needed to Execute PTPPKF Reconfiguration").
In order to enable the movement of one PTPPKF from one PCU to another, all the
i PCUs shall be configured in the same manner..
8.1 Dynamic PTPPKF Reconfiguration

The PTPPKFs distribution/redistribution algorithm is performed by the GPRS/EGPRS
load control process implemented in the TDPC processor.
The PTPPKFs reconfiguration is performed in the following cases:
• when the boards related to the PCU become unavailable; this situation could happen
when:
– PPXU board fails;
– PPXU board is locked.
• the connection of the PCU towards the SGSN network node goes down, that means
that the last NSVC connection from the PCU to the SGSN is no longer available; this
situation can 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);
– 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;
A30808-X3247-M24-5-7618 221
System
• the connection of the PCU towards the SGSN comes back, that means that the last
NSVC connection from the PCU to the SGSN is available again..
In general, the PTPPKFs reconfiguration is triggered from all the operations
i that generate a PCU/Gb down-restart.
So the previous causes can be summarized as follow: “any time the Gb inter-
face related to any PCU is no longer 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 as consequence an unbal-

anced distribution of PTPPKFs among the PCUs.
It shall be noted that:
1. the PTPPKF creation is not included as a trigger for the PTPPKFs reconfiguration
(when a PTPPKF is created, it is assigned to the less loaded PCU);
2. the PCU creation itself does not trigger the PTPPKFs reconfiguration, but the recon-
figuration starts when the first NSVC is created and enabled for this PCU (for
example when the connection on the Gb interface is available);
3. the PCU overload (see the chapter: "8.2 PCU Overload Management") does not
trigger the PTPPKF reconfiguration, since, in this case, no PCU/Gb down-restart is
executed.
To handle the distribution/redistribution algorithm, the system uses the following infor-
mation:
• dynamic information:
– state of PCUs configured in the BSC;
– state of PTPPKFs configured in the BSC;
• static information:
– number of PCUs and PTPPKFs configured in the BSC;
– total number of radio channels configured for PS services for each PTPPKF
(packet control channels + reserved packet channels + dynamic packet chan-
nels);
– Routing Area of the PTPPKF (only at init time);
– total number of timeslots configured for each PCU on the Gb interface (see the
chapter: "7 Gb Interface").
Considering the following definition:
PCU_TS_Gb Number of 64 kbit/s timeslots related to the FR links associated

to a specific PCU
PTPPKF_load(i) Number of GPRS/EGPRS channels (static and dynamic)
configured for a specific PTPPKF(i)
The load of a single PCU can be considered as the sum of the PTPPKF_load of all the
PTPPKFs 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); It results:
PCU_load = (Sum PTPPKF_load(i) [i=1..n]) / PCU_TS_Gb

where “n” is the number of PTPPKFs associated to the PCU
222 A30808-X3247-M24-5-7618
System
Then the algorithm tries to distribute the packet switched traffic among the configured
and available PCUs, so that 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 with 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 the 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 carrying traffic because they are
disabled or have been locked; this set is 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
possible moving; this set is the second analyzed for possible moving of PTPPKFs,
when a new PCU goes into service.
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);
– Creation of a new PCU object (new PPXU board));
– PCU not available;
– PCU again in service.
8.1.1 System Initialization

When the system is initialized, BVCI synchronization is performed, between the BSC
and the SGSN, using the BVC RESET procedure (see the chapter: "7.3.1.1 BVC Proce-
dures"). Then the distribution algorithm distributes the configured PTPPKFs among the
configured and available PCUs as represented in the Fig. 8.1; the algorithm takes into
account, besides the PCU loads, the Routing Area of the PTPPKFs (regarding routing
areas, see the chapter: "9.2 Network Structure").
The algorithm considers the Routing Areas only at init time.
i
In fact the algorithm tries, if possible, to associate a Routing area to just one PCU for
reducing the paging load.
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-M24-5-7618 223
System
PCU:0
PTPPKF
NSEI:0
RA=2 PTPPKF
PCU_load=9/3=3
1 PDCH RA=1
BVC=4 3 PDCH
BVC=23 PCU_TS_Gb= 3
PTPPKF
RA=2 PTPPKF PTPPKF
1 PDCH RA=2 RA=1
BVC=24 1 PDCH 3 PDCH
BVC=33 BVC=34
SGSN
PCU:4
NSEI:4
PCU_load=3/1=3 PTPPKF
RA=3
1 PDCH
BVC=77 PCU_TS_Gb= 1
PTPPKF
RA=5
2 PDCH
BVC=35
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 as represented in the Fig. 8.2.
Then, when the cells are shifted to the new PCU, the BVC RESET and UNBLOCK
procedures are performed for the same cells as represented in Fig. 8.3.
In the BSS system neither the Cell Identifier nor the BVCI of the moved cells change.
224 A30808-X3247-M24-5-7618
System
PCU:0 BSSGP:BVC_BLOCK_34
PTPPKF
NSEI:0
RA=2 BSSGP:BVC_BLOCK_ACK_34
old_PCU_load=9/3=3 PTPPKF
1 PDCH RA=1
new_PCU_load=6/3=2
BVC=4 3 PDCH
BVC=23 PCU_TS_Gb= 3
PTPPKF
RA=2 PTPPKF PTPPKF
1 PDCH RA=2 RA=1
BVC=33 BVC=34
PCU:2
NSEI:2
PCU_load=4/2=2
PCU_TS_Gb= 2 SGSN
New PCU is created
PCU:4
NSEI:4 BSSGP:BVC_BLOCK_77
old_PCU_load=3/1=3 PTPPKF
new_PCU_load=2/1=2 RA=3 BSSGP:BVC_BLOCK_ACK_77
1 PDCH
BVC=77 PCU_TS_Gb= 1
PTPPKF
RA=5
2 PDCH
BVC=35
Fig. 8.2 Example of PTPPKF distribution-Step 1
A30808-X3247-M24-5-7618 225
System
PCU:0
PTPPKF
NSEI:0
RA=2 PTPPKF
PCU_load=6/3=2
1 PDCH RA=1
BVC=4 3 PDCH
BVC=23 PCU_TS_Gb= 3
PTPPKF
RA=2 PTPPKF
1 PDCH RA=2
BVC=24 1 PDCH
BVC=33
PCU:2 BSSGP:BVC_RESET_34:Cell Identifier

NSEI:2
BSSGP:BVC_RESET_ACK_34
PCU_load=4/2=2 PTPPKF
RA=1 BSSGP:BVC_UNBLOCK_34
3 PDCH
BVC=34 BSSGP:BVC_UNBLOCK_ACK_34 SGSN
PCU_TS_Gb= 2
PTPPKF BSSGP:BVC_RESET_77:Cell Identifier

RA=3 BSSGP:BVC_RESET_ACK_77
1 PDCH
BVC=77 BSSGP:BVC_UNBLOCK_77
BSSGP:BVC_UNBLOCK_ACK_77
PCU:4
NSEI:4
PCU_load=2/1=2
PCU_TS_Gb= 1
PTPPKF
RA=5
2 PDCH
BVC=35
Fig. 8.3 Example of PTPPKF distribution - Step 2
226 A30808-X3247-M24-5-7618
System
8.1.3 PCU Not Available

When a PCU is not available (for example for a fault), the algorithm redistributes the
configured PTPPKFs among the remaining PCUs.
Since the PCU is faulty, it is not possible to perform the BVC BLOCK procedure on the
damaged PCU (in any case the SGSN can detect this anomaly because the L2 layer is
not running).
The PTPPKFs are moved onto healthy PCUs, and then a BVC RESET procedure is
started for each shifted PTPPKF Managed Object as represented in Fig. 8.4.
The routing area information is not considered by the algorithm, to save the time of the
elaboration.
PCU:0
PTPPKF
NSEI:0 BSSGP:BVC_RESET_34:Cell Identifier
RA=2 PTPPKF
old_PCU_load=6/3=2
1 PDCH RA=1
new_PCU_load=9/3=3 BSSGP:BVC_RESET_ACK_34
BVC=4 3 PDCH
BVC=23 PCU_TS_Gb= 3
PTPPKF
RA=2 PTPPKF PTPPKF BSSGP:BVC_UNBLOCK_34
1 PDCH RA=2 RA=1 BSSGP:BVC_UNBLOCK_ACK_34
BVC=33 BVC=34
PCU:2 NO block procedures

NSEI:2 on Gb interface.
FAILED PTPPKF The PCU fails suddenly
RA=1
3 PDCH
PCU_TS_Gb= 2
BVC=34 SGSN
PTPPKF
RA=3
1 PDCH
BVC=77

NSEI:4 PTPPKF
old_PCU_load=2/1=2 RA=3 BSSGP:BVC_RESET_ACK_77
new_PCU_load=3/1=3 1 PDCH
BVC=77
PCU_TS_Gb= 1
PTPPKF
RA=5
2 PDCH BSSGP:BVC_UNBLOCK_77
BVC=35 BSSGP:BVC_UNBLOCK_ACK_77
Fig. 8.4 Example of PTPPKF distribution in case of PCU unavailable
A30808-X3247-M24-5-7618 227
System
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 as represented in Fig. 8.5.
This process is not considered as a PTPPKF reconfiguration, in fact in order to mini-
mize the TBFs release, the reallocation algorithm is not performed when a PCU comes
back in service after a fault, but the PTPPKFs belonging to this PCU will be put back on
it.
Eventually, the PTPPKFs that belonged to the other faulty PCUs are 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 (for example it has been created), then the algorithm performs a total
reconfiguration;
2. if some modifications regarding the FRLs allocation of the PCU have been done
during the period of time the PCU/Gb has been 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 global redistribution.
In the first case, the previously moved cells are returned back without a new load calcu-
lation; the reason for not doing so is that in this case a new recalculation is simply due
to the need of managing short unavailability of Gb or PCU.
228 A30808-X3247-M24-5-7618
System
PCU:0 PTPPKF BSSGP:BVC_BLOCK_34

NSEI:0 RA=2
old_PCU_load=9/3=3 PTPPKF BSSGP:BVC_BLOCK_ACK_34
1 PDCH RA=1
new_PCU_load=6/3=2 BVC=4 3 PDCH
BVC=23 PCU_TS_Gb= 3
PTPPKF
RA=2 PTPPKF PTPPKF
1 PDCH RA=2 RA=1
BVC=33 BVC=34

NSEI:2
BSSGP:BVC_RESET_ACK_34
IN-SERVICE PTPPKF
RA=1 BSSGP:BVC_UNBLOCK_34
3 PDCH
BVC=34 BSSGP:BVC_UNBLOCK_ACK_34 SGSN
PCU_TS_Gb= 2
PTPPKF BSSGP:BVC_RESET_77:Cell Identifier

RA=3 BSSGP:BVC_RESET_ACK_77
1 PDCH
BVC=77 BSSGP:BVC_UNBLOCK_77
BSSGP:BVC_UNBLOCK_ACK_77
PCU:4
NSEI:4 PTPPKF BSSGP:BVC_BLOCK_77
old_PCU_load=3/1=3 RA=3
1 PDCH BSSGP:BVC_BLOCK_ACK_77
new_PCU_load=2/1=2
BVC=77
PTPPKF
RA=5
2 PDCH
BVC=35
Fig. 8.5 Example of PTPPKF distribution when a PCU is in Service
A30808-X3247-M24-5-7618 229
System
8.1.5 Time Needed to Execute PTPPKF Reconfiguration

For what concerns the PTPPKFs distribution/redistribution algorithm a mechanism
based on a Guard Timer is provided for avoiding oscillation in cases of fast PCU
changes.
This timer lasts five 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 the Gb/PCU status).
Obviously, this timer does not regard newly 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 a few milliseconds, apart
from some calculations taking into account routing area considerations.
Calculations taking into account routing area considerations lasts some tens of millisec-
onds, so they cannot be done when the TDPC is normally running. Thus they are
executed only at init phase as described in the chapter: "8.1.1 System Initialization").
The redistribution procedure takes, in general, few 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.
8.2 PCU Overload Management

For what concerns the PTPPKFs distribution/redistribution algorithm, no reconfiguration
is foreseen due to Overload reasons, since as it has been described in the chapter: 8.1,
the only triggers are Down/Restart of PCU/Gb.
The overload prevention mechanism is based on the real time of the related board.
The PCU overload management alarm is triggered when the 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,
non-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, non-configurable,
threshold.
The GPRS/EGPRS overload handler acts structurally as the already existing BSC and
BTS overload handlers. When a PCU Overload occurs, an alarm message is generated
and it is sent in real time to the LMT Evolution and also to the Radio Commander. The
overload process is controlled by BSCT17 and BSCT18 attributes 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 the GPRS/EGPRS overload handler to reduce the PS
service traffic, is based upon the sending of System Information indicating that
GPRS/EGPRS services are not available in the cell. This is done for a progressively
230 A30808-X3247-M24-5-7618
System
increasing number of cells (at steps of ten 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 is present again are sent; this is done in steps of five cells that
had been formerly "GPRS/EGPRS barred". When all the cells return in the original situ-
ation, the PCU overload alarm is ceased.
A30808-X3247-M24-5-7618 231
System
9 GPRS/EGPRS Procedures
In this chapter the main procedures for supporting and providing GPRS/EGPRS
services are described.
9.1 Mobile Stations for Packet Switched Services

A GPRS/EGPRS Mobile Station is able to operate in one of three modes of operation.
The mode of operation depends on:
– the services that the Mobile Station is attached to, for example, only PS services or
both PS and CS service;
– the Mobile Station capabilities to operate GPRS/EGPRS and other GSM services
simultaneously.
The three modes of operation are the following:
• Class-A mode of operation: the Mobile Station is attached to both GPRS/EGPRS
and other GSM services, and it supports simultaneous operation of GPRS/EGPRS
and other GSM services;
• Class-B mode of operation: the Mobile Station is attached to both GPRS/EGPRS
and other GSM services, but the Mobile Station can only operate one set of services
at a time. In network operation mode III (see the chapter: "9.8.3.1 Network Opera-
tion Modes for Paging"), a Mobile Station 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 Mobile Station reverts to class-C mode of operation.
• Class-C mode of operation: the Mobile Station is exclusively attached to
GPRS/EGPRS services.
For what concerns EGPRS Mobile Station only, a supplementary distinction exists. Two
classes are foreseen:
– the first class supports the 8PSK modulation in downlink direction and the GMSK
modulation in uplink direction;
– the second class has a more advanced capability and it supports the 8PSK modu-
lation in both uplink and downlink directions.
9.2 Network Structure

On the air interface, the network structure remains the same as for GSM. An additional
identifier has been 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 Location Area 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 attributes have been introduced:
• the Routing Area Code (RACODE): it identifies 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.
The Fig. 9.1 shows an example of network structure.
232 A30808-X3247-M24-5-7618
System
Location Area
Routing Area
Fig. 9.1 Network Structure: Example
9.3 Mobility Management Functionalities
9.3.1 Mobility Management States

The Mobility Management (MM) activities related to a GPRS/EGPRS user are charac-
terized by one of three different Mobility Management states as represented in next
Fig. 9.2. Each state describes a certain level of functionality and of allocated informa-
tion. The information, which is held on both MS and SGSN sides, is defined Mobility
Management (MM) context.
A30808-X3247-M24-5-7618 233
System
Fig. 9.2 Mobility Management States
9.3.1.1 IDLE State

In GPRS IDLE state the user is not attached to the GPRS/EGPRS mobility manage-
ment. Both the MS and the SGSN contexts hold no valid location or routing information
for the user. The user-related mobility management procedures are not executed.
PLMN selection and GPRS/EGPRS cell selection and re-selection processes are
performed by the Mobile Station.
In order to establish Mobility Management contexts in the MS and in the SGSN, the MS
performs the GPRS Attach procedure (see the chapter: "9.3.2.1 Attach Function").
When the GPRS attach procedure has been successfully executed, the Mobility
Management state moves from IDLE to READY: the MS requests access and a logical
link to a SGSN is established.
9.3.1.2 STAND-BY State

In STANDBY state the user is attached to GPRS/EGPRS mobility management. The
Mobile Station and the SGSN network node have established MM contexts for the
subscriber.
Pages for PTP data transfers or signaling 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
are not possible in stand-by state.
The Mobile Station 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 Mobile Station does not inform the SGSN
about a change of the cell in the same RA. Therefore, for Mobile Stations in STANDBY
234 A30808-X3247-M24-5-7618
System
state, the location information in the SGSN MM context contains only the routing area
identity (RAI).
The Routing Area Identity is calculated by means of the following formula:
i RAI = MCC + MNC + LAC + RAC
where:
- MCC = mobile country code;
- MNC = mobile network code;
- LAC = location area code;
- RAC = routing area code.
The Mobile Station may initiate the activation or the deactivation of PDP contexts while
it is in STANDBY state. A PDP context must be activated before data can be transmitted
or received for this PDP context.
The SGSN can send data or signaling information to a Mobile Station in STANDBY
state; in this case the SGSN sends a Paging Request in the routing area where the
Mobile Station is located. The MM state in the Mobile Station changes to READY when
the MS responds to the page, and in the SGSN when the response to paging is received.
The MM state in the MS also changes to READY when data or signaling information is
sent from the MS and the MM state in the SGSN changes to READY when data or
signaling information is received from the Mobile Station.
The Mobile Station or the network can start the GPRS Detach procedure to move to the
IDLE state. After the expiration 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 INAC-
TIVE 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 Mobile Station.
9.3.1.3 READY State

In READY state the MM context corresponds to the “STANDBY” MM context extended
by the location information for the subscriber on the cell level. The Mobile Station
performs mobility management procedures to provide the network with the actual
selected cell. GPRS/EGPRS cell selection and re-selection is executed locally by the
Mobile Station, or optionally may be controlled by the network (see the chapter:
"10.4 Network Controlled Cell Reselection and Traffic Control Management").
The Mobile Station may send and receive PDP PDUs in this state. The network does
not initiate PS pages for a Mobile Station in READY state; pages for other services may
be done via the SGSN network node. The Mobile Station 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-M24-5-7618 235
System
In order to move from READY state to IDLE state, the Mobile Station initiates the GPRS
Detach procedure.
The following procedures cause the transition from the ready state to the other MM
states:
• moving from READY to STANDBY:
– READY timer expiry: 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 are 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 that 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 Mobile Station and the SGSN MM
contexts return to STANDBY state. The length of the READY timer is 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

The Mobility Management procedures use the LLC and RLC/MAC protocols for the
messages’ transmission on the Um interface. The MM procedures provide information
to the underlying layers to enable reliable transmission of MM messages. User data can
be transmitted during MM signaling procedures.
User data transmitted during attach, authentication, and routing area update procedures
may be lost and therefore may have to be retransmitted. In order to minimize the need
for retransmission, the Mobile Station and the SGSN network node do not 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 Mobile Station. In the attach
procedure, the Mobile Station provides its identity and an indication of which type of
attach it shall 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 Mobile Station 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-
ordinated way, for example, only when the Gs interface between the MSC and the
236 A30808-X3247-M24-5-7618
System
SGSN is configured (see also the chapter: "9.8.3.1 Network Operation Modes for
Paging").
If the network operates in Mode I (see the chapter: "9.8.3.1 Network Operation Modes
i for Paging"), then a Mobile Station 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 accesses the CCCH
channel for CS only operation.
After having executed the GPRS attach procedure, the Mobile Station is in READY state
and MM contexts are established in both the MS and the SGSN. The MS may then acti-
vate PDP contexts as described in the chapter: "9.7 Activation and Deactivation of a
PDP Context".
An IMSI-attached MS that can only operate in class-C mode of operation follows the
normal IMSI detach procedure before making a GPRS attach. A GPRS-attached MS in
class-C mode of operation performs always a GPRS detach before making an IMSI
attach.
The steps of the Attach procedure are illustrated below:
1. The Mobile Station 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 shall be performed, for example,
GPRS/EGPRS attach only, GPRS/EGPRS Attach while already IMSI attached, or
combined (E)GPRS/IMSI attach;
– DRX Parameters: indicate when the Mobile Station is in a non-sleep mode and
when it is able to receive paging requests and channel assignments (see the
chapter: "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
message: “Attach Complete”..
P-TMSI (Packet Temporary Mobile Subscriber Identity) is optionally sent by the SGSN
i 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 allo-
cated 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 Mobile Station. The P-TMSI signature parameter has only local significance in the
SGSN that has allocated the signature.
P-TMSI is similar the GSM T-IMSI (temporary IMSI).
A30808-X3247-M24-5-7618 237
System
If the Attach Request cannot be accepted, the SGSN send the message: Attach Reject
to the Mobile Station. The message contains the cause that has generated the rejection.
A GPRS/EGPRS-attached Mobile Station makes IMSI attach via the SGSN with the
combined RA/LA update procedure if the network operation mode is “I”. In network oper-
ation modes “II” and “III”, or if the Mobile Station is not GPRS/EGPRS-attached, the
Mobile Station executes the IMSI attach as defined in the GSM Recommendations.
9.3.2.2 Detach Function

The Detach function allows a Mobile Station to trigger a GPRS/EGPRS and/or an IMSI
detach procedure. Besides the network can inform the Mobile Station that it has been
GPRS/EGPRS-detached or IMSI-detached.
A GPRS/EGPRS-attached MS sends the message:Detach Request to the SGSN
network node, asking a GPRS/EGPRS detach.
The message: Detach Request contains an indication to determine if the detach is due
to switch off or not. The indication is needed to decide whether or not a Detach Accept
message will be returned.
9.4 Radio Resource Management

Radio Resource (RR) management procedures are characterized by two different RR
operating modes with the related states as respresented in Fig. 9.3. Each mode
describes a certain functionality and information allocated.
- No RLC context in
Packet Idle State
MS & SGSN
- Mobile originated
call - Deactivation of RLC context
- Answer to paging
Packet Transfer - RLC context in MS & SGSN

- Routing context between
State MS & SGSN
Fig. 9.3 Radio Resource States
9.4.1 Packet Idle State

In packet idle mode no Temporary Block Flows exist (see the chapter: "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).
238 A30808-X3247-M24-5-7618
System
In packet idle mode the MS listens to the PBCCH channel and to the paging sub-channel
for the paging group to which the MS belongs. If the PCCCH is not present in the cell,
the mobile station listens to the BCCH and to the relevant paging sub-channels.
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. leaves the packet transfer mode;
2. enters the packet idle mode;
3. switches to the new cell;
4. reads the system information of the new cell;
5. 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

The Tab. 9.1 provides the correspondence between the Radio Resource states and
The Mobility Management states.
MM States READY STAND-BY

RR States Packet Transfer Packet Idle state Packet Idle state
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 Mobile Station, in
the SGSN and GGSN network nodes.
Every PDP context exists independently in one of two PDP states. The PDP state indi-
cates whether or not the PDP address is activated for data transfer. Activation and deac-
tivation procedures are described in the chapter: 9.7. All PDP contexts of an user are
associated with the same MM context for the IMSI of that user as respresented in
Fig. 9.4 below.
A30808-X3247-M24-5-7618 239
System
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
user 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 the user causes no update for the PDP context in INACTIVE state
even if the user 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-termi-
nated PTP packets received in INACTIVE state invoke error procedures in the GGSN
(for instance an IP packet is discarded). Other error procedures can be introduced on
the application level but they are not described in this manual.
The MS initiates the transition from the INACTIVE state to the ACTIVE state by starting
the PDP Context Activation procedure (see the chapter: "9.7.1 PDP Context Activa-
tion").
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 GGSN network nodes. The PDP context contains mapping and routing
information for transferring the PDUs (for that particular PDP address) between the MS
and the GGSN network node. The ACTIVE PDP state is permitted only when the
mobility management state of the subscriber is STANDBY or READY.
240 A30808-X3247-M24-5-7618
System
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 meaningful at the NSS level and in the MS, and do not directly
involve the BSS system. 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 GGSN
network nodes.
Upon receiving a message: “Activate PDP Context Request”, the SGSN initiates the
procedures to set up PDP contexts.
Upon receiving a message: “Deactivate PDP Context Request”, the SGSN starts the
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
only the ‘best effort’ quality of service, giving the available resources to the MS, without
taking into account any mobile request.
In the following, the PDP Context Activation procedure is described in detail:
1. In order to activate a PDP context, the mobile station sends a message: CHANNEL
REQUEST to the network. The network, after having reserved a channel on the
BTS, sends a message: IMMEDIATE ASSIGNMENT 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 ACTI-
VATE PDP CONTEXT REQUEST;
2. The MS sends the message: “ACTIVATE PDP CONTEXT REQUEST” to the SGSN
network node. The following information is contained in the message:
– PDP Address: 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
leaves the PDP Address empty to request a dynamic PDP address;
– Access Point Name: it is a logical name referring to the external packet data
network to which the subscriber wishes to connect;
– QoS: indicates the desired QoS profile;
3. Security functions are executed by the SGSN;
4. The SGSN validates the message: 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 message : CREATE PDP CONTEXT REQUEST (PDP Type,
PDP Address, Access Point Name, Negotiated QoS) to the affected GGSN;
6. The GGSN uses the Access Point Name to find 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 message: CREATE PDP CONTEXT RESPONSE to the
SGSN. PDP Address is included if the GGSN has allocated a PDP address;
A30808-X3247-M24-5-7618 241
System
8. The SGSN selects the Radio Priority based on the Negotiated QoS, and returns the
message: ACTIVATE PDP CONTEXT ACCEPT to the MS.
The RLC/MAC layer supports four Radio Priority levels and an additional level for
i signaling messages as defined in GSM 04.60 Recommendation. 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 signaling message transmission. This information is used by the
BSS to determine the radio access precedence (for example the access priority) and
the service precedence (for example, transfer priority under congested situation).
The Radio Priority concept is related to the QoS one, for example a higher Quality of
Service corresponds to a higher Radio Priority. The Radio Priority is coded as follows:
- 0: Radio Priority 1 (Highest priority, used also for signaling)
- 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 used a dynamic PDP address, then
the GGSN releases this PDP address and makes it available for subsequent activa-
tions by other MSs;
4. The SGSN returns a DEACTIVATE PDP CONTEXT ACCEPT message to the MS.
At GPRS/EGPRS detach, all PDP contexts for the MS are implicitly deactivated.
i
9.7.3 One Time Slot for MM and SM procedures

During the execution of signaling procedures (for example the RA update, PDP Context
Activation, Attach, Deattach, etc), the PCU allocates the downlink PDCH’s equal to the
maximum number that the Mobile Station is capable of.
For the reason that signaling is still a major part of the traffic in the mobile networks,
there is a waste of air interface resources due to the small amount of data that is trans-
ferred during the execution of the signaling procedures. Due to the horizontal allocation
two 4 TS Mobile Station could allocate a complete TRX and only for submission of a
small number of radio blocks. In this way it is possible to reach the peak number of
timeslots (PDTs) which can be handled by the PCU and thus limiting the availability and
the throughput for the user data.
For the reason that customers have configured today only a small number of PDCHs in
a cell (typically up to 6), this feature also prevents too much multiplexing of several users
on the same Time Slot, thus additionally speeding up the throughput for other users
transferring data.
Moreover a delay occurs in the system according to the PDCH bring up / synchroniza-
tion. The GPRS/EGPRS supports unidirectional channels. So the uplink and downlink
are synchronized independently. The PDCH synchronization time (150ms) takes longer
than the submission of some blocks on a single timeslot. In case of a single timeslot only
242 A30808-X3247-M24-5-7618
System
1 synchronization is necessary leading the GMM and SM procedures speeding up of

about 150ms
As a consequence in the current BSS BR8.0 release the GMM and SM procedures are
handled with 1 timeslot in downlink only. The assignment to one timeslot is applied
during the channel allocation and not when the channel is already allocated.
This features applies to downlink only for the reason that for the uplink it is not known
whether signaling or data is arriving. As a consequence the BR7.0 implementation has
been preserved.
9.8 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 to establish a TBF can be done:
• on CCCH if the PBCCH/PCCCH is not configured in the cell;
• on PCCCH if the PBCCH/PCCCH is allocated in the cell.
Two types of establishment have been defined:
– TBF establishment initiated by the MS, for example a MS initiated packet transfer;
– TBF establishment initiated by the network, for example a network initiated packet
transfer.
9.8.1 Medium Access Modes

Two types of access modes have been defined:
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 the MS that monitors the USF values on the allocated
PDCHs and transmits Radio blocks on those that currently bear the USF value
reserved for the usage of the MS;
b) Fixed Allocation: it is characterized by fixed allocation of radio blocks and PDCHs in
the assignment message, without assigning USF values. In the current 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 from the Mobile Station to the network. Packet access is done on the
PCCCH if it exists, otherwise packet access is done on the CCCH.
Messages that are exchanged either on the CCCH or PCCCH channel are shown using
i the following method: messages exchanged on CCCH are normally used, whereas the
corresponding PCCCH messages are inserted in brackets.
The packet access procedure is started by the Mobile Station when a request to transfer
LLC PDUs comes from upper layers.
Two different access types exist:
• one phase access: the network responds reserving resources on the PDCH(s) to
allow the uplink packet transfer of a number of Radio Blocks;
A30808-X3247-M24-5-7618 243
System
• two phase access: the network responds reserving resources for transmitting a
message: PACKET RESOURCE REQUEST. This message is used by the MS to
better define the requested radio resources.
In both cases, when the uplink TBF is set up, the following attributes 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 will use the continuous update timing advance mechanism, using the PTCCH
in the same timeslot as the assigned PDCH. If a timing advance index (TAI) field is
not included, the continuous update timing advance mechanism will not be used;
– MAC access mode (always set to dynamic) see the chapter: "9.8.1 Medium Access
Modes").
In addition, the EGPRS uplink assignment contains the following information:
– the EGPRS modulation and coding scheme;
– the EGPRS window size;
– information on whether or not retransmitted uplink data blocks must be reseg-
mented.
When a MS tries to access to the network, the attribute: GPATH indicates if the MS,
according to its priority class, is authorized to perform a random access to request the
packet switched services.
9.8.2.1 8 Bit or 11 Bit Uplink Access

To access the GSM network, a slotted-aloha protocol is used; the access is performed
sending a traditional 8 bit Access Burst type.
According to the ETSI specifications, a new enhanced Access Burst type with 11 infor-
mation bit can be sent by the mobile station to try to access the network. In fact, 8 bit of
information does not allow to widely specify the needed resources. To overcome this
bottleneck an access burst using 11 information bit is defined. The Fig. 9.5 shows the
coding process of the 11 bit access burst.
Therefore, a GPRS/EGPRS Mobile Station can access the network by using an 8 bit or
an 11 bit access burst, in particular:
• the CHANNEL REQUEST message sent on the RACH is always formatted with 8 bit
of information;
• the PACKET CHANNEL REQUEST sent on the PRACH can be formatted either with
8 or 11 bit.
The possibility of using one message type or the other one for the message:
PACKET CHANNEL REQUEST depends on the network settings: the capability of
the network to receive 8 or 11 bit length message is broadcast by the System Infor-
mation attribute: ABUTYP, that indicates the allowed type of access.
The ABUTYP setting also indicates which type of access burst (8 or 11 bit) must be
sent:
– for PACKET CONTROL ACKNOWLEDGMENT messages, that are formatted as
four access burst;
244 A30808-X3247-M24-5-7618
System
– 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
i CHANNEL REQUEST message, that can be used from EDGE mobile stations to access
a cell as described in the chapter: "9.8.2.4 TBF Establishment for EDGE Mobile
Stations".
The advantages of the 11 bit uplink access are the following:

– it allows a one phase access instead of a two phases access;
– it speeds up the call set-up and decreases the signaling load.
The 8 bit access on the PRACH or RACH is used in case of PAGING RESPONSE,
CELL UPDATE, MM PROCEDUREs and in all cases that the MS requires sending no
more information than its class and priority.
The 11 bit access on the PRACH is used in all cases described for 8 bit access, but with
additional information to be carried in the access phase for example an enhanced
random reference number leading to less probability of MS collision when trying to
establish an uplink TBF.
11 information bit
1/2
+ 6 bit 36 encrypted
Convolutional
6 parity bit puncturing bit
coder
+
4 tail bit
Access Burst
Tail Synchronization Sequence Information bit Tail Guard period
36 bit
Fig. 9.5 Coding of the 11 Bit Access Burst
9.8.2.2 Establishment using a One Phase Access

A Mobile Station initiates the packet access procedure by scheduling the sending of the
HANNEL REQUEST (PACKET CHANNEL REQUEST) messages on the RACH
(PRACH) channel, and simultaneously leaving the packet idle mode.
The arguments described in this chapter are valid for GPRS MSs and also for EDGE
i MSs when the EGPRS PACKET CHANNEL REQUEST message is not supported in the
cell (see the chapter: "9.8.2.4 TBF Establishment for EDGE Mobile Stations").
Then, the mobile station monitors the full CCCH (PCCCH) channel corresponding to its
RACH (PRACH) channel waiting for the network answer.
If the PCCCH is configured and the mobile station receives the PERSISTENCE_LEVEL
i parameter from the network, the value of the PERSISTENCE_LEVEL parameter is
taken into account at the next PACKET CHANNEL REQUEST attempt (see the chapter:
"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 occurs according to its class:
A30808-X3247-M24-5-7618 245
System
– a Mobile Station in class A or class B mode of operation will 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 proce-
dure, if it receives a paging message indicating the establishment of circuit switched
connections;
– Mobile Stations in class C mode of operation will not respond to any type of paging
messages during the packet access procedure.
CHANNEL REQUEST (PACKET CHANNEL REQUEST) messages are sent on the
RACH (PRACH) channel and contain, beside the indication of the type of access, the
required parameters to indicate the demand of radio resources from the Mobile Station.
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 according to the information about the
requested resources, comprised in the channel request.
On the RACH channel, in the CHANNEL REQUEST message, there are only 8 bit 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 the RACH, using the CHANNEL REQUEST
message, see the chapter: "9.8.2.4 TBF Establishment for EDGE Mobile Stations") or
to request a two phase access.
On the PRACH, the message: “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.
The Fig. 9.6 shows a one phase access procedure on PCCCH.
246 A30808-X3247-M24-5-7618
System
Fig. 9.6 One Phase Access on PCCCH channel
9.8.2.3 TBF Establishment using a Two Phases Access

In the first phase of a two phase 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 indi-
cates 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 phase access can be initiated either by the MS or the network as follow:
• 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 Alloca-
tion structure;
– by a Mobile Station, by requiring a two phase access in the PACKET CHANNEL
REQUEST message. In this case, if access is granted, the network will 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.
• 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.
A30808-X3247-M24-5-7618 247
System
When the network receives the PACKET RESOURCE REQUEST message, it responds
by sending either a PACKET UPLINK ASSIGNMENT message (radio resources assign-
ment on one or more PDCHs to be used by the mobile station for the TBF) or a PACKET
ACCESS REJECT message to the Mobile Station.
The Fig. 9.7 shows a two phases access procedure on the CCCH channel.
Fig. 9.7 Two Phases Access on the CCCH

In the current release an improvement of the GAP between the Assignment and Packet
Resource Request (PRR) and/or the TBF start has been implemented. A gap of about
350, 450 ms has been detected between the IACMD and the PRR in case of two phase
access. For this reason a reduction and optimization of the overall delay for all the types
of PRR/TBF start has been applied for both idle and active channels. The improvement
has been achieved with the optimization of the commanded TBF starting time.
In case of active channels it is not necessary the syncronization of the PDTs. As a
consequence the PRR/TBF start can be commanded without risk according to the
internal RNLC timing.
In case of idle channels the Immediate Assignment (IACMD) is submitted by the PCU
parallel to the ongoing channel synchronization roughly before the ending of the channel
synchronization itself. Considering that the channel synchronization has a final cycle
without any TA and FN changes and an additional virtual cycle should be taken into
account as reserve (60-100ms) the PRR delay or the TBF start could be improved by
about 200ms.
9.8.2.4 TBF Establishment for EDGE Mobile Stations

As described in the chapter: "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
248 A30808-X3247-M24-5-7618
System
or in PSI1 and finding the support indication field in the message:

EGPRS_PACKET_CHANNEL_REQUEST.
The EGPRS_PACKET_CHANNEL_REQUEST support indication field, is represented
by one bit, and can assume the values 0 or 1.
• In the first case, an EGPRS capable MS, will use the following to access a cell:
– 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, will use the following to access a cell:
– a two phase access with PACKET CHANNEL REQUEST message on the
PRACH for uplink TBF establishment when there is a PBCCH in the cell;
– 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 informa-
tion, 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 described in the
chapter: "9.1 Mobile Stations for Packet Switched Services", two mobile classes are
foreseen for what concerns EGPRS mobile stations; therefore:
– 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 note 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 (see, for more details, the chapter
"5.5 Enabling Packet Switched Services in a Cell"):
a) at least one EDGE CU is configured in the BTS equipment of the cell;
b) the attribute: TRXMD of the BCCH carrier is set to EDGE;
c) the TrxCapability of the BCCH carrier is set to EDGE.
Besides, the attribute: ABUTYP that indicates the format of the information field of
access bursts must be set to the value: ACBU11BIT.
Therefore, 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 MS sends the 11 bit 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 MS
will 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 in more detail.
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:
A30808-X3247-M24-5-7618 249
System
– if the PBCCH channel is not supported, the MS sends an EGPRS PACKET

CHANNEL REQUEST message on the RACH channel.
The procedure is similar to those described in the chapter: "9.8.2.2 Establishment
using a One Phase Access": the BSC answers with the IMMEDIATE ASSIGN-
MENT 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 the PRACH channel.
The procedure is similar to those described in the chapter: "9.8.2.2 Establishment
using a One Phase Access": the BSC answers with a Packet Uplink Assignment
for Uplink EGPRS TBF.
b) EGPRS PACKET CHANNEL REQUEST is NOT supported: in this case, the one
phase access does not allow establishing an EGPRS TBF; a GPRS TBF will be allo-
cated following the procedure described in the chapter: "9.8.2.2 Establishment
using a One Phase Access".
EGPRS Uplink TBF Establishment using a Two Phase Access

The following different cases exist regarding this kind of Uplink TBF establishment:
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 the
chapter: "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 the
chapter: "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 the chapter: "9.8.2.3 TBF Estab-
lishment using a Two Phases Access";
– if the PBCCH is supported, the MS sends a 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 the chapter: "9.8.2.3 TBF Estab-
lishment 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 phase access.
The two phase access is inherently immune from the possibility that two MSs can
perceive the same channel allocation as their own. Namely, the second access phase,
250 A30808-X3247-M24-5-7618
System
for example the Packet Resource Request, uniquely identifies the MS by its TLLI. The
same TLLI is included in the Packet Uplink Assignment/Packet Downlink Assignment..
The Temporary Logical Link Identity (TLLI) identifies a GPRS/EGPRS user inside the
i 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.
An efficient contention resolution mechanism has been implemented and it has the
following characteristics:
The first part of the solution is the identification of the MS. The identification of transmit-
ting MS on the RLC/MAC level is necessary not only for the contention resolution, but
also to be able to establish the RLC protocol entity for that Temporary Block Flow on the
network side. Additionally the 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 the 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. In this way the conten-
tion is resolved after the first occurrence of the 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
(for example carried by the same PDCH).
The Control Parameters Information Element of PRACH contains the access persis-
tence 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 defines (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 will 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: corresponds to the GS database parameter
– TX_INT: 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
station’s 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 execute a successive attempt. The number of TDMA
frames between two successive attempts to send a PACKET CHANNEL REQUEST
A30808-X3247-M24-5-7618 251
System
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 the 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 from the network, corresponding to one of the 3 last
PACKET CHANNEL REQUESTs sent by the MS, it starts the T3172 timer; while the
timer is running, the MS is not allowed to access to the cell (for example it cannot send
any other PACKET CHANNEL REQUEST messages). The following situations can
occur as respresented in 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.
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 the paging sub-channels on PCCCH. If
PCCCH is not present in the considered cell, the mobile station listens to paging sub-
channels on CCCH.
Paging sub-channels are, in any case, monitored according to the paging groups
i defined for the Mobile Station and its current DRX mode (see the chapter:
"9.8.3.2 Discontinuous Reception"). Paging for GPRS/EGPRS is performed on Routing
Areas.
If the MS is in Standby state, the SGSN only knows 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 channel
(PPCH).
The MS responds to one PACKET PAGING REQUEST message by initiating a mobile
originated packet transfer, as described in the chapter: "9.8.2 TBF Establishment Initi-
ated by the MS on CCCH/PCCCH".
This Mobile originated packet transfer allows the Mobile Station 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.
252 A30808-X3247-M24-5-7618
System
When the packet paging response has been sent by the MS and 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 the exact cell where the MS is
i camped on; then the SGSN sends the assignment message on PCH (PPCH) or AGCH
(PAGCH), without sending the PACKET PAGING REQUEST message.
If an uplink packet transfer is in progress, the PACKET DOWNLINK ASSIGNMENT
message is transmitted on the PACCH.
The transmission of RLC/MAC blocks to a Mobile Station 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
(PACKET DOWNLINK ASSIGNMENT) message on the CCCH (PCCCH) timeslot
corresponding to the CCCH (PCCCH) group to which the mobile station belongs. 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 DOWN-
LINK ASSIGNMENT) message can be sent. If the mobile station applies DRX, the
message will be sent in a CCCH (PCCCH) block corresponding to a paging group deter-
mined 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 allo-
cated to the MS:
– TFI;
– Time Slot numbers;
– ARFCN;
– optionally Timing Advance parameters (TAI and Timeslot number);
– MAC access mode (always set to dynamic, see the chapter:; "9.8.1 Medium Access
Modes")
– optionally, for EGPRS MSs, the EGPRS window size.
The TBF establishment triggered by the network is shown in the Fig. 9.9 in case of
PCCCH channel.
A30808-X3247-M24-5-7618 253
System
Fig. 9.9 TBF Establishment Initiated by the Network on the PCCCH channel
9.8.3.1 Network Operation Modes for Paging

The network may provide co-ordination of paging for circuit-switched and packet-
switched services. Paging coordination means that the network sends paging messages
for circuit switched services on the same channel as used for packet switched services,
for example:
– 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 shall only monitor one channel at any time.
Three network operation modes have been defined (see the 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
(for example the PCCCH if it is configured, otherwise the CCCH), or on a PDCH
traffic channel. This means that the MS shall 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 must 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
254 A30808-X3247-M24-5-7618
System
messages either on PCCCH (if it is allocated in the cell) or on the CCCH paging
channel. Therefore a MS that wants to receive pages for both circuit-switched and
packet-switched services will monitor both paging channels if the packet paging
channel is allocated in the cell. No paging co-ordination is performed by the network.
Mode CS services paging PS paging channel Paging

channel co-ordination
Mode I PPCH paging channel PPCH paging channel YES

CCCH paging channel CCCH paging channel
Packet data channel Not Applicable
Mode II CCCH paging channel CCCH paging channel NO
Mode III CCCH paging channel PCCCH paging NO
channel
CCCH paging channel CCCH paging channel
Tab. 9.2 Network Operation Modes
When the Gs interface is implemented all the 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 READY state. The network operates in mode I.
When the Gs interface is not implemented all MSC-originated pages of GPRS/EGPRS-
attached MSs goes via the A interface, and co-ordination of paging cannot be
performed. Then the network will either operate:
– In mode II, meaning that the packet common control channel is not allocated in the
cell;
– 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
the MSs. The user sets this value with 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 (apart
from the current MM state, for example ready or standby state), so a mobile station in
packet idle mode listens to radio blocks on CCCH or PCCCH channels.
For PS services, as for the CS service, it is 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 whether or not it wants to use discontin-
uous reception (DRX). If the MS uses DRX mode, the MS must also specify other DRX
parameters that indicate the delay for the network to send page requests or channel
assignments to the MS.
A30808-X3247-M24-5-7618 255
System
DRX parameters are indicated by the MS in the Attach procedure (see 9.3.2.1). Then it
sends these parameters in each page request to the BSS, that uses both this informa-
tion 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 or not the MS uses DRX.
• DRX period: It 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 defined by the SPLIT_PG_CYCLE param-
eter. 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
i SPGC_CCCH_SUP parameter (not configurable in the database) indicates the support
NO
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 transmis-
sions of the same paging message in the same paging group.
The parameters used to define the paging groups for GPRS/EGPRS MSs are shown in
the Tab. 9.3, 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; therefore the required time to execute
the paging procedure is reduced. As long as the timer is running (hence the MS is
in non-DRX mode), the BSC sends downlink assignments on the AGCH or PAGCH
channel (and not in paging blocks that the MS monitors when DRX mode is active,
and that occur with a low frequency) reducing in this way the time to allocate the
resources.
When the MS changes from packet transfer mode to packet idle mode, the BSC
starts a timer; the duration of this timer is calculated by the following formula:
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 proce-
dure
During this period, the MS is in non-DRX mode; when the timer expires, the MS
resumes discontinuous reception.
256 A30808-X3247-M24-5-7618
System
In applications such as WAP, the time needed to get a reply is a key factor for end user
i 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 assign-
ment/packet downlink assignment messages (polling requests) on the AGCH/PAGCH
instead of PCH/PPCH channel. So, when the DRX mode is temporarily disabled, the
time that occurs to receive at the MS side a data block that 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, it does
not consider it 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
i 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
terminates.
Subjects GPRS/EGPRS Corresponding GSM

parameters
PCCCH CCCH CCCH
DRX period SPLIT_PG_CYCLE NFRAMEPG (*) NFRAMEPG

SPLIT_PG_CYCLE (**)
Blocks not available for BSPBBLK + BPAGCHR NBLKACGR NBLKACGR (***)
paging per multiframe
Number of timeslots (phys- Depending on the number Depending on the number Depending on the
ical channels) containing of slots reserved for of slots reserved for number of slots reserved
paging PCCCH by means of the CCCH. for CCCH.
GDCH parameter.
(*) 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
signaling during a period of a 51 TDMA frames (that means during a period of a 51 TDMA multiframe). Its value
has to be always > 0, to support mobile stations which do not handle the SI2 quater correctly.
Tab. 9.3 Parameters for DRX Operation
GPRS/EGPRS Paging using CCCH:

A Mobile Station using DRX monitors 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 information about the usage of DRX, sends a paging
message to all PCUs that are supporting the right Routing Area. This message
includes the information on whether or not DRX is used, and additionally, if the
A30808-X3247-M24-5-7618 257
System
enhanced DRX mechanism is used, the SPLIT_PG_CYCLE parameter that indi-

cates 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 the requested DRX parameters that must be broadcast on the
BCCH;
4. the BTS queues all Packet Paging Request messages and sends them in first-in
first-out order on the PCHs in the CCCH multiframe.
GPRS/EGPRS Paging using PCCCH:

A MS using DRX is required to monitor the PPCH channel. 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 the following:
1. The SGSN, which has the information about the usage of DRX, sends a paging
message to all the PCUs located in the right Routing Area. This message includes
the information about whether or not DRX is used 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 the
requested DRX parameters that shall be broadcasted on the PBCCH channel;
3. The PCU includes the Packet Paging Request messages into RLC/MAC blocks and
schedules the messages into the PDCH multiframes, which contain the PCCCH.
The RLC/MAC blocks are transferred via PCU frames to the BTS, which immediatly
transmits the Packet Request message.
9.8.4 Relative Reserved Block Period Field (RRBP)

The RRBP field is contained in the MAC header of every RLC/MAC block sent in down-
link direction. Its value specifies a single uplink block in which the Mobile Station will
transmit either a message: PACKET CONTROL ACKNOWLEDGEMENT (to acknowl-
edge a downlink control block) or another PACCH block to the network.
If the RRBP field is received as part of a RLC/MAC control block containing any
message except Packet Paging Request, Packet Access Reject, and Packet Queueing
Notification, the mobile station will transmit a PACKET CONTROL ACKNOWLEDGE-
MENT message in the specified uplink radio block.
If the RRBP field is received as part of a RLC/MAC control block containing a Packet
Paging Request, Packet Access Reject, or Packet Queueing Notification message, the
Mobile Station does not consider the RRBP field.
If the RRBP field is received as part of a RLC/MAC data block, the Mobile Station will
transmit a PACCH block (for example a PACKET UPLINK ACK/NACK message to
acknowledge the downlink data block) in the specified uplink radio block.
The Mobile Station will always transmit the uplink radio block on the same timeslot as
the block where the RRBP has been received.
258 A30808-X3247-M24-5-7618
System
To indicate to the Mobile Station whether or not the received RRBP field is valid, a bit of
the MAC header is used; according to the value of this bit, the Mobile Station knows if
the RRBP field is meaningful in the received block.
The multislot class of the MS limits allowed combinations and configurations when the
i 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 the chapter: "4.7.1 Mobile Station Classes for Multislot Capabil-
ities"). For polling the MS the network must send the downlink block with a valid RRBP
field on a timeslot where the polled MS is able to answer.
9.8.5 Polling Procedures

As described in the chapter: "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 Imme-
diate Assignment if the PCCCH channel is not configured) carries the estimated timing
advance value to the Mobile Station.
But, when Packet Downlink Assignment must be sent without prior paging (for example
in the Ready state), no valid timing advance value may be available.
Then the network has two options:
1. The RRBP field 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 the
System information indicates that acknowledgement is access bursts,for example it
can be used only if the attribute: CACKTYP is set to 0;
The attribute: CACKTYP parameter is hard-coded to the value 0.
i
2. 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.
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 needed to exchange timing advance information
between the network and the Mobile Station). 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 polling the Mobile Station by means of the RRBP field of the assign-
ment message; as a consequence, the CACKTYP parameter shall be set to 0, to force
the Mobile Station to respond with four Access Burst.
Different procedures are executed according to the configuration of the PBCCH
channel.
Procedure when the PBCCH is configured:

If the PBCCH channel is configured, the following steps are executed:
A30808-X3247-M24-5-7618 259
System
– the BSC sends the PACKET DOWNLINK ASSIGNMENT message (on the
PPCH/PAGCH) setting the RRPB field to poll the Mobile Station;
– upon reception of the PACKET CONTROL ACKNOWLEDGEMENT message from
the Mobile Station, the BSC can immediately start the transmission of data blocks in
the downlink direction;
– as soon as possible (also before the transmission of the first downlink data block)
the BSC shall send the PACKET POWER CONTROL/TIMING ADVANCE message
to the Mobile Station, including the estimated timing advance value.
Procedure when the PBCCH channel is not configured:

If the PBCCH channel 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 ASSIGN-
MENT message setting the RRPB field to poll the Mobile Station;
– upon reception of the PACKET CONTROL ACKNOWLEDGEMENT message from
the Mobile Station, the BSC can immediately start the transmission of data blocks in
downlink direction;
– as soon as possible (also before the transmission of the first downlink data block)
the BSC must send the PACKET POWER CONTROL/TIMING ADVANCE message,
including the estimated timing advance value, to the Mobile Station.
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 shall 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 can operate in RLC acknowledged or unacknowledged mode.
9.9.1 Acknowledged Mode for RLC/MAC Operation

There are some differences regarding the GPRS and EGPRS acknowledged modes;
They are described below:
9.9.1.1 GPRS Acknowledged Mode

GPRS acknowledged operation mode uses the 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
reassembly. Every such message acknowledges all correctly received RLC Data Blocks
260 A30808-X3247-M24-5-7618
System
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 by the following:
a) a selective type I ARQ mechanism, where coding of a RLC Data Block is based on
the prevailing transmission (for example erroneous blocks are not stored);
b) a type II hybrid ARQ mechanism (called Incremental Redundancy - IR) where erro-
neous blocks are stored by the receiver and a joint decoding with new transmissions
is done.
Both methods are coupled with the numbering of the RLC Data Blocks within one
Temporary Block Flow.
The Incremental Redundancy mechanism for EGPRS is only used in the downlink direc-
i tion; in the 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) can be set by the user according to the number of
timeslots allocated in the direction of the TBF (uplink or downlink). The user can set the
window sizes with the following parameters:
– EGWSONETS, in case one timeslot is assigned;
– EGWSTWOTS, in case two timeslots are assigned;
– EGWSTHREETS, in case three timeslots are assigned;
– EGWSFOURTS, in case four timeslots are assigned;
– EGWSFIVETS, in case five timeslots are assigned;
– EGWSSIXTS, in case six timeslots are assigned;
– EGWSSEVENTS, in case seven timeslots are assigned;
– EGWSEIGHTTS, in case eight timeslots are assigned.
According to the link quality, an initial MCS is selected for a RLC block. For retransmis-
sion, the same or another MCS from the same family of MCSs can be selected (see the
chapter: "10.7 Link Adaptation"). For example if MCS-7 is selected for the first transmis-
sion of a RLC block, any MCS of the family B can be used for retransmissions.
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 that are retransmitted using MCS6 or MCS3, padding of the first six octets in the
data field will be applied, and the CPS field will be set to indicate that this has been done.
Incremental redundancy is used only in the downlink direction. The split block field is
used to indicate to the MS whether or not the block has been segmented. In fact, the
following shall be underlined:
A30808-X3247-M24-5-7618 261
System
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 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 punc-
turing scheme) and 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 (for example 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, addi-
tional coded bit (for example the output of the rate 1/3 encoded data that is punctured
with PS 2 of the prevailing MCS) are sent and decoded with the previously received
code-words until decoding succeeds. If all of the code-words (different punctured
versions of the encoded data block) have been sent, the procedure will start over, and
the first code-word (which is punctured with PS 1) will be sent followed by PS 2 etc.
RLC data blocks, that are retransmitted using a new MCS, will be sent with the punc-
turing scheme indicated in the Tab. 9.4, at the first transmission after the MCS switch.
MCS switched MCS switched to PS of last transmis- PS of first trans-

from sion before MCS mission after MCS
switch switch
MCS9 MCS6 PS1 or PS3 PS1

PS2 PS2
MCS6 MCS9 PS1 PS3
PS2 PS2
MCS7 MCS5 any PS1
MCS5 MCS97 any PS2
all other combinations any PS1
Tab. 9.4 Puncturing Schemes to be used after a Coding Scheme Switch
In the EGPRS type I ARQ, the operation is similar to 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).
Therefore, the MS can use either the type I ARQ or the type II ARQ mode, according to
the current situation .
If the memory for IR operation run out in the MS, the MSwill indicate this by setting the
LA/IR bit in the EGPRS PACKET DOWNLINK ACK/NACK message.
If IR is considered as "not-working-properly"at the MS (IR_statusk<0.5, see "10.7 Link
Adaptation"), then the PCU may decide to re-segment the 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 "prop-
erly 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:
262 A30808-X3247-M24-5-7618
System
– 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 length of the user information by replacing
missing RLC Data Blocks by dummy information bit. To convey the necessary control
signaling (for example the 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
RLC/MAC acknowledged mode. The fields for denoting the erroneous RLC blocks can
be used as an additional measure for channel quality (for example the parameter for link
adaptation). 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 re-
transmitted (ARQ functions are not used). BLER information could be derived and the
link adaptation algorithm can work in a similar way to the acknowledged mode case.
However the unacknowledged mode is typically used to support real time applications
and in this case minimizing the data unit error ratio, for example the fraction of data unit
lost or detected as erroneous, is much more important than maximizing the throughput.
9.9.3 Operations on Uplink TBF

In this chapter the main operations related to the Temporary Block Flow in the Uplink
direction are described.
9.9.3.1 Uplink TBF Using the Acknowledged Mode

The mobile station transmits RLC/MAC blocks in each assigned uplink data block.
RLC/MAC control blocks have the precedence over RLC data blocks, for example
temporarily replacing the PDTCH with PACCH. The network sends PACKET UPLINK
ACK/NACK messages when needed.
In case of GPRS service, where the window size is fixed to 64 blocks (see the chapter:
"9.9.1.1 GPRS Acknowledged Mode"), the NRLCMAX attribute has been defined to
indicate to the network when it must send a PACKET UPLINK ACK/NACK message.
With this Attribute , the user can configure how many blocks must be transmitted by the
MS, before receiving a PACKET UPLINK ACK/NACK message. The NRLCMAX value
is chosen as a compromise between the following conditions:
– it will avoid reaching the stall condition of the transmitting window (see below); from
this point of view the value should be quite low;
– it will avoid a frequent number of PACKET UPLINK ACK/NACK messages; from this
point of view, the value should be quite high.
In case of EGPRS service,for which, according to the number of timeslots assigned to
the MSs, a specific window size is used (see the chapter: "9.9.1.2 EGPRS Acknowl-
A30808-X3247-M24-5-7618 263
System
edged Mode") the following attributes have been defined to indicate to the network when
it shall send a PACKET UPLINK ACK/NACK message:
– EGPLGPONETS, in case one timeslot is assigned;
– EGPLGPTWOTS, in case two timeslots are assigned;
– EGPLGPTHREETS, in case three timeslots are assigned;
– EGPLGPFOURTS, in case four timeslots are assigned;
– EGPLGPFIVETS, in case five timeslots are assigned;
– EGPLGPSIXTS, in case six timeslots are assigned;
– EGPLGPSEVENTS, in case seven timeslots are assigned;
– EGPLGPEIGHTTS, in case eight timeslots are assigned.
With these attributes the user can configure how many blocks must be transmitted by
the MS, before receiving a PACKET UPLINK ACK/NACK message, according to the
number of assigned PDCHs. The value of these parameters is chosen as a compromise
between the following conditions:
– avoid reaching the stall condition of the transmitting window;
– avoid a frequent number of PACKET UPLINK ACK/NACK messages.
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 (for
example when a valid PACKET UPLINK ACK/NACK message is received).
Upon detecting the stall condition, the mobile station also starts the T3182 timer. T3182
timer is stopped upon the reception of a PACKET UPLINK ACK/NACK message, that
allows to close the stall condition (see Fig. 9.10).
If T3182 timer expires:
– the mobile station decrements the N3102 counter by the PAN_DEC value; the
PAN_DEC value is defined 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 channel and initiates the establishment of a new uplink TBF,
otherwise the MS performs an abnormal release with the cell reselection as
described 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 will never exceed the PAN_MAX
value.
The user can configure PAN_INC and PAN_MAX values of the PKTNINC and PKTNMA
attributes respectively.
Upon cell reselection, the mobile station sets the N3102 counter to the PAN_MAX value.
When N3102 = 0 is reached, the mobile station performs an abnormal release with cell
re-selection..
In case the PAN_DEC, PAN_INC, or PAN_MAX are set to the value 0, the counter
i N3102 is disabled.
264 A30808-X3247-M24-5-7618
System
N3102 = N3102 + PAN_INC N3102 = N3102 - PAN_DEC
Cell reselection Start T3182 Stop T3182 T3182 Expired

N3102 = PAN_MAX Stall condition (Reception of a Packet Abort all TBFs
Uplink Acknowledge)
Fig. 9.10 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 the 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 trans-
mitted by the MS, before receiving a control message from the network, is fixed to 64
(for example the value of the transmitting window used in acknowledged mode).
If the mobile station transmits a number of data blocks equal to the window size, without
receiving a PACKET UPLINK ACK/NACK message, the mobile station starts the T3182
timer. T3182 will be stopped upon the reception of a PACKET UPLINK ACK/NACK
message.
If the timer T3182 expires, the mobile station decrements the N3102 counter by the
PAN_DEC (PKTNDEC) value, aborts all the TBFs in progress and its associated
resources, returns to the CCCH or PCCCH channel and initiates the establishment of a
new uplink TBF.
Whenever the Mobile Station receives a PACKET UPLINK ACK/NACK message it
increments the N3102 by PAN_INC (PKTNINC), however N3102 does never exceed the
value PAN_MAX (PKTNMA).
Upon cell reselection, the mobile station set the counter N3102 to the PAN_MAX value.
When N3102 = 0 is reached, the mobile station performs an abnormal release with the
cell re-selection.
In case the PAN_DEC, PAN_INC, or PAN_MAX are set to the value 0, the N3102
i counter is disabled.
9.9.3.3 Anomalies During an Uplink TBF

During an Uplink Temporary Block Flow the following anomalies Mobile Station and
Network Side can occur:
Mobile Station Side:

When the Mobile Station transmits a RLC/MAC block to the network, it starts the timer
T3180. When the mobile station detects an assigned USF value on an assigned PDCH
A30808-X3247-M24-5-7618 265
System
channel, the Mobile Station reset the T3180 timer. If the T3180 timer expires, the mobile
station aborts all TBFs in progress and its associated resources, returns to the CCCH
or PCCCH channel, and initiates the establishment of a new uplink TBF.
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 allo-
cated radio block to that mobile station, for which no data is received.
If the N3101 reaches its maximum value, the network stops the scheduling of RLC/MAC
blocks from the Mobile Station and it starts the T3169 timer. When the T3169 expires,
the network can reuse the USF and TFI values (the procedure is shown in the
Fig. 9.11).
The user can also set the N3101 maximum value of the N3101 attribute.
N3101 = 0 N3101 = N3101 + 1 N3101 = N3101+1= N3101max
time
NW sends Data is NW sends Data is not NW sends USF Data is not received T3169 Expired
USF received USF received from the MS. Reuse of TFI
from the from the Start T3169 and USF
MS. MS. communication with
the MS is broken.
Fig. 9.11 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 orig-
inated packet transfer, the mechanism based on the acknowledgment of the final Packet
Uplink Ack/Nack message (combined with timers) is used. (see Fig. 9.12).
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 is
then sent in the uplink TBF.
The CV value is calculated as follows:
x = round  ----------------------------------------
TBC – BSN′ – 1
 NTS 
then
266 A30808-X3247-M24-5-7618
System
x if x ≤ BSCVMAX
CV = 
 15 otherwise
in which:
- 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 the result is 0 only for (TBC - BSN’ - 1) = 0.
The final RLC data block transmitted in the TBF (for example the RLC data block with
BSN’ = TBC - 1) will have CV set to the value ‘0’. Once the mobile station transmits a
value of CV other than 15, the MS will not queue any new RLC data blocks, and any
data that arrives after the commencement of the countdown process will 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 of 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 that must be immediately acknowledged by the MS
in the reserved uplink block period (the network also resets the N3103 counter).
If the 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 channel and it 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 reception of the acknowledgement, the network can reuse the TFI and USF
values.
A30808-X3247-M24-5-7618 267
System
Fig. 9.12 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 the chapter: "9.8.4 Relative
Reserved Block Period Field (RRBP)"), it increments the N3103 counter and it retrans-
mits the PACKET UPLINK ACK/NACK message. If the counter N3103 exceeds its limit,
which the user can define with the N3103 parameter, the network starts the T3169 timer.
When the T3169 timer expires, the network may reuse the TFI and USF resources
(see Fig. 9.13).
N3103 = N3103 + 1 N3103 = N3103+1= N3103max
NW waits for NW has not received any NW has not received any T3169 Expired
acknowledgment ackn. from the MS. ackn. from the MS. Reuse of TFI and USF
Start T3169
communication with
MS is broken.
Fig. 9.13 Release of the resources on Network Side during an UL TBF
268 A30808-X3247-M24-5-7618
System
Improving overall performances in the interaction between TCP/IP based applica-

tions and the GPRS/EGPRS network (uplink direction)
In the PS network, the continuous interruptions of data flow due to frequent establish-
ments and releases of TBFs reduce the performances of many TCP/IP based applica-
tions, such as Web Browsing applications.
To reduce these disadvantages during uplink data transfer, a delay into the uplink TBF
release procedure is introduced as respresented in next Fig. 9.12.
The BSC delays sending the final PACKET UPLINK ACK/NACK message. This
behavior is introduced to save time when a downlink LLC PDU arrives from the SGSN
Network Node just after the reception of the RLC Block with CV = 0. In this case, the
BSC can open the downlink TBF as a concurrent case, that is faster than 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 is not longer because during this delay, the
MS cannot 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 for the expiration of delay timer.
9.9.4 Operations on Downlink TBF
9.9.4.1 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 must send a PACKET DOWNLINK
ACK/NACK message different parameters are provided according to the service type:
• in case of GPRS, the NRLCMAX parameter is provided; Setting the values of this
attribute the user can configure how many blocks must be transmitted by the
network, before receiving a PACKET DOWNLINK ACK/NACK message;
• in case of EGPRS the following eight attributes have been defined: (depending on
the defined window size:
– EGPLGPONETS, in case of one timeslot assigned;
– EGPLGPTWOTS, in case of two timeslots assigned;
– EGPLGPTHREETS, in case of three timeslots assigned;
– EGPLGPFOURTS, in case of four timeslots assigned;
– EGPLGPFIVETS, in case of five timeslots assigned;
– EGPLGPSIXTS, in case of six timeslots assigned;
– EGPLGPSEVENTS, in case of seven timeslots assigned;
– EGPLGPEIGHTTS, in case of eight timeslots assigned;
Setting the values of thease attributes the user can configure how many blocks have
to be transmitted by the network, before receiving a PACKET DOWNLINK
ACK/NACK message, according to the number of PDCH channels assigned to the
MS.
In unacknowledged mode, the MS shall send a PACKET DOWNLINK ACK/NACK
message after:
• it has received 64 blocks (for example the window size) in case of GPRS;
A30808-X3247-M24-5-7618 269
System
• it has received a number of blocks equal to the configured window size, in case of
EGPRS.
In both unacknowledged cases (GPRS and EGPRS) the PACKET DOWNLINK
ACK/NACK message is used to check the connection between the MS and the network
(see below).
For both 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 the chapter: "9.8.4 Relative Reserved Block Period Field (RRBP)"), reserves the
uplink resource to transmit the control messages.
The N3105 attribute is the threshold for unreceived control messages from the MS, after
sending the RRPB field in downlink direction. If the threshold is reached, the communi-
cation with the associated MS is broken.
Every time the network does not receive the control message from the MS, the N3105
value is increased; every time the network receives the control message from the MS,
the N3105 is reset. When the N3105 attribute reaches its maximum value (N3105max),
the communication with the MS is broken as respresented in next Fig. 9.14.
The user can configure the N3105max threshold of the N3105 attribute.
N3105 = N3105 + 1 Reset N3105 N3105 = N3105 +1= N3105max
NW sets RRPB NW has not received any NW has received a NW has not received any
in DL data block control message control message control message
from the MS. from the MS. from the MS.
Communication with
MS is broken.
Fig. 9.14 Control Procedure Executed by the Network during a Downlink TBF
9.9.4.2 Release of a Downlink TBF

The release of resources (as represented in Fig. 9.15) 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
shall be acknowledged by the MS in a reserved radio block on the uplink.
The TFI handling is steered with timers that run 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.
270 A30808-X3247-M24-5-7618
System
Therefore, upon the reception of the final Packet Downlink Ack/Nack from the MS (with
Final Ackn = 1), the T3193 timer is started on the 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 as represented in the Fig. 9.15.
Fig. 9.15 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 will continue to monitor all the assigned PDCHs; in this case the
network must retransmit some RLC blocks.
If the network receives a PACKET DOWNLINK ACK/NACK message before the T3191
timer expires, and if retransmissions are required, then the network stops the T3191
timer and retransmits necessary RLC data blocks.
Improving overall performances in the interaction between TCP/IP based applica-

tions and the GPRS/EGPRS network (downlink direction):
As described in the chapter: "9.9.3.4 Release of an Uplink TBF", the continuous inter-
ruptions of data flow due to the 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 as represented in Fig. 9.15.
The BSC waits for the expiration of a timer before sending the FBI=1. The user can set
this timer using the TIMEDTBFREL attribute.
When TIMEDTBFREL attribute’s value is set to “0” no delay in TBF downlink occurs.
i
During this time, the BSC maintains open the downlink TBF, by sending Dummy LLC
frames included in single RLC Blocks, with the polling bit (RRBP) set to one.
There are two advantages when Dummy LLC frames are used:
A30808-X3247-M24-5-7618 271
System
1. The MS may request UL resource in the PACKET DOWNLINK ACK/NACK

message; with these Dummy frames, the BSC presses the MS for an answer, for
example if the MS can send its data quickly.
The delay time is not only influenced by the network, but also by the MS, so the delay
time can be different using different Mobile Stations;
2. If a new LLC is received from the SGSN, it is possible to send the relative RLC block
immediately (without an explicit assignment procedure). In this manner there is an
unique long single DL TBF, rather than several DL TBFs with a lot of assignment
messages.
In order to speed up the uplink establishment during the Delay TBF Release time, polling
periods should be quite low.
The delay between two subsequent pings is reduced due to the fact that the block
containing the Dummy LLC is sent (polled) every 50 ms (alternating 40/60 ms) for a
duration of 450 ms; in this way the MS may request resources in a shorter time. After
that the polling period is extended to 280 ms (1 poll every 280 ms). The reason is a
compromise between speed up of procedure, battery saving and resource usage. With
this strategy the MS uplink establishment is speed up during the delay downlink TBF
release time; infact improvements of about 80 ms are expected on Ping Delay time
measured as a sequence of 50 pings) and also on FTP throughput.
The Ping Delay time is further reduced, by reducing the internal PCU queue of radio
blocks, obtaining a quite immediate sending of data when available. This improvement
can save approximately 20-40 msec per direction and it is implemented only on the
PPXU boards.
A further improvement is related to the First Ping. The worst condition in a cell with all
the PDCHs being idle is a a value of 1.55 seconds for the First Ping. The implemented
solution is general and it applies also to other GMM and SM procedures as well as to
Data Transfer. The number of PDT assigned to a single block has to be set to the value
“2” if concatenated PCU frames are used in the cell. In case standard PCU frames are
used in the cell the number of PDT has to be set to the value “1”. Furthermore also the
RLC octet count in PRR has to be taken into account for avoiding an unnecessary align-
ment of 2 Uplink Timeslot (for Mobile Stations that have more than 1 Timeslot in Uplink
direction).
With this improvement two sequential PDT/PDCH alignment are executed instead of
three. The improvement of the First Ping is expected to be very near to 200 msec and it
is valid for each GPRS and also for almost all EGPRS access cases.
In the current BSS BR8.0 release the number of TBF released in the network has been
decreased increasing as a consequence the Network performances. The decreasing
has been reached changing the BCCH change mark only when the system info is
changed. In this way Mobile Station releases the ongoing TBF to read all the incoming
system info only when they are changed.
In presence of MBCCH combined configuration there is no improvement of the delay on
the first ping.
During a Mobile Station normal Downlink transfer, fast pooling is applied for EGPRS and
GPRS, when on the DL main Timeslot only one DL TBF is present (the one of the related
Mobile Station. No Uplink is present at all, not even the one of the related Mobile Station
itself. PCU shall not be in overload condition. During this period every DL block sent on
main Timeslot is polled. The reason for this polling type is a more fast reaction to missin
blocks and a higher probability of Uplink operating. For GPRS this strategy permitts to
272 A30808-X3247-M24-5-7618
System
avoid as much as possible to enter into stall conditions. Fast polling strategy is stopped
when another Mobile Station is multiplexed on the Timeslot in Uplink or Downlink, when
Mobile Station itself asks for new UL resources and also when PCU enters into an over-
load situation.
If fast polled Downlink TBF enters into Delayed Phase, 20 msec polling strategy still
applies until rapid delay phase ends (about 750/800ms).This strategy has been intro-
duced in the general path of EGPR/GPRS performance improvements in BR7.0 release.
9.9.5 Notes About Concurrent TBFs

When concurrent TBFs shall be established during the resource allocation or the
resource upgrade strategy (see the chapter: "5.7 Management of Packet Data Chan-
nels"), 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 both directions.
Mobile stations for which this problem arises are those providing a dynamic allocation
i of the number of resources, for example those belonging to the following multislot
classes (see Tab. 4.6): “6, 7, 10, 11, 12”.
For example the class 8 (4+1) is not affected, because in total 5 "timeslots" can operate;
instead class 10 (4+2) is affected, because in sum only 5 timeslots can be active,
however 6 are possible. So either 4+1 or 3+2 operation (or less) is possible.
Tests with a Mobile Station with multislot class 6 have shown that with two simultaneous
FTP connections, one in uplink and the other 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 note-
book, which is always full concerning the uplink traffic) the downlink transfer is reduced
(stalled condition).
If the chosen solution was always downlink based (for example: 3+1), also pure uplink
traffic such 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 acknowledg-
ments arrives.
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_Resource_Request or the Packet_Downlink_Ack/Nack message
(PDAN). Within these messages there is the Channel_Request_Description information
element that contains the field “RLC_Octet_Count”.
The RLC_Octet_Count field indicates the number of RLC data octets that the mobile
station wants to transfer; its range is from 0 to 65535. Besides:
– the value 0 is interpreted as a request for an open-ended TBF by the Mobile Station
(for example the Mobile Station does not specify the number of blocks it must
transmit);
– all other values are interpreted as a request for a close ended TBF (for example the
RLC_Octet_Count value indicates the number of blocks the Mobile Station must
transmit).
A30808-X3247-M24-5-7618 273
System
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 Mobile Station asks for uplink resources, if RLC_Octet_Count=0 or if
RLC_Octet_Count is more than a value defined by the THSULBAL parameter, then a
switch from downlink priority to uplink priority is executed; in this case, the number of
blocks the Mobile Station must transmit could be high.
Otherwise a timer defined by the TSULBAL is activated. If the uplink TBF is closed until
the timer is running, then the timer is stopped and downlink priority in maintained; if the
timer elapses and the uplink TBF is still opened, 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 needed to suspend the GPRS/EGPRS service.
In fact, when a GPRS/EGPRS-attached Mobile Station enters the Circuit Switched dedi-
cated mode, and when the Mobile Station limitations make it unable to handle both the
CS dedicated mode and the PS transfer mode, the Mobile Station requests the network
to suspend the PS services.
This is the case of a MS operating in Class B mode. The MS is attached to both the PS
and CS services, but it can only operate one set of services at a time (see the chapter:
"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 runs as follow as respresented in Fig. 9.16:
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 will suspend PS services. The GPRS SUSPENSION REQUEST
message contains the following information:
– Temporary Logical Link Identity (TLLI);
– Routing Area Identifier (RAI);
– Suspension Cause (SC);
The BSC stores the information related to the request, namely the TLLI and the RAI,
associating them with 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.
If 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.).
If the T3 timer expires SUSPEND-RETRIES times or a SUSPEND NACK is received
from the SGSN, the suspend procedure is considered unsuccessful, an Alarm is
generated and it is then sent to the LMT Evolution/Radio Commander;
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 will store the TLLI and RAI in order to be able to request the SGSN to resume
274 A30808-X3247-M24-5-7618
System
PS services when the MS leaves dedicated mode; the BSC also receives the SRN
(Suspend Reference Number) information from the SGSN.
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
i the Radio Commander/LMT Evolution) 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
i 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 SGSN MSC/VLR
Dedicated Mode is entered
GPRS SUSPENSION REQUEST
SUSPEND (TLLI, RAI)

Start T3
Stop T3 SUSPEND ACK (TLLI, RAI, SRN)
Fig. 9.16 Suspend Procedure
The BSC starts the resume procedure as soon as the circuit switched dedicated mode
is left, that is when the Mobile Station is disconnected from the MSC.
Two cases shall be distinguished:
a) during the suspension period, the Mobile Station has not changed cell;
b) during the suspension period, the Mobile Stationhas changed cell or routing area.
In case a), the resumption request is managed with the SGSN; in the following this
procedure is explained (the procedure in case of successful resume is shown in the
Fig. 9.17):
A30808-X3247-M24-5-7618 275
System
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 also started.
If 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, an
alarm message is generated and then sent to the Radio Commander/LMT Evolu-
tion.
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" info-
element 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 Mobile Station 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 the Mobile Station related to
i the received TLLI/RAI is already "Resumed" or the received TLLI/RAI does not
correspond to a Mobile Station for which the resumption has been required.
4. Eventually the BSS determines that the circuit-switched radio channel will be
released. If the BSS is able to request the SGSN to resume PS services, the BSS
will 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 a RR Channel Release (Resume) message to the MS. Resume indi-
cates whether the BSS has successfully requested the SGSN to resume
GPRS/EGPRS services for the MS, for example whether Resume Ack has been
received in the BSS before the RR Channel Release message has been trans-
mitted. The Mobile Station 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 will resume GPRS/EGPRS services by sending a Routing Area Update
Request message to the SGSN, as described in subclause "Routing Area Update
Procedure".
276 A30808-X3247-M24-5-7618
System
MS BSC SGSN MSC/VLR
RESUME (TLLI, RAI, SRN)

Start T4
RESUME ACK (TLLI, RAI)

Stop T4
Channel Release
Fig. 9.17 Resume Procedure
In case b), the resume procedure towards the SGSN is skipped; in the following, this
procedure is explained (the procedure is shown in the Fig. 9.18):
1. The BSC removes the information related to the previous suspend request and it
immediately sends a CHANNEL-RELEASE message to the Mobile Station. The
information element "GPRS Resumption" will not be included in the message.
2. As a result, if the Routing Area has been changed, a Routing Area Update proce-
dure is initiated by the Mobile Station; if the cell was changed but not the Routing
Area, depending on its state, the Mobile Station will continue in the following way:
– Ready state: a Cell Update procedure is initiated by the Mobile Station. The
SGSN is aware of the cell to which the Mobile Station currently belongs.
– Standby state: the Mobile Station does nothing. When the SGSN side Ready
Timer expires, the SGSN will page the MS in the Routing Area it knows, to find
the right cell.
A30808-X3247-M24-5-7618 277
System
MS BSC SGSN MSC/VLR
Channel Release
(no Resumption Result)
Routing Area Update Request
Fig. 9.18 Resume Procedure (The MS has changed the Routing Area)
If the MS performs an inter-BSC handover while suspended, the old BSC transfers the
“Old BSS to New BSS information” IE to the new one; 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 Mobile Station 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
i system, and both T3 and T4 timers cannot be set by the operator and assume the
following default values:
- T3 = 5 s
- T4 = 1 s
9.9.7 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 executed by the resource allocation algorithm, which is
described in the chapter: "5.7 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 able to handle EGPRS/GPRS mobiles multiplexed on the
same PDCH channels: 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 modu-
lation; therefore uplink and downlink scheduling must be performed jointly, trying to
avoid setting 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.
278 A30808-X3247-M24-5-7618
System
9.9.7.1 Supported QoS Attributes

As previously mentioned, the main 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 system; these attributes are different between the uplink and down-
link directions.
Regarding downlink scheduling, the BSC handles the following two R97/98 attributes
specified in the DL-UNITDATAs supported by the “Gb” interface:
– Peak Throughput (used in the allocation phase);
– Service Precedence.
The Service Precedence indicates the importance of maintaining the service commit-
ments 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.
The Service Precedence is then used to assign different priorities to different connec-
tions; 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 Scheduling Priority

Service Precedence = 1 1
When multiple TBFs are allocated on the same physical resources, they will be served
according to their own scheduling priorities.
Regarding the scheduling of uplink TBFs, the Radio Priority attribute is used. This
attribute is mapped one to one to the uplink scheduling priority as follows:
QoS Attribute Scheduling Priority

Radio Priority = 1 1
9.9.7.2 Scheduling Process

As a general rule, the scheduling algorithm for each PDCH channel checks the active
TBFs onto that timeslot, both in uplink and downlink directions; then it verifies the sched-
uling priorities of each TBF, and associates the corresponding scheduling weights Wk
to each priority.
In fact, each scheduling priority is associated with a specific scheduling weight: the
association between priorities and weights can be performed by the user with the
following attributes:
– SCHWEIPRI1: weight associated to scheduling priority 1;
A30808-X3247-M24-5-7618 279
System

For each direction of transmission and for each timeslot, the algorithm selects a TBF
using an approach that 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 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 as follows:
• Polling Requests: when a Mobile Station must be polled, the scheduler manages
the downlink block (containing the RRBP value) for this Mobile Station, with an
higher priority than other blocks to be sent in downlink direction;
• Downlink Control Blocks for uplink TBFs: when a downlink control block (for
example: Packet Uplink Ack/Nack message) must be sent for an uplink TBF, the
scheduler manages the downlink block for this uplink TBF, with a 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 the
PCCCH. Therefore, 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 Mobile Station are multiplexed on the same PDCH
channels some additionally constraints must 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 setting USFs for GPRS mobiles in 8PSK-coded down-
link blocks.
In this case, the problem arises when, for example a downlink block coded with 8PSK
modulation shall be sent and at the same time the USF should be coded with GMSK
modulation allowing to a GPRS-only mobile station to read the USF value and 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 uses the GMSK modulation, an USF
(the first in the list of the USF to be transmitted) corresponding to a GMSK mobile is
selected; if there are no GMSK USF, then a 8PSK one is selected, because this
choice does not cause any problem;
b) If the downlink block corresponds to a TBF that uses the 8PSK modulation, an USF
(the first 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 selected (starting from UpLink 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 (for example, 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.
9.9.8 EGPRS/GPRS Scheduler Enhancements for Rel5 Qos Support

In this chapter the enhancements implemented to the BR7.0 GPRS/EGPRS scheduler
are described.
280 A30808-X3247-M24-5-7618
System
The scheduler has been improved mainly for the following reasons:
1) to support new BR8.0 features: Packet Flow Context Procedure, Streaming Traffic
Class in addition to Interactive and Background ones and Release 5 QoS Attributes;
2) to manage only R97/98 attributes.
The main purpose for the Temporary Block Flow (TBF) scheduler is to distribute permis-
sion to access physical resources to the different active TBFs. The distribution of the
active TBFs over the available GPRS/EGPRS carriers and the multislot allocation of a
particular TBF on the timeslot of the corresponding GPRS/EGPRS carrier is executed
by the resource allocation algorithm.
In case a TBF containing a Streaming PFC is allocated in a Time Slot , then this TS can
not be assigned to an other TBF.
If the Packet Flow Context (PFC) Procedure is not supported , a TBF could be shared
among more than one Packet Flow Context (PFC). A new entity (PFC Scheduler)
distributes the TBF permission to access the physical resource to the different PFCs
sharing the TBF.
The scheduler is composed by the following software components:
• TBF Scheduler;
• PFC Scheduler.
If the Network and the Mobile Station support Packet Flow Context (PFC) Management,
the involved scheduling entities are the following:
- For Downlink TBF: TBF Scheduler and PFC Scheduler;
- For Uplink TBF: TBF Scheduler.
In case the Network or the Mobile Station cannot support PFC Management (R97/98),
the involved scheduling entities are the following:
- For Downlink TBF: TBF Scheduler;
- For Uplink TBF: TBF Scheduler.
A system model when PFC management is enabled without Multiple TBF is represented
in Fig. 9.19.
Fig. 9.19 Enabled PFC Management without Multiple TBF
Temporary Block Flow (TBF) Scheduler:

Temporary Block Flow (TBF) Scheduler distributes permission to access the physical
resources to the different active TBFs. The distribution of the active TBFs over the avail-
able GPRS/EGPRS carriers and the multislot allocation of a particular TBF on the
timeslot of the corresponding GPRS/EGPRS carrier is executed by the resource alloca-
tion algorithm.
A30808-X3247-M24-5-7618 281
System
A TBF Scheduling Weight is associated to each TBF and it is provided to TBF Scheduler
from Radio Resource Manager (RRM) application. See the chapter: "9.10 Quality of
Service Support for PS Services" for more details about the RRM application.
The TBF Scheduler algorithm does not change in case of Rel5 or R97/98 QoS attribute
managing.
Only the assignment of TBF Scheduling Weight to a TBF depends on Rel5 and R97/98
QoS attribute managing.
TBF Scheduler has been designed to run with the parameter: USF_GRANULARITY set
i to 0. For more details on USF_GRANULARITY see TS GSM 44.060 Recommendation.
In the current BR8.0 Release both USF Granularity 0 and USF Granularity 1 are
supported. Guidelines for the support of USF Granularity 0/1 have been designed with
the aim of minimizing the impact on the scheduler due to its relations with additional
features, like EDA and Extended Cells management.
If the feature PFC Management is disabled, the network – as regards downlink sched-
uling - can only handle two R97/98 attributes specified in the message: DL-UNITDATAs
coming from the Gb interface. The attributes are the following: The “Peak Throughput”
(used in the allocation phase) and the “Service Precedence”. In this case the Service
Precedence is used to assign different weights to different connections.
A Downlink TBF could transfer LLC PDUs with different Service Precedence. The
(Downlink) TBF Scheduling Weight is defined as the weight associated to the managed
Service Precedence.
As regards the scheduling of uplink TBFs, the Radio Priority attribute is used to deter-
mine the (Uplink) TBF Scheduling Weight. This attribute is mapped one to one to uplink
scheduling priority/TBF Scheduling Weight.
If an Uplink TBF requires a new Radio Priority with the message: “Packet Resource
Request”, Radio Resource Manager does not update (Uplink) the TBF Scheduling
Weight.
To calculate TBF Scheduling according to Rel5 the following conditions shall be consid-
ered:
• TBF carries a Streaming PFC. TBF Scheduling Weight is not needed because TBF
multiplexing is not allowed by the Radio Resource Manager application. All physical
resources are available for that TBF that is always selected by the TBF Scheduler.
In case TBF is shared eventually by other (not Streaming) Packet Flow Context, the
i PFC Scheduler distributes permission to access physical resources to the different
active PFC sharing the TBF.
• TBF does not carry a Streaming PFC. In this case TBF Scheduling Weight is
needed, because TBF multiplexing is allowed by Radio Resource Manager applica-
tion. TBF scheduler distributes permission to access the physical resources to the
TBF according to its TBF Scheduling Weight.
If TBF is shared eventually by more than one (not Streaming) Packet Flow Context,
i PFC Scheduler will distribute permission to access the physical resources to the
different active PFC sharing the TBF.
Downlink TBF Scheduling Weight is the sum of all PFC Scheduling Weights related to
the PFCs sharing the TBF.
The Uplink TBF Scheduling Weight is equal to the PFC Scheduling Weight relating to
the last required PFI in the Packet Resource Request Message.
282 A30808-X3247-M24-5-7618
System
Packet Flow Control (PFC) Scheduler:

If the feature: “PFC Management” has been activated, PFC Scheduler is involved in
downlink scheduling phase.
For each (Downlink) TBF supporting PFC Management, one buffer [PFC_Buffer_x,
x=1,2,3...] is allocated for each PFC sharing the TBF. Buffers contain LLC Frames
(received from Gb interface) for each PFC. The PFC Scheduler distributes permission
to access the physical resources to the different active PFC sharing a TBF. The Permis-
sions are distributed so that each PFC radio resource utilization is proportionally to the
PFC Scheduling Weight. The weight for each activated PFC is assigned by TBF
Manager Application.
Signaling PFC and Streaming PFC scheduling strategy is not based on the scheduling
weight. They are managed with high priority by PFC Schedule. Signaling PFC priority is
higher than Streaming PFC priority.
If a signaling PFC is active, the PFC Scheduler assigns the maximum priority to the
signaling PFC: until LLC Buffer of signaling PFC is not empty, LLC Data of the signaling
PFC are transmitted.
In case Streaming PFC is active, PFC Scheduler assigns priority to Streaming PFC: until
LLC Buffer of Streaming PFC is not empty, LLC Data of the Streaming PFC are trans-
mitted.
Bandwidth surplus is shared among Not Streaming and Not signaling PFCs according
to their scheduling weight.
A Scheduling Weight is defined also for signaling PFC, but it only determines TBF
i Scheduling Weight for the TBF Scheduler.
To calculate PFC Scheduling Weight the following cases have been defined:
• PFC Streaming: PFC Scheduling Weight is not needed: PFC Scheduler algorithm
assigns maximum priority (but less than PFC signaling Type) to Streaming PFC;
• PFC Pre-defined:
– SMS Type: PFC Scheduling Weight is configurable by means of O&M attributes.
The default setting is equal to Background Traffic Class;
– LCS Type : PFC Scheduling Weight is configurable by means of O&M attributes.
Default setting is 4 (corresponding to Interactive Class, Traffic Handling Priority =
2);
– Signaling Type: PFC Scheduling Weight is configurable by means of O&M
attributes. Default setting is 8 (corresponding to Interactive Class, Traffic
Handling Priority = 1).
– Best Effort Type : PFC Scheduling Weight is configurable by means of O&M
attributes. Default setting is 1 (corresponding to Background Class).
Scheduling Weight for signaling PFC is used only to determine TBF Scheduling Weight
i for TBF Scheduler (not for PFC Scheduler.)
• PFC Not Pre-defined:Weight is determined by Traffic Class Parameter and Traffic
Handling Priority.
TBF Scheduling Algorithm:
For each TS “j” two different data structures for downlink block scheduling:
DL_Scheduling_List(j) and High_Priority_DL_Buffer(j) have been implemented:
A30808-X3247-M24-5-7618 283
System
• DL_Scheduling_List(j) is filled with the indices of downlink TBFs (d/TFI = downlink

Temporary Flow Indicator) scheduled for transmission. This information is used by
TBF Manager to send RLC data block or RLC/MAC control block for scheduled TBF;
• High_Priority_DL_Buffer(j) contains the indices of TBFs (d/TFI or u/TFI) that require
radio resources for specific - high priority – requests, for example the following:
– when an uplink radio block has to be allocated with polling mechanism (see GSM
4.60 Recommendation);
– when a downlink control block (for example Packet Uplink Ack/Nack) is sent for
an uplink TBF;
For uplink (USF) scheduling two data structures for TS “j” as well: UL_Scheduling_List(j)
and High_Priority_UL_Buffer(j) have been implemented:
• UL_Scheduling_List(j) contains the indices of TBFs scheduled for uplink transmis-
sion (USF);
• High_Priority_UL_Buffer(j) contains the USFs that shall be sent with high priority, for
example permissions for sending a PRACH (USF = FREE) or dummy USF values
(USF = value not assigned to any UL TBF) to avoid conflicts when an uplink radio
block has been allocated with the polling mechanism.
Specific requests made by TBF Manager have the highest priority. Therefore, at each
time step and for each timeslot j, the scheduler checks first if there is some valid infor-
mation in the first position of High_priority_DL_Buffer j.
In this case information is sent to TBF Manager (for example: d/TFI or u/TFI and, if
present, the valid RRBP value), the first element of High_priority_DL_Buffer j is then
deleted from the list and all other elements are shifted down by one position.
On the contrary, if first position of High_priority_DL_Buffer j is empty, the information
contained in the first position of DL_Scheduling_List j is sent to TBF Manager and then
deleted from the list. At the same time the elements of High_priority_DL_Buffer j are
shifted down by one position.
For uplink scheduling (USF) the same behaviour applies. High priority Downlink buffers
have always priority on “UL_Scheduling_Lists”.
At each time step TBF Manager receives information from Scheduler indicating what
TBF is allowed to access the physical resources.
For each possible Timeslots the following conditions need to be taken into account:
• If TBF Manager receives an u/TFI, it sends the first RLC/MAC control block waiting
to be transmitted for the addressed uplink TBF. If a valid RRBP value is obtained
from Scheduler, RRBP and S/P fields are according TS GSM 4.60 Recommenda-
tion;
• If TBF Manager receives a d/TFI together with a valid RRBP value, it sends the first
RLC/MAC block that has triggered a polling request for the addressed downlink TBF
i;.
• If TBF Manager receives a d/TFI without a valid RRBP value, it sends a RLC/MAC
block (for the addressed downlink TBF i) with the following priority:
– RLC/MAC control blocks, except Packet Downlink Dummy Control Blocks;
– RLC data blocks, selecting RLC block with lowest sequence number. Any out of
sequence transmission is not permitted and wrong RLC or badly received blocks
are retransmitted with higher priority;
– RLC/MAC control blocks containing Packet Downlink Dummy Control Blocks.
• In any case TBF Manager set USF value for the selected RLC/MAC block according
to information (USF i) sent by the scheduler.
284 A30808-X3247-M24-5-7618
System
When EGPRS and GPRS Mobile Stations are multiplexed on the same PDCH the main
problem is due to the fact that GPRS mobiles are not able to read USF in downlink
blocks transmitted with 8PSK modulation. Therefore uplink and downlink scheduling
shall be performed jointly, avoiding to set USFs for GPRS mobiles in 8PSK-coded down-
link blocks.
A solution is to implement a Weighted Round Robin strategy for downlink scheduling
where tokens for a given TBF are uniformly (not sequentially) distributed in the sched-
uling list. As a consequence, "DL tokens" for 8PSK and GMSK TBFs are uniformly
distributed in the list.
On the contrary, tokens in UL_Scheduing_List shall be ordered according to TBFs’
scheduling priorities.
Scheduler decision for downlink transmission is supported by the following rules:
High_priority_DL_Buffer j is checked first, but if the first position is empty then the first
“DL token” is extracted from the DL_Scheduling_List j.
As additional rule, to guarantee that USFs from High_priority_UL_Buffers can be
successfully received, when an USF is extracted from an High_priority_UL_Buffer it
dominates the modulation. This means that if USF is for a GMSK mobile, a GMSK down-
link block is sent in any way; for example an EGPRS TBF is instantaneously switch to a
GMSK MCS.
Packet Flow Control (PFC) Scheduling Algorithm:
Main purpose of PFC Scheduling algorithm selects the next sending LLC Frame.For
each PFC belonging to a Mobile Station a LLC Buffer is created (in TBF Manager Entity).
Radio Resource Manager (RRM) provides PFC Scheduler with Scheduling Weights for
each activated Packet Flow Context. signaling PFC and Streaming PFC are managed
with high priority by PFC Scheduler: the related PFC scheduling strategy is not based
on scheduling weight. Signaling PFC priority is higher than the priority of Streaming PFC
one.
If a signaling PFC is active, PFC Scheduler gives maximum priority to the signaling
PFC: until LLC Buffer of signaling PFC is not empty, LLC Data of the signaling PFC are
transmitted.
If a Streaming PFC is active, PFC Scheduler gives priority to Streaming PFC: until LLC
Buffer of Streaming PFC is not empty, LLC Data of Streaming PFC are transmitted.
Bandwidth surplus is shared among Not Streaming and Not signaling PFCs according
to their scheduling weight.
The target of PFC Scheduler is to share radio resource utilization more or less propor-
tionally to PFC scheduling weights for Not-signaling and Not-Streaming PFC. Besides
PFC Scheduler organizes PFCs, belonging to a BSS Context, according to their sched-
uling weight from the highest one to the lowest one.
The implementation of the Scheduler improvements has requested the introduction of
the new attribute ““TimerPFCBuffer_Value” related to “CPCU” Managed Object”. This
attribute is the value of TIMERPFCBUFFER timer. The timer is defined for each allo-
cated PFC_Buffer. It is started, when PFC_Buffer gets empty. It is deleted if new LLC
Frames are coming for that PFC_Buffer. When it expires, Downlink TBF Scheduling
Weight Updating Algorithm is triggered.
A30808-X3247-M24-5-7618 285
System
9.10 Quality of Service Support for PS Services

In this chapter it is analyzed the impact on Radio Resources Management (RRM, air
interface side) and BSSGP procedures (SGSN interface side) due to the introduction of
the Release 99 EDGE/EGPRS and Quality of Service (QoS) UMTS model (Recommen-
dation 23.107) and of the following updates up to release 5 for QoS support for Non Real
Time and Real Time (Streaming only) services. Enhanced Flow control, Network
Assisted Cell Change and RAN Information Management procedures are outside the
scope of this chapter, though involved in the support of Release 5 features. One Tempo-
rary Block Flow (TBF per direction) is handled (multiple TBF handling is not standard-
ized in R5) with multiple PFCs.
The support of two Timeslots in Uplink is conditioned by the “overheating” condition
i affecting the Mobile Station.
For the reason that PPCU boards are not more supported in the current release, the
features described in this chapter are managed by PPXU software.
Besides the term „Admission control“ is adopted according to following definition
included in GSM 23.060 Recommendation: “The purpose of admission control is to
calculate which network resources are required to provide the quality of service (QoS)
requested, to determine if those resources are available, and then to reserve them.
Admission control is performed in association with Radio Resource Management func-
tions in order to estimate the radio resource requirements within each cell“.
The Resource reservation (included in the admission control definition) is foreseen for
RT services only and applies only to preallocation and Temporary Block Flow lifetime.
The term “preallocation“ is used instead of reservation, to indicate that the calculated
resources are reserved for a TBF, but no “PACKET UL” or “DL ASSIGNEMENT” or
“PACKET TIMESLOT RECONFIGURE” command is issued to the Mobile Station (allo-
cation to the Mobile Station is not performed). Preallocation/reservation includes the
alignment procedure between PCU and BTS to use the Timeslot as PDCH.
Using R5 standards, streaming traffic class is supported by those resources allocated in
a virtually dedicated mode. It is an assumption that in this case the TBF is mostly not
shared with NRT PFCs if the risk of application data mutual blocking between different
PFCs is incurred; it is however impossible to prevent multiple PFCs working “in parallel”
for a system restriction of running only one streaming PFC per Mobile Station with either
symmetric or asymmetric bandwith requirements.
In this chapter RT (streaming) service terminology is used to indicate Packet Flow
Contexts with RT characteristics according to TS 23.107 Recommendation,Tables 3
and 5 , that is with traffic class streaming (and conversational), transfer delay and guar-
anteed bit rate meaningful parameters;
Maximum and guaranteed bit rates are reduced by the supported multislot classes
i (according to the maximum number of Timeslots in UL and DL and balanced/unbal-
anced configurations).
Streaming traffic class does not imply asymmetric bandwith requirements; differentia-
tion between conversational and streaming traffic classes is only in the transfer delay
values, differentiation between NRT/best effort traffic classes and RT is in the rules
defined by GSM 24.008 Recommendation. The transfer delay value is ignored if the
Traffic Class is interactive or Background class.
It is important to underline that the latest approved versions of the release 5 standards
are the reference for this feature; the Recommedations are the following:
286 A30808-X3247-M24-5-7618
System
- 3GPP TS 23.060;
- 3GPP TS 24.008;
- 3GPP TS 44.018;
- 3GPP TS 44.060;
- 3GPP TS 45.002;
- 3GPP TS 45.008;
- 3GPP TS 45.010;
- 3GPP TS 48.008;
- 3GPP TS 48.018;
Besides informative references are contained in following Recommendation:
- 3GPP TS 23.107;
- 3GPP TS 29.208 :
End to end QoS signaling flows (indicates mapping rules from IP QoS to QoS I.E TS
24.008 applied by the Mobile Station and Core Network, IMS oriented).
The Packet Flow Management (PFM) procedures, according to the TS 48.018 Recom-
mendation, are supported by BSSGP protocol. For the reason that the PFM procedures
are described in the standard, they are out of the scope of this chapter.
GSM 48.018 Recommendation includes also modifications related to IP SNS handling,
for example the possibility to handle zero length LLC indication in the BSSGP Unitdata
(this information is transparently passed to the Network Service (NS) layer).
According to subnetwork service, QoS information is mapped at NS transport level. The
information is passed together with the LLC to be sent, through the NS layer, to SGSN
network node. As PFC support is administrable in order to facilitate the feature testing,
initial PFC value and modifications are signalled through a signaling BVC reset,
conveying the “new” value for PFC support.
RLC/MAC protocol supports the QoS feature by providing the requested QoS informa-
tion in uplink direction. In downlink direction, all QoS data are provided by BSSGP
protocol. As the PFC support information can change, due to SGSN network node
updates or local PCU administration in order to facilitate the feature testing, modifica-
tions of PFC support (based on PCU enabled/disabled state and SGSN information) is
signalled on air through the GPRS cell options parameter on BCCH or PBCCH channels
, that is broadcasting it in SI13 or PSI1, PSI13 messages.
QoS information in uplink are provided directly and/or indirectly:
• Directly provided are the Radio Priority (short or one phase access with 11 bit
Packet Channel Request / EGPRS Packet Channel request or two phase access)
and Peak Throughput and RLC/LLC mode (two phase access only);
• Indirectly provded is the Packet Flow Identifier (PFI) for uplink traffic. BSSGP can
use the PFI to request detailed QoS data from SGSN network node if not received
via the message: “CREATE BSS PFC”.
QoS information can be transferred (as queued LLC) in case of cell changes. Different
cases are applicable to cell changes, however as inter-NSE rerouting is not supported,
“transfer” of the Context information and queued LLCs are supported on SGSN side.
The RRM uses these parameters for the allocation of an appropriate TBF. Besides the
scheduler provides the QoS dependent resources for this TBF.
A30808-X3247-M24-5-7618 287
System
For the support of real time services it is used a virtually dedicated mode in the
resources allocation; assigned time slots on air are “exclusively” used by only one
Mobile Station requesting a RT PFC; only streaming services are supported according
to R5 features, that is in a single TBF “context” , because the support of conversational
requires capabilities not yet standardized; this means the BSC does not admit an ABQP
indicating a conversational traffic class.
The same Mobile Station can run one streaming Packet Flow as perceived by BSC.
Handling of multiple RT PFCs, for example two streaming PFI is currently not supported
and it may be subject to a further step together with scheduler enhancements.
As a consequence the assumption is that these multiple streaming packet flows are
either not admitted at SGSN or shall be considered as one PFC mutliplexing of concur-
rent streams at application layer. This is transparent to the BSC, perceivable only by the
messages: “Create BSS PFC PFM” issued by SGSN network node whenever a
streaming packet flow (streaming PDP context) is added (PDP context activated) or
subtracted (PDP context activated/deleted).
In the admission control phase, a request for traffic class conversational is rejected with
a message: “Create BSS PFC Nack” with the related cause: “PFC creation failure”, as
the request to set up a second streaming flow (with PFI different from PFI currently in
use). When admission/allocation is executed on the basis of information relevant to one
direction only, 1 Timeslot in the not specified direction is allocated as well.
Besides according to GSM 45.002 Recommendation, this feature does not affect the
handling of MS multislot classes and new MS mutlislots classes are supported as
already implemented.
Qos support provides additional streaming services to users, for example the following:
• Push To talk over Cellular (instant talk, chat groups);
• Downloading of news, images or video clip on special events (video goal) (tailored
to user profile);
• Downloading of news audio clips (tailored to the user profile);
• Same as push news (text and images) with video (sport news);
• Commercial promotions announcements, press and stock exchange radio news
updates, songs eventually tailored to the user profile;
• On line video, movies, video clips and On line music.
9.10.1 QoS and RRM procedures

The support of Qos affects RRM procedures.
Admission Control:
Precondition for Admission Control and Resource Preallocation/Allocation modifications
is the signaling of ABQP parameters on Gb interface based on the Packet Flow
Management (PFM) procedures that affect also BSSGP protocol.
The support of RT PFC (streaming) is configurable by the user if PFM procedures are
i applicable; by default PFM and streaming procedures are disabled.
When PFM procedures are enabled, the system storage capacity of ABQPs parameters
related to non predefined PFI values, is limited to 4; The reason is the handling of single
TBF only Mobile Station and only 4 SAPI LLC coding available for “data”. BSC does not
perform “merging” operations based on traffic class parameters.
288 A30808-X3247-M24-5-7618
System
The Admission Control Algorithm has been enhanced (the current algorithm is based on
peak throughput request and MS multislot class).
No admission control is performed based on available Gb interface bandwith, as the
i bandwith on Gb interface can be of max 31*64 kbps in case Gb over Frame Relay (FR)
is used and higher if the Gb over IP over Ethernet (High Speed Gb) is used.
The following two cases are applicable when the Packet Flow Management (PFM)
procedures are negotiated:
• Radio Resources are requested at a time such that BSC does not know the context
for a non predefined PFI, or Radio Resources are requested for a pre-release 99
Mobile Station;
• For release 99 onwards Mobile Station, the PFC information is “created” before the
Mobile Station or the network requests radio resources allocation for the PFC.
When a message: “PAGING PS” is received it may contain, according to GSM 48.018
Recommendation, a PFI and/or ABQP information. This information is relevant to the
cause triggering the PAGING procedure (for example a predefined PFI is included if the
following DL transfer is for best effort, or SMS or signaling or LCS; an ABQP is included
if the transfer is for a background or streaming or interactive traffic class).
This information is not to be stored according to the 48.018 Recommendation. The
paging procedure is described in 44.018 and in 44.060 Recommendations. As the
message: “PAGING” can be sent as a RLC block, ABQP/PFI Information may be used
for scheduler prioritization of the block “PAGING RLC”.
In case RT streaming has been activated/enabled by the user, RT streaming services
are admitted only when in Horizontal Status. Basically in vertical allocation a new RT
PFC request (creation request) is rejected.
TBF establishment can be requested in Uplink with the message: “PACKET CHANNEL
REQUEST”. This is a GPRS request without radio priority indication. It can be requested
also with the message: “PACKET CHANNEL REQUEST / EGPRS PACKET CHANNEL
REQUEST”.
None of these requests contain an indication if the initial PFI is used for Uplink transfer.
Therefore on the message: “PCR/EGPRS PCR” the already used allocation rules are
applied, for example the BSC forces a two phase access in the cases allowed by TS
44.060 Recommendation. The result is the assignment of a single block or multiblock
structure (PACKET UPLINK ASSIGNMENT) triggering the message: “PACKET
RESOURCE REQUEST (PRR)” sent by Mobile Station. PRR message includes the PFI
(optional) and the Channel request description including the peak throughput class,
radio priority and RLC mode.
The message “Packet Channel Request (PCR)” contains an indication relevant to the
cause triggering its generation. The indication can include the specific “cell update”
request in case of non EGPRS PCR; in case of EGPRS PCR a generic signaling cause
is used, including possible cell update cases. Target is “Normal” PCR triggered by
application layer for an Uplink (first) data transfer (for example not for cell update cases).
The establishment of successive PFCs for a TLLI with an Uplink active TBF is performed
with the message: “PACKET RESOURCE REQUEST (PRR)”. This message contains
RLC mode , therefore it is possible to check if RLC mode is the same or a different one
against the already allocated PFC.
If the RLC mode is not the same, then actions described in GSM 44.060 Recommenda-
tion apply. If the extended Uplink TBF mode has been implemented then RLC is
A30808-X3247-M24-5-7618 289
System
changed, and in any case the current TBF is released. Admission restarts TBF re-allo-
cation.
In any case, TBF is released due to RLC change or TBF is reallocated/reconfigured, the
additional throughput requirement of PFC is checked, that is the need for an upgrade. If
the number of requested TS for the new throughput is the same as for the previous one,
no upgrade is performed for TBF (either already established or re-established); an
upgrade is needed if maximum throughput of the newly established PFC is higher than
the one already established/allocated.
If the PFI is not known (message: “CREATE BSS PFC” or predefined PFI not received),
the ABQP is requested, default background applies for first transfer of UL information.
If four PFCs are already created for MS, further PFCs creation is rejected: in case a PFI
in the non predefined range is received, data flow is handled according to default behav-
iour, ABQP is requested just to send the message: “CREATE NACK (PFC creation
failure)”. If ABQP is available or if ABQP is received for a PFC “normally” accepted,
specific rules apply.
The establishment of first TBF and PFC for a TLLI in Downlink is triggered by the
network for DL direction when the MS has no active TBF transfer in Uplink, with MS in
idle transfer mode. The procedure is triggered by a request from upper layers on the
network side to transfer an upper layer PDU to a MS in packet idle mode. The request
from upper layers specifies an optional priority level, a QoS profile including the
requested RLC mode, optional DRX parameters, optional PFI, an optional IMSI and an
optional MS Radio Access Capability, multislot class and mobile classmark to be asso-
ciated with the packet transfer. The request is implicit when receiving an upper layer
PDU to a MS not already having any assigned radio resources. Consequently the
network starts a packet downlink assignment procedure.
The allocated radio resource is assigned to the MS in a message: “PACKET DOWN-
LINK ASSIGNMENT” sent to the MS. This message is transmitted on the PCCCH
timeslot corresponding to the PCCCH group the MS belongs to. The appropriate
PCCCH group is calculated from the IMSI.
If the PFI is a predefined one, applicable also to prerel99 MSs, there is no need to get
additional information; in case the default best effort PFI is used, throughput is the one
in the QOS I.E. in the BSSGP header, the relevant weight is engineerable (default for
the background class is recommended).
If the PFI is not a predefined one and not known, the relevant ABQP is requested, mean-
while the request is handled according to default background (with throughput as
requested in the QOS I.E.). If the PFI is already known the preallocated resources are
indicated to the MS in the message: “PACKET DOWNLINK ASSIGNMENT”. For NRT
cases preallocation is used as well but in this case the real allocation can be performed
differently due to changes in the Horizontal/vertical allocation status.
For the purpose specific rules in DL have been implemented. Their description is out of
the scope of this manual.
The establishment of additional/alternate PFCs for a TTLI with an active TBF Downlink
is performed through the same information as for the initial assignment, that is signaling
the new PFI in the BSSGP header, together with the QOS mandatory Information
Element. The generic rules applicable for first assignment (that is handling of predefined
PFI, new unknown PFI or PFI for which a message: “CREATE BSS PFC” has already
been received) apply, including the handling of non predefined PFC exceeding the limit
of 4.
290 A30808-X3247-M24-5-7618
System
In particular, if the PFC related context information has been already received, the
message: “CREATE BSS PFC” cannot be assigned to the MS before the first relevant
BSSGP DL Unitdata is received. It is an assumption that if the ABQP is known before
the first DL-Unitadta is received, the first DL unitdata will follow in a short time and in this
case an evaluation of possible preallocation could happen.
When admission control is executed for preallocation/radio resource reservation, the
message: “CREATE BSS PFC” may be acknowledged at preallocation time; if timer to
free preallocated resources expires no modification is indicated; modification will be indi-
cated at resources allocation time if the PFC cannot be granted.
If the RLC mode in the BSSGP header QOS I.E. is not the same as for the allocated
TBF/PFC, then actions described in GSM 44.060 Recommendation apply. The TBF is
then re-established according to the requirements for the new RLC mode (as for initial
TBF and PFC establishment).
In case RLC mode is the same, then the additional throughput, that is the need for an
upgrade, of the PFC is checked. If the number of requested TS for the new throughput
is the same as for the previous one, no upgrade is performed even if the allocation was
performed for a RT streaming PFC.
The establishment of concurrent TBFs in packet transfer state Uplink or Downlink and
balanced/unbalanced assignment decision is executed as follow:
During uplink transfer, the network starts a downlink TBF by sending the message:
“PACKET DOWNLINK ASSIGNMENT”, or the message: “PACKET TIMESLOT
RECONFIGURE”, to the MS on the PACCH channel. If the message: “PACKET
TIMESLOT RECONFIGURE” is sent, then the message contains the
DOWNLINK_TFI_ASSIGNMENT field. If uplink and downlink TBFs are already estab-
lished, then the network sends the message: “PACKET TIMESLOT RECONFIGURE”
without the field: DOWNLINK_TFI_ASSIGNMENT. The mobile station shall interpret
this as a reassignment of the timeslot allocations of the concurrent uplink and downlink
TBFs and the downlink TFI is not changed.
The MS can request the establishment of an uplink transfer during a downlink TBF by
including a Channel Request Description information element in the PACKET DOWN-
LINK ACK/NACK message.
The Initiation is triggered by a request from upper layers to transfer an upper layer PDU.
It specifies a Radio Priority that shall be associated with the packet transfer. The MS
starts the packet access procedure by sending the Channel Request Description infor-
mation element in the message: “PACKET DOWNLINK ACK/NACK” on the PACCH
channel and then starting the timer T3168.
On receipt of a Channel Request Description information element in the message:
“PACKET DOWNLINK ACK/NACK”, the network can assign radio resources to the Ms
on one or more PDCHs by transmitting a “PACKET UPLINK ASSIGNMENT” or
“PACKET TIMESLOT RECONFIGURE” message on the PACCH channel. The request
can also be rejected sending the message: “PACKET ACCESS REJECT” on the
PACCH channel. If the message: “PACKET TIMESLOT RECONFIGURE” is sent, then
the message contains the field: UPLINK_TFI_ASSIGNMENT.
If the PFI is signalled in the concurrent TBF set up , then the same procedure for sepa-
rate UL and DL TBF/PFC admission control applies.
Currently the decision about balanced/unbalanced assignment is performed according
to information included in the Channel request description, for example if the RLC octet
count is higher than a threshold or if the UL transmission persist for more than an engi-
A30808-X3247-M24-5-7618 291
System
neerable timer. With the availability of the PFM procedures, if context information is
available some further impacts on the balanced/unbalanced assignment needs to be
considered, due to the possibility to contemporary indicating the needs for UL and DL
together or to indicate them separately but within the PFM messages sent by the SGSN
network node.
To handle the decision about balanced/unbalanced assignment according to MS and
PFM information general rules have been implemented for first balanced/unbalanced
allocation decision, but their description is out of the scope of this manual.
Radio Resource Allocation Procedures:
Two cases are applicable for Radio Resource Allocation phase (without considering
resource reallocation cases and concurrent TBF establishment; for example the phase
ending with the PACKET UPLINK or PACKET DOWNLINK assignment equivalent to
the first TBF allocation):
Admission and Allocation are executed on request for transfer of RLC blocks in Uplink
(PCR/PRR received) or on request to transfer LLC in Downlink reception of a DL-Unit-
data with PFI information and a predefined PFI is signalled or the relevant PFC is not
known. The following handling of allocation/scheduling weights is performed (the
handling applies also when allocation is performed because of reception of PCR/PRR
in UL or BSSGP DL-Unitdata with known PFI):
For Uplink direction, the TBF weight is calculated in accordance to the currently radio
priority only without differentiating between rel99 and prerel99 Mobile Stations for
predefined best effort PFI. If a new traffic class is associated to the new PFI, the TBF
weight is dynamically changed based on the relevant (per traffic class) configured
weight. The resources are assigned according to the maximum throughput between the
TBF components (the Mobile Station sends in sequence according to internal prioritiza-
tion) even if a RT component is admitted.
For Downlink direction, the TBF weight is the sum of PFC weights, whilst the resource
are assigned according to the maximum throughput needs between RT and NRT
components.
Admission procedure has been executed based on the message: “CREATE BSS PFC”
sent by SGSN network node:
Admission has been performed including a RT PFI for which preallocated resources are
defined: if the same PFI is indicated in the Mobile Station request UL or in a BSSGP DL
unitdata header, the preallocated resources are immediately assigned and related
preallocation timer is stopped. If preallocated resources are no more available, admis-
sion has to be performed again based on system status (horizontal or vertical allocation
status) unless the PFI has been rejected due to its conversational nature.
For NRT PFI, allocation is searched; if a cell in congested state does not allow for allo-
cation (first PFC in the TBF) the previously granted PFC shall be modified with a
message: “MODIFY BSS PFC” with the maximum bitrate set to 0.
In the radio resource allocation phase there is no more a completely unbalanced assign-
ment (that is an assignment for only one direction, either DownLink, as in previous
releases, or UpLink).
At allocation time the allocation/scheduling weight for the TBF and PFC is assigned as
follow:
The traffic class (plus traffic handling priority for interactive class) is used with meaning
equivalent to the service precedence, from this information an allocation/scheduling
292 A30808-X3247-M24-5-7618
System
weight is derived to be used for optimized distribution of the radio resources to the TBFs;
scheduling weights are useful for NRT TBF as these can share the same Radio
Resources.
In case of RT components within one TBF, the RT weight (allocation weight) is relevant
only for decision on preemption by Circuit Switched (CS) services.
It is possible to distinguish between two different kinds of grouping:
• aggregating NRT (one group), where TBF multiplexing is allowed;
• RT services (the other group), where TBF multiplexing is not allowed (only PFC
multiplexing is allowed, that is only NRT PFC of the same TBF can share the radio
resources.
RT service is granted in “normal” load cases, that is when horizontal allocation is active.
By release 97/98 attributes the NRT grouping only is addressed, with the same alloca-
tion rules.
The weights are assigned according to the following rules: with rel 97/98 parameters, no
mapping for the RT services is foreseen, the service precedence and radio priority are
handled as shown in the following table:
Qos Attribute Weight default Scheduling priority
Service Precedence=1 8 1
Tab. 9.5 Service Precedence and Radio Priority Table
When multiple TBFs are allocated on the same physical resources, they are served
according to their own scheduling priorities.
As regards the scheduling of uplink TBFs, the Radio Priority attribute is used. It is
mapped one to one to the uplink scheduling priority as reported in the following table:
Qos Attribute Weight default Scheduling priority
Radio Priority=1 8 1
Tab. 9.6 Mapping between Radio Priority and Scheduling Priority Table
When R99 QoS attributes are known at the BSS system (for example when Packet Flow
i Context procedures are supported and the aggregate BSS QoS Profile has been trans-
ferred to BSS) then also the Interactive Class connections (with their different Traffic
Handling Priorities) as well as Background Class connections are handled, with no need
for modifications.
Moreover it is possible to handle R97/98 and R99 connections on the same Radio
Resources at the same time (NRT cases only). The TBF scheduler does not directly
consider the different QoS attributes; It only looks at the scheduling priority/ weight to
prioritize among different TBFs where applicable.
A30808-X3247-M24-5-7618 293
System
A specific scheduling priority is not needed for a TBF “containing” a streaming PFC ,
however PFC scheduling is needed for prioritizations between PFCs of the same TBF.
PFI best effort, allocation and scheduling weights are based on already configured
weights for radio priority (indicated in UL), for the Downlink direction a specific weight
can be defined, suggested default is the same as for the background traffic class.
PFI signaling (for example cell update): This procedure is treated as highest scheduling
priority (by PFI value). For TBF allocation evaluation the weight is configurable by the
user;
PFI SMS: The weight is configurable by the user, the default is equal to background
class weight.
PFI LCS: LCS procedures on the BSSGP protocol have not been currently requested.
This PFI is not supported.
Multiplexing over the same PDCH of TBFs pertaining to different Mobile Stations is not
allowed for RT services. Instead multiple PFCs can share the same Radio Resources
for the same TBF for the same Mobile Station.
In case the Allocation for a Mobile Station with RT streaming service is executed, no
multiplexing is allowed from an other Mobile Station, whilst parallel PFCs with non RT
characteristics can be multiplexed on the virtually dedicated channel. The way to distin-
guish if multiplexing with other TBF is allowed does not depend from the implementation
based on the knowledge of the TBF having a RT streaming component.
When the PFM procedures are enabled in the system QoS handling of Rel 97/98 MS
has been changed as follow:
In case PFI is a predefined one, but for PFI-0, there is no need to get additional infor-
mation; in case the default best effort PFI (PFI-0) is used, the throughput is the one in
the QOS I.E. in the BSSGP header, the relevant weight is engineerable and it is chosen
according to the Mobile Station revision level contained in the Mobile Station radio
access capabilities.
In case the RA capability I.E. is included in the DL-Unitdata or is stored in the Mobile
Station context and R99 onwards is indicated, the default value for the background class
is recommended (in this case the 48.018 Recommendation states the service prece-
dence in the QOS I.E in the BSSGP header shall be disregarded).
If the RA capability information is included or MS radio access capability stored within
the MS context and R97/98 is indicated, the weight configured for the Service prece-
dence indicated is used. If the RA capability is not included in the DL-Unitdata and not
available as stored information, the default background traffic class is used.
The weight information is “re-freshed” as applicable for peak throughput information, for
example at least when a TBF resumes from delayed TBF release state, in case of
Release 97/98 Mobile Station. As a consequence, in case PFM procedures are not
enabled, the scheduler takes care to apply different weights based on the Service
Precedence parameter received in the DL-UNITDATA message. If the PFM procedures
are enabled, the scheduler applies always the Background weights to Rel 97/98 Mobile
Stations.
With this approach, when the user activates Streaming services, it has to enable PFM
procedures, but release 97/98 Mobile Stations are handled in the system with "lowest
priority" for example background) in respects to Rel 99 onwards Mobile Stations.
Upgrading/Downgrading Procedures:
294 A30808-X3247-M24-5-7618
System
The current upgrading procedure has been enhanced to support PFC procedures and
RT services and to include the possibility of allocation in another TRX of the cell (without
a service change).
The current implementation foresees a synchronous/asynchronous mode of triggering
the upgrade. The upgrade is checked in synchronous (immediately) with the following
new additional rules:
In case message: “CREATE BSS PFC” with modified parameters (for example
throughput), for already assigned PFI is received, or message: “CREATE BSS PFC” for
an unknown PFI is received either when in Delayed TBF release /extended uplink TBF
mode or with an already active PFC, the previous release constraint on use of delayed
TBF is removed, at least for R99 onwards MSs with PFC feature negotiated.
If the modified parameters or the new PFC shows the streaming RT traffic class and the
TBF is allocated on the Timeslot shared with other Mobile Stations, if the needed
resources are available on another TRX, the message: PACKET TIMESLOT RECON-
FIGURE is sent in order to reallocate the Mobile Station.
Congestion Procedures:
For the reason that RT services require a “virtual dedicated” Radio Resource assign-
ment, the service is granted with some limitations.
Additional parameters are not requested. Besides RT services are granted only in Hori-
zontal allocation status.
If it is not possible to grant resources according to the guaranteed bit rate, the message:
“CREATE BSS PFC” is rejected with a NACK (PFC create failure cause). At allocation
time (for example on reception of a PRR with the PFI waiting for allocation or at recep-
tion of a DL-unitdata with the PFI), if there are no preallocated resources for a RT
service, the resources condition is checked again.
If the system is in horizontal allocation but it is not possible to allocate the minimum
needed resources number or the system is in vertical allocation status, the message:
“CREATE BSS PFC” is rejected if it is the first one (in case no preallocation is performed
for the first CREATE with that PFI) with the following cause: “PFC create failure / cell
traffic congestion” if the CREATE PFC has not yet been acknowledged (data to transfer
received between the CREATE BSS PFC reception and sending of relevant ACK/NACK
indication). In case the message: “CREATE BSS PFC” has been already Acknowledged
otherwise a modification procedure is used with maximum and guaranteed bitrate set to
0.
If the message: “CREATE BSS PFC” is not the first one, a modification request has been
triggered by the SGSN via the message: “CREATE BSS PFC” with PFI known, the
second CREATE, for which no upgrade is possible, is acknowledged with data for the
first accepted CREATE BSS PFC, that is maximum and guaranteed bit rate are the
same as for the first one.
PDCH/PDT Preemption:
The following messages are received by the PCU from the TDPC:
• PDCH pre-emption order;
• PDT pre-emption order;
• PDT_Reallocated (PDT occupancy threshold reached: freeing of PDTs related to
TBFs with empty channel timer running requested);
A30808-X3247-M24-5-7618 295
System
• Forced_Release: this message is used when a control channel (highest priority)

needs resources (PDT), the cell and list of cells belonging to the same BTSM are
included in the message.
The current algorithm is impacted by the Service dependent channel allocation
enhancements. The ordered list of TRXs (according to service preferred layer for the
service to be granted) is assigned by the TDPC when pre-emption is requested in order
to serve a CS single slot request. Moreover, as preallocated resources can be present
in the system, in case a preemption/downgrading order is received for a CS call, the
possible allocation of the needed TS is executed starting from:
• PDCH with empty channel timer;
• PDCH preallocated;
• PDCH busy.
In case more than one candidate is found for PDCH pre-emption, the information on
ranking of the possible choices is given against the TDPC information about the
preferred layer per service to be granted. The PCU takes care in order to downgrade as
latest PDCH allocated to RT TBFs/ PFCs, detecting the condition by using the PDCH
allocation weight (higher or equal to the streaming weight) only, or the PDCH allocation
weight and no multiplexed TBF information on the target PDCH as a better guarantee
of the granted bandwith.
The PCU take care also of downgrading the Coding Scheme of NRT allocated TBFs in
order to fulfill the initial allocation for RT TBFs (possible internal PDT pre-emption not
triggered by TDPC). If this is not possible the RT allocation cannot be granted: “In case
a RT streaming service is requested, availability check of internal resources is
performed: no downgraded CS/MCS assignment is allowed resulting in a throughput
below the guaranteed bit rate.
PDT_Reallocated message from TDPC handling: for the reason that PDT_Reallocation
is a system protecting measure, no modification is necessary to the current behaviour
leaving only PDTs associated to PDCH with empty channel timer.
Forced_Release from TDPC: the forced_Release can request with highest priority pre-
emption of radio resources. In this case it is handled as for PDCH preemption/down-
grading, and/or PDT preemption. For this last case it follows the choice for PDT-pre-
emption.
QoS and Gb Interface:
Considering Gb interface, optional Packet Flow Management procedure is supported;
the availability of PFM function is signalled during the signaling BVC reset procedure.
The BSS system indicates this capability by default (no parameter shall be configured
by the user). On air interface the information enabling release 99 and higher Mobile
Stations to use the PFI is broadcasted in the messages SI 13 and/or PSI1, PSI13 (the
PFC_FEATURE_MODE is included in the GPRS-cell-options extension for release99)
according to PCU PFC capability combined to SGSN capability received via signaling
BVC reset procedure (feature bitmap).
In case of cell update in the FLUSH-LL procedure, SGSN follows the cases for inter-
NSE rerouting when no INR capability has been signalled in the feature bitmap.
PFC Supports impacts on GSM protocols:
When the streaming support flag is modified no GSM protocol is impacted because no
information is exchanged between SGSN and the Mobile Station regarding the support
of streaming services. When PCU PFC support flag is changed (from its default value
to “enabled” and viceversa), a signaling BVC reset procedure is called to update the
296 A30808-X3247-M24-5-7618
System
feature bitmap towards SGSN; as a consequence changes of the PFC support are
executed in “no traffic” conditions (at least for in-field systems). The change is notified
also to Mobile Stations through broadcast of information in the following cases:
• When PFC support is disabled (locally, after it has been enabled);
• When the full network (PCU and SGSN network node) supports PFC procedures
again.
9.10.2 QoS and BSS impacts

”CPCU” (Common PCU) Managed Object collecting information common to the PCU
serving a BSC service area (according to TS 23.236 Recommendation a Service area
is defined as the set of all cells supported by BSS system) has been implemented to
avoid the repetition of equally valued parameters per each PCU.
CPCU is automatically created at system release change; CPCU-0 is automatically
created if PCU is equipped, CPCU-0 reference is also automatically created in existent
PCU and PTPPKF Managed Objects at version conversion time.
To support QoS, new attributes have been associated to CPCU, PCU and PTPPKF
Managed Objects. They are listed in chapter: "11 Managed Objects and attributes".
9.11 EGPRS/GPRS on Extended Cell

The radius of a GSM cell is limited to 35 km. It is defined “extended cell” a cell whose
radius can measure up to 100 km. Extended cell support voice services, where the BTS
expects an UpLink (UL) burst on two consecutive timeslots. Until BR8.0 Release the
BSS system supports EGPRS/GPRS services only in normal cells (radius up to 35km)
and in the near area of extended cells. The continuous increasing number of
EGPRS/GPRS mobiles and the increasing request for Internet/streaming services have
requested the support of the GPRS services also in Extended Cells.
The support of a Mobile Station in an extended cell affects only UpLink (UL) direction:
to ensure the correct reception of a normal burst at the BTS, the Mobile Station sends
the burst “early enough”, such that the burst arrives within a defined time window. The
time necessary to the Mobile Station for sending its bursts earlier is defined “Timing
Advance (TA)”. It corresponds to the air round trip delay. Its value is: “0 ..63” (6 Bits)
such that the maximum compensated run time is 31,5 bit period (that means: 116.3
microseconds) which corresponds nearly to 35 Km. The MS receives in the SACCH
downlink channel the Timing Advance (TA) and sends in uplink the TA value currently
used. A burst sent by the Mobile Station beyond 35 km arrives at least partly at the BTS
in the next following timeslot.
The transmission in DownLink (DL) is not affected.
The next Fig. 9.20 below represents two Mobile Stations with two Uplink timeslots, one
in the near area and the other in the far area. The two bursts of the Mobile Station in the
near area arrive correctly in the time raster. The two bursts of the MS in the far area are
delayed and occupy three timeslots. In general the BTS can receive “n” consecutive
bursts from a Mobile Station in the far area on “n+1” consecutive timeslots.
A30808-X3247-M24-5-7618 297
System
2 Timeslots
MS burts in near area
3 Timeslots
MS burts in far area
Fig. 9.20 Example of Mobile Stations with two Uplink timeslots
More in general it is assumed that timeslots “k,…, k+n” are defined for EGPRS/GPRS,
with k+n < 8. Whenever a Mobile Station in the far area transmits on the timeslots k,...,
k+n-1, BSS system ensures that no other Mobile Station sends on the timeslot (k+n).
This Timeslot is defined “spill over TS”, as it is needed to receive these n bursts. This is
ensured dynamically by a proper scheduling in the PCU via Uplink State Flag (USF) and
Relative Reserved Block Period (RRBP).
In this case no special declaration as “double” timeslot is necessary for PDCH and all
eight Timeslots of a TRX can be utilized in Downlink direction. This configuration is only
permitted on non BCCH TRX with HOPMODE = SYNHOP and if no Downlink TBF has
Timeslot 7 used as Timing Advance Index TS number.
Two types of traffic channel are supported by BSS system:
• Channels which are allocated for circuit switched services (CS, near + far area) as
double timeslots and are therefore not available for supporting EGPRS/GPRS
services. These channels shall be configured in order that the first channel has a flag
“extended mode” and the subsequent channel is configured as “not installed”;
• Remaining traffic channels (TCH) can be either used for supporting EGPRS/GPRS
services (near area) or Circuit Switched (CS) services (near area) using the same
dynamic resource allocation.
With the support of EGPRS/GPRS services on extended cells, time slots of the second
type are usable not only for circuit switched (CS) and EGPRS/GPRS services in near
area but also for supporting EGPRS/GPRS services in far area.
This feature is supported by BTSplus family. Besides the Timing Offset (TO) range is
limited to 123 for all the Circuit Switched (CS) services. Special values are 124 (4AB),
125 (spill over) and 126 (invalid). As a consequence in Downlink only 7 bits for TO in
Abis are needed and the maximum range is limited to 103 km.
298 A30808-X3247-M24-5-7618
System
In BSS system the following modifications have been implemented to support

EGPRS/GPRS services on extended cells:
• Packet access in far area has been managed for BTSplus cells and rejected for old
BTS and for BR 8.0 BTS-2x/6x cells at TDPC side;
• Resource Manager has been modified to enable a specific management in case of
extended cells;
• Resource Manager has to considerate the new multislot allocation in far area;
• The new structures TAI_TBF has been created to store the TAI assignment for each
PDCH;
• The Scheduler Manager inserts TO_TA value of related uplink block in each DL
block;
• Scheduler Manager schedules, in a combined way (that is supporting TRX based
approach), blocks in TRX where a Mobile Station in far area is present;
• Information about TAI carried on PCU Idle Frame is managed;
• Already existent messages from TBF Manager to Scheduler Manager
UL_TBF_Add, DL_TBF_Add have been modified with the indication of far/near
Mobile Station;
• TBF Manager monitors “TO_TA” value of each Mobile Station and inform RMM
about transaction.
Besides TDPC and PCU boards manage a new information related to PTPPKF
Managed Object indicating if in the cell the feature is supported: the field assumes the
value “TRUE” if the cell is an Extended Cell, BTSE is a BTSplus and if the BSS release
is BR 8.0. In all other cases the field’s value is set to “FALSE”.
The support of EGPRS/GPRS services on extended cells can be enabled/disabled by
the user with specific CLI commands. It is out of the scope of this manual the commands’
description. For the purpose see the manual: “CML:BSC”.
9.11.1 Assignment of resources on extended cells

For the assignment of resources on extended cells it is assumed no PBCCH channel is
configured. Besides on a TRX, (n+1) timeslots “k, k+n” are usable as PDCH.
When a Mobile Station requests resources, it sends an access burst to the BTS on the
RACH channel which comprises two timeslots in case of extended cells. This provides
an initial timing advance that is needed to decide if the Mobile Station is in far area or
not.
Timing Advance (TA, 6 Bits) and Timing Offset (TO, 8 Bits) parameters shall be config-
ured for resources’ assignment. Timing Offset is used for supporting circuit switched
services in extended cell. Then the message: “CHANNEL REQUIRED” sent from BTS
to PCU contains access delay and timing offset also, if a packet channel is required.
Uplink TBF:
When a Mobile Station requires m timeslots (m<=n) and these are assigned, PCU allo-
cates them in the timeslots “k,..., k+n-1”. It allocates “m” timeslots consecutive. The
timeslots that are assigned to the Mobile Station are activated on the BTS side with the
message: “CHANNEL ACTIVATION” and contain the assigned Abis resources.
The message: “CHANNEL ACTIVATION” for a timeslot to be used in spillover mode
allocates always at least one Abis-subslot (16 kbps), which implies that Abis list for
PDCH’s is never be empty. The reason is that BTS needs to be informed by PCU for
every active PDCH, whether it shall operate in spillover mode or in normal mode. This
A30808-X3247-M24-5-7618 299
System
information is provided in every Downlink PCU-frame by means of a special Timing

Offset value.
To guarantee the correct reception of a block sent by a far Mobile Station the scheduler
keeps dynamically free the following TS when send an USF for a far MS on a certain
timeslot. The statement “keep dynamically free” means that whenever on TS j a Mobile
Station transmits in far area, no other Mobile Station can transmit on TS j+1 in the same
TDMA frame. If no Mobile Station in far area is scheduled to transmit on TS j in a TDMA
frame , then of course a near area UL TBF can transmit on TS j+1. This is managed by
the Scheduler assigning USF in a combined way.
Downlink TBF:
In case of extended cell, downlink transmission on air for the normal cell does not
require modifications. Nevertheless to each downlink PDTCH is associated an uplink
PACCH channel, which allows the Mobile Station to send RLC/MAC control information
in uplink. The network polls the Mobile Station setting the 2 bit field RRBP in MAC
header and the Mobile Station replies in the specified uplink radio block with a signaling
message. If the Mobile Station is located in far area of extended cell, BSS system
checks that the timeslot j where the Mobile Station sends its uplink burst is in the range
k,…, k+n-1, and no other Mobile Station sends on the timeslot “j+1” in this frame.
9.11.2 TAI Allocation

A Mobile Station gets a timing advance index (TAI) and a time slot for the continuous
Timing Advance procedure in the message: “PACKET ASSIGNMENT”. Furthermore
PCU does not assign a TAI for a Mobile Station in far area on the last timeslot of a contig-
uous set of PDCHs. If a TAI for a near area Mobile Station is assigned on the last
timeslot, PCU recalculates the allocation when the Mobile Station enters the far area.
The last PDCH needs a special treatment, for example there could be assigned TAI only
for Mobile Station in near area or no TAI at all.
This means for a fixed timeslot “j” on BTS, that alternating the 12 / 38 frames, one time
an access burst is tried to decode together with timeslot (j-1), when an access burst on
timeslot (j-1) is expected at the next time, an access burst is tried to decode together
with timeslot (j+1), when an access burst on timeslot j itself is expected. To avoid even-
tual conflicts, PCU assigns TAI respecting the following rules:
• TAI from 0 up to 7 is assigned to odd TS;
• TAI from 8 up to 15 is assigned to even TS.
The number of Mobile Stations which can be served by continuous timing advance is
only the half of all possible, but this does not cause problems because if all TAI(s) are
used, no reasonable throughput can be achieved any more.
An additional method to determine the Timing Advance (TA) is by polling. This is used
in case of:
• Packet Polling Request;
• Packet_DL_Assignment without prior paging, when Mobile Station is in ready state.
In this case Mobile Station sends four identical access burst, which are transmitted from
BTS to PCU. PCU informs BTS whether the access bursts arrive on one or two
timeslots.
300 A30808-X3247-M24-5-7618
System
9.11.3 Time Offset values in Abis Downlink PCU frames

Time Offset (TO) value is used only by BTS to orient where the Mobile Station with the
indicated USF is expected. TO is zero in case of TO_TA < = 63. So the received normal
burst from a Mobile Station in far area has a delay of “TO” bit durations. There are no
Control bits free in the first PCU frame in downlink. The TO-value is therefore set into
the last data bits of the last used PCU Sub Frame. In case of MCS1 and only one PCU
frame used in Downlink there remain only the seven data bits D210 … D216 free. The
maximum valid TO is 123, which corresponds to a timing advance of 186 and conse-
quently a maximum cell radius of 103 km.
The TO values” 124,125, 126” have special meanings:
- 0x7F spare bits, not a TO value;
- 0x7E invalid TO;
- 0x7D spill-over;
- 0x7C 4AB on two timeslots.
When a cell is configured as an extended cell, Downlink CPCU frames always contain
a TO value (no spare bits), and if no Uplink transmission of a Mobile Station is pending,
the “invalid TO” is used.
9.11.4 Timing Advance Update in Extended Cell

Timing Advance (TA) value is updated cyclically to ensure that a Mobile Station sends
uplink information in time. In normal cells this is executed in the continuous timing
advance procedure for Packed Switched services. This procedure supports also
extended cells. The only little difference is that access bursts in Packet timing advance
control channel (PTCCH) is expected on BTS on two timeslots.
The message: “PACKET_ASSIGNMENT (Uplink and Downlink)” contains the assign-
ment of PTCCH/U. This means that BSS system indicates to the Mobile Station on
which timeslot and with which Timing Advance Index (TAI) it has to send the access
bursts which are used by BTS to determine current Timing Advance (TA) value.
Therefore PTCCH/U for Mobile Station in far area shall be allocated as well in the time
slots “k,..., k+n-1” and whenever a Mobile Station in the far area sends the access burst
(frame 12 or 38 in the 52 multiframe) no other Mobile Station sends on the following time
slot. In the downlink of the same timeslot the timing advance message is a broadcast
message for up to sixteen Mobile Stations, from which each Mobile Station extracts its
updated Timing advance value.
As the values 0..63 of TA are not enough for Mobile Station in far area, TO is processed
additionally in the continuous timing advance procedure. So BTS stores (TO,TA) values
instead of TA values only.
For normal cells, BTS is master of the timing advance. In contrast BTS does not know
about user, their TBF and multislots . In case of extended cells, BTS determines as well
the Timing Offset/Timing Advance values, but informs PCU periodically. In this way PCU
makes decisions about its proper scheduling of resources (change inner < --> far area).
A30808-X3247-M24-5-7618 301
System
9.11.5 Transition between near and far Area

Based on TA evolution, PCU can decide if the Mobile Station is moving from near to far
area or vice versa and it supports the requested adaptations sending a reassignment
message. A transition from near to far area occurs in case:
TA(i) > TA(i-1) >= 60.
When Mobile Station is moving from far to near area, then the burst arrives correctly in
the time raster and no spill over TS is executed. A little waste of resource occurs in this
spill over TS, but it does not affect BSS system. Before going back to near, an hysteresis
is used to avoid too many switches between areas.
As a consequence, if TA(i) < 58 for a Mobile Station in far area then a transition to near
area is executed.
9.11.6 Extended Cells and Radio Resource Manager

The support of EGPR/GPRS on extended cells affects Radio Resource Manager (RRM)
application that has been modified to enable the management of two different resource
allocation strategies in Near and Far Area of Extended Cell.
A new scheduling of resources for Mobile Stations in Far Area is available.
A Mobile Station that requires “n” Uplink TSs implies on BTS side the channel activation
of “n+1” TS as PDCH and then the first “n” TS are assigned to the Mobile Station in the
message: “PACK_UL_ASS”. If no other Mobile Station is multiplexed in Uplink on TS
“n+1”, in the sense that no other Mobile Station gets TS (n+1) assigned in the message:
“PACK_UL_ASS”, this TS will have one associated Abis slot. Additionally there may be
PDCH activated on BTS without Mobile Station multiplexed on it. Such a PDCH cannot
be released if on the foregoing TS a Mobile Station in far area has an Uplink TBF active.
As no multiplexing is admitted in case a streaming TBF is allocated, the resources will
be preallocated for the related time interval also in extended cell, the spill over TS will
be preallocated and afterwards “allocated” in virtually dedicated mode.
The movement of Mobile Stations for near to far area is supported respecting the
following rules:
• For streaming the dedicated resources, including the spill over Uplink TS , handling
is granted; in case a suitable far area allocation is not found, the discontinued
streaming service support is indicated with message: “MODIFY BSS PFC” with
maximum bit rate and guaranteed bit rate set to 0. The inclusion of the spill over TS
does not affect other “dedicated” allocations (that is no multiplexing on other TBFs,
no “overriding” of control channels is allowed);
• For best effort TBFs: no multiplexing of new configuration over streaming TBF or
control channel is admitted as the consequence of inclusion of the spill over TS in a
TBF configuration (Uplink TBF); if the inclusion of the spill over TS violates the rule
above, TBF moving from near to far area is downgraded (for example, from 2 UL TS
to 1 UL TS). The new downgraded allocation is indicated to the Mobile Station.
Moving of the TBF from far to near area: the spill over TS is no more needed and the
TBF reference is deassociated from TS.
If the condition of having (n+1) consecutive TS available cannot more be satisfied, the
usual behaviour followed in “Quality of Service Support for PS services” feature is
adopted.
For more details see the chapter "9.10 Quality of Service Support for PS Services".
302 A30808-X3247-M24-5-7618
System
10 GPRS/EGPRS Functionalities
This chapter describes the main functions that support the GPRS/EGPRS services (for
example Cell Selection and Reselection, Power Control).
10.1 Cell Selection and Re-selection

No Handover functionality is foreseen for PS services: the Mobile Station selects the
best cell on the basis of the cell selection/reselection criteria.
If the Mobile Station is involved in data transfer, packets may be lost during the execu-
tion of the cell re-selection procedure. The Upper layers of the supported protocols then
recognize the inconsistency, discard the frame and ask for their retransmission.
In GPRS standby and ready states (described in the chapter: "9.3.1 Mobility Manage-
ment States"), cell re-selection is performed by the Mobile Station.
The only exception regards the Mobile Station of class A 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 the GPRS/EGPRS
cell selection/re-selection. When the circuit switched connection is released, the Mobile
Station triggers again 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 Mobile Stations attached to GPRS/EGPRS if
the PBCCH channel exists in the serving cell.
The C1 criterion is the same criterion used in GSM cell selection and re-selection proce-
i dure, but it makes use of additional attributes (see the chapter:"10.1.2.1 GPRS/EGPRS
Path Loss Criterion (C1 Criterion)").
If the PBCCH channel is configured, the Mobile Station does not monitor the system
information on both the serving cell and non-serving cells, but is only required to monitor
system information on the PBCCH channel of the serving cell. In other words:
• if PBCCH is configured, the GPRS/EGPRS Mobile Station retrieves all of the infor-
mation, regarding both the serving cell and neighboring cells, from the serving
PBCCH; the Mobile Station monitors the other BCCH carriers only to take signal
level measurements;
• if PBCCH is not configured, the GPRS/EGPRS Mobile Station retrieves all the infor-
mation 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 also monitors the other BCCH carriers to take the signal level measure-
ments.
If PBCCH is not configured, for example when 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 Cell-
Reselection (described in the chapter: "10.4 Network Controlled Cell Reselection and
Traffic Control Management"), by which the network can control the cell selection
process.
If the PBCCH is configured, cells to be monitored for cell re-selection are defined in the
BCCH Allocation (BA GPRS) list, which is broadcast on the PBCCH. This list could be
different from the BCCH Allocation (BA) list, that is used for GSM. If PBCCH does not
exist, BA(GPRS) list is equal to the BA(BCCH) as described in the chapter:
"10.1.4 Management of GPRS/EGPRS Neighboring Cells").
A30808-X3247-M24-5-7618 303
System
10.1.1 Measurements for Cell Selection and Re-selection

The Mobile Station measures the received RF signal level on the following:
– BCCH carrier of the serving cell:
– BCCH carriers of the surrounding cells as indicated in the BA(GPRS) list.
Then it calculates the average received level (RLA_P) for each carrier. In addition the
Mobile Station verifies the BSIC of the BCCH carriers. Only cells with allowed BSIC are
considered for re-selection purposes.
A distinction shall be done between Mobile Stations in packet idle mode and in packet
transfer mode:
a) Packet Idle Mode: whilst in packet idle mode a Mobile Station monitors continu-
ously 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 Mobile Station
according to its current DRX mode and its paging group (see the chapter:
"9.8.3.2 Discontinuous Reception").
The Mobile Station will take at least one measurement for each BCCH carrier for
every 4 seconds. The Mobile Station is 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 will 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 Mobile Station will 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
Mobile Station, or 10 seconds, whichever is greater. If a change of BSIC is detected
then the carrier will be treated as a new carrier.
In the case of a multiband Mobile Station, it will 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 attribute
(MULTIBAND_REPORTING); this attribute is broadcast on the PBCCH channel, or
if it is not configured, on the BCCH channel.
b) Packet Transfer Mode: while in packet transfer mode, a Mobile Station continuously
monitors 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 will 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 Mobile
304 A30808-X3247-M24-5-7618
System
Station will 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 param-
eter.
The Mobile Station will 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, it will 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 the PBCCH channel,
or if this channel is not configured, on the BCCH channel.
10.1.2 Cell selection and Re-selection Criteria
10.1.2.1 GPRS/EGPRS Path Loss Criterion (C1 Criterion)

The Mobile Station measures the received signal level on the PBCCH carriers of the
serving cell and the surrounding cells and calculates 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 BCCH Allocation (GPRS)
list, which is broadcast on the PBCCH channel. At least 5 received signal level measure-
ment samples are required for a valid RLA_P:
RLA_P = 1/5 * (GPRS_RXLEV1 + GPRS_RXLEV2 + ...+ GPRS_RXLEV5)
The path loss criterion C1, for example the minimum signal level criterion for
GPRS/EGPRS cell selection and cell re-selection, is defined by the following formula:
C1 = RLA_P – GPRS_RXLEV_ACCESS_MIN – Max

(0, GPRS_MS_TXPWR_MAX_CCH–P)
Where:
- P is the Power Class of the Mobile Station;

- GPRS_RXLEV_ACCESS_MIN is the minimum allowed received level to access a
cell; the user can define this value with the GRXLAMI parameter;
- GPRS_MS_TXPWR_MAX_CCH is the maximum power that the Mobile Station can
use to access the cell; the user can define this value when configuring the
GMSTXPMAC parameter related to the Managed Object PTPPKF. This attribute spec-
ifies the maximum TX power level that a Mobile Station can use when accessing the
system in presence of the PBCCH channel. In case the PBCCH does not exist the
Mobile Station uses the MSTXPMAXCH attribute to evaluate the path loss criterion
parameter “C1” whereas the BSC uses the GMSTXPMAC attribute for the evaluation
of the same parameter. For the serving and neighbour cells the GMSTXPMAC value
is sent in broadcast on the PBCCH of the serving cell.
A30808-X3247-M24-5-7618 305
System
The path loss criterion is satisfied if C1>0.

This means that the minimum allowed received downlink level to access the network
must be above a threshold defined by GRXLAMI value.
To ensure a sufficient uplink received level even for Mobile Station 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)
For example 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
C1 = RLA_P – GPRS_RXLEV_ACCESS_MIN
For example the received level must only be higher than the access threshold
(GPRS_RXLEV_ACCESS_MIN); in this case, the nominal power of the Mobile Station
is higher than the GPRS_MS_TXPWR_MAX_CCH.
C1 criterion is an assessment about the field strengths (on both uplink and downlink
i directions).
If PBCCH is used, the C1 criterion is calculated by the same formula used in GSM, but
with a separate parameter set (for example 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 the PBCCH channel the network has the chance to indicate
in the BA(GPRS) list a different set of neighboring cells with respect to the BA list trans-
mitted on BCCH (see 10.1.4).
Beside the C1 radio criterion, there have been defined 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. C1 is greater than 0;
2. the cell belongs the selected PLMN;
3. the cell supports PS services;
4. 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 the following formula:
306 A30808-X3247-M24-5-7618
System
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)
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 struc-
tures criteria in the cell reselection. The user can define this threshold using the
GHCSTH parameter. The user defines 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 specifies it by
the GHCSTH attribute related to the PTPPKF Managed 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 attribute
related to the ADJC Managed Object;
• PRIORITY_CLASS is the priority of each cell. The user can define this priority sett-
ting the values of the GHCSPC attribute (a higher value means a 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 specifies
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, with the GHCSPC
attribute related to the ADJC Managed 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 Mobile Station 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 the GTEM-
POFF and GPENTIME attributes related to the ADJC Managed Object;
Regarding the previous parameters, it is important to underline that their values are
broadcasted on the PBCCH channel of the serving cell, for example the Mobile Station
A30808-X3247-M24-5-7618 307
System
can retrieve all of the cell re-selection information from the PBCCH of the serving cell
without monitoring the other neighboring carriers. More details about this feature are
described in the chapter: "10.1.4 Management of GPRS/EGPRS Neighboring Cells".
This is different from the standard GSM implementation for which the Mobile Station
must retrieve the cell re-selection attributes of the neighboring cells, by reading their
BCCH carriers.
C31 is used for hierarchical cell structures; the advantage is that C31 also uses a priority
i mechanism. It is necessary to introduce C31 into GPRS/EGPRS, to make re-selection
for PS services similar to the GSM handover algorithm.
The Mobile Station needs to get information of the neighbor cells (for example in which
layer the neighboring cells are laying, and the priority of the neighbor cells), to decide
about cell re-selection. For CS services, the Handover decision is done completely by
the BTS, so it is not necessary to give additional information to the Mobile Station.
10.1.2.3 C32 Criterion

The C32 cell ranking criterion is used to select those cells that have same priority. It is
defined by the following relationship:
Serving Cell:
C32(s) = C1(s)
Neighboring Cell:
PRIORITY_CLASS(n) = PRIORITY_CLASS (s)
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 define this priority
setting the values of the GHCSPC attribute (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 specifies
it setting the value of the GHCSPC attribute related to the PTPPKF Managed
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 attribute of the ADJC Managed Object;
308 A30808-X3247-M24-5-7618
System
• 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 the
GRESOFF attribute related to the ADJC Managed 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 Mobile Station 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, setting the values
by the GTEMPOFF and the GPENTIME attributed of the ADJC Managed Object.
GPRS_RESELECT_OFFSET, GPRS_TEMPORARY_OFFSET, PRIORITY_CLASS
and GPRS_PENALTY_TIME are broadcast on the PBCCH channel of the serving cell.
Regarding the previous parameters it is important to underline that their values are
broadcasted on the PBCCH of the serving cell, for example the Mobile Station can
retrieve all of the cell re-selection information from the PBCCH of the serving cell without
monitoring the other neighboring carriers. More details about this feature are described
in the chapter: "10.1.4 Management of GPRS/EGPRS Neighboring Cells". This is
different from the standard GSM implementation for which the Mobile Station shall
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
i 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
(for example the Mobile Station shall "see" that cell for that period of time before it may
re-select it; this can be used to prevent some cells from beeing re-selected by a fast
driving Mobile Station).
10.1.3 Cell Re-selection Algorithm

The Mobile Station executes a cell reselection if the following conditions are verified:
• C1 (serving cell) < 0 for a period of 5 seconds;
• Mobile Station detects DL Signaling failure (for example no paging has been
possible);
• Cell becomes barred.
Beside these conditions that regard only the serving cell, other conditions derive from
the comparison between the serving cell and the neighboring ones.
There are two different conditions:
a) Both GPRS/EGPRS serving cell and GPRS/EGPRS neighboring cells config-
ured with the BCCH channel;
b) Both GPRS/EGPRS serving cell and GPRS/EGPRS neighboring cells config-
ured with the PBCCH channel.
A30808-X3247-M24-5-7618 309
System
a) GPRS/EGPRS serving cell and GPRS/EGPRS neighboring cells configured with

the BCCH channel:
C2 (GSM) criteria is switched on; a cell reselection is executed if the following conditions
are verified:
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 serving cell) + CELL_RESELECT_HYST < C2 (suitable
GPRS/EGPRS neighboring cell)
If the suitable neighboring cell is in another location area for a period of 5 s.
The C1 value of the neighboring cell must obviously be greater than 0.
i
C2 (GSM) criteria is not switched on; a cell reselection is executed if f the following
conditions are verified:
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.
C1 (GPRS/EGPRS serving Cell) + CELL_RESELECT_HYST < C1 (suitable

GPRS/EGPRS neighboring cell)
If the suitable neighboring cell is in another location area for a period of 5 s.
The CELL_RESELECT_HYST value is defined by the user through the GSM CELL-
i RESH attribute.
b) GPRS/EGPRS serving cell and GPRS/EGPRS neighboring cells configured with

the PBCCH channel:
First, the C31 criterion for the serving cell and all neighboring cells is calculated.
The best cells are found between all of these cells, therefore the following is checked:
If there are cells for which C31>=0, then the PRIORITY_CLASS is checked only for
these cells.
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 the C32 criterion will be
calculated for these cells. The cell with the highest C32 criterion will be the best cell on
which to make the cell reselection.
If there are not 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 on which to make cell rese-
lection.
When evaluating the better cell, the following hysteresis values will be subtracted from
the C32 value of the neighboring cells:
a) in standby state, if the new cell is in the same routing area no hysteresis values are
subtracted;
310 A30808-X3247-M24-5-7618
System
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 re-
selection, since a TBF might be interrupted; the user sets this hysteresis with the
GCELLRESH attribute;.
If the C31H parameter (C31_HYST) is set to TRUE, and the Mobile Station
i 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,
because routing area changes will produce a lot of extra signaling; the user sets this
hysteresis using the RARESH attribute.
d) if 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 channel of the serving cell.
If the attribute C32QUAL (C32_QUAL) is set to TRUE, positive
i 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.
Cell re-selection for any other reason (see GSM 03.22 Recommendation) is executed
immediately, but the cell on which the Mobile Station was camped on will not be returned
to within 5 seconds, if another suitable cell can be found. If valid RLA_P values are not
available, the Mobile Station will wait until these values are available and then perform
the cell re-selection if it is required. The Mobile Station 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 will be performed. Since
information concerning a number of channels is already known by the Mobile Station, it
may assign high priority to those 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 Management of GPRS/EGPRS Neighboring Cells
10.1.4.1 Handling of Neighboring Cells

A mechanism has been introduced to manage both internal adjacent cells (cells
belonging to the same BSC) and external adjacent cells (cells belonging to other BSCs).
The management of both internal and external adjacent cells is supported configuring
the TGTCELL attribute related to the ADJC Managed Object; this attribute is mandatory
and specifies the path of the target cell instance.
Upon creating an adjacent cell relationship, a distinction is necessary between the
following two possible situations:
• adjacency between cells supporting only GSM service (adjacent relationships
between BTSs);
• adjacency between cells supporting EGPRS/GPRS service too (adjacent relation-
ships between PTPPKFs);
A30808-X3247-M24-5-7618 311
System
ADJACENT RELATIONSHIPS BETWEEN BTSs:

In case of an adjacency to an internal BTS, the TGTCELL attribute contains a reference
(for example the complete path) to the internal target BTS.
In case of external adjacency, the TGTCELL attribute contains a reference to a new
object, namely the TGTBTS Managed Object. A TGTBTS Managed Object instance
contains a copy of the attributes of an external BTS MOI, to which an adjacent relation-
ship must be made up. Once a TGTBTS MOI is configured, it is treated by the system
for the management of the adjacencies, as the other internal target BTSs.
This means that, in case the external target BTS is adjacent to more than one internal
serving BTS, it is not more necessary to replicate all the attribute values in every ADJC
Managed Object Instance, but the different ADJC MOIs refer to the same TGTBTS MOI.
Next Fig. 10.1 shows the management of adjacent cells.
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/she must specify only those attributes
that are not enclosed in BTS:2 (for example the handover management attributes), while
for the other attributes (for example the BCCH, BSIC, CELLGLID, etc.) the TGTCELL
attribute provides the reference to the BTS:2 Managed Object.
When the user creates the ADJC2 instance, he/she must specify only those attributes
that are not enclosed in the BTS:5 (for example the handover management attributes).
312 A30808-X3247-M24-5-7618
System
The TGTCELL attribute provides the reference to the TGTBTS:0 instance, that contains
all the attributes (for example: BCCH, BSIC, CELLGLID, etc.) enclosed in BTS:5.
Therefore, the user must create the TGTBTS instance containing the attributes
belonging to the external cell, before creating an external adjacent relationship.
ADJACENT RELATIONSHIPS BETWEEN PTPPKFs:

The same considerations apply for the management of the adjacencies between
PTPPKFs. The TGTPTPPKF Managed Object provides the configuration of external
EGPRS/GPRS neighboring cells in the BSC database.
TGTPTPPKF This Managed Object models external

GPRS/EGPRS neighboring cells.
Tab. 10.1 TGTPTPPKF Managed Object
The TGTPTPPKF Managed Object is hierarchically dependent on the TGTBTS

Managed Object class in the Information Model containment tree. A TGTPTPPKF
Managed Object instance contains a copy of the attributes, of an external PTPPKF
instance, involved in the management of the adjacency. Once a TGTPTPPKF Managed
Object instance is configured, it is treated by the system for the management of the adja-
cencies, as the other internal target PTPPKF Managed Objects.
Therefore:
• in case of internal adjacency, the TGTCELL attribute identifies the target PTPPKF
instance, through the reference to the superordinate BTS instance;
• in case of external adjacency, the TGTCELL identifies the TGTPTPPKF Managed
Object instance, through the reference to the superordinate TGTBTS Managed
Object instance
For each serving cell, it is possible to configure up to 32 neighboring cells supporting
i GPRS/EGPRS.
10.1.4.2 GPRS/EGPRS Neighboring Cells and Involved Parameters

As described in the previous chapters, cell re-selection attributes of both the serving cell
and its neighboring cells are transmitted on the PBCCH channel of the serving cell. In
this way, a Mobile Station camped on a cell can read all the re-selection attributes
without synchronizing to the other cells.
This happens only if the PBCCH channel 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-selec-
tion;
2. the Mobile Station takes the re-selection attributes of the neighboring cells from the
BCCHs of those cells; for example the Mobile Station shall synchronize to these
cells to read their data.
To allow the Mobile Station to read from the PBCCH of the serving cell the re-selection
attributes of the neighboring cells, the involved attributes are specified either in the
PTPPKF or in the ADJC/TGTPTPPKF Managed Objects. The Tab. 10.2 show these
attributes.
A30808-X3247-M24-5-7618 313
System
INTERNAL ETSI
GRXLAMI GPRS_RXLEV_ACCESS_MIN
GMSTXPMAC GPRS_MS_TXPWR_MAX_CCH
GHCSTH HCS_THR
GHCSPC PRIORITY_CLASS
GRESOFF GPRS_RESELECT_OFFSET
GTEMPOFF GPRS_TEMPORARY_OFFSET
GPENTIME GPRS_PENALTY_TIME
Tab. 10.2 Attributes involved in the management of EGPRS/GPRS neighboring cells
Among the attributes shown in Tab. 10.2, a distinction is necessary, as follow:

a) GRXLAMI and GMSTXPMAC attributes are only cell parameters; they must be
defined only on a cell basis, using the PTPPKF Managed Object. Nevertheless, to
allow the transmission of the neighboring cell parameters in the packet system infor-
mation of the serving cell, they are also defined for every adjacent relationship; they
must be defined in the TGTPTPPKF Managed object, only if the adjacent cell does
not belong to the same BSC of the serving one;
b) GHCSTH and GHCSPC attributes are defined both on a cell basis and on the adja-
cent relationship basis;
– they are defined on a cell basis in the PTPPKF Managed Object to define the cell
values;
– for each neighboring cell of the involved cell, the two parameters are specified in
the ADJC Managed Object, to specifies the values of the neighboring cells.
c) GRESOFF, GTEMPOFF, and GPENTIME parameters regard only adjacent relation-
ships; for each neighboring cell of the involved cell, the parameter values are spec-
ified in the ADJC Managed Object to indicate the values of the neighboring cells.
To manage the previous features, the following attribute related to the ADJC Managed
Object is involved:
• TGTCELL: When the cell is internal, this attribute allows making a link to the BTS
(PTPPKF) Managed Object that defines this cell in the database; if the cell is
external, this parameter allows to make a link to the TGTBTS (TGTPTPPKF)
Managed Object that defines this cell in the database.
10.1.4.3 Configuration of an Adjacent Cell supporting GPRS

When the PBCCH is configured on the serving cell and the user configures a neigh-
boring cell supporting GPRS the following two cases shall be considered:
1. the neighboring cell is internal;
2. the neighboring cell is external.
In the following, the cases are described considering also the GPRS/EGPRS parame-
ters shown in Tab. 10.2.
The Neighboring Cell is INTERNAL:

If the target cell is internal, the user, with TGTCELL attribute, executes a link to the BTS
object (and as a consequence to the PTPPKF one) related to this cell.
314 A30808-X3247-M24-5-7618
System
Regarding the parameters shown in Tab. 10.2, the following considerations are neces-
sary:
1. GRXLAMI and GMSTXPMAC parameters must not be defined in the TGTPTPPKF
Managed Object (because it, in this case, does not exist for the neighboring cell),
since they are cell parameters and are directly taken from the linked PTPPKF
Managed Object;
2. GHCSPC and GHCSTH parameters could be specified in the ADJC Managed
Object; if they are not specified, their default values are considered;
3. GPENTIME, GRESOFF, and GTEMPOFF parameters could be specified in the
ADJC Managed Object; if they are not specified, their default values are considered.
The Neighboring Cell is EXTERNAL:

If the target cell is external, the user, with the TGTCELL attribute, executes a link to the
TGTBTS Managed Object (and as a consequence to the TGTPTPPKF Managed
Object) related to this cell, since it does not belong to the same BSC.
Regarding the parameter shown in the Tab. 10.2, the following considerations are
necessary:
1. GRXLAMI and GMSTXPMAC parameters must be defined in the TGTPTPPKF
Managed Object: they must have the same values that have in the PTPPKF
Managed Object of the BSC database where they have been defined;
2. GHCSPC and GHCSTH parameters could be specified in the ADJC Managed
Object; if they are not specified, their default values are considered;
3. GPENTIME, GRESOFF, and GTEMPOFF parameters should be specified in the
ADJC Managed Object; if they are not specified, their default values are considered.
When the target cell is external, both RACODE and RACOLattributes (see the chapter:
i "9.2 Network Structure") shall be specified in the TGTPTPPKF Managed 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 not supporting GPRS

The EGPRS/GPRS re-selection parameters of the neighboring cell not supporting
GPRS are not transmitted in the serving cell. Besides, this cell is not included in the
GPRS BCCH Allocation list, for example the list of cells over which GPRS/EGPRS re-
selection can be done; from GSM point-of-view, the cell is always considered for cell re-
selection purposes (using GSM C1 and C2 criteria).
The following example referred to a cell (in which PBCCH is configured) that has 10
neighboring cells is considered:
In case:
– Six neighboring cells support GPRS service;
– The remaining four cells do not support GPRS service;
then starting from the serving cell:
– Six cells can be re-selected from PS/CS services point-of-view by means of C1 (with
GPRS/EGPRS parameters), C31 and C32 criteria;
– Four cells can be re-selected only from GSM Mobile Stations by means of C1 (with
GSM parameters) and C2 criteria.
A30808-X3247-M24-5-7618 315
System
In this case, BA(GPRS) list contains six cells, and a BA(GSM) list contains ten cells.
Considering the previous example, if the PBCCH is not configured in the same cell, both
i the BA(GPRS) list and the BA(GSM) list contain 10 neighboring cells
When the PBCCH is configured on the serving cell and the user configures a neigh-
boring cell which does not support GPRS service, independently if the neighboring cell
is internal or external, the EGPRS/GPRS re-selection attribute shall not be specified in
the ADJC Managed 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 the PBCCH channel
exists, an abnormal cell reselection based on BCCH Allocation (BA GPRS) list is
attempted.
For example the Mobile Station starts the “abnormal release with cell reselection” proce-
i dure after having made M+1 attempts to send a Packet Channel Request on PRACH,
without receiving any answer from the network (see the chapter: "9.8.2.6 Uplink Access
on PRACH (Access Persistence Control)").
To enable the abnormal cell re-selection, the attribute RAARET

(RANDOM_ACCESS_RETRY) is set to TRUE. This parameter allows enabling the
abnormal cell reselection starting from the serving cell, when an abnormal release with
cell reselection occurs.
In current BR8.0 Release, the attribute RAARET related to the Managed Object
PTPPKF looses its meaning due to 3GPP Recommendation. As a consequence the
fixed value 1 in PSI3 is broadcast instead of the value of the attribute RAARET. The
attribute is at the moment maintained in the BSS Information model in order to avoid
changes.
The Mobile Station executes the following algorithm to determine which cell shall be
used for this cell reselection attempt:
1. the received level measurement samples, taken on the neighboring carriers indi-
cated 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 following conditions are verified:
– 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 ((RAARET attribute 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 the steps 2.and 3.;
5. if the cells with the six strongest received average level values (and with permitted
BSICs) have been tried, but cannot be used, the abnormal cell reselection attempt
is terminated, and the usual reselection algorithm is executed (see the chapter:
"10.1.3 Cell Re-selection Algorithm").
316 A30808-X3247-M24-5-7618
System
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 attribute.
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
elapses without a successful abnormal cell reselection, the attempt is terminated and
the usual reselection algorithm is executed (see the chapter: "10.1.3 Cell Re-selection
Algorithm").
In the event of an abnormal release with cell reselection when only BCCH is ocnfigured,
the Mobile Station performs only the usual reselection algorithm, using GSM C1 and C2
criteria.
10.2 Network Assisted Cell Change

The Cell Reselection operation supported by the BSS system up to the current release
for the packed switched (PS) services causes a considerable service interruption time
because, as first activity in the target cell, the Mobile Station collects the system infor-
mation message by listening to the BCCH/PBCCH channels of the target cell before trig-
gering the data transfer. The purpose of the Network Assisted Cell Change (NACC)
feature is to reduce the service outage time during intra BSS cell re-selection of a Mobile
Station providing the system information of the target cell before performing the cell
change as long as the Mobile Station is attached to the old serving-cell. The reduction
of the service interruption is from 5 seconds up to 500-700 ms.
NACC procedure runs in all cells controlled by BSC (internal cells). If cell reselection is
performed between cells controlled by different BSC(s) (external cells), NACC feature
is not supported. Besides the Network Assisted Cell Change between GSM and UMTS
cells is not supported by the 3GPP Rel.5 standards , therefore it is not supported by
NACC feature too.
NACC procedure is structured into two main indipendent set of procedures; the first
supports the Mobile Station with neighbouring cell system information, the second
prepares the Mobile Station and puts it into the Cell Change Notification (CCN) Mode.
When the Mobile Station is in CCN mode, it informs the BSC about the proposed cell for
the cell reselection procedure. The BSC evaluates the proposed cell in order to approve
it or eventually to change the candidate cell. Besides if the system information
messages are available, the BSC provides the system information related to the chosen
cell. The evaluation about the candidate cell are provided by NACC algorithm imple-
mented in the BSC. NACC procedure manages the Mobile Station also after the cell
change, providing the required missing System Information.
The following messages exchanged between Mobile Stations and BSC have been
required by the NACC procedure:
• Packet Cell Change Notification (PCCN):
This message is sent from the Mobile Station to the BSC to inform the network that
the cell-reselection criteria are satisfied and that the Mobile Station has been
entered in “Cell Change Notification Mode”.
• Packet Cell Change Continue (PCCC):
This message is sent from the BSC to the Mobile Station to force the Mobile Station
to continue the Cell Reselection procedure towards the target cell proposed by the
Mobile Station.
A30808-X3247-M24-5-7618 317
System
• Packet Neighbor Cell Data (PNCD):

This message is sent from the BSC to the Mobile Station to provide the system Infor-
mation required for the initial access to a neighbor cell.
Besides the additional following messages are used by NACC procedure without modi-
fications:
• Packet Cell Change Order (PCCO):
This message is sent from the BSC to the Mobile Station to force the Mobile Station
to continue Cell Reselection procedure to another cell different from the one
proposed by the Mobile Station itself.
• Packet Control Ack (PCA):
This Message is sent from the Mobile Station to the BSC after the reception of the
Packet Cell Change Order or the Packet Cell Change Continue messages; the
Mobile Station may then switch towards another cell.
NACC is a distributed and concurrent internal BSC software application. Its main func-
tions are provided by functional modules implemented in PPXU boards and in TDPC
processor (version with 512 Mbyte of memory). The TDPC assumes the role of “NACC
server”, instead each PPXU board assumes the role of “NACC client”. The client has
also the task to activate the NACC algorithm each time it receives a message of “Cell
Change Notification (CCN)”.
The NACC “base” functionalities are provided by following software modules:
• Cell Change Manager (CCM):
It is implemented in each PPXU board. It assists the Mobile Station on the cell rese-
lection procedure and it manages the coexistence with other features when needed.
The coexistence derives from the fact that in the current release it is supported the
Network Controlled Cell Reselection from GSM to UMTS due to sufficient radio level
condition feature. In this case all the Mobile Stations in Packet Transfer Mode are
ordered to NC2 mode. The CCN mode requested by NACC feature is applicable only
with Mobile Stations in Packet Transfer Mode ordered to NC0 or NC1 mode, but not
to NC2 mode. In this case the NC2 mode takes the precedence over the CCN mode.
• Cell Information distribution (CID):
This functionality is implemented in TDPC processor. It is used for sending to the
PPXU the internal/external System Information and also the eventual congestion
information.
• Common Memory Storage Area (CMSA):
This Storage Area is implemented in the TDPC processor. It is used for storing the
external neighbor system information and some other information related to the
external NACC server/client and some others internal information.
• PPXU routing:
This functionality is implemented in the TDPC processor. It routes the incoming
PPXU messages to the other PPXU(s).
NACC procedure in BSC area can be enabled from the user by setting from LMT Evolu-
tion and also from the Radio Commander the attribute “CCN-active” to the value “True”.
Besides the procedure is supported in Mobile Controlled Cell reselection mode (NC1)
as well as in Network Controlled Cell reselection mode (NC2).
NACC algorithm, triggered by the reception of the Packet Cell Change Notification
(PCCN) message has the following structure, as represented in next Fig. 10.2.
318 A30808-X3247-M24-5-7618
System
BEGIN
Pccn
Measure Eval.
Is the cell No Is another Gprs

Acceptable for the Are another neighbor Cell accettable for
Reselection? Cell Available? reselection?
Yes No Yes
No
Are the Sys.Info for Are the Sys Info
the target cell available? for the target cell
Available?
No No Yes
Pncd Pncd
Pmo (Nc2)
Pccc
Pcco
END
Fig. 10.2 Network Assisted Cell Change algorithm
The following messages are exchanged:

PCCN: Packet Cell Change Notification;
PCND: Packet Neighbour Cell Data;
PCCC: Packet Cell Change Continue;
PNCD: Packet Neighbour Cell data;
PCCO: Packet Cell Change Order.
In the NACC algorithm the “Packet Cell Change Notification” message is sent by a
Mobile Station in CCN mode and with NCO = NC1.
An internal neighbor cell(i) is acceptable for the reselection procedure if the following
conditions are verified: “The C1(i) > of the value of the parameter “NCC1THADJC(i)” and
it is also > of the value of the attribute “NCC1TH(j)”. The Cell(i) is not congested, not
blocked and on it the GPRS/EGPRS services are still supported.
An external neighbor cell(j) is accettable for the reselection procedure if the following
conditions are verified: “The C1(j) > of the value of the attribute “NCC1THADJC(j)” and
in it the GPRS/EGPRS services are still supported.
The BSC configures NCO=NC1 for the Mobile Station in CCN mode only if there are not
cells available for the reselection procedure.
A30808-X3247-M24-5-7618 319
System
When a “Packet Cell Change Order” message is sent (that means that BSC has to
choose a cell available for reselection) the current Network Controlled Cell Reselection
(NCCR) algorithm has to be triggered.
For managing the NACC procedures, the Mobile Stations shall be of release “4” or
greater and of release “99”.
When the feature Network Assisted Cell Change (NACC) is enabled and the Mobile
Station is of release 4 or greater, a PMO is sent to the Mobile Station indicating NC1.
When both the features: Network Assisted Cell Change (NACC) and Network Controlled
Cell Reselection (NCCR) are enabled, a PMO is sent to the Mobile Station indicating
NC1 only if the Mobile Station is of release 4 or greater and if NCCR from GPRS to
UMTS is disabled. In all the other cases, the system always sends PMO with NC2. In
NC1 the Mobile Station can send or not the measures to the network. In case no
measures are received, NACC procedure is performed sending to the Mobile Station the
system info of the target cell provided by the Mobile Station itself. NACC is a procedure
to speed up the cell reselection process containing methods of providing neighbour cell
SI messages and CCN mode.
Due to the fact that it is not clear the behavior of the Mobile Stations on the reception of
NC1, NACC/NCCR procedures have been enhanced as follow:
• Possibility to define the usage of NC0 or NC1 in the PMO to the Mobile Station when
the NACC procedure is enabled and for Mobile Stations of release 4 or greater. The
attribute (NACC-NCO) has been implemented in the BSC Managed Object to define
the usage of NCO during NACC when the Mobile Station is in Packet Transfer
Mode. The parameter’s values are: “NC0”, “NC1”. Default value: “NC0”. The value
broadcast in the system info is always NC0. If the Mobile Station does not add
measures in the PCCN message, the network relies on the Mobile Station decision
for the target cell. For a target cell within the same BSS system the network sends
the PNCD message to the Mobile Station before sending the PCCC message,
otherwise PCCC is sent directly. If the Mobile Station adds measures in the PCCN
message, the network may influence the target cell choice for the cell reselection
procedure according to radio condition and load situation by sending the PCCO,
otherwise the PCCC is sent. Before sending PCCO or PCCC the network shall send
PNCD if system info are available;
• In case Network Controlled Cell Reselection (NCCR) is enabled, NC2 is always
used in PMO message sent to the Mobile Stations. In case also NACC is enabled it
is sent the System Info of the target cell (if available) before network controlled cell
reselection to the Mobile Stations (only for Mobile Stations that support NACC) is
triggered.
In current BR8.0 Release most of Rel 97/98 MSs does not correctly handle the Network
Controlled Order 2 (NC2). This behaviour is still accepted but no measurements are
sent to the BSC to decide on which cell the MS can be moved. As a consequence, it has
been introduced a parameter inside the system at BSC level, in order to enable or
disable the sending of Network Control Order 2 (NC2) to pre-Rel99 MSs.
In case NC2 is disabled and Network Controlled Cell reselection feature is enabled,
Network Controlled cell reselection is not executed on pre-rel99 MSs and cell reselec-
tion is done by the MS itself. In case NC2 is enabled and Network Controlled Cell rese-
lection is enabled, NC2 indication is instead sent to all MSs.
To enable/disable the sending of NC2 to pre-rel99 MSs a specific bit in BSC Mainte-
nance Bit Mask (MntBitMask) is provided.
320 A30808-X3247-M24-5-7618
System
10.3 Cell Re-selection from GSM/GPRS/EGPRS Network to

UMTS Network
With the introduction of the UMTS technology, it becomes very important to allow a dual
mode mobile station to re-select a UMTS cell starting from a GSM one.
Without this feature, once a dual mode GSM/UMTS Mobile Station 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 described in this
i chapter; the opposite case (re-selection of a GSM cell starting from the UMTS network)
is outside the scope of this manual.
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 User Equip-
ment (UE)/Mobile Station (MS) which UMTS frequencies shall 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 type of service that the MS supports and the configuration of the
serving GSM cell, two different algorithms have been implemented for reselecting a
UMTS cell (either FDD cell or TDD one), starting from a GPRS/EGPRS one; The
following re-selection procedures can therefore occur:
1. re-selection of the UMTS cell in case of circuit switched modality; this type of re-
selection 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
configured 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 channel has been
configured in the serving cell.
The two procedures are described in the next chapters.
10.3.1 GSM-UMTS Re-selection Algorithm: Circuit Switched Case

When the PBCCH channel 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 of the suitable GSM neighboring cells:

RSCP(UTRAN cell) >= RLA_C_n + XXX_Qoffset
A30808-X3247-M24-5-7618 321
System
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: It is the signal/noise ratio regarding the UMTS FDD cell;
– RLA_C_s: It is the power level received from the serving cell;
– RLA_C_n: It is the power level received from neighboring cells;
– XXX_Qoffset: It is the offset for cell reselection for UMTS cells; the user sets this
value by the FDDQOattribute related to the BTS Managed Object for FDD cells, or
by the TDDQO attribute related always to the BTS Managed Object for TDD cells;
– FDD_Qmin: It is the minimum threshold for Ec/No for UMTS FDD cell re-selection;
the user sets this value with the FDDQMIattribute related to the BTS Managed
Object.
If the 3G Cell Reselection list (sent by the network to the MS) includes UTRAN frequen-
cies, the MS updates the RLA_C value for the serving cell and each of the at least six
strongest non-serving GSM cells at least every 5 seconds.
The MS then reselects 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 fulfills the above criteria, the MS selects the cell with the
highest RSCP value.
If the MS has reselected a GSM cell from an UMTS one, cell reselection to UMTS does
not occur within 5 seconds, if a suitable GSM cell can be found.
It has been defined also a threshold by which the network indicates whether or not the
measurements for the cell reselection of the UMTS cells should be performed; this
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
attribute related to the BTS Managed Object.
FDDQO, TDDQO, FDDQMI, and QSRHI attribute are broadcast on the BCCH channel
i of the serving cell.
10.3.2 GSM-UMTS Re-selection Algorithm: Packet Switched Case

When the PBCCH channel 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 of the suitable GSM neighboring cells:

RSCP(UTRAN cell) >= RLA_P_n + XXX_GPRS_Qoffset
322 A30808-X3247-M24-5-7618
System
And also (only for FDD cells):

Ec/No (UTRAN FDD cell) >= GFDD_Qmin
where:
– RSCP (Received Signal Code Power): it is the power level received from the UMTS
cell;
– Ec/No:It is the signal/noise ratio;
– RLA_P_s:It is the power level received from the serving cell;
– RLA_P_n: It is the power level received from the neighboring cells;
– XXX_GPRS_Qoffset: It is the offset for cell reselection for FDD cells; the user sets
this value with the FDDGQO attribute related to the PTPPKF Managed Object for
FDD cells, or by the TDDGQO attribute related to the PTPPKF Managed Object for
TDD cells;
– GFDD_Qmin: It is the minimum threshold for Ec/No for UMTS FDD cell re-selection;
the user sets this value by the GFDDQMI attribute related to the PTPPKF Managed
Object.
If the GPRS 3G Cell Reselection list includes UTRAN frequencies, the MS updates the
value RLA_P for the serving cell and each of the at least six strongest non-serving GSM
cells at least every five seconds.
The MS then reselects 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 five seconds and (only in case of FDD cells)
the UTRAN cells measured Ec/No value is equal or greater than the value FDD_Qmin.
If a cell reselection occurrs within the previous 15 seconds, XXX_GPRS_Qoffset is
increased by five dB.
If more than one UMTS cell fulfills the above criteria, the MS selects the cell with the
highest RSCP value.
If the MS has reselected a GSM cell from an UMTS one, cell reselection to UMTS does
not occur within five seconds, if a suitable GSM cell can be found.
It has been defined also a threshold by which the network indicates whether or not the
measurements for the cell reselection of the UMTS cells should be performed; this
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
attribute related to the PTPPKF Managed Object.
FDDGQO, TDDGQO, GFDDQMI, and QSRHPRI parameters are broadcast on the
i PBCCH channel of the serving cell.
10.3.3 Handling of UMTS Neighboring Cells

Besides defining the re-selection criteria, the user must also define the UMTS neigh-
boring cells to be re-selected (a UMTS cell is always considered an external cell, that
means a cell that does not belong to the BSC). To define a UMTS neighboring cell for a
A30808-X3247-M24-5-7618 323
System
specific BTS object instance, the user creates an instance of the ADJC3G Managed
Object (subordinated to the BTS Managed Object).
For each BTS Managed Object instance the user can define up to 64 neighboring UMTS
i cells (ADJC3G Managed Object).
For each BTS Managed Object instance, the user can define up to 32 neighboring
GSM/GPRS/EGPRS cells (ADJC Managed Object) if there are no UMTS neighboring
cells, and up to 31 neighboring GSM/GPRS/EGPRS cells (ADJC Managed Object) if
UMTS neighboring cells are defined.
The TGTCELL attribute of the ADJC3G Managed Object contains a reference to:
• a TGTFDD Managed Object instance, in case of FDD neighboring cell; a TGTFDD
Managed Object instance contains all the parameters that allow describing the
external UMTS FDD cell in the BSC database (the same principle as described in
the chapter: "10.1.4.1 Handling of Neighboring Cells" is also used to manage
external UMTS cells).
The following attributes are the more important related the TGTFDD Managed
Object:
– CELLGLID (C-ID cell identifier): It identifies univocally the UMTS FDD cell in the
UMTS/GSM networks and it is composed by the MCC (Mobile Country Code),
MNC (Mobile Network Code), LAC (Location Area Code) and CI (Cell Identifier);
– FDDARFCN: It defines the frequency of the cell;
– RNCID: It identifies the RNC;
– FDDSCRMC: It defines the scrambling code;
– FDDDIV: indicates if diversity is applied for the cell;
• a TGTTDD Managed Object instance, in case of TDD neighboring cell; a TGTTDD
Managed Object instance contains all the parameters that allow describing the
external UMTS TDD cell in the BSC database;
The following parameters are the more important related to the TGTTDD Managed
Object:
– CELLGLID (C-ID cell identifier): it identifies univocally the UMTS TDD cell in the
UMTS/GSM networks and it is composed by the MCC (Mobile Country Code),
MNC (Mobile Network Code), LAC (Location Area Code) and CI (Cell Identifier);
– TDDARFCN: it defines the frequency of the cell;
– RNCID: it identifies the RNC;
– BNDWIDTDD: it defines the bandwidth used for TDD;
– TDDDIV: it indicates if diversity is applied for the cell.
Therefore, before creating the ADJC3G Managed Object related to an UMTS neigh-
boring cell of a specific BTS, the user must already have created either the TGTFDD or
the TGTTDD object defining the UMTS cell.
In this way, different BTS objects, that have the same UMTS cell as neighboring cell, will
indicate the same TGTFDD (or the same TGTTDD) object instance in the adjacent rela-
tionship defined by the subordinate ADJC3G Managed Object instance.
EXAMPLE: if the TGTFDD:0 instance has been created to define a UMTS cell in the
BSC database, this UMTS cell can be defined as adjacent to 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 neigh-
boring relationship towards the UMTS cell defined by the TGTFDD:0 instance, the
user sets the TGTCELL attribute equal to TGTFDD:0;
324 A30808-X3247-M24-5-7618
System
– if, for example, the ADJC3G:2 instance of the BTS:5 object represents the neigh-
boring relationship towards the UMTS cell defined by the TGTFDD:0 instance, the
user sets the TGTCELL attribute equal to TGTFDD:0.
10.4 Network Controlled Cell Reselection and Traffic Control

Management
As described in the chapter: "10.1 Cell Selection and Re-selection", the cell reselection
algorithm is executed normally by the Mobile Station (MS). Every MS in packet idle
mode and in packet transfer mode measures the received signals from both the serving
cell and neighboring cells, and performs autonomously the cell reselection procedure.
The Network Controlled Cell Reselection is an additional cell reselection method: the
network may request the measurement reports from the MSs and control their cell rese-
lection.
Therefore, if the user enables this feature, the network can ask the MS 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.
However 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 the traffic capacity might be available in neighboring cells. Therefore, if the
user enables the Traffic Control feature, the network may redistribute MSs among cells
to satisfy the maximum number of service requests. Then the Traffic Control Network
Controlled Cell Reselection can be executed.
The Traffic Control network controlled cell reselection procedure guarantees the
optimum usage of resources, for example, the better traffic distribution among the avail-
able channels in all of 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, for
example, the distribution of MSs among cells according to network criteria.
Besides:
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 also the Traffic Control controlled cell reselection, he/she
must enable the traffic control strategy besides the network controlled cell reselec-
tion,.
The procedures are described in the following chapters:
– The chapter 10.4.1 describes how the network controlled cell reselection works;
– The chapter 10.4.1.1 describes some notes about the packet measurement reports;
– The chapter 10.4.1.2 describes the Radio Link network controlled cell reselection
algorithm;
– The chapters 10.4.1 and 10.4.3.1 describe the Traffic Control strategy and the
related traffic control network controlled cell reselection algorithm.
A30808-X3247-M24-5-7618 325
System
10.4.1 Network Controlled Cell Reselection

With the support of the network controlled cell reselection procedure , the network may
request measurement reports from the MSs and control their cell re-selection.
The NTWCOR (NETWORK_CONTROL_ORDER) attribute 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 the chapter: "10.1 Cell Selection and Re-selection";
• NC1: MS control with measurement reports; the MS sends measurement reports to
the network, but it still performs autonomous cell re-selection procedure;
• NC2: network control; the MS sends measurement reports to the network, and it
does not perform autonomous cell re-selection procedure.
The NETWORK_CONTROL_ORDER attribute is broadcast from the network to all the
MSs in the cell, by means of the PSI5 message on the PBCCH channel or SI13
message on the BCCH channel. Alternatively, the network can use the
Packet_Measurement_Order or Packet_Cell_Change_Order messages sent on the
PACCH channel to address a particular MS.
To enable the Network Controlled Cell Reselection feature, the user must set the NCRE-
SELFLAG attribute belonging to the BSC Managed Object to the value: ENABLE.
When the user set the NCRESELFLAG parameter at ENABLE, only the radio link
i controlled cell reselection is enabled.
When the feature is enabled, the network can ask the MS (by setting the NTWCOR
parameter for that MS) to transmit the carrier level of both serving and adjacent cells;
then the MS sends measurement reports periodically. The period is defined by the
following 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, it has been also defined the NTWCNDRXP attribute
i that defines the minimum time the MS stays in non-DRX mode after a measurement
report has been sent with the mobile in packet idle mode; however this parameter is not
used, since MSs in packet idle mode do not send measurement reports.
GPRS and EGPRS MSs in packet idle mode always work in NC0 mode, otherwise the
network would have to manage the packet measurement reports and associated access
requests needed by MS to transmit periodically packet measurement reports. In fact,
taking into account that the longest period of transmission of packet measurement
report for MSs in packet idle mode is about 60 seconds, at least 60 channel requests
per MS per hour shall be considered only for measurement report transmission; this
would hardly increase PCU real time requirements. In addition, there are impacts even
on battery power safe.
Consequently, NC2 will be used only for MSs in packet transfer mode, which will then
submit measurement reports with the reporting period defined by the attribute
NTWCREPPTR.
Therefore, if the network controlled cell reselection is enabled (attribute NCRE-
SELFLAG set at ENABLE) the following conditions are satisfied:
The NTWCOR broadcast value (PSI5 on PBCCH channel or SI13 on BCCH channel) is
always NCO, so every MS in packet idle mode does not transmit any packet measure-
ment report to the BTS.
326 A30808-X3247-M24-5-7618
System
When a GPRS/EGPRS MS 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 MS on the PACCH channel. This message also
carries the NTWCREPPTR attribute, which overwrites the correspondent value option-
ally broadcasted by PSI5 or SI13 messages. In the Packet Measurement Order
message the NTWCNDRXP and the NTWCREPPIDL have no significant value (MS
transmits packet measurement report only in packet transfer mode).
After this change MS working in NC2 control mode periodically transmits Packet
Measurement Report messages to the 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 the needed conditions are verified (see the chapter: "10.4.1.2 Radio Link Network
Controlled Cell Reselection Algorithm" and the chapter: "10.4.3.1 Network Controlled
Cell Reselection Algorithm") the BSC may transfer the MS to another cell using a Packet
Cell Change Order message; this message contains the following information:
– characteristics of the new cell that are necessary to identify it (as the BSIC + BCCH
frequency);
– network controlled measurement attributes valid for the mobile station in the new cell
(for example the attribute NTWCREPPTR)
– IMMEDIATE_REL parameter.
Upon the reception of the Packet Cell Change Order message the MS starts the timer
T3174. When a network controlled cell reselection is executed, the MS will act upon the
IMMEDIATE_REL value which has been received in the Packet Cell Change Order. If
required, it will immediately abort any TBF in progress by ceasing to decode the down-
link and transmit on the uplink, stopping all RLC/MAC timers except the timers related
to measurement reporting, otherwise the mobile station may continue its operation in the
old serving cell until TBF end. The MS then switches to the identified new cell and will
obey the relevant RLC/MAC procedures on this new cell.
The MS considers this procedure “completed” when it has received a successful
response to its access request on the new cell.
If the 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 MS starts the T3176 timer and return to the old
cell.
If the MS was in uplink packet transfer mode or in a simultaneous uplink and downlink
packet transfer mode before the cell change, the MS will establish a new uplink TBF and
send the PACKET CELL CHANGE FAILURE message on this TBF. The mobile station
will then resume its uplink transfer on this TBF. When the mobile station has sent a
PACKET CELL CHANGE FAILURE message, the timer T3176 will be stopped. If the
timer 3176 expires and the MS was previously in an uplink packet transfer mode or in a
simultaneous uplink and downlink packet transfer mode on the old cell, the mobile
station will perform the abnormal release with random access.
If the MS was previously in a downlink packet transfer mode only on the old cell, the MS
will perform an abnormal release with return to the CCCH or PCCCH channel.
On the MS side, if the Packet Cell Change Order message instructs the MS to use a
frequency that it is not capable of using, then the mobile station will return a PACKET
CELL CHANGE FAILURE message with cause "frequency not implemented". If the
A30808-X3247-M24-5-7618 327
System
Packet Cell Change Order message is received by the MS while a circuit switched
connection is on-going, then the MS will 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
system will signal this exception condition to a SGSN network node by sending a
RADIO-STATUS PDU message (Radio Cause value: cell reselection ordered). It
contains 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 system.
When the MS changes the cell, it starts a cell update procedure or a routing area update
procedure towards the SGSN network node.
After this procedure, the SGSN transmits the FLUSH_LL message towards the 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 node, indicating if re-route or
discard is made. It is responsibility of the higher layer protocols in the SGSN node to
cope with discarded LLC frames. If new cell belongs to another SGSN, an inter_SGSN
routing area update is required before the TBF starts in the new cell as shown in the
Fig. 10.3.
Before ending the TBF, the BSC changes the network control mode to NC0, so when
this MS enters the packet idle mode, it no longer transfers packet measurement reports.
MS BSC SGSN
Packet Cell Change Order
Start T3174
Radio Status
Cell Change
Packet Channel Request
Packet Uplink Assignment

Stop T3174
RLC Block
RLC Block
LLC (Cell Update)
Flush LL
Fig. 10.3 Network Controlled Cell Reselection Procedure
328 A30808-X3247-M24-5-7618
System
10.4.1.1 Measurement Reporting

At the end of each reporting period defined by the NTWCREPPTR attribute, the MS
sends a measurement report to the BSS system.
The MS then discards any previous measurement report, that it has not been able to
send. The Packet Measurement Report contains the following information:
– RXLEV for the serving cell;
– Received signal level for the non-serving cells.
For normal measurement reporting, carriers will be reported if they are among the six
strongest carriers and BSIC is successfully decoded and allowed, for example, either
equal to the BSIC of the list or with allowed NCC part of BSIC. In the latter case, which
applies for BCCH Allocation list where no BSIC is given, the decoded BSIC will be
included in the report.
In the case of a multiband MS, the MS reports the number of the strongest BCCH
carriers in each band as indicated by the GNMULBAC attribute , broadcast on the
PBCCH, or it does not exist, on the BCCH channel.
For multi-RAT MS, the MS reports the number of valid cells in each other radio access
technology as indicated by the specific attributes: GFDDMURREP (GPRS FDD
MULTIRAT REPORTING) and GTDDMURREP (GPRS TDD MULTIRAT REPORTING).
These attributes define the number of valid UMTS neighbor cells (FDD and TDD) which
will be reported by the MS/UE. The remaining positions in the measurement report are
used for reporting of GSM cells. If remaining positions still exist, these will be used to
report the next 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 compar-
! ison with the GSM received level because the Ec/No is a quality parameter and not a
received level parameter.
Therefore, the GFDDREPQTY attribute (FDD_REP_QUANT) has been introduced in
order to inform the GPRS/EGPRS attached MS/UE whether to report the RSCP value
(GFDDREPQTY=RSCP) or the Ec/No value (GFDDREPQTY=EC_NO) to the BTS.
10.4.1.2 Radio Link Network Controlled Cell Reselection Algorithm

When the network controlled cell reselection has been enabled (the NCRESELFLAG
attribute has been set by the user to the value: ENABLE) the radio link controlled cell
reselection algorithm is executed by the BSC.
The algorithm runs independently if the GPRS/EGPRS control strategy (see the
i chapter: "10.4.3 GPRS/EGPRS Traffic Control Strategy") has been enabled by the
user.
When the radio conditions of the MS are degraded, the BSC chooses a better neigh-
boring cell and triggers that MS to move on this new cell.
According to the chapter: "10.4.1 Network Controlled Cell Reselection", the MS sends
measurement reports to the BSC; when the BSC receives a packet measurement report
from a MS, 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.
A30808-X3247-M24-5-7618 329
System
The C1 value for both serving and neighboring cells is calculated with the following
formula:
C1 = RLA_P – GPRS_RXLEV_ACCESS_MIN – Max( 0,

GPRS_MS_TXPWR_MAX_CCH – P)
In which:
- 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 attribute (for the serving cell this
parameter is set in the PTPPKF Managed Object, for neighboring cells it is set in the
TGTPTPPKF Managed Object);
- 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 attribute (for the
serving cell this parameter is set in the PTPPKF Managed Object, for neighboring cells
it is set in the TGTPTPPKF Managed Object.
If C1(s) < NCC1TH, the MS shall be moved to another cell, to avoid loosing it.
The PKTMEASREPCNT attribute specifies how many consecutive measurements of
i 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.
Besides the BSC triggers following checks at the reception of a packet measurement
report from the MS:
In case the target cell is on the same PCU of the serving cell:
• C1(j) > NCC1THADJC(j) and C1(j) > NCC1TH(j) and cell(j) is not congested and
cell(j) is not blocked (or locked) and on cell(j) the GPRS is still supported and
ping_pong effect is not present.
In case the target cell is on different PCU:
• C1(j) > NCC1THADJC(j) and cell(j) is not congested and cell(j) is not blocked (or
locked) and on cell(j) GPRS is still supported and ping_pong effect is not present.
If the target cell is on different BSC:
• C1(i) > NCC1THADJC(i) and on cell(i) GPRS is still supported and ping_pong effect
is not present.
Then, according to the value of the NCSARA attribute, the selected cells are ordered
respecting different priorities.
If NCSARA = TRUE, the adjacent cell is searched, before, among cells belonging to the
same routing area of the serving cell; therefore the following priorities are used to order
cells:
1. target cell with the same Routing Area on the same PPXU;
2. target cell with different Routing Area but on the same PPXU;
3. target cell with the same Routing Area on different PPXU and same BSC;
4. target cell with different Routing Area on different PPXU and same BSC;
5. target cell on different PPXU and different BSC.
330 A30808-X3247-M24-5-7618
System
If NCSARA = FALSE, adjacent cells of the same routing area have no priority compared
to adjacent cells of other routing areas; therefore 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;
2. target cell on different PPXU and same BSC;
3. target cell on different PPXU and different BSC.
Among neighboring cells with the same priority, the cell with the highest C32(n) value is
chosen. The C32(n) value is calculated by the following formulas:

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)
In which:
• NC_GPRS_RESELECT_OFFSET(n) is a positive offset that increases the priority
of the selected cell in the list of the strongest neighbor cells. The user sets a
NC_GPRS_RESELECT_OFFSET(n) value for every adjacent relationship, by the
NCGRESOFF attribute of the ADJC Managed 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 six 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 NCGTEM-
POFF and NCGPENTIME attributes related to the ADJC Managed Object.
When NCSARA is set at FALSE, a hysteresis value is subtracted from the C32 value for
the neighbor cells. The hysteresis value can be set by the user via the NCRARESH
attribute related to the PTPPKF Managed Object. NCRARESH must be set at DB00
(default value) when NCSARA is set to the value: TRUE.
Moreover, in order to prevent “ping_pong” effect due to particular MS behaviour during
Network Controlled Cell Reselection, the TRFPSCTRL attribute of the PTPPKF
Managed Object is used to avoid too frequent cell reselection of the same adjacent
cell.To this end the BSC does not order to the MS to move again into the same adjacent
target cell where a NCCR failed,in spite of good radio link scenario until the timer TRFP-
SCTRL is expired and the following relationship is satisfyed:
– STGTTLLIINF > TRFPSCTRL
If the STGTTLLIINF attribute is set to NULL, no TBF temporary data is stored and there-
i fore the ping pong NCCR cannot be avoided.
10.4.2 NC Cell Reselection due to sufficient UMTS coverage

Up to the current release the GSM/GPRS to UMTS cell reselection can only be triggered
by the Mobile Station/User Equipment itself and not by the network. As a consequence
the inter-system cell reselection is "Mobile Station/User Equipment controlled“ and not
A30808-X3247-M24-5-7618 331
System
"Network Controlled“. Network Controlled (NC) cell reselection is only performed by

means of the GSM radio access technology (RAT) and not between different RATs. This
means that the Network Controlled Cell Reselection is not performed between the GSM
system and the UMTS system.
The BSS system supports the Network Controlled cell reselection from GSM/GPRS
(including also the E-GPRS technology) to UMTS, which is abbreviated as "NCCR G-
>U" within this BSS technical description. This NCCR G->U performs a network
controlled inter-system cell change for a Mobile Station/User Equipment in packet
transfer mode, for Packet Switched (PS) services only.
The network controlled inter-system cell change has been supported only for a Mobile
Station/User Equipment in dedicated mode; this means for Circuit Switched (CS)
services as specified in the feature "Handover (circuit switched) from GSM to UMTS".
The thresholds for "sufficient UMTS coverage" for Packet Switches (PS) services and
for Circuit Switches (CS) services can be set independently by the user. The main objec-
tive of the new Network Controlled Cell Reselection from GSM/GPRS to UMTS due to
sufficient UMTS coverage is to perform a cell reselection to the UMTS system as soon
as possible,that means as soon as the UMTS measurement quantity (for example:
RSCP or Ec/No for FDD cells, RSCP for TDD cells) exceeds a "sufficient" threshold in
order to direct as much Packed Switched traffic as possible towards the UMTS cells in
areas which provides "sufficient" UMTS coverage.
By means of the functions provided by this feature the customers can offer an UMTS
connectivity to its end users (with the only precondition to be equipped with a dual mode
GSM/UMTS Mobile Station) as soon as an user reaches a region with a sufficient UMTS
coverage.
In the following Fig. 10.4 it is represented a simplified network architecture for a
combined GSM/GPRS-UMTS mobile network.
Gb Iu
2G/3G Combined Core
Network
BSC RNC
Abis Iub
Bts NodeB
Mobile Station/User Equip.
Abis Uu
Fig. 10.4 Combined GSM/UMTS Network Architecture
The Network Controlled Cell Selection procedures are triggered by the BSC that forces
a Mobile Station/User Equipment to work in NC2 mode. For the purpose the BSC sends
the message:”Packet Measurement Order” containing the NC2 parameter.A Mobile
Station/User Equipment in Network Controlled Cell Reselection Mode (or in NC1 mode
as requested by the NACC feature, see the chapter: "10.2 Network Assisted Cell
Change" sends back periodically to the BSC the message: “Packet Measurement
332 A30808-X3247-M24-5-7618
System
Report”. This message stores the GSM cells’ identifiers (serving and neighbour cells)
that are evaluated by the Network Controlled Cell Selection algorithm embedded in the
BSC software.
By means of the results of these evaluations the NCCR algorithm selects a GSM neigh-
bour cell that is defined as the target cell for the Network Controlled cell reselection. At
this point the BSC activates the NCCR procedures by sending the “Packet Cell Change
Order” message (including in it the new selected GSM target cell) to the Mobile
Station/User Equipment.
In the following section of this chapter the main functions and the message flows needed
for the execution of the NCCR G -> U procedure are described.
1) Triggering of a Network Controlled Cell Reselection from GSM/GPRS to UMTS:
The NCCR G->U is triggered by the BSC that sends a “PACKET CELL CHANGE
ORDER” message with the UMTS target cell to the Mobile Station/User Equipment.This
switches to the UMTS cell and it stops its transmission to the GSM/GPRS mobile
network. A Mobile Station/User Equipment in Network Controlled cell reselection mode
(or in NC1 mode) sends periodically the PACKET MEASUREMENT REPORT
messages to the BSC. The NCCR algorithm embedded in the BSC software evaluates
the measurements of the GSM cells (serving cell and neighbour cells) which are
contained in these PACKET MEASUREMENT REPORT messages. Based on these
evaluations, the NCCR algorithm selects a GSM neighbour cell as a target cell for the
Network Controlled cell reselection. As a consequence the BSC triggers the NC cell
reselection procedure by sending a PACKET CELL CHANGE ORDER message
(including this GSM target cell) to the Mobile Station/User Equipment. The NCCR G->G
functionality is the precondition for the related NCCR G->U procedure. The following
BSC functions have been implemented in the current BR8.0 release in order to support
the NCCR G->U procedure.
Some of this functions have been already implemented in the previous releases (for
i example in the BSS BR7.0 release) because of other additional BSS features.This
condition is clearly stated in the description, where necessary.
• UMTS neighbour cells are stored in the BSC data base:

The inclusion of UMTS neighbour cells in the BSC database is already implemented
because of the already introduced features MS/UE controlled cell reselection from GSM
to UMTS.
• Certain Packet System Information (PSI) and System Information (SI) messages shall
be broadcasted in order to inform the MS/UE about UMTS neighbour cells and about
specific UMTS related measurement parameters:
The Broadcasting of the necessary Packet System Information (PSI) and System Infor-
mation (SI) messages has been already implemented because of the introduced
features MS/UE controlled cell reselection from GSM to UMTS, Handover (circuit
switched) from GSM to UMTS and "GPRS: Network Controlled cell reselection”. Specific
UMTS related measurement parameters which are required for the NCCR G->U are
added in these SI and PSI messages.
• Evaluation of 3G measurements of 3G neighbour cell:
The BSC evaluates the 3G measurements of the 3G neighbour cells (UMTS cells) which
the MS/UE sends to the BSC within the PACKET MEASUREMENT REPORT message.
• Enhancement of the current NCCR G->G algorithm embedded in the BSC software:
A30808-X3247-M24-5-7618 333
System
The NCCR G->G algorithm has been enhanced. See the chapter:
"10.4.2.1 Enhancement of the NCCR G->G algorithm".
• Support of the O&M parameters:
All the requested O&M parameters are supported by the BSC data base, by the LMT
Evolution connected to the BSC and also by the Network Management Systems ( Radio
Commander and O&M Tool Set).
2) “Routing Area Update Request” Message:
The Mobile Station/User Equipment sends a message: “Routing Area Update Request”
(P-TMSI, old RAI, old P-TMSI Signature, Update Type, CM, MS Network Capability) to
the 3G-SGSN to which the UTRAN subnetwork is connected. The Update Type indi-
cates RA update or combined RA / LA update, or, if the Mobile Station/User Equipment
wants to perform an IMSI attach, combined RA / LA update with IMSI attach requested,
and also if the Mobile Station/User Equipment has a follow-on request, for example if
there is pending uplink traffic (signaling or data). The SGSN may use, as an implemen-
tation option, the follow-on request indication to release or keep the Iu connection after
the completion of the RA update procedure. The SRNC adds the Routing Area Identity
including the RAC and LAC parameters of the area where the Mobile Station/User
Equipment is located before forwarding the message to the 3G SGSN. This RA identity
corresponds to the RAI in the MM system information sent by the SRNC to the MS/UE
[as sepecified in the Recommendation TS 23.060].The BSS system is not involved in
this phase.
3) SGSN Context Request (3G-SGSN -> 2G-SGSN):
The new 3G SGSN uses the old RAI received from the MS to derive the old 2G SGSN
address, and it sends a SGSN Context Request (old RAI, old P-TMSI, New SGSN
Address) message to the old 2G SGSN to get the MM and PDP contexts for the Mobile
Station/User Equipment. If the new SGSN provides functionality for the Intra Domain
Connection of RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old
SGSN from the old RAI and the old P-TMSI and it sends the SGSN Context Request
message to this old SGSN. Otherwise, the new SGSN derives the old SGSN from the
old RAI. In any case the new SGSN will derive an SGSN that it believes is the old SGSN.
This derived SGSN is itself the old SGSN, or it is associated with the same pool area as
the actual old SGSN and it will determine the correct old SGSN from the P-TMSI and
relay the message to that actual old SGSN. The old 2G-SGSN validates the old P TMSI
Signature and responds with an appropriate error cause if it does not match the value
stored in the old 2G SGSN. If the received old P-TMSI Signature does not match the
stored value, the old 2G-SGSN initiates the security functions in the new 3G-SGSN. If
the security functions authenticate the Mobile Station/User Equipment correctly, the new
3G-SGSN sends a SGSN Context Request (old RAI, IMSI, Mobile Station/User Equip-
ment, Validated, New SGSN Address) message to the old 2G-SGSN. The Mobile
Station/User Equipment Validated indicates that the new 3G-SGSN has authenticated
the Mobile Station/User Equipment. If the old P TMSI Signature was valid or if the new
3G-SGSN indicates that it has authenticated the MS/UE correctly, the old 2G SGSN
starts a timer and stops the transmission of N-PDUs to the Mobile Station/User Equip-
ment. [As specified in the Recommendation TS 23.060]. The BSS system is not involved
in this phase.
4) SGSN Context Response (3G-SGSN <- 2G-SGSN):
The old 2G SGSN responds with an SGSN Context Response (MM Context, PDP
Contexts) message.Each PDP Context includes the GTP sequence number for the next
334 A30808-X3247-M24-5-7618
System
downlink N-PDU to be sent to the MS/UE and the GTP sequence number for the next
uplink N-PDU to be tunnelled to the GGSN. Each PDP Context also includes the
SNDCP Send N-PDU Number for the next downlink N-PDU to be sent in acknowledged
mode SNDCP to the MS/UE and the SNDCP Receive N-PDU Number for the next uplink
N-PDU to be received in acknowledged mode SNDCP from the MS/UE. The new 3G-
SGSN derives the corresponding PDCP sequence numbers from these N-PDU
sequence numbers by adding eight most significant bits "1". These PDCP sequence
numbers are stored in the 3G-SGSN PDP contexts. The new 3G-SGSN ignores the
Mobile Station Network Capability contained in the MM Context of the SGSN Context
Response only when it has previously received a MS Network Capability in the Routing
Area Request [TS 23.060]. The BSS system is not involved in this phase.
5) Security Management functions:
Security management functions are implemented according to the TS 23.060 Recom-
mendation. The BSS system is not involved in this phase.
6) SGSN Context Acknowledge (3G-SGSN -> 2G-SGSN):
The new 3G SGSN sends a message: SGSN Context Acknowledge to the old 2G
SGSN. This informs the old 2G SGSN that the new 3G SGSN is ready to receive data
packets that belongs to the activated PDP contexts. The old SGSN marks in its context
that the MSC/VLR association and the information in the GGSNs and the HLR are
invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the Mobile
Station/User Equipment initiates a routing area update procedure back to the old SGSN
before completing the ongoing routing area update procedure. The BSS system is not
involved in this phase.
7) Forward packets (2G-SGSN -> 3G-SGSN):
The old 2G SGSN duplicates the buffered N-PDUs and starts tuneling them to the new
3G-SGSN. Additional N-PDUs received from the GGSN before the timer described in
step 3 expires are also duplicated and tunelled to the new 3G SGSN. N-PDUs that were
already sent to the Mobile Station in acknowledged mode SNDCP and that are not yet
acknowledged by the Mobile Station are tunnelled together with their related SNDCP N-
PDU sequence number. No PDCP sequence numbers shall be indicated for these N-
PDUs. No N-PDUs shall be forwarded to the new 3G SGSN after the expiring of the
timer described in: 3) SGSN Context Request (3G-SGSN -> 2G-SGSN).The BSS
system is not involved in this phase.
8) Update PDP Context (3G-SGSN <-> GGSN):
The new 3G SGSN sends an Update PDP Context Request (new SGSN Address, TEID,
QoS Negotiated) message to each GGSN concerned. Each GGSN updates its PDP
context fields and returns an Update PDP Context Response (TEID) message.The BSS
system is not involved in this phase.
9) Update GPRS Location (3G-SGSN -> HLR):
The new 3G SGSN informs the HLR of the change executed by the SGSN by sending
an Update GPRS Location (SGSN Number, SGSN Address, IMSI) message to the HLR.
The BSS system is not involved in this phase.
10) Cancel Location (HLR <-> 2G-SGSN):
The HLR sends a Cancel Location (IMSI, Cancellation Type) message to the old 2G
SGSN. The old 2G SGSN removes the MM and PDP contexts if the timer described in
step 3 is not running. If the timer is running, the MM and PDP contexts are removed
A30808-X3247-M24-5-7618 335
System
when the timer expires. The old 2G SGSN acknowledges with a Cancel Location Ack
(IMSI) message. The BSS system is not involved in this phase.
11) Insert Subscriber Data (HLR <-> 3G-SGSN):
The HLR sends an Insert Subscriber Data (IMSI, GPRS Subscription Data) message to
the new 3G SGSN. The 3G SGSN constructs an MM context for the Mobile Station and
returns an Insert Subscriber Data Ack (IMSI) message to the HLR.The BSS system is
not involved in this phase.
12) Update GPRS Location Ack (3G-SGSN <- HLR):
The HLR acknowledges the Update GPRS Location (step 9) by returning an Update
GPRS Location Ack (IMSI) message to the new 3G SGSN.The BSS system is not
13) Location Update Request (3G-SGSN -> VLR):
If the association has to be established, if Update Type indicates combined RA/LA
update with the IMSI attach requested, or if the LA changed with the routing area update,
the new SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Loca-
tion Update Type) to the VLR. Location Update Type shall indicate IMSI attach if Update
Type in step 2 indicated combined RA/LA update with IMSI attach requested. Other-
wise, Location Update Type shall indicate normal location update. When the SGSN
does not provide functionality for the Intra Domain Connection of RAN Nodes to Multiple
CN Nodes, the VLR number is derived from the RAI. When the SGSN provides function-
ality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the SGSN uses
the RAI and a hash value from the IMSI to determine the VLR number. The 3G SGSN
starts the location update procedure towards the new MSC/VLR upon receipt of the first
Insert Subscriber Data message from the HLR in step 11. The VLR creates or updates
the association with the 3G SGSN by storing SGSN Number. The BSS (GSM) is not
14) Update Location (new VLR <-> HLR <-> old VLR):
If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR
informs the HLR. The HLR cancels the old VLR and inserts the subscriber data in the
new VLR: The new VLR sends an Update Location (new VLR) to the HLR. The HLR
cancels the data in the old VLR by sending a Cancel Location (IMSI) to the old VLR. The
old VLR acknowledges with Cancel Location Ack (IMSI). The HLR sends Insert
Subscriber Data (IMSI, subscriber data) to the new VLR. The new VLR acknowledges
with Insert Subscriber Data Ack (IMSI). The HLR responds with Update Location Ack
(IMSI) to the new VLR. The BSS (GSM) system is not involved in this phase.
15) Location Update Accept (3G-SGSN <- new VLR):
The new VLR allocates a new TMSI and responds with a Location Update Accept (VLR
TMSI) to the 3G SGSN.The VLR TMSI is not mandatory if the VLR has not changed.
The BSS system is not involved in this phase.
16) Routing Area Update Accept (MS/UE <- 3G-SGSN ; sent via UMTS cell):
The new 3G SGSN validates the MS/UE's presence in the new RA. If due to roaming
restrictions the MS is not allowed to be attached in the RA, or if subscription checking
fails, the new 3G SGSN rejects the routing area update with an appropriate cause. If all
checks are successful, the new 3G SGSN constructs MM and PDP contexts for the
MS/UE. The new 3G SGSN responds to the Mobile Station with a Routing Area Update
Accept (P TMSI, P TMSI signature) message. The BSS system is not involved in this
phase.
336 A30808-X3247-M24-5-7618
System
17) Routing Area Update Complete (MS/UE -> 3G-SGSN ; sent via UMTS cell):
The Mobile Station/User Equipment acknowledges the new P-TMSI by returning a
Routing Area Update Complete message to the 3G-SGSN. The BSS system is not
18) TMSI Reallocation Complete (3G-SGSN -> VLR):
The new 3G SGSN sends TMSI Reallocation Complete message to the new VLR. The
BSS system is not involved in this phase.
19) Service Request (MS/UE -> 3G-SGSN):
If the Mobile Station /User Equipment has uplink data or signaling pending it shall send
a Service Request (P-TMSI, RAI, CKSN, Service Type) message to the 3G-SGSN.
Service Type specifies the requested service. Service Type indicates one of the
following: Data/Signaling.The BSS system is not involved in this phase.
20) RAB Assignment Request / Response (3G-SGSN <-> SRNS):
If the Mobile Station/User Equipment has sent the Service Request, the new 3G SGSN
requests the SRNS to establish a radio access bearer by sending a RAB Assignment
Request (RAB ID(s), QoS Profile(s), GTP SNDs, GTP SNUs, PDCP SNUs) message to
the SRNS. The PDCP sequence numbers are derived from the N PDU sequence
numbers in step 4 and stored in the SGSN PDP contexts.The SRNS sends a Radio
Bearer Setup Request (PDCP SNUs) message to the MS/UE. The MS/UE responds
with a Radio Bearer Setup Complete (PDCP SNDs) message. The MS/UE deducts
PDCP-SND from its Receive N PDU Number by adding eight most significant bits "1".
The SRNS responds with a RAB Assignment Response message. The SRNS shall
discard all N PDUs tunnelled from the SGSN with N PDU sequence numbers older than
the eight least significant bits of the PDCP SNDs received from the MS/UE. Other N
PDUs shall be transmitted to the MS/UE. The MS/UE shall discard all N PDUs with
SNDCP sequence numbers older than the eight least significant bits of the PDCP SNUs
received from the SRNS. Other N PDUs shall be transmitted to the SRNS. The SRNS
negotiates with the MS/UE for each radio bearer the use of lossless PDCP or not regard-
less whether the old 2G-SGSN used acknowledged or unacknowledged SNDCP for the
related NSAPI or not. If the new SGSN is unable to update the PDP context in one or
more GGSNs, the new SGSN shall deactivate the corresponding PDP contexts as
described in subclause "SGSN-initiated PDP Context Deactivation Procedure". This
shall not cause the SGSN to reject the routeng area update. The PDP Contexts shall be
sent from the old to the new SGSN in a prioritized order,for example the most important
PDP Context first in the SGSN Context Response message. If the new SGSN is unable
to support the same number of active PDP contexts as received from the old SGSN, the
new SGSN should use the prioritization sent by the old SGSN as input when deciding
which PDP contexts to maintain active and which ones to delete. In any case, the new
SGSN shall first update all contexts in one or more GGSNs and then deactivate the
context(s) that it cannot maintain. This shall not cause the SGSN to reject the routing
area update. The BSS system is not involved in this phase.
10.4.2.1 Enhancement of the NCCR G->G algorithm

The algorithm supporting the procedures for the NCCR G->G is described in the
chapter: "10.1.3 Cell Re-selection Algorithm". This algorithm has been enhanced in the
current BSS BR 8.0 Release for supporting the procedures for the Network Controlled
Cell Selection from GSM/GPRS to UMTS due to sufficient UMTS coverage.
A30808-X3247-M24-5-7618 337
System
The Network Controlled Cell Reselection from a GSM/GPRS serving cell to an UMTS
neighbour cell (both FDD and TDD) is triggered if the following conditions are met:
• The threshold condition for "sufficient UMTS coverage" is met:
• The parameter “EnableUmts_SuffCov_NC_Resel” is set to Enable
• The Network Controlled GSM/GPRS to GSM/GPRS cell reselection algorithm of the
BSC is enabled for example the parameter “NCRESELFLAG” is set to ENABLE.
• The BSC has received information that the Mobile Station/User Equipment supports
the UMTS technology (FDD or TDD) of this UMTS neighbour cell.
In addition if also the Mobile Speed Sensitive (MSS) Network Controlled Cell Reselec-
tion to UMTS microcells is enabled the following further condition has to be verified:
• An UMTS neighbour cell, which is defined as a microcell shall only be included in
the UMTS Target Cell List (TCL) if this UMTS microcell fulfills the condition for the MSS
NC GSM/GPRS to UMTS cell reselection.
The condition for triggering the NCCR G->U procedure is the following:
For an UMTS TDD neighbour cell:
UMTS_MeasQuant(n) > UmtsSuff_RSCP_NC_Resel
“UMTS_MeasQuant(n)" denotes the UMTS measurement quantity of the UMTS neigh-
bour cell (n) which is reported by the Mobile Station/User Equipment in the message:
Packet Measurement Report. For UMTS TDD cells, the UMTS measurement quantity
"RSCP" is reported by the Mobile Station/User Equipment.
For an UMTS FDD neighbour cell the parameter “FDD_REP_QUANT” informs the
MS/UE whether to report the parameters "RSCP" or "Ec/No" in the message: PACKET
MEASUREMENT REPORT.
For RSCP reporting:
UMTS_MeasQuant(n) > UmtsSuff_RSCP_NC_Resel
For Ec/No reporting:
UMTS_MeasQuant(n) > UmtsSuff_EcNo_NC_Resel
The parameters “UmtsSuff_RSCP_NC_Resel”, “UmtsSuff_EcNo_NC_Resel” are
configurable by the user from the LMT Evolution or from the Radio Commander.
When all the above conditions are met the BSC generated an UMTS Target Cell List
(TCL) for the related Mobile Station User Equipment. This list stores all the potential
UMTS neighbor cells (both TDD and FDD) to which the NCCR G->U procedure can be
applied. The list is then sorted by the BSC according to RSCP; the TDD cell with the
highest RSCP value are sorted to the top of the TDD sublist.The FDD sublist is sorted
according to RSCP or according to the Ec/No, depending on the parameter
“FDD_REP_QUANT”. If RSCP reporting is used, the FDD cell with the highest RSCP
value shall be sorted to the top of the FDD sublist. If Ec/No reporting is used, the FDD
cell with the highest Ec/No value is sorted to the top of the FDD sublist. In order to
complete the list the FDD sublist is sorted before the TDD sublist, because FDD cells
has a higher priority than TDD cells.
When the list is completed the BSC includes the UMTS neighbour cell on the top of the
TCL list within the message: “Packet Cell Change Order” that is then sent to the o Mobile
Station/User Equipment.
In case the commanded change cell order has failed the MS/UE sends back the
message: “Packet Cell Change Failure with UMTS cell” to the BSC. The BSC supports
338 A30808-X3247-M24-5-7618
System
the reception of the cell description (FDD, TDD) contained in the message and it sends
again to the same MS/UE the message: “Packet Cell Change Order”. For avoiding
excessive repetitions of the message in case of consecutive failures the following mech-
anism has been implemented.
When the BSC has received the message:“Packet Cell Change Failure” with inside an
UMTS cell description from a Mobile Station/User Equipment. The BSC triggers the
timer: “Timer_Fail_NC_Umts” for this Mobile Station/User Equipment. Until expiry of this
timer, this UMTS cell shall be excluded from the UMTS target cell list (TCL). After the
expiration of the timer the UMTS cell is included again in the list if the preconditions for
the execution of the NCCR G->U are still met. When the BSC has repeated the sending
of the message: “PACKET CELL CHANGE ORDER” and again it receives a “PACKET
CELL CHANGE FAILURE” message (containing the same UMTS cell description), the
BSC restarts the timer Timer_Fail_NC_Umts for this MS/UE and shall again exclude this
UMTS cell from the UMTS TCL until the expiring of the timer.
The maximum number of these consecutive repetitions of the messages: “PACKET
CELL CHANGE ORDER” is limited by the parameter: “Max_Fail_NC_Umts”.For
example when the number of retries has reached the Max_Fail_NC_Umts parameter,
no more NCCR retries shall be performed to this UMTS neighbour cell for this connec-
tion of the Mobile Station/User Equipment.
The parameters: “Timer_Fail_NC_Umts, Max_Fail_NC_Umts” are configurable by the
user from the Radio Commander and from the LMT Evolution.
Also a fast ping-pong back cell reselection shall be avoided. For example it has to be
avoided that a Mobile Station/User Equipment, which just arrived in a GSM/GPRS cell,
is immediately Network Controlled cell reselected to UMTS as follow:
When a MS/UE (in packet transfer mode) has reselected to a GSM/GPRS cell, the BSC
triggers the timer: “Timer_Back_NC_Umts”. related to this MS/UE. Until this time has
expired , NC GSM/GPRS to UMTS cell reselection are not executed for this MS/UE.
The BSC does not know from which cell the MS/UE has performed the cell reselection.
i In particular, the BSC has no information whether the MS/UE has reselected from an
UMTS cell or from a GSM cell. In any case the timer is triggered.
The parameter: “Timer_Back_NC_Umts” is configurable by the user from the LMT

Evolution or from the Radio Commander.
The BSC does not execute NC cell reselection from a GSM/GPRS serving cell to an
UMTS microcell for a "fast moving" MS/UE. The Mobile Speed Sensitive (MSS) cell
reselection to UMTS microcells can be enabled/disabled by means of the parameter:
“EnableUmts_MSS_NC_Resel”.
In the context of NCCR G->U, an UMTS microcell is defined as an UMTS neighbour cell
for which the parameter "GPRS_micro cell_Umts" is set to the value: “TRUE”.
The prefix "GPRS_" is included in the parameter name in order to distinguish this param-
eter from the parameter "MICROCELL" which is already used in case of Mobile Speed
Sensitive GSM to UMTS handover. The parameter "GPRS_micro cell_Umts" can be set
independently from the parameter "MICROCELL"; this has the advantage that UMTS
microcells for "NC GSM/GPRS to UMTS cell reselection" (packet switched services)
and for "GSM to UMTS Handover" (circuit switched services) can be independently
defined.
When the threshold condition for "sufficient UMTS coverage" is verified for an UMTS
microcell, the BSCl activates the timer: “Timer_UE_Speed” for this UMTS microcell.
A30808-X3247-M24-5-7618 339
System
Until the expiration of this timer, NC GSM/GPRS cell reselection to this UMTS microcell
is inhibited for this MS/UE; for example this UMTS microcell will not be included in the
UMTS TCL.
If the threshold condition for "sufficient UMTS coverage" is violated before the expiration
of the timer, the timer is stopped and reset. When the threshold condition for "sufficient
UMTS coverage" is met again, the timer (which was reset before) is restarted again. The
UMTS microcell is only included in the UMTS TCL, if the threshold condition for "suffi-
cient UMTS coverage" is met during the whole time period "Timer_UE_Speed", because
this means that the speed of the MS/UE is low and therefore the MS/UE location is still
within the coverage area of the UMTS microcell.
A "fast moving" Mobile Station/User Equipment violates this timer condition of the UMTS
microcell, and therefore this UMTS microcell is not included in the UMTS Target Cell List
(TCL). For example NC cell reselection from a GSM/GPRS serving cell to this UMTS
microcell is not performed for this "fast moving" Mobile Station/User Equipment.
The parameters: “EnableUmts_MSS_NC_Resel”, “Timer_UE_Speed”, “GPRS_micro
cell_Umts” are configurable by the user from the Radio Commander and from the O&M
Tool Set.
In addition the attribute “MsTxPmaxUmts” related to the Managed Objects “TGTFDD”
and “TGTTDD” which has been implemented in the BSS system starting from the BR
7.0 release is still valid in the current BR8.0 release. Only its default value is changed.
The value of this attribute is not more used in the computation of the enhanced algorithm
for the network controlled cell reselection from GSM/GPRS to UMTS due to sufficient
coverage. In this way the dependency on the UMTS power class (FDD, TDD) of the
Mobile Station is removed.
10.4.3 GPRS/EGPRS Traffic Control Strategy

The GPRS/EGPRS Traffic Control Strategy feature controls the traffic distribution
among the cells belonging to the same PCU; the feature is based on the Network
Controlled Cell Reselection and on appropriate traffic 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 related to the way of running this available
information (only radio link conditions are taken into account); the GPRS/EGPRS Traffic
Control Strategy feature exploits this information to distribute the traffic among all the
available network resources.
To enable the Traffic Control Strategy feature at BSC level, the user must set the TRFPS
(trafficPs) attribute to the value: TRUE.
The feature can be enabled only if Network Controlled Cell Reselection feature has
i been already enabled.
When the attribute TRFPS is set to TRUE, the traffic control algorithm is executed (see
the chapter: "10.4.3.1 Network Controlled Cell Reselection Algorithm"). The purpose of
this feature is to spread the cell traffic on more than one cell, that is to move MSs
attached to an high traffic cell towards available resources in neighboring cells.
The Traffic control algorithm is applied only to cells belonging to the same PCU,
i because every PCU knows only its own traffic.
340 A30808-X3247-M24-5-7618
System
The Traffic control algorithm performs an evaluation of the radio resource occupation
within each cell, based on the number of channels configured and in service available
for the GPRS/EGPRS, and on the type of strategy configured by the user.
10.4.3.1 Network Controlled Cell Reselection Algorithm

When the Traffic control strategy procedure is enabled, every TBF activation is checked
if, for a specific cell, the radio resource occupation has reached or exceeded a config-
ured threshold, defined by the CRESELTRHSOUT attribute.
The radio link criteria, described in the chapter: "10.4.1.2 Radio Link Network Controlled
i Cell Reselection Algorithm" is maintained also when Traffic Control Strategy is enabled.
As first action, the algorithm looks for MSs candidates to be forced for a cell reselection
procedure. The candidate MS(s) are chosen among those in packet transfer mode,
applying the following criteria for the choice of the 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 among those cells belonging to the
same routing area of the serving cell; therefore the following priorities are used to order
cells:
1. target cell with the same Routing Area on the same PPXU;
2. target cell with different Routing Area, but on the same PPXU;
If NCSARA = FALSE, adjacent cells of the same routing area have no priority compared
to adjacent cells of other routing areas; therefore only priority level exists, for example
target cell with the same RA or target cell with different RA, but on the same PPXU.
Among neighboring cells with the same priority, the cell with the highest C32(n) value is
chosen. The C32(n) value is calculated with the following formula:
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 the cell in the list of the strongest neighbor cells. The user sets a
NC_GPRS_RESELECT_OFFSET(n) value for every adjacent relationship, by
means of the NCGRESOFF attribute of the ADJC object;
A30808-X3247-M24-5-7618 341
System
• 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 six 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 the
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 NCGTEM-
POFF and NCGPENTIME attributed of the ADJC Managed Object.
When NCSARA is set to 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
attribute, belonging to the PTPPKF Managed Object. NCRARESH must be set at DB00
(default value) when NCSARA is set at TRUE.
The algorithm also looks for a possible candidate cell into which to move a MS. A cell
can be a candidate for this procedure only if the following conditions are verified:
– It belongs to the same PCU of the serving cell;
– It is adjacent to the origin cell (for example the relevant ADJC Managed 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 attribute.
Then, the number of MSs to be forced in reselection is determined taking as many MSs
as the radio resources that must 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 must perform the cell reselec-
tion.
Details About the Calculation of the “Allocated Resources”:

When the traffic control strategy is enabled, the following statements shall be taken into
account:
– Every TBF activation is checked if the radio resource occupation has reached or
exceeded a threshold, defined by the CRESELTRHSOUT attribute, for a specific
cell;
– The algorithm looks for a possible candidate cell into which to move a MS; the
resource occupation of the candidate cell must be under a threshold. This threshold
can be set by the user with the CRESELTRSHINP attribute;
– 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
control of the NCTRFPSCTH attribute.
The traffic control strategy is active when vertical allocation is present and it is based on
the calculation of the “allocated resources”, according to the following rules.
The calculation is applied both to uplink and downlink TBFs: it considers the number of
allocated timeslots, the GMANMSAL attribute value and weight factors, which take into
account the average number of timeslots allocated for each TBF (uplink or downlink).
The algorithm calculates the available resources both in the uplink and downlink direc-
tions by means of the following formulas:
342 A30808-X3247-M24-5-7618
System
AVAL_TBF_DL= [N_GPRS_allocated_ts * GMANMSAL_DL] / aver_ass_ts_dl
AVAL_TBF_UL= [N_GPRS_allocated_ts * GMANMSAL_UL] / aver_ass_ts_ul
where:
– N_GPRS_allocated_ts is the number of allocated time slots when vertical allocation
is present;
– “Aver_ass_ts_ul” and “Aver_ass_ts_dl” are weighted factors which consider the
number of time slots assigned to the uplink and downlink TBF on average.
The system calculates the “traffic percentage“ both for uplink and for downlink direc-
tions, each time a TBF or a PDCH is added or removed:
PercTrfUL = TBF_UL / AVAL_TBF_UL

PercTrfDL = TBF_DL / AVAL_TBF_DL
where TBF_UL and TBF_DL indicate the number of currently opened uplink and down-
link TBFs, taking into account the related weight factors aver_ass_ts_ul and
aver_ass_ts_dl.
If TRFPS is set to TRUE and if the vertical allocation is used, the system checks the
following relationships:
1. (PercTrfUL > CRESELTRHSOUT) OR (PercTrfDL > CRESELTRHSOUT);
2. (PercTrfUL < NCTRFPSCTH) AND (PercTrfDL < NCTRFPSCTH);
3. (PercTrfUL_adjc > CRESELTRSHINP ) OR (PercTrfDL_adjc > CRESELTRSHINP).
Then:
a) when condition 1) is satisfied, the system moves a mobile station from the serving
cell to a suitable adjacent cell; this process of moving suitable mobile stations
continues until condition 2) is reached;
b) when condition 2) is satisfied, the system stops moving mobiles to the adjacent cell
for traffic reason;
c) when, for an adjacent cell, condition 3) is verified, this adjacent cell is no longer suit-
able to accept MSs coming from a congested cell.
The process is stopped when a transition from the vertical allocation to the horizontal
allocation is executed.
10.5 Power Control

The main purpose of the power control feature is to adapt the transmitted power of the
MS, as well as of the BTS, to the reception conditions. Power control provides:
1. The reduction of the power consumption of the MS’s batteries;
2. The 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 is optimized by
means of specific attributes. The algorithm runs for 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 direc-
tions;
A30808-X3247-M24-5-7618 343
System
– closed loop power control: the MS output power is commanded by the network
based on signal measurements executed in the BTS.
In the current release 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 must transfer Channel Quality reports to the BTS.
In the current release downlink power control is not supported: power control is a
mandatory feature for the Mobile Station, while it is optional for the network.
10.5.1 Power Control Algorithm

Even if the BSSsystem is not directly involved, this paragraph provides the description
i of the power control algorithm that has been implemented in the MSs.
The RF output power, Pch, to be employed by the MS on each individual uplink PDCH
is obtained by the following formula:
Pch= min (GAMMA0 - GAMMAch - ALPHA * (C+48), Pmax) (1)
where:
GAMMAch: It 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 attribute r
of the PTPPKF Managed Object.
GAMMA0: = 39 dBm for GSM900
= 36 dBm for GSM1800.
ALPHA: It is the ALPHA system parameter, which is broadcast on the
BCCH/PBCCH channel or optionally sent to the MS in a control
message.
C: It is the normalized received signal level at the MS side,
Pmax: It is the maximum allowed output power in the cell. It is equal to:
- GMSTXPMAC if the PBCCH channel is configured in the serving cell
- MSTXPMAXCH (for example the analogous GSM parameter) other-
wise.
Power levels are expressed in dBm.
When the MS receives either a new GAM or ALPHA value, the MS uses the new value
to update the Pch according to the 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 the packet transfer on the PDCH channel, the MS
uses the output power defined by Pmax.
If a calculated output power is not supported by the MS, the MS uses the supported
output power that is the nearest to the calculated output power.
344 A30808-X3247-M24-5-7618
System
10.5.2 Measurement at the MS Side

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

In packet idle mode, the MS periodically measures the received signal level of the
PCCCH or, if PCCCH is not configured, of the BCCH channel. 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 the chapter: "9.8.3.2 Discontinuous Reception").
The normalized C value for each radio block is calculated by means of the following
formula:
Cblock(n)= SSblock(n) + Pb (2)
where:
SSblock(n): It is the mean value of the received signal levels on the four normal
bursts that compose the block;
Pb: It is the BTS output power reduction (relative to the output power used
on the BCCH channel) used on the channel on which the measure-
ments are performed; it corresponds to the PRPBCCH attribute. For
PCCCH, Pb is broadcast on PBCCH. For BCCH, Pb = 0 (not broad-
cast).
Finally, the Cblock(n) values are filtered with a running average filter:
C(n)= (1- a)* C(n- 1) + a * Cblock(n) C(0)=0
where “a” is the forgetting factor calculated as follow:
a = 1/MIN(n, MAX (5, TAVG_W/TDRX)
TDRX: It is the DRX period for the MS (see the chapter:

"9.8.3.2 Discontinuous Reception");
TAVG_W: is the TAVGW attribute and it 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 the BCCH channel.
n n is the iteration index. The filter will be restarted with n=1 for the first
sample every time a new cell is selected. Otherwise, when entering
packet idle mode, the filter will continue from the n and C(n) values
obtained during packet transfer mode. The filter will also continue from
its previous state if TDRX is changed.
A30808-X3247-M24-5-7618 345
System
The current C(n) value is used in the formula (1) to calculate the output power when the
MS transfers its first radio block.
10.5.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 the chapter:
"10.5.2.2 Packet Transfer Mode: Measurements for Power Control"). The measure-
ments 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:
SSn: It is the received signal level of the measurement samples;

TAVG_T: It 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 the BCCH channel.
n n is the iteration index; when entering packet transfer mode, the filter
will continue from the n and C(n) values obtained during packet idle
mode.
If indicated by the PCMECH (PC_MEAS_CHAN) attribute, the MS will 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 the
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 channel.
n n is the iteration index; when entering packet transfer mode, the filter
will continue from the n and C(n) values obtained during packet idle
mode.
346 A30808-X3247-M24-5-7618
System
Once the current C(n) value has been obtained, this value is used to update the 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.5.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 will make these
measurements during the search frames and PTCCH frames. The measured interfer-
ence will be averaged in a running average filter. For each channel, the MS will perform
at least NAVGI measurements before valid running average filter values can be deter-
mined.
The NAVGI is broadcast on the PBCCH or, if the PCCH does not exists, on the BCCH.
In packet idle mode, the MS will measure the interference signal strength on certain
channels that are indicated on the PBCCH or if the PBCCH does not exist, on the BCCH.
The interference measurements will be made and averaged in the same way as for
packet transfer mode.
10.5.3 BTS Output Power

The BTS uses constant power on those PDCH radio blocks that contain PBCCH or
which may contain PCCCH. This power may be lower than the output power used on
the BCCH. The difference will be broadcast on PBCCH by means of the PRPBCCH
attribute.
10.5.4 DTM Power Control

Downlink and Uplink Power Control procedures are affected by Dual Transfer Mode
feature.
Downlink Power Control:
The BSC informs the BTS if a channel, engaged in a CS connection, is involved or not
in DTM. This aspect is already included in the Overheating management. According to
the current implementation, the BSC assigns the relevant fields in the new IE DTM Data
included in the messages: Channel Activation and Mode Modify Request:
• LBSPL (Limit BS Power Level) = 1 limit the Power Level using the data provided in
field BSPL in case DTM is active;
• BSPL (BS Power Level) = 0.
Uplink Power Control:
The BSC supports Uplink Power Control management informing the BTS if a channel,
engaged in a CS connection, is involved or not in DTM, how many Uplink TS between
CS and PS are involved in DTM as the power that a MS can supply depends from how
many TS are used in uplink direction and which is the multislot power profile of the MS
using the resources.
The Abis messages: Channel Activation and Mode Modify Request include in the new
IE DTM Data the fields: GMSKPP (GMSK Multislot Power Profile), PSK8PP (8- PSK
Multislot Power Profile) and NULTS (Number of UpLink TimeSlot).
A30808-X3247-M24-5-7618 347
System
The GMSK/8-PSK Multislot Power Profiles are included in Classmark 3 and MS Radio
Access Capability from 3GPP specification Release 4, if the Multislot_Power_Profile
value is not available at the time this IE is being assembled then the
Multislot_Power_Profile 0 is set as default.
The TDPC informs the BTS about the DTM status and about the number of assigned
Uplink Timeslot during DTM.
For more information about the DTM feature, see the manual: “TED:BSS Common”.
10.6 Mobile Station Overheating Management

A EGPRS/GPRS Mobile Station (MS) has a maximum number of transmit timeslots
computed by its multi-slot class, and a maximum transmit power level evaluated and
managed by its power class.
This Mobile Station may not be able to consistently operate at its maximum permissible
output power while the maximum number of timeslots have been assigned for uplink
operation, due to possible overheating of the transmitter hardware. This factor can limit
the ability for the MS to take full advantage of its power class and/or multislot class and,
as consequence, the maximum uplink data rate is limited.
For solving the problem the solution implemented in the BSS system combines the
reduction of the MS maximum output power and a signaling technique of informing the
mobile network of the exact MS multislot output power capability. This is the purpose of
the Mobile Station Overheating Management feature.
A reduction in the MS maximum output power implies a reduction in the maximum
distance between the MS and the BTS within a cell. In this way the feature has been
implemented to prevent the loss of the connection from a EGPRS/GPRS MS which is
given multiple uplink timeslots and has reduced its maximum output power. For the
purpose the Timing Advance (TA) parameter of the MS is monitored.
The MS overheating management affects Radio Resource Management (RRM) appli-
cation in two different phases:
• During the PFC/TBF allocation phase;
• During the PFC/TBF lifetime.
During PFC/TBF allocation phase the consistency with the overheating constraints is
verified when a suitable MS configuration or a group of MS configurations have been
found for a given PFC/TBF. The consistency is between the number of timeslots
assigned on Uplink, the maximum output power level and the distance from the Mobile
Station to the related BTS in the cell.
The overheating management is supported by a specific algorithm. This algorithm veri-
fies if the number of timeslots allocated on UL (defined as: TS_All_UL) is less or equal
to the maximum number of UL TS (defined as: Max_N_UL_TS) which can be managed
according to overheating constraints.
The number of timeslots assigned on UL is related to the MS configurations that have
to checked. The maximum output power depends on the number of timeslot assigned
on UL, on MS Multislot Class, on MS Power Class, on the band of operation and modu-
lation used and on MS Multislot Power Profile.
The distance between the MS and the BTS in the cell is calculated using the Timing
Advance (TA) parameter.
348 A30808-X3247-M24-5-7618
System
A data structure defined: “Max_TS_Allocation_Table” has been defined. It contains the

maximum number of UL timeslots which can be assigned for a given value of maximum
timing advance (TA). The table’s calculation is based on path loss model for each
scenario. Tuning is not foreseen. An example of table is reported below:
Max_N_UL_TS Maximum TA
1 TA_1
2 TA_2
3 TA_3
4 TA_4
Tab. 10.3 Max_TS_Allocation_Table for an assigned scenario
The table’s generation is driven by the following steps:

For a given MS Power Class (Band of operation and modulation used shall be specified)
and XXX_Multislot_Power_Profile, the Maximum Output Power Level for a given
number of assigned UL TS can be determined.
Taking into account the band of operation and the path-loss model of the cell, for each
value of “Maximum_Output_Power_Level_N_TS”, the maximum distance between the
MS and the BTS which can be managed (Maximum_Distance_MS_BTS_N_TS) can
also be calculated.
The path-loss model for a cell the MS is camped on is defined by the parameter: “Cell
i Scenario”.
Finally, the maximum value of timing advance (“Maximum_TA_N_TS”) which can be

dealt with a given number of timeslot can be calculated using the
“Maximum_Distance_MS_BTS_N_TS”. These values are then stored in the table and
associated in the same row with the correspondent number of Uplink Timeslot, defined
as: “Max_Number_UL_TS’.
The following relationship is defined: “TA_i<TA_i+1”.
During the allocation phase when a given value of Timing Advance (TA) has been
measured, the overheating management algorithm accesses the
Max_TS_Allocation_Table. PCU frames used have to carry TA information as required
by Overheating algorithm.
In case: “TA_i < TA_Measured < TA_i+1” then Max_N_UL_TS is set equal to i: the
checked allocation configuration can be used if the number of timeslots assigned on UL
is less or equal to i.
The overheating management algorithm accesses the proper
i Max_TS_Allocation_Table within a complete set of tables that are available. Each table
is identified by MS Power Class, Band and Modulation of operation and XXX Multislot
Power Profile. Moreover, each table has to be created according to the radio environ-
ment of the cell it refers to.
The algorithm’s flow diagram to determine the “Max_N_UL_TS” parameter for a given
MS configuration is represented in the next Fig. 10.5 :
A30808-X3247-M24-5-7618 349
System
Fig. 10.5 Allocation phase: Calculation of: “Max_N_UL_TS”
During TBF lifetime, the distance between MS and BTS in the cell is monitored again
and the parameter: “Max_N_UL_TS” consequently recomputed. This is executed in
order to detect the need of TBF reallocation (if MS is getting farer from the BTS and the
number of UL TS has to be reduced) or, rather, the opportunity for a TBF reconfiguration
(in case MS is getting nearer to the BTS and a greater number of UL TS can be
managed). Due to the thermal ties related to overheating feature, the calculation of the
350 A30808-X3247-M24-5-7618
System
MS to BTS distance shall be executed periodically with a period of few seconds (2-5
seconds).
For the purpose, the algorithm represented in the Fig. 10.6 is executed again during
TBF lifetime. Every time a new measure of the timing advance is available
Max_N_UL_TS is calculated again by accessing the Max_TS_Allocation_Table for the
allocation configuration used. The computed value of Max_N_UL_TS is compared with
the number of timeslot actually used on UL TS_All_UL.
A30808-X3247-M24-5-7618 351
System
Fig. 10.6 Overheating Management Algorithm
The algorithms represented in the Fig. 10.5 and Fig. 10.6 have been implemented in
the Overheating Management Application (OME). OME functionality are supported by
the Channel Allocation Algorithm (CAA) which is implemented in the Radio Resource
Manager (RRM) Application. OME and RRM are represented in the Fig. 10.7 below that
shows also the main exchanged messages.
352 A30808-X3247-M24-5-7618
System
Fig. 10.7 OME and RRM Applications

The MS Overheating Management has requested the implementation of the attribute:
“Csce (Cellscenario)” related to the BTS Managed Object. It is enumerative (Values:
“urban, sub_urban, rural_quasi_open, rural_open”). It defines the propagation scenario
of the cell.
In case DTM feature is enabled, to manage the aspects relevant to overheating the BSC
performs a Physical Context Request/Confirm procedure while in Dedicated mode and
before to enter in Dual Transfer Mode. Then it performs a Polling procedure to get the
TA value, while in Transfer mode using standard PCU frame. To speed up the procedure
to enter in DTM mode, the Polling procedure is executed if the TA value is unknown or
four seconds older. The BSC Informs the BTS if a channel, engaged in a CS connection,
is involved or not in DTM. Then the BSC get the Timing Advance value from the
message: Channel Data Abis and uses them in the Overheating Algorithm, while in DTM
mode.
More details about the DTM feature are described in the manual: “TED: BSS Common”.
10.7 Link Adaptation

As previously described in the chapter: "4.2 Channel Coding", GPRS provides four
different coding schemes, instead, for EGPRS nine different modulation and coding
schemes are defined.
In both cases (GPRS and EGPRS) lowest coding schemes (for example: CS1 and
MCS1 respectively) have good performances in poor radio conditions; on the other
hand, only the highest coding schemes (for example: CS4 and MCS9 respectively) can
provide high data throughput in good radio environments.
Therefore, an algorithm is needed 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.
A30808-X3247-M24-5-7618 353
System
Therefore, 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 changing from one coding scheme to another.
Link Adaptation can be enabled, for both GPRS and EGPRS services, setting the
ELKADPT attribute of the PTPPKF Managed Object. Link Adaptation is enabled in both
uplink and downlink directions at the same time.
The advantage to switching to a more robust coding scheme is shown in next Fig. 10.8,
taking into account GPRS CS2 and CS1 coding schemes.
Gross CS2
Throughput
[kbit/s]
CS1
C/I [dB]
Fig. 10.8 CS1 and CS2 Throughput Depending on C/I (dB)
Assuming that the C/I ratio is better (for example higher direction towards '+') than the
value denoted with '='. In this case the use of the higher coding scheme (as CS2) results
in an improved gross throughput compared to the use of CS1.
The situation changes, if the C/I becomes lower than '=' (direction towards '-'), according
to the propagation conditions. 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 (for example 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 cannot be estimated easily in a real network, so another mecha-
nism has been implemented.
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 (for example the sum of the
acknowledged blocks and the unacknowledged one). Therefore to fix the switching
points, the NACK/(ACK+NACK) ratio (Block Erasure Ratio - BLER) is used; link adap-
tation 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 (as described in the chapters: "10.7.1 Link Adap-
tation for GPRS" and "10.7.2 Link Adaptation for EGPRS").
354 A30808-X3247-M24-5-7618
System
Since switching points depend on the actual RF scenario, it is impossible to calculate

the optimal values for each particular scenario. Upgrade switching points and down-
grade switching points are then stored in pre-calculated matrix tables, one for each
possible RF environment (these matrix tables cannot be set by means of O&M
attributes). 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 attribute allows the operator to specify the radio environment. As previously
described, according to the chosen radio environment certain matrix tables are selected
(specific either for GPRS or for EGPRS) to define the BLER thresholds of the switching
points. The attribute assumes the following two values:
– LOWDIV (lowDiversity): it means that, for the MS, radio conditions can change
slowly, for example because Frequency Hopping is disabled and the cell is charac-
terized by low user mobility (for example because MS have a speed less than 50
Km/h or because the cell is a small one);
– HIGHDIV (highDiversity): it means that, for the MS, radio conditions can change fast,
for example because Frequency Hopping is enabled.
Even if there are some common attributes managing the link adaptation, some differ-
ences exist between GPRS and EGPRS handling.
Besides in the current release an improvement of the Link Adaptation (LA)
GPRS/EGPRS algorithm’s thresholds has been implemented. The GPRS/EGPRS Link
Adaptation thresholds have been already optimized due to the improved RTT. Starting
from this first improvement the Threshold Table has been optimized again. For Uplink
and Downlink directions the Throughput versus C/I curves for all the CS/MCS has been
measured again for low and high Diversity scenarios. In case of significant changes in
the Link Adaptation threshold Tables the new values have been applied. In this way a
better throughput per user and an overall data capacity increase of the network is
reached.
10.7.1 Link Adaptation for GPRS

In the following, Link adaptation features for GPRS service are described.
With GPRS the receiver operates only in type I ARQ mode (see the chapter:
"9.9.1.1 GPRS Acknowledged Mode"); therefore link adaptation procedure is based
only on this mode of operation.
10.7.1.1 GPRS: Switching Points

The exact values of switching points depend on the real network situation and are
subjects of simulation and/or measurements.
A first schema of the values to be expected is provided by the following simulations
based on TU3 with an optimized frequency hopping, as represented in next Fig. 10.9.
A30808-X3247-M24-5-7618 355
System
Fig. 10.9 Gross Throughput Depending on CS and C/I (dB)
It is possible to estimate the 'ideal' switching points as follows:
CS1 <---> CS2 C/I=6.2 dB

CS2 <---> CS3 C/I=9.6 dB
CS3 <---> CS4 C/I=16.5 dB
However, switching points between coding schemes are defined in terms of BLER
thresholds. The corresponding BLER values are shown in the Fig. 10.10.
356 A30808-X3247-M24-5-7618
System
Fig. 10.10 BLER as Function of C/I (dB) for all GPRS Coding Schemes
For GPRS, the following BLER thresholds can be defined:
BLER_CS1(CS1 ---> CS2) = 17% BLER_CS2(CS2 ---> CS1) = 43% C/I=6.2 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 for example for CS1<->CS2 provides approximately the same gross
throughputs:
(1-0.17)*9.05 kbit/s=7.51 kbit/s (1-0.43)*13.4 kbit/s=7.64 kbit/s
It is also possible to see – depending on the wished QoS – that 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 must be repeated at least once,
so the delay will be much higher than if one uses CS1. Therefore 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. The curves above (see Fig. 10.9) are re-scaled, each one by a
proper factor, and the 'ideal' switching points should be recalculated accordingly. These
switching points are reported in Tab. 10.4, and are the values that are contained in the
GPRS internal switching matrix. It is important to underline that for GPRS, only one
switching matrix exists, independently of the value given to the RAENV attribute.
A30808-X3247-M24-5-7618 357
System
CS1 CS2 CS3 CS4
CS1 <13%
CS2 >31% <14%
CS3 >26% <7%
CS4 >30%
Tab. 10.4 GPRS Thresholds with RAENV set to LOWDIV/HIGHDIV
In Tab. 10.4, coding schemes written in the vertical direction represent the starting
coding schemes, whereas those written in the horizontal direction represent the arrival
ones. For example, watching at Tab. 10.4, to go from CS1 to CS2, the BLER value must
be less than 10%; to go from CS2 to CS1, the BLER value must 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 the following must always be valid:
1) BLER(CSi-->CSi+1)<BLER(CSi=CSi+1) i=1..3
2) BLER(CSi=CSi+1)<=BLER(CSi<--CSi+1) i=1..3
10.7.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 the following situation
(“quality trap”): if conditions worsen (or a 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 must be resent with the old CS).
The situation described above is very pessimistic. In more common cases, interference
i and fading conditions are variable enough, from block to block, to allow a 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 switching to
a lower coding scheme, a progress retransmission will 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 the
chapter: "10.7.3 Selection of the Candidate Initial Coding Scheme" to get more details
about this procedure).
For example, for transmission in the 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.
358 A30808-X3247-M24-5-7618
System
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, for transmission in the 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 again requires the TBF within the STGTTLLIINF time, CS3 coding
scheme will be used (last commanded coding scheme).
10.7.1.3 GPRS: Link Adaptation Algorithm

The GPRS link adaptation is based on the following features:
1. All of the signaling is done with CS1;
2. Data transfer is started with the highest available coding scheme; the following
considerations shall be considered:
– If the transmission to be started is a retry due to a previous “quality trap” (see the
chapter: "10.7.1.2 “Quality Traps” Disadvantage"), the CS to be selected must be
more stable than the one used before. The PCU must store abnormal releases for
a certain time, to recognize a retry and adapt the CS for that case.
– As described in the chapter: "10.7.1.2 “Quality Traps” Disadvantage", the PCU
holds in memory the value of the last used coding scheme for a defined time; 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 attribute (see the chapter: "10.7.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, but all of NACK
blocks must be successfully sent using the old coding scheme (for example after a
change from coding scheme A to coding scheme B, all of the not acknowledged
blocks must be resent using the coding scheme A); this may lead to the 'quality trap'.
This problem is solved only by expiration of a timer and reestablishing the transmis-
sion with a more appropriate CS.
5. If conditions improve, an upgrade to the higher CS is performed, but all of NACK
blocks must successfully be sent using the old coding scheme. 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 (as C/I or BLER) but also on the available
resources. A switch (for example: CS2 to CS3) is not allowed, if there is insufficient
transmission capacity on the Abis (for example a 32 kbit/s channel available for a
CS3, see the chapter: "6.3 PCU Frames and Dynamic Allocation on the Abis Inter-
face").
10.7.2 Link Adaptation for EGPRS

For EGPRS, up to nine modulation and coding schemes have been defined; each
scheme belong to a certain family.
In general, according to the link quality, an initial Modulation and Coding Scheme (MCS)
is selected for a RLC block. For retransmissions, the same or another MCS from the
A30808-X3247-M24-5-7618 359
System
same family of MCSs can be selected. For example, if MCS7 is selected for the first
transmission of a RLC block, any MCSs of the family B can be used for the retransmis-
sion.
In the type I ARQ mode (see the chapter: "9.9.1.2 EGPRS Acknowledged Mode"),
decoding of a RLC Data Block is based solely on the prevailing transmission (for
example: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.7.2.1 EGPRS: Switching Points

With EGPRS, different MCSs allow different performance (throughput) as a function of
the C/I ratio (and the actual RF channel); The Fig. 10.11 shows the curves for TU3 with
no frequency hopping, for family A + MCS1 (without Incremental Redundancy).
Fig. 10.11 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 only using MCSs belonging to the family A (plus MCS1), the 'ideal' switching
points could be as follows:
MCS1 <---> MCS3 C/I=1.5 dB

MCS3 <---> MCS6 C/I=7.5 dB
MCS6 <---> MCS9 C/I=16 dB
360 A30808-X3247-M24-5-7618
System
As described for GPRS, also with EGPRS the thresholds are assigned in terms of
BLER, since C/I values are difficult to estimate; some examples of defined BLER thresh-
olds could be as follows:
BLER(MCS1 ---> MCS3) = 61% BLER(MCS3 ---> MCS1) = 77% C/I=1.5 dB

BLER(MCS3 ---> MCS6) = 38% BLER(MCS6 ---> MCS3) = 69% C/I=7.5 dB
BLER(MCS6 ---> MCS9) = 24% BLER(MCS9 ---> MCS6) = 62% C/I=16 dB
The throughput is 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 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 envi-
ronment.
More precisely, these values are stored in pre-calculated matrix tables, one for each
possible RF environment; therefore:
– if RAENV is set to HIGHDIV, some threshold values are used;
– if RAENV is set to LOWDIV, some other threshold values are used.
With O&M, it is possible (by setting the RAENV parameter) to select the suitable matrix
table, containing all of 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. 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 the
chapter: "10.7.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 signaling and due to the
fact that MCS1 is the only MCS that requires only one Abis timeslot;
b) If MCSx is implemented, all of 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
i 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 configured, considering a given MCSx in use, the general
rule to decide the upgrading/downgrading MCS is the following: the “upgrading”
MCS is the one characterized by the highest switching threshold (among the config-
A30808-X3247-M24-5-7618 361
System
ured ones), while the “downgrading” MCS is the one characterized by the lowest
switching threshold (among the configured ones).
It may happen that the upgrading threshold is higher that the downgrading
i threshold. In this case one of the two conditions is always satisfied (implic-
itly this means that the current MCS is a “transition one” and the best
choice is to immediately switch to a new one). In case both conditions are
satisfied, the best choice is to switch to the upgrading MCS.
According to the chosen sets of coding schemes (in uplink or downlink direction),
different thresholds must be considered, since different coding schemes are selected.
The Tab. 10.5 shows which thresholds are considered if, for instance, the user has
enabled FamilyA plus MCS1. Instead the Tab. 10.6 shows which thresholds are consid-
ered 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. Therefore, for
example, watching at Tab. 10.5, to go from MCS1 to MCS3 the BLER must be less than
a XX% value; to go from MCS3 to MCS1 the BLER must be greater than another XX%
value.
If more than one family is enabled, the possible switching points are those given by the
i sum of the tables related to the single families.
Fam C Fam B Fam A + Fam C Fam B Fam A + Fam B Fam A Fam A

Fam A Fam A Padding
Padding Padding
MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7 MCS8 MCS9
Fam C MCS1 <XX%
Fam B MCS2
Fam A + MCS3 >XX% <XX%
Fam A
Padding
Fam C MCS4
Fam B MCS5
Fam A + MCS6 >XX% <XX%
Fam A
Padding
Fam B MCS7
Fam A MCS8
Padding
Fam A MCS9 >XX%
Tab. 10.5 Thresholds to be used if Family A plus MCS1 are chosen
362 A30808-X3247-M24-5-7618
System
Fam C Fam B Fam A + Fam C Fam B Fam A + Fam B Fam A Fam A

Fam A Fam A Padding
Padding Padding
MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7 MCS8 MCS9
Fam C MCS1 <XX%
Fam B MCS2 >XX% <XX%
Fam A + MCS3
Fam A
Padding
Fam C MCS4
Fam B MCS5 >XX% <XX%
Fam A + MCS6
Fam A
Padding
Fam B MCS7 >XX%
Fam A MCS8
Padding
Fam A MCS9
Tab. 10.6 Thresholds to be used if Family B plus MCS1 are chosen
If all EGPRS coding schemes are enabled, according to radio environment (i.e., RAENV
parameter setting) and IR, four different threshold settings are foreseen:
a) RAENV set to LOWDIV and IR is working;
b) RAENV set to LOWDIV and IR is not working;
c) RAENV set to HIGHDIV and IR is working;
d) RAENV set to HIGHDIV and IR is not working.
To MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7 MCS8 MCS9

From
MCS1 <35% <35% <30%
MCS2 >60% <30% <25% <35%
MCS3 >70% >60% <20% <35% <30%
MCS4 >70% >60% >45% <40% <40%
MCS5 >70% >65% >70% <40% <45%
MCS6 >70% >75% >70% <40% <40% <40%
MCS7 >80% >70% <30% <30%
MCS8 >75% >75% <15%
MCS9 >80% >80% >80%
Tab. 10.7 EDGE with Incremental Redundancy working and RAENV set to "LOWDIV"
A30808-X3247-M24-5-7618 363
System

From
MCS1 <35% <35% <30%
MCS2 >60% <30% <25% <35%
MCS3 >70% >60% <20% <35% <30%
MCS4 >70% >50% >45% <40% <40%
MCS5 >70% >65% >70% <40% <25%
MCS6 >70% >75% >70% <30% <25% <15%
MCS7 >65% >60% <30% <15%
MCS8 >65% >50% <15%
MCS9 >65% >45% >30%
Tab. 10.8 EDGE with Incremental Redundancy not working and RAENV set to "LOWDIV"

From
MCS1 <15% <10% <10%
MCS2 >45% <3% <1% <20%
MCS3 >50% >35% <5% <40% <35%
MCS4 >55% >40% >25% <45% <45%
MCS5 >70% >70% >70% <15% <30%
MCS6 >70% >70% >45% <5% <15% <40%
MCS7 >70% >45% <5% <5%
MCS8 >60% >25% <15%
MCS9 >75% >35% >50%
Tab. 10.9 EDGE with Incremental Redundancy working and RAENV set to "HIGHDIV"

From
MCS1 <15% <3% <1%
MCS2 >45% <3% <1% <10%
MCS3 >50% >35% <5% <50% <35%
MCS4 >55% >40% >25% <90% <75%
MCS5 >60% >80% >90% <15% <2%
MCS6 >70% >90% >45% <5% <2% <2%
MCS7 >55% >45% <5% <5%
Tab. 10.10 EDGE with Incremental Redundancy not working and RAENV set to "HIGHDIV"
364 A30808-X3247-M24-5-7618
System
MCS8 >50% >25% <15%

MCS9 >55% >35% >50%
Tab. 10.10 EDGE with Incremental Redundancy not working and RAENV set to "HIGHDIV"
To summarize, the following considerations shall be taken into account:

• 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 it is quite diffi-
cult to define consistent thresholds among all of the possible MCSs.
10.7.2.2 EGPRS: Link Adaptation Algorithm

Regarding EGPRS link adaptation algorithm, some differences exist between the uplink
and downlink directions; these differences arise from the following situations:
a) there are EGPRS MSs that do not support the PSK modulation in uplink direction,
but only the GMSK one (see the chapter: "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 direc-
tion. 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, an attribute is given for each family. The attributes
areyje following (in uplink direction, the Incremental Redundancy is not implemented):
• EMFA1UNIR8PSK (enMcsFamAMcs1UplinkWoutIncrRed8Psk): enables MCS
belonging to FamilyA and MCS1 to be used, if MS support 8PSK modulation in the
Uplink;
• EMFAP1UNIR8PSK
(enableMcsFamilyApMcs1UplinkWithoutIncrementalRedundancy8Psk): enables
MCS belonging to FamilyA padding and MCS1 to be used, if MS support 8PSK
modulation in the Uplink case;
• EMFB1UNIR8PSK (enMcsFamBMcs1UplinkWoutIncRed8Psk): enables MCS
belonging to Family B and MCS1 to be used, if MS support 8PSK modulation in the
Uplink EGPRS TBF;
• EMFCUNIR8PSK (enMcsFamCUplinkWoutIncRed8Psk): enables MCS belonging
to Family C and MCS1 to be used, if MS support 8PSK modulation in the Uplink
case;
• EMFGUNIR8PSK (enMcsFamGmskUplinkWoutIncRed8Psk): enables MCS
belonging to Family Gmsk to be used, if MS supports 8PSK modulation in the Uplink
case;
• EMFCUNIRGMSK (enMcsFamCUplinkWoutIncrRedGmsk): enables MCS
belonging to Family C to be used, if MS does not support 8PSK modulation in the
Uplink case;
A30808-X3247-M24-5-7618 365
System
• EMFGUNIRGMSK (enMcsFamGmskUplinkWoutIncrRedGmsk): enables MCS

belonging to Family Gmsk to be used, if MS does not support 8PSK modulation in
the Uplink case.
Family GMSK is constituted by MSCs that can be used from a MS supporting, in uplink
i direction, the GMSK modulation only. The coding schemes belonging to Family GMSK
are: MCS1, MCS2, MCS3, and MCS4; these coding schemes use the GMSK modula-
tion (see "3.1 GPRS and EGPRS Modulation Principles").
The user can also define the initial MCS to be used as default in uplink direction; if no
information is available about a MS in a cell, the defined MCSs will be used (see the
chapter: "10.7.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 runs as follow:
1. The initial Modulation and Coding Scheme is decided. In the 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 as described in
the chapter: "10.7.3 Selection of the Candidate Initial Coding Scheme";
2. Once the connection is established, BLER is continuously updated at the PCU (each
20 ms) by checking whether or not RLC blocks have been carefully received; the
filtering period can be defined, in number of radio blocks, by the BLERAVEUL
attribute;
3. Once the initial filtering period has elapsed (for example after 100 radio blocks if
BLERAVEUL is set to UNIT100), BLER is continuously monitored. Each time (for
example for each received block) BLER is checked and tested against the appro-
priate thresholds; if MCSx is the actual MCS, MCSy the next available one and
MCSz the previous available one, the appropriate thresholds are given by the
following relationship:
Up_th= BLER(MCSx--->MCSy) upgrade threshold

Dn_th= BLER(MCSx--->MCSz) 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, as
i described in the chapter: "6.3 PCU Frames and Dynamic Allocation on the Abis Inter-
face"and "5.7.5.2 Upgrade of Abis Resources".
Downlink direction:
In the downlink, direction incremental redundancy is assumed to always be enabled,
since it is mandatory for EGPRS MSs.
The user can configure which sets of coding schemes can be used in the downlink direc-
tion. EGPRS MSs are able to receive 8PSK modulated signals, therefore at least one
family of available MCSs must be enabled (all of the MSs are 8PSK receive capable).
366 A30808-X3247-M24-5-7618
System
To enable sets of coding schemes, an attribute related to each family has been imple-
mented. The attributes are the following:
• EMCSFAMA1DL (enMcsFamAMcs1Downlink): enables MCS belonging to Family A
and MCS1 to be used, in Downlink case;
• EMCSFAMAP1DL (enMcsFamAPaddingMcs1Downlink): enables MCS belonging
to Family A padding and MCS1 to be used, in Downlink case;
• EMCSFAMB1DL enMcsFamBMcs1Downlink): enables MCS belonging to Family B
and MCS1 to be used, in Downlink case;
• EMCSFAMCDL (enMcsFamCDownlink): enables MCS belonging to Family C to be
used, in Downlink case;
• EMCSFAMGDL (enableMcsFamilyGmskDownlink): enables MCS belonging to
Family GSMK to be used, in Downlink case.
The user can also define, setting the INIMCSDL attribute, the initial MCS to be used as
the default in the downlink direction; if no information about the MS in a cell is available,
the suggested MCSs will be used (see the chapter: "10.7.3 Selection of the Candidate
Initial Coding Scheme").
The link adaptation algorithm in the downlink direction runs as follows:
1. The initial Modulation and Coding Scheme is decided. In the 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 as described in the chapter: "10.7.3 Selection of the Candidate Initial
Coding Scheme";
2. Once the connection is established, BLER is updated at the PCU with the informa-
tion provided by the EGPRS PACKET DOWNLINK ACK/NACK MESSAGE, reported
by the MS upon periodic request from the network (let k be the reporting instant); the
filtering period can be defined, in number of radio blocks, by the BLERAVEDL
parameter;
3. 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. From the MS OUT OF
MEMORY bit, the IR_status_k variable is derived, providing information about the
efficiency of incremental redundancy at the MS at a specific instant k:
– IR is considered as "not-properly working” when IR_status_k<0.5
– IR is considered as "properly working” when IR_status_k>0.5
4. BLER is continuously monitored; each time an EGPRS PACKET DOWNLINK
ACK/NACK is received, BLER is checked and tested against the appropriate thresh-
olds; 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 did not work at all, the appropriate thresholds would be:
A30808-X3247-M24-5-7618 367
System
Up_th_k= BLER(MCSx--->MCSy) upgrade threshold

Dn_th_k= BLER(MCSx--->MCSz) downgrade threshold
– generally (IR efficiency given by IR_statusk) the appropriate thresholds would be

something between thresholds defined above:
Up_th_k= (1-IR_status_k)*BLER(MCSx--->MCSy)+ upgrade

IR_status_k*BLER(MCSx_wIR--->MCSy_wIR) threshold
Dn_th_k= (1-IR_status_k)*BLER(MCSx--->MCSz)+ downgrade
IR_status_k*BLER(MCSx_wIR--->MCSz_wIR) 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, the Abis availability should be checked. For
i the purpose see the chapter: "6.3 PCU Frames and Dynamic Allocation on the Abis
Interface" and "5.7.5.2 Upgrade of Abis Resources".
10.7.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 previously 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 described in the chapter: "9.1 Mobile
Stations for Packet Switched Services", not all the EDGE MSs support the 8PSK
modulation, therefore:
– 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 MSs 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 valid information of the coding scheme to use when the TBF starts.
In fact, the PCU holds into memory, for each MS, 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) attribute expires or if a cell reselection proce-
dure is executed. These values of coding schemes are called “historical” coding
schemes; configured by O&M commands, the coding schemes will be used only if no
historical values are available at the PCU side.
Besides the coding scheme, the PCU also holds in memory, for the same time, the
i “historical BLER”, for example the last measured BLER. This value is used to assign
radio resources to the new TBF (see for more details the chapter: "5.7.4 Management
of Incoming GPRS/EGPRS Requests").
368 A30808-X3247-M24-5-7618
System
When a new TFB starts, the Candidate Initial Coding Scheme must be selected:
a) For GPRS MS, only the ‘candidate initial CS’ must be calculated;
b) For EGPRS MS, both the ‘candidate initial MCS’ and the ‘candidate initial CS’ must
be calculated. In fact, only after the Resource Allocation procedure (see the chap-
ters: "5.7.4.1 PCU Algorithm" and "5.7.4.2 TDPC Algorithm") will be clear which TBF
mode (GPRS or EGPRS) shall be used.
Therefore, the candidate initial coding scheme is selected in the following order:
For GPRS capable mobiles:
– historical CS, if available;
– configured initial CS, if historical CS is not available.
For EGPRS capable mobiles:
a) canditate initial MCS:
– based on historical MCS, if any;
– based on historical CS, if available (see Tab. 10.12);
– configured 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.11);
– configured initial CS, if historical CS/MCS are not available.
Besides, for EGPRS service it is important to remember 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 cannot be directly
usable for the new TBF to be set up, because the user has changed the value of the
related attributes. In this case, the rule to select the candidate initial MCS is: take the
highest configured MCS less or equal to the available historical MCS.
The following tables show the rules to decide the candidate initial coding scheme for:
– GPRS TBF mode, when the last coding scheme has been stored for a EGPRS TBF
mode (see Tab. 10.11).
– EGPRS TBF mode, when the last coding scheme has been stored for a GPRS TBF
mode (see Tab. 10.12);
Historical MCS Candidate CS
MCS1 CS1
MCS2 CS2
MCS3 CS3
MCS4 or higher MCSs CS4
Tab. 10.11 Candidate Initial Coding Scheme for a GPRS TBF when the Historical
Coding Scheme is related to an EGPRS TBF
A30808-X3247-M24-5-7618 369
System
Historical CS Candidate MCS
CS1 -MCS1
CS2 -MCS2 if FamilyB is configured
-MCS1 otherwise
CS3 -MCS3 if FamilyA is configured
-MCS2 if FamilyB is configured
-MCS1 otherwise
CS4 DL or UL TBF for fully 8PSK UL TBF for GMSK capable
capable mobiles mobiles
-Configured Initial MCS if it is -MCS4 if FamilyC is configured
upper than MCS4 -MCS3 if FamilyA is configured
-MCS4 if FamilyC is configured -MCS2 if FamilyB is configured
-MCS3 if FamilyA is configured -MCS1 otherwise
-MCS2 if FamilyB is configured
-MCS1 otherwise
Tab. 10.12 Candidate Initial Coding Scheme for an EGPRS TBF when the Historical
Coding Scheme is related to a GPRS TBF
370 A30808-X3247-M24-5-7618
System
11 Managed Objects and attributes

This chapter is a collection of the main attributes and Managed Objects that have been
implemented to provide the GPRS/EGPRS services.
The chapter contains four tables:
– In the first table all the attributes related only to the GPRS/EGPRS features
described in this manual are described in the alphabetical order. For each parameter
the user finds one or more links to the chapters of the manual where the parameter
is described and also a link to the title of the Feature Sheet (or Change Requests)
that requires the implementation of the parameter in the BSS system.
– In the second table are described in the alphabetical order the unspecific
GPRS/EGPRS attributes that are discussed in the manual since they are also
related to the GPRS/EGPRS technology. One or more links for each parameter is
related to the chapters of the manual where the parameter is described; besides,
starting from the parameters of the BSS BR5.5 release onwards, a link to the
features that describe the parameter is provided.
– In the third table all the Managed Objects that have been implemented for supporting
the GPRS/EGPRS technology are described in the alphabetical order. For each
object a link to the corresponding Feature Sheet (or Change Request) that has
required its implementation in the BSS system is provided.
– In the fourth table all the Managed Objects that are affected by the GPRS/EGPRS
services but that are not specific for this technology are described. For each
Managed Object a link to the chapters of the manual that are related to it is provided.
Attribute Feature/CR Chapter
ABUTYP FSH 0720 "9.8.2.1 8 Bit or 11 Bit Uplink Access"

"9.8.2.4 TBF Establishment for EDGE Mobile
Stations"
ACCEPTGDEGR FSH 0516 "5.7.5.1 Upgrade of Radio Resources"
ALPHA FSH 0720 "10.5.1 Power Control Algorithm"
"10.5.2.2 Packet Transfer Mode: Measure-
ments for Power Control"
ALRMSEVES " FSH 86992" "7.4 High Speed Gb Interface"
ARFCN --- "9.8.2 TBF Establishment Initiated by the MS
on CCCH/PCCCH"
BAF FSH 0720 "7.1 Physical Layer"
BEPAVGP FSH 0420 NOT USED IN BR7.0
BER FSH 0720 "7.1 Physical Layer"
BLERAVEDL FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
BLERAVEUL FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
BNDWIDTDD FSH 0418 "10.3.3 Handling of UMTS Neighboring Cells"
Tab. 11.1 GPRS/EGPRS Specifc Attributes
A30808-X3247-M24-5-7618 371
System
BPAGCHR FSH 0720 "4.5.2 PDCH Carrying both PBCCH and

PCCCH"
"9.8.3.2 Discontinuous Reception"
"4.5.3 PDCH Carrying PCCCH"
BPRACHR FSH 0720 "4.5.2 PDCH Carrying both PBCCH and
PCCCH"
"4.5.3 PDCH Carrying PCCCH"
BSCDVMA FSH 0720 "9.9.3.4 Release of an Uplink TBF"
BSPBBLK FSH 0720 "4.5.2 PDCH Carrying both PBCCH and
PCCCH"
BVCBHIPER FSH 0514 "7.3.3.2 BVC Flow Control Message"
BVCBMAPER FSH 0514 "7.3.3 SGSN-BSS Flow Control"
BVCBLPER FSH 0514 "7.3.3.2 BVC Flow Control Message"
BVCBSPPER FSH 0514 "7.3.3 SGSN-BSS Flow Control"
C31H FSH 0720 "10.1.3 Cell Re-selection Algorithm"
C32QUAL FSH 0720 "10.1.3 Cell Re-selection Algorithm"
CACKTYP FSH 0720 "9.8.5 Polling Procedures"
CR - X617
CODE FSH 0720 "7.1 Physical Layer"
CRC FSH 0720 "7.1 Physical Layer"
CRESELTRHSOUT FSH 0418 "10.4.3.1 Network Controlled Cell Reselection
Algorithm"
CRESELTRSHINP FSH 0418 "10.4.3.1 Network Controlled Cell Reselection
Algorithm"
CSCE " FSH 88930" "10.6 Mobile Station Overheating Manage-
ment"
CSCH3CSCH4SUP FSH 0419 "4.2.1 GPRS Channel Coding"
DIFFSERVSUP- " FSH 86992" "7.4 High Speed Gb Interface"
PORT
DRXTMA FSH 0720 "9.8.3.2 Discontinuous Reception"
CR - F190
CR - X617
EBCCHTRX FSH 0420 "5.5.1 Aspects Related to Carrier Configura-
tion"
"5.7.4 Management of Incoming
GPRS/EGPRS Requests"
EDASUP " FSH 88930" "5.7.3 Extended Dynamic Allocation"
372 A30808-X3247-M24-5-7618
System
EEDGE FSH 0420 "5.5 Enabling Packet Switched Services in a

CR - X0158 Cell"
EGPLGPONETS FSH 0420 "9.9.3.1 Uplink TBF Using the Acknowledged

Mode"
"9.9.4.1 Acknowledged and Unacknowledged
Modes on Downlink TBFs"
EGPLGPTWOTS FSH 0420 "9.9.3.1 Uplink TBF Using the Acknowledged
Mode"
EGPLGPTHREETS FSH 0420 "9.9.3.1 Uplink TBF Using the Acknowledged
Mode"
EGPLGPFOURTS FSH 0420 "9.9.3.1 Uplink TBF Using the Acknowledged
Mode"
EGPLGPFIVETS FSH 0420 "9.9.3.1 Uplink TBF Using the Acknowledged
Mode"
EGPLGPSIXTS FSH 0420 "9.9.3.1 Uplink TBF Using the Acknowledged
Mode"
EGPLGPSEVENTS FSH 0420 "9.9.3.1 Uplink TBF Using the Acknowledged
Mode"
EGPLGPEIGHTTS FSH 0420 "9.9.3.1 Uplink TBF Using the Acknowledged
Mode"
EGPRS FSH 0420 "5.5 Enabling Packet Switched Services in a
CR - X0158 Cell"
EGWSONETS FSH 0420 "9.9.1.2 EGPRS Acknowledged Mode"
EGWSTWOTS FSH 0420 "9.9.1.2 EGPRS Acknowledged Mode"
EGWSTHREETS FSH 0420 "9.9.1.2 EGPRS Acknowledged Mode"
A30808-X3247-M24-5-7618 373
System
EGWSFOURTS FSH 0420 "9.9.1.2 EGPRS Acknowledged Mode"

EGWSFIVETS FSH 0420 "9.9.1.2 EGPRS Acknowledged Mode"
EGWSSIXTS FSH 0420 "9.9.1.2 EGPRS Acknowledged Mode"
EGWSSEVENTS FSH 0420 "9.9.1.2 EGPRS Acknowledged Mode"
EGWSEIGHTTS FSH 0420 "9.9.1.2 EGPRS Acknowledged Mode"
ELKADPT FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
ELLCOM " FSH 84566" "5.1 Radio Channel Allocation Strategy"
ELLPRM " FSH 84566" "5.1 Radio Channel Allocation Strategy"
EMCSFAMA1DL FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EMCSFAMAP1DL FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EMCSFAMB1DL FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EMCSFAMCDL FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EMCSFAMGDL FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EMFA1UNIR8PSK FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EMFAP1UNIR8PSK FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EMFB1UNIR8PSK FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EMFCUNIR8PSK FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EMFCUNIRGMSK FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EMFGUNIR8PSK FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EMFGUNIRGMSK FSH 0444 "10.7.2.2 EGPRS: Link Adaptation Algorithm"
EUMSSNCRESEL " FSH 87029" "10.4.2 NC Cell Reselection due to sufficient
UMTS coverage"
"10.4.2.1 Enhancement of the NCCR G->G
algorithm"
FDDGQO CR - X482 "10.3.2 GSM-UMTS Re-selection Algorithm:
Packet Switched Case"
FRSTD FSH 0720 "7.1 Physical Layer"
GAMMA ---- "10.5.1 Power Control Algorithm"
"10.5.2.2 Packet Transfer Mode: Measure-
GASTRABISTH FSH 0516 "5.7.2.4 Switching between VA and HA"
"5.7.2.5 Allocation of Resources"
"5.7.4.2 TDPC Algorithm"
"5.7.5.2 Upgrade of Abis Resources"
374 A30808-X3247-M24-5-7618
System
GASTRTH FSH 0503 "5.7.2.3 Switching between VA and HA

According to Radio Conditions"
"5.7.2.5 Allocation of Resources"
"5.7.5.1 Upgrade of Radio Resources"
GBSNS " FSH 86992" "7.4 High Speed Gb Interface"
GDCH (ex GCCH) FSH 0720 "5.6 Configuration of GPRS Channels in a
FSH 0457 Cell"
FSH 0503
"5.7.2.3 Switching between VA and HA
CR - X706
GCELLRESH FSH 0720 "10.1.3 Cell Re-selection Algorithm"
GEXTS " FSH 87030" "5.3 Multiband Operations"
"5.4 Dual Band Standard Cell"
GFDDMURREP FSH 0418 "10.4.1.1 Measurement Reporting"
GFDDREPQTY FSH 0418 "10.4.1.1 Measurement Reporting"
GHCSPC FSH 0720 "10.1.2.2 C31 Criterion"
CR - F205
"10.1.2.3 C32 Criterion"
"10.1.4 Management of GPRS/EGPRS
Neighboring Cells"
"10.1.4.3 Configuration of an Adjacent Cell
supporting GPRS"
GHCSTH FSH 0720 "10.1.2.2 C31 Criterion"
CR - F205
Neighboring Cells"
supporting GPRS"
GLK FSH 0720 "7.1 Physical Layer"
"7.2.1.1 Examples of Addressing"
A30808-X3247-M24-5-7618 375
System
GMANMSAL FSH 0720 "4.3.4 Multiplexing MSs on the same PDCH:

Configuration"
"4.4.3 Packet Data Traffic Channel (PDTCH)"
"5.6 Configuration of GPRS Channels in a
Cell"
"5.7.2 Horizontal/Vertical Allocation Strate-
gies"
"5.7.2.1 Vertical Allocation Strategy"
"5.7.4.1 PCU Algorithm"
"10.4.3.1 Network Controlled Cell Reselection
Algorithm"
GMANPAL FSH 0720 REMOVED IN BR6.0
CR - X232
GMANPRESPRM " FSH 84566" "5.1 Radio Channel Allocation Strategy"
GMANPRE- " FSH 84566" "5.1 Radio Channel Allocation Strategy"
SPRESCOM
EMANPRESPRM " FSH 84566" "5.1 Radio Channel Allocation Strategy"
EMANPRESPRESCOM " FSH 84566" "5.1 Radio Channel Allocation Strategy"
GLLCOM " FSH 84566" "5.1 Radio Channel Allocation Strategy"
GLLPRM " FSH 84566" "5.1 Radio Channel Allocation Strategy"
GMANRETS --- "9.8.2.6 Uplink Access on PRACH (Access
Persistence Control)"
GMSTXPMAC FSH 0720 "10.1.2.1 GPRS/EGPRS Path Loss Criterion
FSH 0418 (C1 Criterion)"
Neighboring Cells"
supporting GPRS"
"10.4.1.2 Radio Link Network Controlled Cell
Reselection Algorithm"
Algorithm"
GNMULBAC FSH 0418 "10.1.1 Measurements for Cell Selection and
Re-selection"
"10.4.1.1 Measurement Reporting"
GPATH FSH 0720 "9.8.2 TBF Establishment Initiated by the MS
on CCCH/PCCCH"
376 A30808-X3247-M24-5-7618
System
GPDPDTCHA FSH 0503 "5.6 Configuration of GPRS Channels in a

CR - X617 Cell"
"5.7.2.1 Vertical Allocation Strategy"
"5.7.2.3 Switching between VA and HA
"7.3.3.2 BVC Flow Control Message"
GPENTIME FSH 0720 "10.1.2.2 C31 Criterion"
CR - F205
Neighboring Cells"
supporting GPRS"
GPRSEXT " CR-X2357" "4.2.1 GPRS Channel Coding"
GRESOFF FSH 0720 "10.1.2.2 C31 Criterion"
CR - F205
CR - X617
Neighboring Cells"
supporting GPRS"
GRXLAMI FSH 0720 "10.1.2.1 GPRS/EGPRS Path Loss Criterion
FSH 0418 (C1 Criterion)"
Neighboring Cells"
supporting GPRS"
Algorithm"
GS FSH 0720 "9.8.2.6 Uplink Access on PRACH (Access
GTDDMURREP FSH 0418 "10.4.1.1 Measurement Reporting"
GTEMPOFF FSH 0720 "10.1.2.2 C31 Criterion"
CR - F205
Neighboring Cells"
supporting GPRS"
A30808-X3247-M24-5-7618 377
System
GTS FSH 0720 "7.1 Physical Layer"

GTXINT FSH 0720 "9.8.2.6 Uplink Access on PRACH (Access
GUMTSSRHPRI FSH 0418 "10.1.1 Measurements for Cell Selection and
Re-selection"
"10.3 Cell Re-selection from
GSM/GPRS/EGPRS Network to UMTS
Network"
IMCSULNIR8PSK FSH 0444 "4.2.2 EGPRS Channel Coding"
"10.7.2.2 EGPRS: Link Adaptation Algorithm"
"10.7.3 Selection of the Candidate Initial
Coding Scheme"
IMCSULNIRGMSK FSH 0444 "4.2.2 EGPRS Channel Coding"
Coding Scheme"
INIBLER FSH 0516 "5.7.4.1 PCU Algorithm"
Coding Scheme"
INICSCH FSH 0720 "4.7.1 Mobile Station Classes for Multislot
Capabilities"
"10.7.1.3 GPRS: Link Adaptation Algorithm"
Coding Scheme"
INIMCSDL FSH 0444 "4.2.2 EGPRS Channel Coding"
Coding Scheme"
IP ADDRESS " FSH 86992" "7.4 High Speed Gb Interface"
LAYERID " FSH 84566" "5.1 Radio Channel Allocation Strategy"
LOCAL_IP_END_PO " FSH 86992" "7.4 High Speed Gb Interface"
INT
LOWBER FSH 0720 "7.1 Physical Layer"
MAFAILNCU " FSH 87029" "Fig. 10.4 Combined GSM/UMTS Network
Architecture"
"10.4.2.1 Enhancement of the NCCR G->G
algorithm"
MNTBMASK CR - X1869 "4.2.1 GPRS Channel Coding"
378 A30808-X3247-M24-5-7618
System

MSBHIPER FSH 0514 "7.3.3 SGSN-BSS Flow Control"
MSBMAPER FSH 0514 "7.3.3.1 MS Flow Control Message"
MSBLPER FSH 0514 "7.3.3 SGSN-BSS Flow Control"
MSBSPPER FSH 0514 "7.3.3.1 MS Flow Control Message"
MSRMAXU " FSH 86774" "7.3.5 Enhanced Flow Control"
N3101 FSH 0720 "9.9.3.3 Anomalies During an Uplink TBF"
CR - X617
FSH 0444 "10.7.1.2 “Quality Traps” Disadvantage"
N3103 FSH 0720 "9.9.3.4 Release of an Uplink TBF"
N3105 FSH 0720 "9.9.4.1 Acknowledged and Unacknowledged
N391 FSH 0720 "7.2.1.3 Procedures for PVCs"
NAVGI FSH 0720 "10.5.2.3 Derivation of Channel Quality
Reports"
NBVCBR FSH 0720 "7.3.1.1 BVC Procedures"
NBVCUR FSH 0720 "7.3.1.1 BVC Procedures"
NBVCRR FSH 0720 "7.3.1.1 BVC Procedures"
NCC1TH FSH 0418 "10.4.1.2 Radio Link Network Controlled Cell
NCC1THADJC FSH 0418 "10.4.1.2 Radio Link Network Controlled Cell
Algorithm"
NCGPENTIME FSH 0418 "10.4.1.2 Radio Link Network Controlled Cell
Algorithm"
NCGRESOFF FSH 0418 "10.4.1.2 Radio Link Network Controlled Cell
Algorithm"
NCGPENTIME FSH 0418 "10.4.1.2 Radio Link Network Controlled Cell
Algorithm"
A30808-X3247-M24-5-7618 379
System
NCRARESH FSH 0418 "10.4.1.2 Radio Link Network Controlled Cell

Algorithm"
NCRESELFLAG FSH 0418 "10.4.1 Network Controlled Cell Reselection"
"10.4.3 GPRS/EGPRS Traffic Control
Strategy"
NCSARA FSH 0418 "10.4.1.2 Radio Link Network Controlled Cell
Algorithm"
NCTRFPSCTH FSH 0418 "10.4.3.1 Network Controlled Cell Reselection
Algorithm"
NMO FSH 0720 "9.8.3.1 Network Operation Modes for
Paging"
NNSVCBLKR FSH 0720 "7.2.2.2 Control Procedures"
NNSVCRR FSH 0720 "7.2.2.2 Control Procedures"
NNSVCTSTR FSH 0720 "7.2.2.2 Control Procedures"
"7.3.3 SGSN-BSS Flow Control"
"7.3.3.3 Flow Control sending criteria (for both
BVC and MS)"
NNSVCUBLR FSH 0720 "7.2.2.2 Control Procedures"
NRLCMAX FSH 0720 "9.9.3.1 Uplink TBF Using the Acknowledged
CR - X617 Mode"
NSCONNECTION " FSH 86992" "7.4 High Speed Gb Interface"
NSEI FSH 0720 "7.2.1 Sub-Network Service: Frame Relay on
Gb Interface"
"7.3.1 BSSGP Addressing: BSSGP Virtual
Connections (BVCs)"
NSVCI FSH 0720 "7.2.1 Sub-Network Service: Frame Relay on
Gb Interface"
"7.2.2.2 Control Procedures"
380 A30808-X3247-M24-5-7618
System
NSVLI FSH 0720 "7.2.1 Sub-Network Service: Frame Relay on

Gb Interface"
NTWCNDRXP FSH 0418 "10.4.1 Network Controlled Cell Reselection"
NTWCOR FSH 0720 "10.4.1 Network Controlled Cell Reselection"
NTWCREPPIDL FSH 0418 "10.4.1 Network Controlled Cell Reselection"
NTWCREPPTR FSH 0418 "10.4.1 Network Controlled Cell Reselection"
"10.4.1.1 Measurement Reporting"
NUA FSH 0720 "7.1 Physical Layer"
PCMECH FSH 0720 "10.5.2.2 Packet Transfer Mode: Measure-
PCML FSH 0720 "7.1 Physical Layer"
PCUID (FLR object - FSH 0720 "7.1 Physical Layer"
In previous releases it
was called PCUN)
PCUN FSH 0720 REMOVED IN BR6.0
(PTPPKF object)
PERSTLVPRI1 FSH 0420 "9.8.2.6 Uplink Access on PRACH (Access
NCC1THADJC FSH 0418 "10.4.1.2 Radio Link Network Controlled Cell
PFCBBLPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCIBBHIPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCBBMAPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCIBMAPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCIBMAPPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCIBHIPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCIBLPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCIRPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCBRMAXU " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCBRPER " FSH 86774" "7.3.5 Enhanced Flow Control"
A30808-X3247-M24-5-7618 381
System
PFCSBMAPER " FSH 86774" "7.3.5 Enhanced Flow Control"

PFCSBMAPPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCSBHIPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCSBLPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCSRMAXU " FSH 86774" "7.3.5 Enhanced Flow Control"
PFCSRPER " FSH 86774" "7.3.5 Enhanced Flow Control"
PKTNDEC FSH 0720 "9.9.3.1 Uplink TBF Using the Acknowledged
Mode"
"9.9.3.2 Uplink TBF Using the Unacknowl-
edged Mode"
PKTNINC FSH 0720 "9.9.3.1 Uplink TBF Using the Acknowledged
Mode"
edged Mode"
PKTNMA FSH 0720 "9.9.3.1 Uplink TBF Using the Acknowledged
Mode"
edged Mode"
PRPBCCH FSH 0720 "10.5.2.1 Packet Idle Mode: Measurements
for Power Control"
"10.5.3 BTS Output Power"
QSRHPRI CR - X482 "10.3.2 GSM-UMTS Re-selection Algorithm:
RAARET FSH 0720 "10.1.5 Abnormal Cell Re-selection"
RACODE FSH 0720 "9.2 Network Structure"
supporting GPRS"
RACOL FSH 0720 "9.2 Network Structure"
"9.2 Network Structure"
RAENV FSH 0444 "10.7 Link Adaptation"
"10.7.1.3 GPRS: Link Adaptation Algorithm"
RARESH FSH 0720 "10.1.3 Cell Re-selection Algorithm"
REMAL FSH 0720 "7.1 Physical Layer"
SCHWEIPRI1 FSH 0550 "9.9.7.2 Scheduling Process"
382 A30808-X3247-M24-5-7618
System

SNS-SIZE-RETRIES " FSH 86992" "7.4 High Speed Gb Interface"
SNS-CHANGE- " FSH 86992" "7.4 High Speed Gb Interface"
WEIGHT-RETRIES
SNS-CONFIG- " FSH 86992" "7.4 High Speed Gb Interface"
RETRIES
SNS-ADD-RETRIES " FSH 86992" "7.4 High Speed Gb Interface"
STGTTLLIINF FSH 0444 "10.7.1.2 “Quality Traps” Disadvantage"
Coding Scheme"
STARTUP REMOTE " FSH 86992" "7.4 High Speed Gb Interface"
IP ENDPOINT
SNS-DELETE- " FSH 86992" "7.4 High Speed Gb Interface"
RETRIES
TAI --- "9.8.2 TBF Establishment Initiated by the MS
on CCCH/PCCCH"
T1 FSH 0720 "7.3.1.1 BVC Procedures"
T2 FSH 0720 "7.3.1.1 BVC Procedures"
T3 " FSH 86853" "10.2 Network Assisted Cell Change"
T4 " FSH 86853" "10.2 Network Assisted Cell Change"
T3169 FSH 0720 "9.9.3.3 Anomalies During an Uplink TBF"
"9.9.3.4 Release of an Uplink TBF"
T3172 FSH 0720 "9.8.2.6 Uplink Access on PRACH (Access
T3191 FSH 0720 "9.9.4.2 Release of a Downlink TBF"
CR - X617
CR - X617
T391 FSH 0720 "7.2.1.3 Procedures for PVCs"
TAVGT FSH 0720 "10.5.2.2 Packet Transfer Mode: Measure-
TAVGW FSH 0720 "10.5.2.1 Packet Idle Mode: Measurements
for Power Control"
A30808-X3247-M24-5-7618 383
System
TBNCU --- "10.4.2.1 Enhancement of the NCCR G->G

algorithm"
TCONG FSH 0720 "7.2.1.2 Frame Relay Structure"
TCONOFF FSH 0720 "7.2.1.2 Frame Relay Structure"
TDDARFCN FSH 0418 "10.3.3 Handling of UMTS Neighboring Cells"
TDDDIV FSH 0418 "10.3.3 Handling of UMTS Neighboring Cells"
TDDGQO FSH 0418 "10.3.2 GSM-UMTS Re-selection Algorithm:
TEMPCH FSH 0720 "5.7.1 Generalities about Resource Assign-
ments"
"5.7.4.2 TDPC Algorithm"
TEMPPDT FSH 0429 "5.7.1 Generalities about Resource Assign-
ments"
TEXTULTBF ... "4.3.1 Extended Uplink Temporary Block
Flow"
TFAILNCU " FSH 87029" "10.4.2.1 Enhancement of the NCCR G->G
algorithm"
TF1 FSH 0720 "7.3.3 SGSN-BSS Flow Control"
"7.3.3.3 Flow Control sending criteria (for both
BVC and MS)".
TFI --- "9.8.3 TBF Establishment Initiated by the
Network on CCCH/PCCCH"
THPROXT FSH 0720 This parameter has been introduced for an
CR - F287 older SMG release, and it is no longer used
CR - X617 starting from BR6.0 release.
THSULBAL CR - X1495 "9.9.5 Notes About Concurrent TBFs"
TIMEDTBFREL CR - X617 "9.9.4.2 Release of a Downlink TBF"
TIMERPFCBUFFER FSH 86941 "9.9.8 EGPRS/GPRS Scheduler Enhance-
ments for Rel5 Qos Support"
TNSVCBLK FSH 0720 "7.2.2.2 Control Procedures"
TNSVCPTST FSH 0720 "7.2.2.2 Control Procedures"
TNSVCR FSH 0720 "7.2.2.2 Control Procedures"
TNSVCTST FSH 0720 "7.2.2.2 Control Procedures"
TRESEL FSH 0720 "10.1.5 Abnormal Cell Re-selection"
384 A30808-X3247-M24-5-7618
System
TRFPS FSH 0418 "10.4.3 GPRS/EGPRS Traffic Control

Strategy"
TRFPSCTRL CR - X1850 "10.4.1.2 Radio Link Network Controlled Cell
TRFPSCTRLT FSH 0418 This parameter in BR7.0 release is not signifi-
cant.
TRXCAPABILITY --- "9.8.2.4 TBF Establishment for EDGE Mobile
Stations"
TRXMD FSH 0420 "5.5.1 Aspects Related to Carrier Configura-
tion"
"9.8.2.4 TBF Establishment for EDGE Mobile
Stations"
"5.6 Configuration of GPRS Channels in a
Cell"
TSULBAL CR - X1495 "9.9.5 Notes About Concurrent TBFs"
TSNS-PROV " FSH 86992" "7.4 High Speed Gb Interface"
TYPEOfNSVCConf " FSH 86992" "7.4 High Speed Gb Interface"
UDP PORT " FSH 86992" "7.4 High Speed Gb Interface"
UPGRFREQ FSH 0516 "5.7.5.1 Upgrade of Radio Resources"
USF --- "9.8.2 TBF Establishment Initiated by the MS
on CCCH/PCCCH"
USFGRAN " FSH 88930" "5.7.8 Flexible USF Granularity"
WEIGHT_DATA " FSH 86992" "7.4 High Speed Gb Interface"
WEIGHT_SIGNALLI " FSH 86992" "7.4 High Speed Gb Interface"
NG
Attribute Object Feature/CR Chapter
NCGTEMPOFF ADJC --- "10.1.4.1 Handling of Neighboring Cells"

NCGPENTIME ADJC --- "10.1.4.1 Handling of Neighboring Cells"
AMRFRLLCOM BTS " FSH "5.2 Radio Resource Allocation Strategy"
84566"
AMRFRLLPRM BTS " FSH "5.2 Radio Resource Allocation Strategy"
84566"
AMRHRLLCOM BTS " FSH "5.2 Radio Resource Allocation Strategy"
84566"
Tab. 11.2 Attributes and related Managed Objects not specific for GPRS/EGPRS but
affected by PS services
A30808-X3247-M24-5-7618 385
System
AMRHRLL- BTS " FSH "5.2 Radio Resource Allocation Strategy"

PRMRM 84566"
ASCIILLPRM BTS " FSH "5.2 Radio Resource Allocation Strategy"
84566"
ASSLAPD SUBTSLB FSH 0419 "6.3.3 Configuration of Abis Interface"
BSCT17 BSC ---- "8.2 PCU Overload Management"
BSCT18 BSC ---- "8.2 PCU Overload Management"
CCHANTFACT BSC " FSH "10.2 Network Assisted Cell Change"
86853"
CELLGLID TGTFDD CR - X260 "10.3.3 Handling of UMTS Neighboring
Cells"
CELLRESH BTS ---- "10.1.3 Cell Re-selection Algorithm"
CRTSWDLLCO BTS " FSH "5.2 Radio Resource Allocation Strategy"
M 84566"
CRTSWDLLPR BTS " FSH "5.2 Radio Resource Allocation Strategy"
M 84566"
CRTSWSPELL BTS " FSH "5.2 Radio Resource Allocation Strategy"
PRM 84566"
ELLCOM BTS " FSH "5.2 Radio Resource Allocation Strategy"
84566"
ELLPRM BTS " FSH "5.2 Radio Resource Allocation Strategy"
84566"
EUSCN- BSC " FSH "10.4.2.1 Enhancement of the NCCR G-
CRESEL 87029" >G algorithm"
ENFOIAHO BSC FSH 0457 "5.7.7.3 Forced Intracell Handovers of
CR - F092 already established CS Calls"
DGRSTRGY BTS FSH 0457 "5.7.7 Waiting Queue Management"
CR - F092
"5.7.7.1 Pre-emption of PDCH Channels"
CR - X912
CR - X1150
FCRATE CPCU " FSH "7.3.5 Enhanced Flow Control"
86774"
FDDARFCN TGTFDD CR - X260 "10.3.3 Handling of UMTS Neighboring
Cells"
FDDDIV TGTFDD CR - X260 "10.3.3 Handling of UMTS Neighboring
Cells"
FDDQO BTS CR - X260 "10.3.1 GSM-UMTS Re-selection Algo-
rithm: Circuit Switched Case"
386 A30808-X3247-M24-5-7618
System
FDDQMI BTS CR - X260 "10.3.1 GSM-UMTS Re-selection Algo-

CR - X482 rithm: Circuit Switched Case"
"10.3.2 GSM-UMTS Re-selection Algo-
rithm: Packet Switched Case"
FDDSCRMC TGTFDD CR - X260 "10.3.3 Handling of UMTS Neighboring
Cells"
FPER CPCU " FSH "7.3.5 Enhanced Flow Control"
86774"
GLLCOM BTS " FSH "5.2 Radio Resource Allocation Strategy"
84566"
GLLPRM BTS " FSH "5.2 Radio Resource Allocation Strategy"
84566"
GMICROCU ADJC3G " FSH "10.4.2.1 Enhancement of the NCCR G-
87029" >G algorithm"
HSCDS- BTS " FSH "5.2 Radio Resource Allocation Strategy"
DLLCOM 84566"
HSCSDLLPRM BTS " FSH "5.2 Radio Resource Allocation Strategy"
84566"
LAYERID TRX " FSH "5.2 Radio Resource Allocation Strategy"
84566"
MSTXPMAXCH BTS ---- "10.1.2.1 GPRS/EGPRS Path Loss Crite-
rion (C1 Criterion)"
NACC-NCO BSC " FSH "10.2 Network Assisted Cell Change"
86853"
NBLKACGR BTS ---- "9.8.3.2 Discontinuous Reception"
NFRAMEPG BTS ---- "9.8.3.2 Discontinuous Reception"
NTWCARD BSC FSH 0397 "4.2.1 GPRS Channel Coding"
"6.1 Supported BSC Types"
PFCFSUP PCU " FSH "7.3.5 Enhanced Flow Control"
86774"
QSRHI BTS CR - X260 "10.3.1 GSM-UMTS Re-selection Algo-
RNCID TGTFDD CR - X260 "10.3.3 Handling of UMTS Neighboring
Cells"
RXLEVAMI BTS ---- "10.1.2.1 GPRS/EGPRS Path Loss Crite-
rion (C1 Criterion)"
SISGSNREL99 BSC FSH 0420 "7.3.3 SGSN-BSS Flow Control"
FSH 0514
"3.1 GPRS and EGPRS Modulation Prin-
ciples"
A30808-X3247-M24-5-7618 387
System
SLLPRM BTS " FSH "5.2 Radio Resource Allocation Strategy"

84566"
SYSPACK- BSC " FSH "10.2 Network Assisted Cell Change"
SYSSUP 86853"
TH CPCU " FSH "7.3.5 Enhanced Flow Control"
86774"
TF CPCU " FSH "7.3.5 Enhanced Flow Control"
86774"
TDDQO BTS FSH 0418 "10.3.1 GSM-UMTS Re-selection Algo-
TGTCELL ADJC FSH 1928 "10.1.4 Management of GPRS/EGPRS
CR - F119 Neighboring Cells"
"10.1.4.3 Configuration of an Adjacent
Cell supporting GPRS"
TGTCELL ADJC3G CR - X260 "10.3.3 Handling of UMTS Neighboring
Cells"
TUESP ADJC3G FSH 87029 "10.4.2.1 Enhancement of the NCCR G-
>G algorithm"
USECNON- ADJC3G FSH 87029 "10.4.2.1 Enhancement of the NCCR G-
CRESEL >G algorithm"
USRSCPN- ADJC3G FSH 87029 "10.4.2.1 Enhancement of the NCCR G-
CRESEL >G algorithm"
Object Feature Chapter
CPCU FSH 486 "9.10.2 QoS and BSS impacts"

ES " FSH 86992" "7.4 High Speed Gb Interface"
ETHLNK " FSH 86992" "7.4 High Speed Gb Interface"
FRL FSH 0720 "7 Gb Interface"
GBIPLNK " FSH 86992" "7.4 High Speed Gb Interface"
NSVC FSH 0720 "7 Gb Interface"
NSVCIP " FSH 86992" "7.4 High Speed Gb Interface"
NSVLIP " FSH 86992" "7.4 High Speed Gb Interface"
PCMG FSH 0720 "7 Gb Interface"
PCU FSH 0720 "6 Hardware and Software Architecture"
PTPPKF FSH 0720 "4 Radio Interface Description"
Tab. 11.3 GPRS/EGPRS Managed Objects
388 A30808-X3247-M24-5-7618
System
Object Feature Chapter
RNSVLIP " FSH 86992" "7.4 High Speed Gb Interface"

TGTPTPPKF FSH 1928 "10.1.4 Management of GPRS/EGPRS
CR - F119 Neighboring Cells"
Tab. 11.3 GPRS/EGPRS Managed Objects
Object Feature/CR Chapter
ADJC ---- "10.1 Cell Selection and Re-selection"

ADJC3G CR - X260 "10.3.3 Handling of UMTS Neighboring Cells"
SUBTSLB FSH 0419 "6.3.3 Configuration of Abis Interface"
TGTBTS FSH 1928 "10.1.4 Management of GPRS/EGPRS Neighboring
CR - F119 Cells"
TGTFDD CR - X260 "10.3.3 Handling of UMTS Neighboring Cells"
TGTTDD FSH 0418 "10.3.3 Handling of UMTS Neighboring Cells"
TRX --- "10.1 Cell Selection and Re-selection"
Tab. 11.4 Unspecific GPRS/EGPRS Managed Objects affected by PS Services
A30808-X3247-M24-5-7618 389
System
12 Abbreviations
BECN Backward Explicit Congestion Notification
BSN Block Sequence Number
BVC BSSGP Virtual Connection
BVCI BSSGP Virtual Connection Identifier
CS Circuit Switched
DCE Data Circuit-terminating Equipment
DE Discard Eligibility Indicator
DLCI Data Link Connection Identifier
DRX Discontinous Reception
DTE Data Terminal Equipment
FDD Frequency Division Duplex
FECN Forward Explicit Congestion Notification
FR Frame Relay
HA Horizontal Allocation
HCS Hierarchical Cell Structures
HSN Hopping Sequence Number
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IR Incremental Redundancy
LA Location Area
LAC Location Area Code
LAPD Link Access Procedure on the D-channel
LMT Local Maintenance Terminal
MA Mobile Allocation
MAIO Mobile Allocation Index Offset
MCC Mobile Country Code
MCS Modulation and Coding Scheme
MNC Mobile Network Code
MOI Managed Object Instance
NS SDU Network Service Service Data Unit
NS Network Service
NSEI Network Service Entity Identifier
NSVC Network Service Virtual Connection
NSVCI Network Service Virtual Connection Identi-
fier
NSVL Network Service Virtual Link
NSVLI Network Service Virtual Link Identifier
O&M Operation and Maintenance
PAGCH Packet Acces Grant Channel
PCU Packet Control Unit
390 A30808-X3247-M24-5-7618
System
PDCH Packet Data Channel

PDT Packet Data Terminal
PDU Packet Data Network
PDU Packet Data Unit
PPCH Packet Paging Channel
PRACH Packet Random Acces Channel
PS Packet Switched
PSI Packet System Information
PTM Point to Multipoint
P-TMSI Packet Temporary Mobile Subscriber Iden-
tity
PTP Point to Point
PVC Permanent Virtual Circuit
QoS Quality of Service
RA Routing Area
RAC Routing Area Code
RAI Routing Area Identity
RAT Radio Access Technology
TAI Timing Advance Index
TCH Traffic Channel
TDD Time Division Duplex
TLLI Temporary Logical Link Identity ,
TSC Training Sequence Code
UE User Equipment
UMTS Universal Mobile Telecommunication
System
USF Uplink State Flag
VA Vertical Allocation
VLR Visitor Location Register
A30808-X3247-M24-5-7618 391

Gprs

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Gprs

Загружено:

Авторское право:

Доступные форматы

Information

GPRS/EGPRS Global Description

f Important Notice on Product Safety

The same text in German:

Copyright (C) Siemens AG 2006.

Issued by the Communications Group

Technical modifications possible.

Reason for Update

Chapter/Section Reason for Update

3 Changes due to enhancements to current features

1 01/2005 First Edition for new release BR 8.0

2 Siemens Features Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Radio Interface Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.7.1 Mobile Station Classes for Multislot Capabilities . . . . . . . . . . . . . . . . . . . . 86

5 Radio Resources Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6 Hardware and Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8 Load Control for Packet Switched Services . . . . . . . . . . . . . . . . . . . . . . . . 221

9 GPRS/EGPRS Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

9.3.2.1 Attach Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

9.10.1 QoS and RRM procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

10 GPRS/EGPRS Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

10.7.1.1 GPRS: Switching Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

11 Managed Objects and attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Fig. 5.9 Allocation Algorithm implemented in PCU . . . . . . . . . . . . . . . . . . . . . . 126

Fig. 8.1 Example of PTPPKF Distribution During System Initialization . . . . . . . 224

1.2 Structure of the Manual

2 Siemens Features Description

2.1 SBS BR5.5 Feature Description

GPRS: HW and Basic SW for Packet Control Unit (PCU)

Packet Downlink Assignment Procedure on CCCH

GPRS Alignment to SMG 30, 30BIS, 31, 31BIS

GPRS: Non signalling Channels PDCH Static Allocation

GPRS Improvements Step 1

Support of Non-DRX Mode after Change to Packet Idle Mode

Improve Robustness of GPRS Packet DL Assignments

GPRS Improvements Step 2

GPRS Improvements for BR5.5

Change Polling Strategy during Delay TBF Release

2.2 SBS BR6.0 Feature Description

High Capacity BSC

Service Dependent Channel Allocation Strategy - Step1

GPRS: Automatic Horizontal Allocation

Packet Transfer on non BCCH TRXs without Downlink Power Control

Improvement in GPRS scheduler

Miscellaneous Impacts from Q3IG and DIG

Implementation of FRS0457: Service Dependent Channel Allocation Strategy -

Update of FRS 1928 (Miscellaneous impacts from Q3IG and DIG)

GSM-UMTS Cell Selection/Re-Selection

GPRS scheduler Modification

Removal of limitation in the number of GPRS adjacent cells

UMTS-GPRS Cell reselection

New Attribute Definition and Default Adjustment

GPRS Resume Procedure

New PTPPKF Object Management in Case of Unavailability of TRXs Supporting

Reserved GPRS Channels Management Modification

Modification of “Busy Traffic Channel” Calculation

GPRS - Uplink Balanced Assignment of Resources

Enable Throughput of GPRS Attach/Detach Requests to/from Rel. 99

Network Adaptation to Present MS Implementation Regarding PCCCH Operation

Enlarge Fast Polling Period During Delayed DL TBF

Possibility to Enable/Disable Peak Throughput Management Feature

2.3 SBS BR7.0 Feature Description

GPRS: Network Controlled Cell Reselection