GPRS - Siemens

Information

System

GPRS/EGPRS Global Description

A30808-X3247-L24-5-7618

2 A30808-X3247-L24-5-7618

GPRS/EGPRS Global Description InformationSystem

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 mustcomply with the applicable safety standards.Hazardous voltages are present at the AC power supply lines in this electrical equipment. Some components mayalso have high operating temperatures.Failure to observe and follow all installation and safety instructions can result in serious personal injuryor 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 angeschlossenenGeräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.In diesen Anlagen stehen die Netzversorgungsleitungen unter gefährlicher Spannung. Einige Komponentenkönnen auch eine hohe Betriebstemperatur aufweisen.Nichtbeachtung der Installations- und Sicherheitshinweise kann zu schweren Körperverletzungen oderSachschä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 tableA30808-X3247-X910-*-7618, which is shipped with each product. This class also corresponds to the limits for aClass 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 isoperated 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 electromagneticfield / 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 purposescould violate the rights of their owners.

Copyright (C) Siemens AG 2004.

Issued by the Information and Communication Mobile GroupHofmannstraße 51D-81359 München

Technical modifications possible.Technical specifications and features are binding only insofar asthey are specifically and expressly agreed upon in a written contract.

A30808-X3247-L24-5-7618 3

InformationSystem


This document consists of a total of 300 Pages. All pages are issue 5.

Reason for Update

Issue History

Chapter/Section Reason for Update

All New Release BR7.0.

IssueNumber

Date ofIssue

Reason for Update

1 07/2003 First issue for the New Release BR7.0.

2 09/2003 Second issue for BR7.0

3 12/2003 Third issue for BR7.0

4 03/2004 Fourth issue for BR7.0

5 08/2004 Fifth issue for BR7.0

4 A30808-X3247-L24-5-7618


Contents

1 Introductions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1 Generality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2 Structure of the Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Siemens Features Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1 BR5.5 Feature Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 BR6.0 Feature Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 BR7.0 Feature Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 GPRS/EGPRS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1 GPRS and EGPRS Modulation Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3 GPRS/EGPRS Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4 Data Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.5 RLC/MAC Block and Radio Block Structures. . . . . . . . . . . . . . . . . . . . . . . . 403.5.1 RLC/MAC and Radio Block Structures: Data Transfer . . . . . . . . . . . . . . . . 403.5.1.1 RLC/MAC Block and Radio Block Structures for GPRS Data Transfer . . . . 403.5.1.2 RLC/MAC Block and Radio Block Structure for EGPRS Data Transfer. . . . 413.5.2 RLC/MAC Block Structure: Control Signalling . . . . . . . . . . . . . . . . . . . . . . . 42

4 Radio Interface Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.1 GPRS/EGPRS Physical Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2 Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.1 GPRS Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.2 EGPRS Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3 Temporary Block Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.3.1 Multiplexing MSs on the same PDCH: Downlink Direction . . . . . . . . . . . . . 564.3.2 Multiplexing MSs on the same PDCH: Uplink Direction. . . . . . . . . . . . . . . . 574.3.3 Multiplexing MSs on the same PDCH: Configuration. . . . . . . . . . . . . . . . . . 594.4 GPRS/EGPRS Logical Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4.1 Packet Broadcast Control Channel (PBCCH) . . . . . . . . . . . . . . . . . . . . . . . 604.4.2 Packet Common Control Channel (PCCCH) . . . . . . . . . . . . . . . . . . . . . . . . 614.4.3 Packet Data Traffic Channel (PDTCH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.4.4 Packet Dedicated Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.4.5 Coding of GPRS/EGPRS Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . 644.5 Mapping of Logical Channels onto Physical Channels . . . . . . . . . . . . . . . . 644.5.1 PDCH without the Specific GPRS/EGPRS Signalling . . . . . . . . . . . . . . . . . 654.5.2 PDCH Carrying both PBCCH and PCCCH . . . . . . . . . . . . . . . . . . . . . . . . . 654.5.3 PDCH Carrying PCCCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.6 Packet Timing Advance Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.6.1 Initial Timing Advance Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.6.2 Continuous Timing Advance Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.7 Multislot Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.7.1 Mobile Station Classes for Multislot Capabilities . . . . . . . . . . . . . . . . . . . . . 714.7.2 Mapping of Uplink Packet Traffic Logical Channels. . . . . . . . . . . . . . . . . . . 724.7.3 Mapping of Downlink Packet Traffic Logical Channels . . . . . . . . . . . . . . . . 73

A30808-X3247-L24-5-7618 5

InformationSystem


5 Radio Resources Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.1 Enabling Packet Switched Services in a Cell . . . . . . . . . . . . . . . . . . . . . . . 755.1.1 Enabling GPRS Service in the Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.1.2 Enabling EGPRS Service in the Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.1.3 Aspects Related to Carrier Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 805.2 Configuration of GPRS Channels in a Cell . . . . . . . . . . . . . . . . . . . . . . . . . 825.3 Management of Packet Data Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.3.1 Generalities about Resource Assignments. . . . . . . . . . . . . . . . . . . . . . . . . 855.3.2 Horizontal/Vertical Allocation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.2.1 Vertical Allocation Strategy (VA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.2.2 Horizontal Allocation Strategy (HA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.3.2.3 Switching between VA and HA According to Radio Conditions . . . . . . . . . 885.3.2.4 Switching between VA and HA according to Abis Interface Conditions . . . 915.3.2.5 Allocation of Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.3.3 Management of Incoming GPRS/EGPRS Requests . . . . . . . . . . . . . . . . . 925.3.3.1 PCU Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.3.3.2 TDPC Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.3.4 Upgrading Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055.3.4.1 Upgrade of Radio Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055.3.4.2 Upgrade of Abis Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.3.5 Incoming CS Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.3.6 Waiting Queue Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.3.6.1 Pre-emption of PDCH Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105.3.6.2 Pre-emption of PDT Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.3.6.3 Forced Intracell Handovers of Already Established CS Calls . . . . . . . . . . 112

6 Hardware and Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136.1 Supported BSC Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146.1.1 “Standard” BSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.1.2 High Capacity BSC with the Old Rack . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186.1.3 High Capacity BSC with the New Rack . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.1.4 PPCU and PPXU Redundancy and Configuration Rules . . . . . . . . . . . . . 1226.2 BTS Equipment Supporting GPRS and EGPRS. . . . . . . . . . . . . . . . . . . . 1236.3 PCU Frames and Dynamic Allocation on the Abis Interface. . . . . . . . . . . 1246.3.1 Concatenated PCU Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266.3.2 Hardware supporting Flexible Abis Allocation and Concatenated PCU Frames

1296.3.3 Configuration of the Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1316.3.4 Algorithms Regarding Flexible Abis Allocation . . . . . . . . . . . . . . . . . . . . . 1336.3.5 Abis over satellite links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1356.4 Packet Switched Services Supported on CCCH/PCCCH. . . . . . . . . . . . . 135

7 Gb Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387.1 Physical Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397.2 Network Service Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447.2.1 Sub-Network Service: Frame Relay on Gb Interface . . . . . . . . . . . . . . . . 1447.2.1.1 Examples of Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477.2.1.2 Frame Relay Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

6 A30808-X3247-L24-5-7618


7.2.1.3 Procedures for PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547.2.2 Network Service Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557.2.2.1 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567.2.2.2 Control Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567.3 BSSGP Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577.3.1 BSSGP Addressing: BSSGP Virtual Connections (BVCs). . . . . . . . . . . . . 1587.3.1.1 BVC Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617.3.2 Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617.3.3 SGSN-BSS Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1627.3.3.1 MS Flow Control Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667.3.3.2 BVC Flow Control Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687.3.3.3 Flow Control sending criteria (for both BVC and MS) . . . . . . . . . . . . . . . . 172

8 Load Control for Packet Switched Services . . . . . . . . . . . . . . . . . . . . . . . . 1758.1 Dynamic PTPPKF Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1758.1.1 System Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778.1.2 Creation of a PCU Object and Enabling a NSVC for It . . . . . . . . . . . . . . . 1788.1.3 PCU Crash. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818.1.4 PCU Comes Back in Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1828.1.5 Time Needed to Execute PTPPKF Reconfiguration . . . . . . . . . . . . . . . . . 1848.2 PCU Overload Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

9 GPRS/EGPRS Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1869.1 Mobile Stations for Packet Switched Services . . . . . . . . . . . . . . . . . . . . . . 1869.2 Network Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1869.3 Mobility Management Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879.3.1 Mobility Management States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879.3.1.1 IDLE State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1889.3.1.2 STAND-BY State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1889.3.1.3 READY State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1899.3.2 Mobility Management Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1909.3.2.1 Attach Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1909.3.2.2 Detach Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1929.4 Radio Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1929.4.1 Packet Idle State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1929.4.2 Packet Transfer State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1939.5 Correspondence between RR States and MM States . . . . . . . . . . . . . . . . 1939.6 Packet Data Protocol Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1939.6.1 INACTIVE State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1949.6.2 ACTIVE State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1949.7 Activation and Deactivation of a PDP Context . . . . . . . . . . . . . . . . . . . . . . 1959.7.1 PDP Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1959.7.2 PDP Context Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1969.8 Access to the Network (Establishment of a TBF). . . . . . . . . . . . . . . . . . . . 1969.8.1 Medium Access Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1969.8.2 TBF Establishment Initiated by the MS on CCCH/PCCCH . . . . . . . . . . . . 1979.8.2.1 8 Bit or 11 Bit Uplink Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1979.8.2.2 Establishment using a One Phase Access . . . . . . . . . . . . . . . . . . . . . . . . 199

A30808-X3247-L24-5-7618 7

InformationSystem


9.8.2.3 TBF Establishment using a Two Phases Access . . . . . . . . . . . . . . . . . . . 2009.8.2.4 TBF Establishment for EDGE Mobile Stations . . . . . . . . . . . . . . . . . . . . . 2029.8.2.5 Contention Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2039.8.2.6 Uplink Access on PRACH (Access Persistence Control) . . . . . . . . . . . . . 2049.8.3 TBF Establishment Initiated by the Network on CCCH/PCCCH. . . . . . . . 2059.8.3.1 Network Operation Modes for Paging. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2079.8.3.2 Discontinuous Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2089.8.4 Relative Reserved Block Period Field (RRBP) . . . . . . . . . . . . . . . . . . . . . 2119.8.5 Polling Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2129.9 RLC Data Block Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2139.9.1 Acknowledged Mode for RLC/MAC Operation . . . . . . . . . . . . . . . . . . . . . 2139.9.1.1 GPRS Acknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2139.9.1.2 EGPRS Acknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2149.9.2 Unacknowledged Mode for RLC/MAC Operation . . . . . . . . . . . . . . . . . . . 2169.9.3 Operations on Uplink TBF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2169.9.3.1 Uplink TBF Using the Acknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . 2169.9.3.2 Uplink TBF Using the Unacknowledged Mode . . . . . . . . . . . . . . . . . . . . . 2189.9.3.3 Anomalies During an Uplink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2189.9.3.4 Release of an Uplink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2199.9.4 Operations on Downlink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2229.9.4.1 Acknowledged and Unacknowledged Modes on Downlink TBFs . . . . . . . 2229.9.4.2 Release of a Downlink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2239.9.5 Notes About Concurrent TBFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2259.9.6 Suspend/Resume Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2269.9.7 Notes About GPRS/EGPRS TBF Scheduling. . . . . . . . . . . . . . . . . . . . . . 2309.9.7.1 Supported QoS Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2319.9.7.2 Scheduling Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

10 GPRS/EGPRS Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23410.1 Cell Selection and Re-selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23410.1.1 Measurements for Cell Selection and Re-selection . . . . . . . . . . . . . . . . . 23410.1.2 Cell selection and Re-selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . 23610.1.2.1 GPRS/EGPRS Path Loss Criterion (C1 Criterion) . . . . . . . . . . . . . . . . . . 23610.1.2.2 C31 Criterion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23710.1.2.3 C32 Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23910.1.3 Cell Re-selection Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24010.1.4 Management of GPRS/EGPRS Neighboring Cells. . . . . . . . . . . . . . . . . . 24210.1.4.1 Handling of Neighboring Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24210.1.4.2 GPRS/EGPRS Neighboring Cells and Involved Parameters . . . . . . . . . . 24410.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUE . . . . . . . . . . . . . . . 24510.1.4.4 Configuration of an Adjacent Cell with GSUP= FALSE . . . . . . . . . . . . . . 24610.1.5 Abnormal Cell Re-selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24710.2 Cell Re-selection from GSM/GPRS/EGPRS Network to UMTS Network . 24810.2.1 GSM-UMTS Re-selection Algorithm: Circuit Switched Case . . . . . . . . . . 24810.2.2 GSM-UMTS Re-selection Algorithm: Packet Switched Case . . . . . . . . . . 24910.2.3 Handling of UMTS Neighboring Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25010.3 Network Controlled Cell Reselection and Traffic Control Management . . 25210.3.1 Network Controlled Cell Reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

8 A30808-X3247-L24-5-7618


10.3.1.1 Measurement Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25510.3.1.2 Radio Link Network Controlled Cell Reselection Algorithm . . . . . . . . . . . . 25610.3.2 GPRS/EGPRS Traffic Control Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 25810.3.2.1 Network Controlled Cell Reselection Algorithm for Traffic Control Strategy . .

25910.4 Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26110.4.1 Power Control Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26210.4.2 Measurement at the MS Side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26310.4.2.1 Packet Idle Mode: Measurements for Power Control. . . . . . . . . . . . . . . . . 26310.4.2.2 Packet Transfer Mode: Measurements for Power Control . . . . . . . . . . . . . 26410.4.2.3 Derivation of Channel Quality Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26510.4.3 BTS Output Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26510.5 Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26510.5.1 Link Adaptation for GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26710.5.1.1 GPRS: Switching Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26710.5.1.2 “Quality Traps” Disadvantage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27010.5.1.3 GPRS: Link Adaptation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27110.5.2 Link Adaptation for EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27110.5.2.1 EGPRS: Switching Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27210.5.2.2 EGPRS: Link Adaptation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27710.5.3 Selection of the Candidate Initial Coding Scheme. . . . . . . . . . . . . . . . . . . 280

11 Database Parameters and Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

12 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

A30808-X3247-L24-5-7618 9

InformationSystem


IllustrationsFig. 3.1 Basic GMSK Constellation of Signal Vectors. . . . . . . . . . . . . . . . . . . . . 30

Fig. 3.2 Basic 8 PSK Constellation of Signal Vectors . . . . . . . . . . . . . . . . . . . . . 31

Fig. 3.3 GPRS/EGPRS Network Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Fig. 3.4 Protocol Stack for Data Transmission in GPRS/EGPRS Network. . . . . 35

Fig. 3.5 Data Flow across Protocol Layers in case of GPRS/EGPRS(MSC1...MSC6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Fig. 3.6 Data Flow across Protocol Layers in case of EGPRS(MSC7...MSC9) . 37

Fig. 3.7 Data Flow from the SGSN to the MS. . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Fig. 3.8 RLC/MAC block’s structure for Data Transfer . . . . . . . . . . . . . . . . . . . . 40

Fig. 3.9 Radio Block structure for Data Transfer on the “Um” Interface . . . . . . . 40

Fig. 3.10 RLC/MAC Block structure for Data Transfer with one RLC Data Block field41

Fig. 3.11 RLC/MAC Block structure for Data Transfer with two RLC Data block fields41

Fig. 3.12 Radio Block for Data Transfer with one RLC Data Block field . . . . . . . . 42

Fig. 3.13 Radio Block for Data Transfer with two RLC Data Block field . . . . . . . . 42

Fig. 3.14 RLC/MAC Block Structure for Control Messages . . . . . . . . . . . . . . . . . 42

Fig. 3.15 Radio Block for Control Messages (Signalling).. . . . . . . . . . . . . . . . . . . 42

Fig. 4.1 Packet Data Channel (PDCH) within a TDMA frame. . . . . . . . . . . . . . . 45

Fig. 4.2 Multiframe Structure for a PDCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Fig. 4.3 GPRS Coding Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Fig. 4.4 Coding of the RLC/MAC Block using CS-1 . . . . . . . . . . . . . . . . . . . . . . 50

Fig. 4.5 EGPRS Coding Schemes and Families. . . . . . . . . . . . . . . . . . . . . . . . . 52

Fig. 4.6 Interleaving of MCS9 Coded Data into Two Consecutive Normal Bursts54

Fig. 4.7 Interleaving of MCS6 Coded Data into Four Consecutive Normal Bursts .55

Fig. 4.8 Multiplexing Mobile Station on the same PDCH (Downlink) . . . . . . . . . 57

Fig. 4.9 Multiplexing Mobile Station on the same PDCH (Uplink). . . . . . . . . . . . 58

Fig. 4.10 Example of Mapping of the PBCCH Channel. . . . . . . . . . . . . . . . . . . . . 61

Fig. 4.11 Packet Common Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Fig. 4.12 Example of Mapping of the PCCCH Channel. . . . . . . . . . . . . . . . . . . . . 62

Fig. 4.13 Example of Mapping of two PCCCH Channels.. . . . . . . . . . . . . . . . . . . 63

Fig. 4.14 Example of Mapping of Logical Channels in the Physical Channel (Down-link Direction). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Fig. 4.15 Example of Mapping of Logical Channels in the Physical Channel (UplinkDirection).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Fig. 4.16 Example of Downlink Configuration with PBCCH and PCCCH Channels .67

Fig. 4.17 Example of Uplink Configuration with PRACH Channel. . . . . . . . . . . . . 68

Fig. 4.18 Continuous Timing Advance Update Feature . . . . . . . . . . . . . . . . . . . . 70

Fig. 4.19 Example of Multislot Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Fig. 5.1 Example of TRXs enabled to support Packet Switched Services.. . . . . 77

Fig. 5.2 Example of TRXs enabled to support GPRS and EGPRS. . . . . . . . . . . 80

Fig. 5.3 Example of GPRS/EGPRS configuration. . . . . . . . . . . . . . . . . . . . . . . . 84

10 A30808-X3247-L24-5-7618


Fig. 5.4 Example of Vertical Allocation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 87

Fig. 5.5 Example of Horizontal Allocation Algorithm . . . . . . . . . . . . . . . . . . . . . . 88

Fig. 5.6 Example of a Cell Configured with Five TRXs. . . . . . . . . . . . . . . . . . . . . 89

Fig. 5.7 Allocation Algorithm followed by the PCU. . . . . . . . . . . . . . . . . . . . . . . . 99

Fig. 5.8 Allocation Algorithm followed by the TDPC . . . . . . . . . . . . . . . . . . . . . 104

Fig. 6.1 Hardware and Software Entities supporting the GPRS/EGPRS technology113

Fig. 6.2 View of the BSC Rack with and without PPCU Boards. . . . . . . . . . . . . 116

Fig. 6.3 View of the “High Capacity” BSC with the Traditional Rack.. . . . . . . . . 118

Fig. 6.4 High Capacity BSC with the New Rack . . . . . . . . . . . . . . . . . . . . . . . . 122

Fig. 6.5 Fundamental Principle of Concatenated PCU Frames . . . . . . . . . . . . . 126

Fig. 6.6 Abis Mapping for a downlink MCS9 radio block requiring 5 Abis subslots .128

Fig. 6.7 High Capacity BSC: Relationship between PCU Frames and Abis Alloca-tion according to the BTSE Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Fig. 6.8 Standard BSC: Relationship between PCU Frames and Abis Allocationaccording to the BTSE Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Fig. 6.9 BSC handling of BTS Equipment with Software Releases not supportingthe Abis Dynamic Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Fig. 6.10 Mapping of CCCH/PCCCH Channels on the Abis Interface. . . . . . . . . 136

Fig. 6.11 CCCH/PCCCH Message Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Fig. 7.1 Gb Interface: Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Fig. 7.2 Different Connection Types between the BSC and the SGSN. . . . . . . 140

Fig. 7.3 Example of Frame Relay Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Fig. 7.4 Example of Frame Relay Link (GTS=3). . . . . . . . . . . . . . . . . . . . . . . . . 143

Fig. 7.5 Example of Frame Relay Link (GTS=3&4&5&6). . . . . . . . . . . . . . . . . . 143

Fig. 7.6 Example of Frame Relay Link (GTS=3&4&7&8). . . . . . . . . . . . . . . . . . 143

Fig. 7.7 Network Service Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Fig. 7.8 Gb Interface with a Frame Relay Network . . . . . . . . . . . . . . . . . . . . . . 145

Fig. 7.9 Creation of a NSVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Fig. 7.10 BSC Configured with One PCU and Two FR Links (64 kbit/s each). . . 148

Fig. 7.11 BSC Configured with One PCU and Two FR Links (128 kbit/s each one)..149

Fig. 7.12 BSC Configured with Two PCUs and Two FR Links each one. . . . . . . 150

Fig. 7.13 Frame Relay Network Connecting two DTE Devices . . . . . . . . . . . . . . 152

Fig. 7.14 Frame Relay Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Fig. 7.15 Periodic Polling Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Fig. 7.16 Distribution of Packet Switched Data Traffic among Different Cells . . . 160

Fig. 7.17 Cascaded Flow Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Fig. 7.18 Token Leaky Bucket (in SGSN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Fig. 7.19 Closed Loop Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Fig. 7.20 Example Cell Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Fig. 7.21 MS-FLOW-CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Fig. 7.22 SGSN does not answer with MS-FLOW-CONTROL-ACK message . . 173

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

A30808-X3247-L24-5-7618 11

InformationSystem


Fig. 8.2 Example of PTPPKF Distribution when a New PCU is Created - Step 1. .179

Fig. 8.3 Example of PTPPKF Distribution when a New PCU is Created - Step 2. .180

Fig. 8.4 Example of PTPPKF Distribution in Case of PCU Crash. . . . . . . . . . . 181

Fig. 8.5 Example of PTPPKF Distribution when a PCU Comes Back in Service . .183

Fig. 9.1 Network Structure: Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Fig. 9.2 Mobility Management States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Fig. 9.3 Radio Resource States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Fig. 9.4 Packet Data Protocol States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Fig. 9.5 Coding of the 11 Bit Access Burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Fig. 9.6 One Phase Access on PCCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Fig. 9.7 Two Phases Access on CCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Fig. 9.8 Packet Access Reject Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Fig. 9.9 TBF Establishment Initiated by the Network on PCCCH . . . . . . . . . . . 207

Fig. 9.10 Behavior of T3182 Timer and N3102 Counter . . . . . . . . . . . . . . . . . . . 218

Fig. 9.11 Detection of Anomalies during an Uplink TBF on the Network Side . . 219

Fig. 9.12 Release of an Uplink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Fig. 9.13 Release of Resources on the Network Side during an Uplink TBF (in caseof T3169 timer expiration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Fig. 9.14 Control Procedure Executed by the Network during a Downlink TBF . 223

Fig. 9.15 Release of a Downlink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Fig. 9.16 Suspend Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Fig. 9.17 Resume Procedure (the MS has remained in the same cell - SuccessfulResume) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Fig. 9.18 Resume Procedure (The MS has changed the Routing Area) . . . . . . 230

Fig. 10.1 Management of Adjacent Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Fig. 10.2 Network Controlled Cell Reselection Procedure . . . . . . . . . . . . . . . . . 255

Fig. 10.3 CS1 and CS2 Throughput Depending on C/I (dB). . . . . . . . . . . . . . . . 266

Fig. 10.4 Gross Throughput Depending on CS and C/I (dB) . . . . . . . . . . . . . . . 268

Fig. 10.5 BLER as Function of C/I (dB) for all GPRS Coding Schemes . . . . . . . 269

Fig. 10.6 Simulation Results for Family A (+MCS1) without IR . . . . . . . . . . . . . 272

12 A30808-X3247-L24-5-7618


1 Introductions

1.1 GeneralityWith the implementation of the second generation of the mobile systems, due to thedigital transmission mode they use, not only pure speech transmission, but also low ratedata transmission and several supplementary services have been provided to the finalusers.

Nevertheless, since needs for mobile data transmission are rapidly increasing due to thecurrent world wide activities based on the exchange of big amount of informations withthe minimum time delay and maximun efficiency the growth in the area of data transmis-sion is much higher and faster than in the area of speech transmission.

In principle, a higher data transmission rates in the GSM network can be achieved bythe HSCSD feature (High Speed Circuit Switched Data). With HSCSD it is possible tomatch the ISDN transmission rate, by combining four timeslots of the TDMA frame.

One disadvantage of the HSCSD feature, however, is the circuit switched data transmis-sion that it requires and it uses; in fact when circuit switched connections are used thefollowing limitations arise:– efficient resource management becomes difficult to reach.– additional costs arise for the user.

For this reason the HSCSD technology is essentially suited for whose applicationsinvolving high, but constant, transmission rates (e.g., videotelephony).

To further increase data rates, exceeding HSCSD limits, the General Packet DataService (GPRS) has been developed.

GPRS is intended to provide the possibility of transmitting large volumes of data in avery short time; on the other hand it ensures a better management of availableresources, which will:– 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 about150-170 kbit/s per each user.

The incoming third generation of mobile networks, however, requires, for its forthcomingmultimedia applications, much more bandwidth, at least 384 kbit/s. The EnhancedGeneral Packet Data Service (EGPRS) represents the GPRS upgrade and offers theopportunity to achieve those high data rates by preserving the most important GSM airinterface features (e.g. 200 kHz channeling, TDMA access type, cell planningprocesses), by introducing a new modulation scheme (8 PSK instead of GMSK). Thismeans that EGPRS will rely completely on underlying GSM functionality.

Due to its GSM/GPRS compatibility EGPRS is the optimal packet data feature for estab-lished GSM operators, it provides a high protection for old investments and requires onlysmall new investments. Looking at the fact that only a limited number of operators percountry have been assigned UMTS licenses, EGPRS is also a good opportunity forthose operators (so called “UMTS-losers”) to make an evolutionary step to their mobilenetworks and provides the opportunity to offer in advance services normally offered by3rd generation networks.

For this reason it is expected that both UMTS and GPRS/EGPRS networks will coexistin the near future. UMTS will serve mainly hotspots that require up to 2 Mbit/s data

A30808-X3247-L24-5-7618 13

InformationSystem


services per subscriber and GPRS/EGPRS will be used to cover the rest of the areaoffering up to 384 kbit/s data services.

1.2 Structure of the ManualThis manual describes in detail the GPRS/EGPRS technology with a particular attentionto the provided features considering that the satisfaction of almost all customers derivesfrom an optimized system’s usability and cost saving. Therefore its main purpose is toallow users in understanding the main characteristics of packet switched (PS) dataservices.

Besides the general description of GPRS and EGPRS features the Siemens solution isdetailed; when a subject is shown, the parameters involved in the subject are alsodescribed.

The manual is organized in the following way: when a feature requires the descriptionof one or more database parameters, each parameter is linked to a specific table of theBSC:CML manual is executed; that describes:– the meaning of the parameter;– the range of the parameter;– its default value;– the commands to which the parameter belongs to.

The Chapter: "2 Siemens Features Description"is completely dedicated to identifying allthe Siemens Feature Sheets (or Change Requests) for the GPRS/EGPRS technology.The following information is shown for each Feature Sheet (or Change Request):– its number and title;– a brief description of the Feature Sheet (or Change Request);– the release of the Feature Sheet (or Change Request).

Finally, in the last chapter of the manual four different tables are inserted:– in the first table all the parameters, related to the GPRS/EGPRS only, which are

discussed in the manual are listed in the alphabetical order. For each parameter oneor more links to the chapters of the manual where the parameter is described and inaddition also a link to the title of the related Feature Sheets (or Change Requests)that introduce or describe the parameter in Siemens technology are introduced; inthis way a user, who wants to know the meaning of one parameter, can find in themanual the location where the parameter is explained and also which are the otherdocuments that add more information on it;

– in the second table the non specific GPRS/EGPRS parameters which are describedin the manual since they are also related to packet switched services are listed inalphabetical order. For each parameter, one or more links to the chapters of themanual where the parameter is described is given. Besides, starting from the param-eters of the BR5.5 release onwards, a link to the features that describe the param-eter is assigned.

– in the third table all the database objects which are related to the GPRS/EGPRStechnology only are listed in alphabetical order. For each object the link to theFeature Sheets (or Change Requests) that introduce or describe the object is given.

– in the fourth table all the non specific GPRS/EGPRS database objects which areinvolved in packet switched (PS) services are listed in the alphabetical order.Foreach object the link to the chapters of the manual that describe it is given; Besidesstarting from the objects of the BR5.5 release onwards, a link to the features thatdescribe the parameter is also executed.

14 A30808-X3247-L24-5-7618


The manual is subdivided in several chapters:• The chapter: "1 Introductions" explains the purpose of the manual and its structure.

A short description is also added to each chapter for introducing the reader to itscontent.

• The Chapter:"2 Siemens Features Description" is the collection of all the SiemensFeatures related to the GPRS/EGPRS technology; when a parameter is describedin the manual, a link to the feature that is affected is executed;

• The Chapter: "3 GPRS/EGPRS Overview" comprises a general discussion aboutthe packet switched (PS) services, showing the new architecture, the protocol stackand the data flow across the several network entities;

• The Chapter:"4 Radio Interface Description" details the GPRS/EGPRS radio inter-face, that means the configuration of new logical channels, their mapping on phys-ical channels and the rules that allow:– sharing the same physical channel among several mobile stations;– the assignment of more physical channels to the same mobile station;

• The Chapter: "6 Hardware and Software Architecture" describes the hardware andsoftware modules that are requested for the introduction of packet switchedservices; in this chapter also the Packet Control Unit toghether with its main featuresare described.

• The Chapter: "5 Radio Resources Management" introduces the not simple conceptof Radio Resource Management and shows how the user can configure theresources of the cell, to allow him to manage both circuit switched (CS) and packetswitched (PS) services; Toghether with the description are provided some examplesare very important to clarify how the resources can be handled;

• The Chapter: "7 Gb Interface" is dedicated to the Gb interface, i.e., the interface thatconnects the BSC to the core network. The frame relay protocol, which character-izes the Gb interface, is described. In particular, the following topics are detailed:– the physical layer;– permanent virtual connections;– examples of configuration;– procedures regarding the Gb interface.

• The Chapter: "8 Load Control for Packet Switched Services" explains the loadcontrol mechanism, that is adopted to correctly distribute the relevantGPRS/EGPRS traffic among the internal resources of the BSC;

• The Chapter:"9 GPRS/EGPRS Procedures"describes the main proceduresregarding the packet switched services (PS), such as:– GPRS/EGPRS attach/detach.– PDP context activation/deactivation.– Packet Data transfer main procedures.

• The Chapter: "10 GPRS/EGPRS Functionalities" introduces the more recentGPRS/EGPRS algorithms regarding:– cell selection/re-selection;– traffic control management;– power control;– link adaptation;

• The Chapter:"11 Database Parameters and Objects" is like an attachment becauseit contains tables that collect all the managed objects and related parametersdiscussed in the manual.

A30808-X3247-L24-5-7618 15

InformationSystem


2 Siemens Features DescriptionThis chapter is the collection of all the features related to the GPRS/EGPRS analyzedand implemented up to the current SBS BR 7.0 release. Each feature is related to itsFeature Sheets (FSH) or corrresponding Change Request (CR). Besides for eachFeature Sheet (or Change Request) the following additional informations are provided:– FSH number and title.– a summary of the content.– the release in which the feature has been implemented.

2.1 BR5.5 Feature Description

FSH 0720

CR - F017

CR - F135

CR - F187

CR - F189

GPRS: HW and Basic SW for Packet Control Unit (PCU)Release BR5.5This feature is the most important one for the GPRS technology; it describes theobjects, the parameters and the functionalities regarding the packet switched dataservice (PS).

Packet Downlink Assignment Procedure on CCCHRelease BR5.5This Change Request introduces the Packet Downlink Assignment procedure, which ismandatory, on the CCCH channel.

GPRS Alignment to SMG 30, 30BIS, 31, 31BISRelease BR5.5This Change Request aligns the system to the last version of the ETSI standard for therelease ‘97.

GPRS: Non signalling Channels PDCH Static AllocationRelease: BR5.5This Change Request introduces the possibility to configure static GPRS channels (notPBCCH or PCCCH) to support data traffic only.

GPRS Improvements Step 1

16 A30808-X3247-L24-5-7618


CR - F190

CR - F191

CR - F205

CR - F287

CR - X232

Release: BR5.5This Change Request introduces some improvements regarding the GPRS service,with the purpose to increase mainly the customer acceptance and performance of theGPRS.

Support of Non-DRX Mode after Change to Packet Idle ModeRelease: BR5.5This Change Request allows the reduction of about 50% of the time that is needed tosend data blocks from the Gb interface to the Mobile Station. The target is reached byaccelerating the packet downlink assignment procedure.

Improve Robustness of GPRS Packet DL AssignmentsRelease: BR5.5This Change Request allows the reduction of the delay that occurs between the trans-mission of downlink assignment messages and the beginning of packet downlink datatransfers (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 averagereduced by 50% with the realization of this CR).

GPRS Improvements Step 2Release: BR5.5This Change Request introduces some improvements regarding GPRS service, toincrease customer acceptance and performance of GPRS.

Decrease Round Trip Delay Time and Improve Web Browsing PerformancesRelease BR5.5This Change Request allows the improvement in the overall performance of the inter-action between many TCP/IP based applications and the GPRS network.

GPRS Improvements for BR5.5Release: BR5.5This Change Request allows the improvement in the GPRS network, by introducing thefollowing features without O&M impacts:- GPRS channels on all the TRXs of a cell;- horizontal allocation.

halam

Highlight

A30808-X3247-L24-5-7618 17

InformationSystem


CR - X366


FSH 0397

FSH 0457

FSH 0503

FSH 0512

Change Polling Strategy during Delay TBF ReleaseRelease: BR5.5This Change Request allows the reduction the time needed by the MS to establish aconcurrent uplink TBF, when the downlink TBF is kept open using the Delay TBFrelease procedure, introduced by CR - F287.

High Capacity BSCRelease BR6.0This feature introduces the first step for the High Capacity BSC (HC BSC step1), thatexploits the rack already used in the previous releases.

Service Dependent Channel Allocation Strategy - Step1Release BR6.0This feature introduces new strategies to manage Circuit Switched, GPRS and HSCSDcalls.

GPRS: Automatic Horizontal AllocationRelease BR6.0This feature introduces the horizontal allocation strategy, and the parameter used tohandle it.

Packet Transfer on non BCCH TRXs without Downlink Power ControlRelease BR6.0This feature introduces the possibility to configure the GPRS service on the TRXschosen by the operator.

18 A30808-X3247-L24-5-7618


FSH 0515

FSH 1928

CR - F092

CR - F119

CR - F208

CR - X260

CR - X263

Improvement in GPRS schedulerRelease BR6.0This feature introduces a new mechanism to schedule data blocks to be sent/receivedto/from the users.

Miscellaneous Impacts from Q3IG and DIGRelease BR6.0This feature introduces the new method to configure both intra-BSC and inter-BSCneighboring cells.

Implementation of FRS0457: Service Dependent Channel Allocation Strategy -Step 1Release: BR6.0This Change Request allows implementation of the Service Dependent Channel Allo-cation Strategy - Step 1, described in FSH 0457, in BR6.0 release.

Update of FRS 1928 (Miscellaneous impacts from Q3IG and DIG)Release: BR6.0This Change Request is an update of FSH 1928.

Rework of default values for Power Control, Handover, Adjacent Cell and BTSRelease: BR6.0This Change Request introduces new default values for some parameters.

GSM-UMTS Cell Selection/Re-SelectionRelease: BR6.0This Change Request allows GSM/UMTS users to perform a cell reselection from GSMcells to UMTS cells.

GPRS scheduler ModificationRelease: BR6.0

A30808-X3247-L24-5-7618 19

InformationSystem


CR - X411

CR - X482

CR - X617

CR - X669

CR - X685

CR - X706

This Change Request is due to the decision to implement only a few parts of FSH 0515.

Removal of limitation in the number of GPRS adjacent cellsRelease: BR6.0This Change Request increases to 32 the maximum number of GSM adjacent cellssupporting GPRS.

UMTS-GPRS Cell reselectionRelease: BR6.0This Change Request allows GPRS users to perform a cell reselection from GSM cellsto UMTS cells without loosing the service.

New Attribute Definition and Default AdjustmentRelease: BR6.0This Change Request introduces the TIMEDTBFREL parameter and new defaultvalues for some GPRS parameters.

GPRS Resume ProcedureRelease: BR6.0This Change Request allows implementation of the GPRS resume procedure alreadyforeseen for next releases.

New PTPPKF Object Management in Case of Unavailability of TRXs SupportingGPRSRelease: BR6.0This Change Request establishes that when all the TRXs supporting GPRS in a cellare excluded from the service, because LOCKED and/or disabled, the related PTPPKFobject instance is excluded from service too (put into DISABLED state).

Reserved GPRS Channels Management ModificationRelease: BR6.0This Change Request introduces the GMAPERTCHRES parameter and a new defini-tion for the GDCH one.

20 A30808-X3247-L24-5-7618


CR - X912

CR - X1086

CR - X1519

CR - X1553

CR - X1681

Modification of “Busy Traffic Channel” CalculationRelease: BR6.0This Change Request establishes that GPRS non reserved channels must be takeninto account in the calculation of BUSY TRAFFIC CHANNELS only if the setting of theDGRSTRGY parameter does not allow GPRS downgrade.

GPRS - Uplink Balanced Assignment of ResourcesRelease: BR6.0This Change Request allows to implement an Uplink Balanced assignment ofresources; 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 indownlink and uplink directions (Multi-slot mobiles class 6,7,10,11 and 12).

Enable Throughput of GPRS Attach/Detach Requests to/from Rel. 99Release: BR6.0This Change Request allows stopping discarding the ATTACH ACCEPT messagewhen it contains optional fields; without this CR the discarding happened when usingRel. 99 Handset in BR6.0 (Rel. 98) networks.

Network Adaptation to Present MS Implementation Regarding PCCCH OperationRelease: BR6.0This 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 toanother cell or loss of connection.

Enlarge Fast Polling Period During Delayed DL TBFRelease: BR6.0This Change Request allows speeding up the MS uplink establishment during theDelay DL TBF Release Time. Improvements of about 80 ms are expected on PingDelay time and also on FTP throughput.

A30808-X3247-L24-5-7618 21

InformationSystem


CR - X1706


FSH 0418

FSH 0419

FSH 0420

FSH 0429

Possibility to Enable/Disable Peak Throughput Management FeatureRelease: BR6.0This Change Request allows the possibility to Operator to enable/disable the PeakThroughput Management feature. This permits to reduce the time to perform the GPRSAttach procedure.

GPRS: Network Controlled Cell ReselectionRelease BR7.0This feature introduces new strategiesfor the management of both GPRS and EGPRSpacket switched data traffic. It introduces new parameters for packet switched cell re-selection from GSM to UMTS.

Support of CS3, CS4Release BR7.0This feature introduces new GPRS coding schemes.

MAC Protocol Enhancements for EDGERelease BR7.0This feature introduces the enhancements regarding the MAC protocol that is used forthe support of the EDGE functionality. The feature sheet also comprises enhancementsregarding both RLC and BSSGP protocols.It introduces some EDGE parameters related to the previous protocols and new flagsto enable and disable GPRS and EGPRS on a cell basis.

EDGE: Flexible Abis Allocation Strategy (FAAS)Release BR7.0This feature introduces a new strategy to manage resources of the Abis interface. Withthis strategy it is possible to assign in a dynamic way, more than one Abis subslot to asingle air timeslot. New PCU frames are also defined.

22 A30808-X3247-L24-5-7618


FSH 0444

FSH 0514

FSH 0516

FSH 0527

FSH 0550

CR - X0158

Link Quality Control: (LA)Release BR7.0This feature introduces the link adaptation algorithms regarding both GPRS andEGPRS services.

Gb/MS flow control (GPRS Step 1 Completion)Release BR7.0This feature describes the flow control procedure on the Gb interface.

GPRS Resource ManagementRelease BR7.0This feature introduces new algorithms to manage radio resources when packetswitched services (GPRS/EGPRS) are enabled.

2nd Step of the High Capacity BSCRelease BR7.0This 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 HighCapacity BSC”.

EGPRS/GPRS Scheduler EnhancementsRelease BR7.0This feature introduces enhancements in the process that manages the transmis-sion/reception of GPRS/EGPRS radio blocks on the radio interface.

Enable/Disable GPRS and/or EDGE Support on Call BasisRelease: BR7.0This Change Request introduces two new attributes related to the PTPPKF object, toenable GPRS and EGPRS services on cell basis.

A30808-X3247-L24-5-7618 23

InformationSystem


CR - X1150

CR - X1152

CR - X1362

CR - X1454

Improvement of CS Channel AllocationRelease: BR7.0This Change Request introduces changes in PDCH pre-emption, when a circuitswitched call must be served in a congested cell.

Adaptation of FRS AEK0514A to the Current ImplementationRelease: BR7.0The current description of FRS AEK514 (MS/Gb flow control) does not reflect thecurrent implementation. It contains the general and unuseful information that someparameters are under investigation. The requirement contained in this ChangeRequest asks the alignement of the FRS to the current implementation (FeatureSheet).

New O&M Attributes for Network Controlled Cell ReselectionRelease: BR7.0This Change Request asks the addition of the following attributes that are necessaryfor the implementation of the feature: Network Controlled Cell ReselectionADJC object:NCGRESOFF,NCGTEMPOFF,NCGPENTIME,NCC1THRSADJCPTPPKF object:NCC1THRS,NCSAMERA,NCRARESH .The following attribute have to be added for the Handover from GSM to UMTSBSC object:BSCT3121

Multiplexing of GPRS and EGPRS on the same TimeslotRelease: BR7.0This Change Request allows multiplexing of GPRS and EGPRS mobile stations on thesame PDCH dynamically.The possibility of multiplexing GPRS and EGPRS mobiles onthe same channel enables that the customer is not forced to have separeted channelsfor 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 dueto waste of resources.

24 A30808-X3247-L24-5-7618


CR - X1495

CR - X1507

CR - X1656

Uplink Balanced Assignment of E(GPRS) ResourcesRelease: BR7.0This Change Request introduces a new strategy to better manage concurrent TBFs, forMobile Staions able to use more than one timeslot in the uplink direction.Mobilestations (MS) which provides a dynamic allocation of the number of uplink and downlinktime slots (multislot class 6, 7, 10, 11 and 12) should be able to use the maximumnumber of time slots in uplink direction compatible with dynamic allocation for datatransfer, if there is a considerable amount of uplink traffic available. The MS indicatesthe amount of uplink data with a special parameter in the channel request descriptionand the newtwork should take this parameter into account by assigning the time slotsfor both uplink and downlink TBFs. Tests with a multislot class 6 MS have shown, thatwith two simultaneous ftp connections, one in uplink the other in downlink direction(duplex FTP), in case of downlink preferred configuration (3+1) the downlinkthroughput is worse than in uplink preferred configuration (2+2). This is due to the factthat ftp connections are based on TCP as transfer protocol, which causes as acknowl-edged protocol also traffic in the opposite direction. Because of the delayedacknoledgement packets (caused by the queue in MS or notebook which is always fullconcerning the uplink traffic) the downlink transfer is reduced (stalled condition).Also pure UL traffic like FTP put is not handeled optimally, since the network changesto downlink preferred allocation as soon as first DL TBFs for TCP/IP acknowledgmentsarrive.

GPRS Improvements on Ping DelayRelease: BR7.0With this CR it is requested to decrease the Ping Delay Time by reducing the internalPCU queue from 3 to 1(or max2) radio blocks, that means more or less no internalqueueing but immediate sending of data when available. This improvement can saveapproximately 20-40 msec per direction and it's requested only on PPXU.

Shortening of Duration of Immediate Assignment Procedure for GPRSRelease: BR7.0This Change Request allows to transmit immediate assignment message after that, oneach PDCH involved in TBF and which has to be aligned, only two complete uplinkPCU frame have been received by BSC. In this way the duration of Immediate Assign-ment procedure is reduced.

A30808-X3247-L24-5-7618 25

InformationSystem


CR - X1738

CR - X1742

GPRS/EGPRS: Improvement of ABIC/PCUX Interface to Shorten PCU reactiontimeRelease: BR7.0With this Change Request it's requested to furtherly shorten PCU reaction times (roundtrip Delay on Abis, Abis-GB and Gb-Abis crossing times), by improving AbIC-PCUXinterface.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 ULframes are segmented into 4 parts, allowing the parallel processing between receivinginformation from the Abis and sending data to Pentium (SW modifications required onboth AbIC and PCUX).2) DownLink (DL) Frame Request from DSP moved to roughly 9 - 6.5 ms before startingAbis transmission (currently 20 - 16 ms). This allows the parallel processing betweenreceiving data from Pentium and transmission over ABIS interface (SW modificationsrequired on AbIC only).3) DL Block scheduler activated around 5 - 7.5 ms before DL Frame Request (currently20 - 16 ms). The granularity of DL interrupt is lowered to 2.5 msec, allowing the PCUXto implement a very precise and timing mechanism.This change also increases theprobability 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 theseimprovements should further save (with respect to BR 7.0 Step 1) approximately 40msec on PCU round trip time, 20-25 msec on Gb-Abis and some msec on Abis-Gbcrossing time, and it's feasible only on PPXUImportant 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 betweenPCUX Operating System, AbIC and UPK. With the current PPXU card, no furtherimprovements is possible.

Enable/Disable of Delayed DL TBF During Mobility Management

26 A30808-X3247-L24-5-7618


CR - X1850

CR - X1869

Release: BR7.0IIn this Change Request it is requested to maintaine active the delayed TBF also duringMobility management procedures considering always the peak throughput informationfor the assignment of resourses.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 disabledelayed TBF release during Mobility Management procedure in order not to have prob-lems with other customers. When delayed TBF release during MM procedures isdisabled (current implementation):the assignment of resourses is done using the peak throughput information every timethe TBF is established for the different procedures (signalling or data). This means forexample that 1 TS will be assigned for signalling procedures and more TS for datadepending on the information sent by SGSN. esourses).When delayed TBF release during MM procedures is enabled (to optimise GPRSattach time):the assignement of resourses is done using the peak throughput information but theTBF in this case is maintained active during "transaction" from signaling to data. Takingthe example made before, this means that 1 TS will be assigned for signalling proce-dures and an upgrade procedure will be activated on the same TBF to assign more TSfor data.

No “ping_pong” behaviour for mobiles which do not transmit packet cell changefailureRelease: BR7.0This Change Request allows to prevent “ping_pong” effect due to questionable MobileStation behaviour during Netowrk Controlled Cell Reselection.To handle this event theBSC has not to order to mobile to move again into this adjacent target cell , inspite 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’sTLLI 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 inits cell change.This procedure requires also that BSC stores informations related tomobile after the end of each TBF at least for the time STGTTLLIINF ( storage TLLI Info).

Disable CS3&CS4Release: BR7.0Siemens is introducing the GPRS CS3&CS4 in BR7.0. Currently the CS3&CS4 featrueis dependent on the EDGE activation. It is activated when EDGE is on and de-activatedwhen EDGE is off. The Siemens customer Cingular has decided not to launch GPRSwith CS3&CS4 in all their markets. Therefore this CR allows to enable/disable theCS3&CS4 feature independently from EDGE feature activation

A30808-X3247-L24-5-7618 27

InformationSystem


CR-X2132

CR X-2199

CR X-2230

CR X-2263

Title . Removal of BSS restrictions in extended band.Release: BR7.0Description: This Change Request requires to remove some limitations on

the GPRS and FHSY.For the GPRS the GSUP can be set alsoin a different band that the BCCH one. It is left to the userchoiche the decision to enable the GPRS on the Extendedband. For FHSY the new implementation allows the configura-tion of FH laws in the extended band overlapping into theprimary band. No overlapping between primary/extended bandand DCS shall be kept

Title: Common BCCH Improvements for 900 and 1800MhzRelease: BR 7.0Description: This Change Requests asks the implementation of the patch

solution described in the Change Request 1300 (CommonBCCH for Cingular - extension to BR 7.0) also for the frequen-cies 900 / 1800. The CR1300 asks to extend to the release BR7.0 the patch provided with the CR 688: “Modification ofCommon BCCH Implementation via Patch”. The customerasks the use of the common BCCH and (E)GPRS in the innerarea.Besides currently there are in progress commercial nego-tiations with the customer Eurotel in Czech Republic. Siemenshas the big opportunity to swap NOKIA out of the customer’snetwork. For the reason that Nokia has already implementedthe Common BCCH feature”, the patch solution described inthe Change Request is the precondition for a successfulcommercial strategy.

Title: Enhancement of throughput of 8PSK Mobile Stations whenmultiplexed with GMSK Mobile Stations

Release: BR 7.0Description: This change request asks to implement the requirements

described in the FRS AEK550. The throughput decreasing ofEDGE Mobile Station in 8PSK modulation could be atmaximum at 35% with BLER = 0 (no interference) and atmaximum 31% in the normal field condition while currrently itsdegrading is near to 70%.

Title: Common BCCH allowing E(GPRS) in the complementaryBand.

Release: BR 7.0Description: This Change Request enables the usage of a common BCCH

on the 900MHz frequency and it allows the releases of theGPRS/EGPRS services on both 900 and 1800 MHz.

28 A30808-X3247-L24-5-7618


CR X-2313

CR X-2325

Title: Enable Directed Retry to UMTS Independent of Enable Imper-ative Handover HO).

Release: BR 7.0Description: This Change Request asks to enable/disable the Directed

Retry to UMTS independently from the setting of theenable/disable flag of the imperative Handover to UMTS. TheFRS AEK0490 shall be updated accordingly to this ChangeRequest.

Title: (E) GPRS improvements on first ping and gap between IAMCDand PRR/TBF start

Release: BR7.0Description: This Change Request asks the following improvements for the

GPRS/EGPRS system: 1) For the First Ping the number of thePDT 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 PCUframes are used. 2) In the current load there is a gap of roughly350-450ms between the IACMD and the PRR in case of 2phase access. For this reason a reduction/optimization of theoverall delay for all kinds of the PRR/TBF start has to beapplied for cases with both idle channels as weel as activechannels. 3) In the current load the BCCH change mark ischanged about every 15 minutes to refresh the system info.The Mobile Station will release the ongoing TBF to read all theincoming systeminfo even if they are not changed. Therefore itis requested to enlarge the repetition rate to refresh the systeminfo in order to decrease the number of the TBF released in thenetwork. 4) Improvement and Optimization of the GPRS andEGPRS Link Adaptation Thresholds.

A30808-X3247-L24-5-7618 29

InformationSystem


3 GPRS/EGPRS OverviewThe General Packet Radio Service (GPRS) and the Enhanced General Packet RadioService (EGPRS) allow packet switched data transmission on the framework providedby the GSM mobile network.

When the GPRS/EGPRS technology is not configured, the GSM/DCS network works incircuit switched connection mode, i.e., it gives to the customer the exclusive use of acertain amount of bandwidth for the duration of the requirement. The connection is setup on demand and released when the caller breaks the connection. Circuit switchedconnections (CS) are what is provided by the GSM architecture for speech and dataservices. Data transmission with bandwidth larger than 9.6 kbit/s (or larger than 14.4kbit/s, if this higher data rate is enabled) is reached by combining more radio channelsto a given user, by the HSCSD feature. Nevertheless, when a circuit switched connec-tion is established and the user does not transmitt information, which is typical of datatransmission, the specific resources are wasted because they are not available for otherusers requesting the services. In other words, it means that circuit switched connectionsdo not provide an optimized way to support data traffic.

In order to improve and optimize the use of both the network and radio resources, forboth GPRS and EGPRS technology the packet switched (PS) technique has beenimplemented for supporting both data and signalling transfer in an efficient manner.

New GPRS/EGPRS radio channels are defined, and the allocation of these channels isflexible 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 (i.e., the same timeslot can be assigned to

different users at the same time, unlike what happens in GSM);– radio interface resources can be shared dynamically between speech services (i.e.,

circuit switched services) and data services (i.e., packet switched services) as afunction 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 should exhibit one or moreof the following characteristics:• intermittent, non-periodic (i.e., bursts) data transmission;• frequent transmission of small volumes of data;• not frequent transmission of large volumes of data.

iThe well known word EDGE (Enhanced Data rates for the GSM Evolution) applies bothto the circuit switched (CS) and to the packet switched (PS) services. Note that EDGEis mainly a characteristic of the Air Interface, including a new kind of modulation (8PSK,besides the already used GMSK modulation. See for more details the chapter:"3.1 GPRS and EGPRS Modulation Principles").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 isapplied to the packet switched (PS) services. That means, substantially, the coding ofthe radio blocks using a specific set of modulation and coding schemes (MCS1, ..,MCS9), and using new specific RLC/MAC control messages or new specific informationelements in GPRS RLC/MAC control messages. In the current BR 7.0 release, EDGEis applied only to packet services. However, the generic term EDGE is used in O&Mattributes that, in some future release, could be used to define the support of EDGE alsofor the circuit switched (CS) service. In the remainder of this manual, the world EDGEmeans EGPRS and viceversa.

30 A30808-X3247-L24-5-7618


3.1 GPRS and EGPRS Modulation PrinciplesThe GPRS technology is an evolution of the existing GSM technology and it uses thesame modulation scheme, called GMSK (Gaussian Minimum Shift Keying). The GMSKdigital modulation format relies on shifting the carrier 180˚ in phase to produce a binarymodulation scheme capable of delivering 1 bit/symbol (see 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 GPRSChannel Coding") to provide different levels of protection to the packets on the air inter-face.

This modulation scheme, within 200 KHz bandwidth, provides good spectral perfor-mance and an adequate data rates for GSM voice applications, however it cannotsupply fast data services since it only transmits 1 bit/symbol.

The EDGE technology uses the same bandwidth allocated for GSM voice and GPRSdata services, but delivers a higher capacity and fast data services to the mobile networkby using a new modulation scheme called 8 PSK (8-level Phase Shift Keying). With this8PSK modulation, there are eight distinct phase changes that the decoder will look forthe conversion into binary data. Each phase represents a symbol and carries three bitsof information. (see Fig. 3.2).

A30808-X3247-L24-5-7618 31

InformationSystem


Fig. 3.2 Basic 8 PSK Constellation of Signal Vectors

As a consequence, the EDGE’s 8 level-shift keying modulation scheme allows a radiothroughput increase of almost 3 times the radio throughput of GPRS with the samenumber of timeslots with big advantages for the final users. In the following table acomparison of the physical layer parameters is depicted.

With the classical 8 PSK modulation scheme, it is possible during symbol changes forthe signal trajectory to pass through the origin (I/Q value 0,0), which causes both a veryhigh Peak to Average Value (PTA) and a high dynamic range of the signal. To avoid thispossibility, 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 itsprevious starting position.

Nine coding schemes (from MCS1 to MCS9, as described in the chapter: "4.2.2 EGPRSChannel Coding") using both GMSK and 8PSK modulations are introduced and a linkadaptation algorithm allows automatic switching between coding schemes, based onthe radio environment condition. The Tab. 3.1 shows which EDGE coding schemes areGMSK modulated and which are 8 PSK modulated.

GSM EDGEModulation GMSK, 1bit/sym 8 PSK, 3 bit/symSymbol Rate 270833 kbit/s 270833 kbit/sPayload per Burst 114 bit 348 bitGross Rate per TimeSlot

22.8 kbit/s 69.6 kbit/s

GMSK modulated 8 PSK modulated

MCS1 MCS5

MCS2 MCS6

MCS3 MCS7

Tab. 3.1 EGPRS Coding Schemes and their Modulation

32 A30808-X3247-L24-5-7618


3.2 Network ArchitectureGenerally the packet data network establishes a logical connection between the usersbut does not guarantee an immediate access to the transmission network: when moreusers ask the access to the transmission resources at the same time, the network hasto 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 existingone but without substitute it. In fact the network architecture still grants that speech anddata transmission with circuit switched connections (CS) are controlled by the MSC(through the A interface).

Fig. 3.3 GPRS/EGPRS Network Architecture.

But for providing the Packet Switched (PS) services two new network nodes in the GSMcore network have to be 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 atthe same hierarchical level as the MSC and it can be connected to the Base StationSystem (BSS) via a Frame Relay network. It is also possible to connect the SGSN

MCS4 MCS8

MCS9

GMSK modulated 8 PSK modulated

Tab. 3.1 EGPRS Coding Schemes and their Modulation

A30808-X3247-L24-5-7618 33

InformationSystem


and the BSS via nailed-up connections (NUCs) or through point-to-point connec-tions.

The SGSN and the BSC are connected through the Gb interface. It specifies thedata flow and the requested protocols (see the Chapter: "7 Gb Interface") andconsists of connections which carry both data and signalling simultaneously, usingthe Frame Relay protocol. Besides the Gb interface is “standard” and it guaranteesmulti-vendor capabilities.

• Gateway GPRS Support Node (GGSN) : the new 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, but 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 nodescan be interconnected through the so-called “Gp” Interface.

Besides the HLR has to be upgraded with GPRS/EGPRS subscriber information, andoptionally the MSC/VLR can be enhanced for a more efficient coordination of GPRS andnon-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 co-ordination of activities between the MSC and the SGSN, the Gs interfacemust be supported (see Fig. 3.3).

The security management functions for the GPRS/EGPRS technology do not differ forthose implemented for the GSM system: the SGSN performs authentication and ciphersetting procedures based on the same algorithms, keys, and criteria adopted in GSM;the only difference is that GPRS/EGPRS networks require a ciphering algorithm opti-mized for packet data transmission.

In order to access to the packet switched (PS) services, a Mobile Station (a specifc hard-ware and software is needed for being able to provide GPRS services) first makes itspresence known to the SGSN by performing a GPRS attach procedure. It is describedin detail in the chapter: "9.3.2.1 Attach Function".This operation establishes a logical linkbetween the Mobile Station and the SGSN, and it provides the following functions:– paging via the SGSN;– notification of incoming GPRS/EGPRS specific data;– SMS over GPRS;

So at the end of a successful GPRS attach procedure, the SGSN establishes with themobile station a mobility management session, containing information pertaining to, forexample, mobility and security etc.

In order to send and receive packet switched (PS) data, the Mobile Station first activatesthe packet data address that it wants to use. In this way the Mobile Station will be recog-nized by the corresponding GGSN and then interworking with external data networkscan begin. During this procedure, which is called PDP context activation (i.e., PacketData Protocol context activation), the SGSN establishes a PDP context with the relatedGGSN as it is described in the chapter: "9.7 Activation and Deactivation of a PDPContext" This context is used for routing purposes when the user:– will send data to the external data network;

iThe SISGSNREL99 parameter is broadcasted in the cell, in order to informthe Mobile Stations about the specification Release implementation in theSGSN.

34 A30808-X3247-L24-5-7618


– will receive data from the external data network.

At the end of the successful execution of the attach and of the PDP context activationprocedures, the MS can start the transmission or reception of data.

For the purpose, the Mobile Station must establish a physical connection with thenetwork; this physical connection is called “Temporary Block Flow” . The TemporaryBlock Flow allows unidirectional transfer of data through the allocated radio resources.See for more details the chapter: "4.1 GPRS/EGPRS Physical Channels".

The User data is transferred transparently between the Mobile Station and the externaldata networks with a method known as encapsulation and tunnelling: data packets arecompleted with GPRS/EGPRS specific protocol information and transferred betweenthe Mobile Statopm and the GGSN of competence. This transparent transfer methodlessens the requirement for the GPRS PLMN to interpret external data protocols, and itenables an easy introduction of additional interworking protocols in the future. User datacan be compressed and protected with retransmission protocols, to get a consistent,efficient and reliable data transmission.

A30808-X3247-L24-5-7618 35

InformationSystem


3.3 GPRS/EGPRS Protocol StackThe GPRS and EGPRS technology is supported at every level of the OSI stack by a setof protocols that are represented below (See the figure 3.4: Protocol Stack for DataTransmission in GPRS/EGPRS Network.) toghether with the corresponding interfacesstarting from the air-interface (“Um”) up to the core Network (“Gn” Interface between theSGSN 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 followingfunctions:• 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 s 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 Abisinterfaces.It provides a reliable link over the air interface that fits the block structureof 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 itperforms:– 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 physicalconnection is set up by the RLC/MAC layer when there is data to transmit;

halam

Highlight

halam

Highlight

halam

Highlight

36 A30808-X3247-L24-5-7618


• BSSGP: the BSSGP protocol is specified for the Gb interface and it is used totransfer LLC frames together with related information between the SGSN and theBSC. Such information include QoS (Quality of Service) and routing information;

• SNDCF: the Sub Network Dependent Convergence Protocol is the protocol speci-fied for the logical interface between the Mobile Station and the SGSN. It performsthe following tasks:– encryption;– compression;– segmentation/re-assembling;– multiplexing/de-multiplexing of signalling information and data packets.The encryption function grants the best security for the data transmission whereasthe compression and the segmentation are performed to limit the amount of datatransferred by the LLC layer.

• GTP: The GPRS Tunnelling Protocol is specified for the Gn interface. Its main taskis the encapsulation/de-encapsulation function. The different kinds of data packetsare encapsulated in IP packets since IP is the GPRS/EGPRS internal networkprotocol. The encapsulated data packets are then transferred between the GSNnodes.

• 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 Stationup to the GGSN. Depending on the supported network protocol (IP, X.25, CLNP),there are several kinds of network layers;

• Application : The higher layers (for example the “Application Layer”) are outside thescope of the GPRS/EGPRS, because they are not dependent from the underlyingnetwork.

3.4 Data FlowThis chapter describes the way data is transmitted from the core network (SGSN) up tothe Mobile Station, and vice versa.

The figure 3.5: “RLC/MAC Block and Radio Block Structures” and the figure 3.6: “DataFlow across Protocol Layers in case of EGPRS(MSC7...MSC9)” represent in which waythe different protocol’s layers handle 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);

halam

Highlight

halam

Highlight

A30808-X3247-L24-5-7618 37

InformationSystem


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 amobile subscriber.

The following steps are performed:

iPrecondition is that the Mobile Station has already executed the “attach” procedure andit has already activated the PDP context towards the involved data network.

38 A30808-X3247-L24-5-7618


1. the Internet Service provider sends the IP data packet unit to the GPRS/EGPRSnetwork, using the IP address which has been assigned to the Mobile Station duringthe PDP context activation procedure;

2. the GGSN searches for the relevant PDP context and forwards the data unit towardsthe right SGSN. The original IP data unit is encapsulated in a new one (using theGTP 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 alsoencrypted and compressed).

4. when the SGSN knows the location of the Mobile Station (i.e., the cell where theMobile Station is camped on), these LLC frames are sent to the right BSC, acrossthe Gb interface. As in the GSM system, the paging procedure is used to localize thesubscriber.

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 certainnumber of RLC/MAC blocks; these blocks have a well defined length (according tothe used coding scheme);

6. The RLC/MAC blocks are then sent through the Abis interface, to the right BTS;

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 followingdifferent 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; afterthese operations, each received RLC/MAC block reaches, independently from theapplied coding scheme, a fixed length of 456 bits;

– when EGPRS GMSK coding schemes are used (i.e., from MCS1 to MCS4), asingle 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/MACblock 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 singleRLC/MAC block contains two Information Fields; the BTS executes the describedoperations on the RLC/MAC block; after these operations, the RLC/MAC block

iRLC/MAC blocks are sent across the Abis interface, by means of PCU frames. Twokinds of PCU frames exists:- standard PCU frames: they allow the transmission of a restricted number of bits every20 msec and so they support only CS1 and CS2 GPRS coding schemes;- concatenated PCU frames: they support not only CS1 and CS2 GPRS codingschemes, but also CS3 and CS4, and all the EGPRS coding schemes (MSC1..MSC9).More details are described in the chapter: "6.3 PCU Frames and Dynamic Allocation onthe Abis Interface".

halam

Highlight

A30808-X3247-L24-5-7618 39

InformationSystem


reaches, independently from the applied coding scheme, a fixed length of 1392bits;

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 3.7: “Data Flow from the SGSN to the MS.” shows the data flow between theSGSN and the Mobile Station in the downlink direction through the Gb, Abis and Uminterfaces (in the uplink direction the same data flow is transmitted but in the oppositeorder).

Fig. 3.7 Data Flow from the SGSN to the MS.

To avoid mis-understanding in this manual, 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 PCUframes towards the BTS that will apply the right coding;

• Radio Block: a Radio Block is a RLC/MAC block that is generated after the BTS hasapplied the block coding (i.e., it is a RLC/MAC block plus some coding bits).

iAfter block coding, the BTS will apply the convolutional coding and both puncturing andinterleaving procedures; after these operations the interested block will reach a fixedlength of 456 or 1392 bits, and it is still called Radio Block.

40 A30808-X3247-L24-5-7618


3.5 RLC/MAC Block and Radio Block StructuresDifferent RLC/MAC block (and as a consequence different Radio Block) structures fordata 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 controlmessages.

3.5.1 RLC/MAC and Radio Block Structures: Data TransferAs it has been described, two different RLC/MAC Block structures are defined for GPRSand EGPRS data transfer.

3.5.1.1 RLC/MAC Block and Radio Block Structures for GPRS Data TransferA RLC/MAC block for data transfer supported by the GPRS technology consists of oneMAC Header, one RLC Header and one RLC Data Block as represented in the"Fig. 3.8 RLC/MAC block’s structure for Data Transfer".– 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.

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 theend of the operation the Radio Block is generated, as represented in the "Fig. 3.9 RadioBlock structure for Data Transfer on the “Um” Interface". This Radio Block, after convo-lutional coding, puncturing and interleaving, is then transmitted on the “Um” air interfaceand carried by four Normal Bursts.

Fig. 3.9 Radio Block structure for Data Transfer on the “Um” Interface

iAll the different RLC/MAC block types, after the coding, are always carried by fourNormal Bursts on the “Um” radio interface.

MAC Header RLC Header RLC Data

MAC Header RLC Header RLC Data BCS

halam

Highlight

halam

Highlight

halam

Highlight

A30808-X3247-L24-5-7618 41

InformationSystem


3.5.1.2 RLC/MAC Block and Radio Block Structure for EGPRS DataTransferA RLC/MAC block for data transfer supported by the EGPRS technology consists of oneRLC/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 oneRLC Data Block field only (as represented in the "Fig. 3.10 RLC/MAC Block struc-ture for Data Transfer with one RLC Data Block field"), whereas the coding schemesfrom MCS7 to MCS9 use a RLC/MAC block constituted by two RLC Data Block fieldsto reach a more high data rate as represented in the "Fig. 3.11 RLC/MAC Blockstructure for Data Transfer with two RLC Data block fields".

Fig. 3.10 RLC/MAC Block structure for Data Transfer with one RLC Data Block field

Fig. 3.11 RLC/MAC Block structure for Data Transfer 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 the "Fig. 3.12 RadioBlock for Data Transfer with one RLC Data Block field"in case only one RLC Data Blockis inserted and the "Fig. 3.13 Radio Block for Data Transfer with two RLC Data Blockfield" in case two RLC Data Blocks are inserted). Besides two different block codingsare 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 owncheck sequence.

In cases of RLC/MAC blocks constituted by two RLC Data Block fields , each field hasits own block check sequence whereas the RLC/MAC Header is common for both thefields.

At the end of the checks and after convolutional coding, puncturing and interleaving, theRLC/MAC Block structure represented in the "Fig. 3.13 Radio Block for Data Transferwith two RLC Data Block field" is transmitted on the “Um” Air Interface and carried byfour Normal Bursts.

RLC/MACHeader

RLC Data Block

RLC/MACHeader

RLC Data Block RLC Data Block

42 A30808-X3247-L24-5-7618


Fig. 3.12 Radio Block for Data Transfer with one RLC Data Block field

Fig. 3.13 Radio Block for Data Transfer with two RLC Data Block field

3.5.2 RLC/MAC Block Structure: Control SignallingThe same RLC/MAC Block for transferring a control message (for example a signallingmessage) is supported by the GPRS and the EGPRS technology. It consists of oneMAC header and one RLC/MAC Control Message as represented in the"Fig. 3.14 RLC/MAC Block Structure for Control Messages". The Header and theRLC?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.– the RLC/MAC Control Message field contains one RLC/MAC control message;

It is always carried by four normal bursts.

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 operationthe Radio Block is generated as represented in the "Fig. 3.15 Radio Block for ControlMessages (Signalling).". After convolutional coding, puncturing and interleaving theRadio Block is then transmitted on the “Um” Air interface and carried by four NormalBursts.

Fig. 3.15 Radio Block for Control Messages (Signalling).

BCSRLC/MAC

Header HCS RLC Data Block

BCSRLC/MAC

Header BCSHCS RLC Data Block RLC Data Block

MAC Header RLC/MAC Control Message

MAC Header RLC/MAC Control Message BCS

halam

Highlight

halam

Highlight

A30808-X3247-L24-5-7618 43

InformationSystem


The following control messages can be transmitted in the downlink direction within aRLC/MAC Signalling 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 thepower control parameters;

– Packet Access Reject: This message is sent by the network to the Mobile Station toindicate that the network has rejected its access request.

The following control messages can be transmitted in the uplink direction within aRLC/MAC Signalling 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;

iThe Packet Control Acknowledgment message is not formatted as a single RLC/MACblock, but as four Access Bursts.

halam

Highlight

halam

Highlight

halam

Highlight

halam

Highlight

halam

Highlight

halam

Highlight

halam

Highlight

44 A30808-X3247-L24-5-7618


4 Radio Interface DescriptionFor the configuration of the packet switched data (PS) services in a specific cell, the usershall create the PTPPKF object (Point To Point Packet Function) related to that cell andthen he/she shall configure properly all the related attributes. The operation can be donelocally from the Local Maintenance Terminal (LMT) or from the Network ManagementSystem (Radio Commander) by means of the command: “Create PTPPKF”. Thiscommand creates an instance of the PTPPKF Managed Object Class (MOC). In theContainment Tree the PTPPKF Managed Object is hierarchically dependent from theBTS Managed Object. For each BTS instance (that means for each configured cell) it isdefined only one PTPPKF Managed Object Instance (MOI) subordinated to it. Its defaultvalue is always “0”. The configuration’s operation is permitted if the super-ordinated BTSand at least one instance (but it is recommended to create always all the instances) ofthe NSVC (Network Service Virtual Container) Functional Managed Object have beenpreviously created. This Managed Object models the functional end-to-end communica-tion between the BSS and the core network (SGSN).

At the end of the PTPPKF Managed Object successfully creation the cell is allowed tosupport Packet Switched (PS) services on the basis of the configuration settingsassigned by the user. These settings are specified in the chapter: "5 Radio ResourcesManagement".

Once packet switched services have been enabled, the radio resources of the cell canbe assigned to either GPRS/EGPRS packet or circuit switched services, accordingly tothe 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 areshared between packet switched services and circuit switched services accordinglyto the current requests, but circuit switched services have an higher priority thanGPRS/EGPRS packed swtiched ones.

2. Dedicated radio channels (also called static channels): these channels are perma-nently assigned to GPRS/EGPRS packet switched services, and they cannot beused for circuit switched services (even if no GPRS/EGPRS users are exploitingthese channels).

4.1 GPRS/EGPRS Physical ChannelsThe physical channel (one timeslot of the TDMA frame) assigned to the Packet DataServices (PS) (either statically or dynamically) is named “Packet Data Channel (PDCH)as represented within the "Fig. 4.1 Packet Data Channel (PDCH) within a TDMA frame"

Functional object Meaning

PTPPKF This Functional Managed Object models the Point toPoint service in a cell. It allows a cell to provide PackedSwitched (PS) data services supported by theGPRS/EDGE technology. Only one istance (defaultvalue: “0”) of the PTPKF Managed Object can be config-ured for the superior BTS.

Tab. 4.1 PTPPKF Managed Object.

A30808-X3247-L24-5-7618 45

InformationSystem


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 PDCHone), the multiframe structure for this PDCH consists of 52 TDMA frames structured asfollow:– 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 orsignalling as described in the chapter: "3.5 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").

Fig. 4.2 Multiframe Structure for a PDCH

4.2 Channel CodingThe Blocks B0..B11 sent on the radio interface inside the PDCH multiframe are codeddifferently depending on the packet switched (PS) service used (GPRS or EGPRS). Inthe following chapters the differences between the two services are described from thecoding process point of view.

4.2.1 GPRS Channel CodingFour coding schemes: “CS1, CS2, CS3 and CS4” are defined for GPRS RLC/MACblocks used during the data transmission.

The "Tab. 4.2 GPRS Coding Schemes" below summarizes the main characteristics ofeach coding scheme, referring to the structure of the GPRS RLC/MAC block for datatransfer as represented in the "Fig. 3.8 RLC/MAC block’s structure for Data Transfer".

TDMA frame

GPRS/

PDCH

0 7EGPRS

B0 B1 B2 T B3 B4 B5 i B6 B7 B8 T B9 B10 B11 i

52 TDMA Frame - PDCH Multiframe

4 frames 1 frame - i = Idle frame- Bx = Radio Block- T = PTCCH

46 A30808-X3247-L24-5-7618


According to the coding scheme used, the message (RLC/MAC block), delivered bymeans of PCU frames to the encoder of the BTS, has a fixed size of (obviously the samething is valid for the message delivered from the BTS to the BSC):– 184 bits in cases of CS1;– 271 bits in cases of CS2;– 315 bits in cases of CS3;– 431 bits in cases of CS4.

The BTS will then execute the following operations (the coding process, for every codingscheme, is detailed in the "Fig. 4.3 GPRS Coding Process"):

1. the first step of the coding procedure is to add a Block Check Sequence (BCS) forthe 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 theerror correction);

4. the fourth step consists of the puncturing operation. It is executed with the purposeof obtaining the target coding rate.

Codingscheme

Bits of RLCData Field(without

spare bits)

Sparebits in

RLC DataField

Network Data Rate Bits ofRLC/MAC

Header(including

USF)

Total size ofthe RLC/MACblock (bits)

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

A30808-X3247-L24-5-7618 47

InformationSystem


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 signalling and datainformation between the BSC and the BTS, and the GPRS capacity on the Abis waslimited to 16 kbit/s.

In fact, with standard PCU frames, only 271 bits of data can be transmitted, every 20msec, 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 introducedin the system, and the Abis throughput per radio channel (PDCH) is increased to n X16 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 PCUframes:

a) Concatenated PCU frames are used when the support of CS3/CS4 is enabled atboth BSC and at BTS level;

b) Standard PCU frames are used when the support of CS3/CS4 is disabled at theBSC or at the BTS level.

USF= 3 bitBlock code 40 bit+ 4 tail bit

Convolutionalcode (R=1/2)

Interleaving

ModulationCS1

181 bit 184 bit 228 bit 456 bit

USF= 3 bitBlock code16 bit+ 4 tail bit

Convolutionalcode (R=1/2)

Interleaving

Mod.CS2 / CS3

268 bit 274 bit

USF

271 bit 294 bit

Puncturing

588 bit 456 bit

pre-coding

312 bit 318 bit315 bit 338 bit 676 bit 456 bit

USF= 3 bitUSFpre-coding

Block code16 bit

Interleaving

ModulationCS4

428 bit 431 bit 440 bit 456 bit

iTo get more information about concatenated PCU frames and the flexible Abis alloca-tion strategy refer to the chapter:"6.3 PCU Frames and Dynamic Allocation on the AbisInterface".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, inorder to be able to reach the higher coding schemes (CS3/CS4), when CS3/CS4 aresupported at O&M level with the configuration of the related parameters, the selectedPCU frame format is “Concatenated”, even if the initial coding scheme could besupported by standard PCU frames.

48 A30808-X3247-L24-5-7618


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 thepurpose the CSCH3CSCH4SUP attribute of the BSC Managed Object allows the userto 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 theCSCH3CSCH4SUP attribute of the PTPPKF Managed Object..

The MNTBMASK attribute is related also to the feature: “Common Bcch allowingGPRS/EGPRS in the complementary band” introduced in BR7.0 by the ChangeRequest 2263.

By means of the bit24 of the MNTBMASK attribute (plus an object patch) the feature canbe enabled also for GSMDCS.

By means of the bit17 of the MNTBMASK attribute the GSUP can be enabled. As aconsequence the TRXMD can be set to EGPRS also in TRX in the E900 sub-band, bothin EXT900 and in GSMDCS cells with BCCH in P900. This implies to send all thefrequencies (P900 and E900) within the “SystemInfo1 message” causing a limitation onthe number of possible frequencies that could be used in the cell up to 22 independentlyfrom their value. The number could be larger than 22 only if the frequencies are well-distributed. This limitation is applied not only to the cells allowed to the GPRS servicebut to all the EXT900 or the GSMDCS cells in the BSC. (Change Request 2132).

By means of both the bit17 and the bit24 toghether of the MNTBMASK attribute, theGSUP can be enabled. As a consequence the TRXMD can be set to EGPRS in all the

iWhen enabling the CS-3 /CS-4 coding schemes the precondition is that the bit 25 of theMNTBMASK attribute has to be set to FALSE, otherwise (bit 25 of MNTBMASK=TRUE)the max coding scheme usable is forced to CS2 independently from theCSCH3CSCH4SUP value set to TRUE.

With bit 25 of MNTBMASK set to 1, then the CSCH3CSCH4SUP attribute becomes aflag for stating if CONCATENATED PCU frames or STANDARD PCU frames will beused in the whole PTPPKF, that is, on all the TRX supporting EGPRS or GPRS of therelated 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 forenabling 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 PCUframes 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 PCUframes will be used on all the TRX supporting EGPRS or GPRS.

A30808-X3247-L24-5-7618 49

InformationSystem


TRXs of the cells (both 900 and 1800 cells). This implies to send all the frequencies(P900, E900 and DCS1800) within the “SystemInfo1 message” causing a limitation onthe number of possible frequencies that could be used in the cell up to 16 independentlyfrom their value. The number could be larger than 16 only if the frequencies are well-distributed. This limitation is applied not only to the cells allowed to the GPRS servicebut to all the GSMDCS cells in the BSC.

The usage of the bit17 stand alone and the usage of the bit24 and the bit17 toghetherof the MNTBMASK attribute implies modification in the content/encoding of theSystemInfo1 message for all the cells in the BSC and consequently of the MobileAlloca-tions that have to be transmitted to all the BTSs connected to the BSC. For the purposea very complex procedure is needed but it is not implemented in the BSC in the currentrelease. For this reason and considering also that the usage of the bit17 and the bit24normally is related to a specific cell planning strategy and not to a punctual demand, itis strongly recommended not to change the bit17 and the bit24 when the bit17 is in use, if at least one cell is configured in the BSC. Instead this operation is permitted duringthe offline generation/conversion of the database.

The user can also indicate, on a cell basis, which coding scheme has to be used aspreferred for the data transmission , when a new transmission is initiated (whereassignalling 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 thepreferred initial coding scheme configuring the INICSCH attribute. .

Then the link adaptation algorithm (the algorithm is described in the chapter: "10.5 LinkAdaptation"), if enabled, can change the coding scheme of the TBF according to specificradio conditions. If the link adaptation is not enabled, the initial coding scheme is the onlyone used for the data transmission in the cell.

As it is described in the chapter: "6 Hardware and Software Architecture", in order tosupport GPRS TBFs with CS3 or CS4 coding schemes, the requirements are thefollowing:• Only High Capacity BSC(s) support the CS3/CS4 coding schemes;• BTS1, BTS+, E-microBTS and PicoBTS, support the CS3/CS4 coding schemes.

The coding process of a RLC/MAC block, using CS1, is shown in the "Fig. 4.4 Codingof the RLC/MAC Block using CS-1": the 456 bits obtained after BTS coding are sentacross 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 theactual coding scheme (see for more details the chapter: "4.2.2 EGPRS ChannelCoding").

iThe user defines a value of coding scheme to be used when a data transmission startsconfiguring the INICSCH parameter. This value will be used only when the system doesnot have any other information to choose the initial coding scheme (more details aredescribed in the chapter: "10.5.3 Selection of the Candidate Initial Coding Scheme").

50 A30808-X3247-L24-5-7618


Fig. 4.4 Coding of the RLC/MAC Block using CS-1

4.2.2 EGPRS Channel CodingAs it has been described in the chapter "3.1 GPRS and EGPRS Modulation Principles",the following nine different modulation and coding schemes: “MCS1..MCS9”, aredefined 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 tothe structure of the EGPRS RLC/MAC block for data transfer (see the"Fig. 3.10 RLC/MAC Block structure for Data Transfer with one RLC Data Blockfield"and the "Fig. 3.11 RLC/MAC Block structure for Data Transfer with two RLC Datablock fields").

USF TFI Data bits

3 bits 181 bits

BCS Tail

RLC/MAC block

PCU

R=1/2 Convolutional Code

Encrypted RLC frame

456 bits

Encrypted bits TrainingTail Sequence Encrypted bits Tail

Normal Burst

Guardperiod

57 bits57 bits

456 bits are split in 4Normal bursts.

40 bits 4 bits

Stealing bits

Codingscheme


spare bits)

Net Data Rate Bits ofRLC/MAC

Header DL/UL(including

USF)

FBI+Efields(bits)

Total size ofthe RLC/MACblock DL/UL

(bits)

MCS1 176 8,8 kbit/s (176 bit/20 msec) 31/31 2 209

Tab. 4.3 EGPRS Coding Schemes

A30808-X3247-L24-5-7618 51

InformationSystem


According to the coding scheme used, the message (RLC/MAC block) delivered, bymeans of PCU frames, to the encoder embedded in the BTS software has a fixed sizeas follow:– 209 bits in cases of MCS1;– 257 bits in cases of MCS2;– 329 bits in cases of MCS3;– 385 bits in cases of MCS4;– 478 bits in cases of MCS5 in the downlink direction, and 487 bits in cases of MCS5

in the uplink direction;– 622 bits in cases of MCS6 in the downlink direction, and 631 bits in cases of MCS5

in the uplink direction;– 940 bits in cases of MCS7 in the downlink direction, and 946 bits in cases of MCS7

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 thedifferent MCSs:

The MCSs are divided into different families:– A;– Apadding;– 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 ofpayload units within one Radio Block. For the families A and B, one, two or four payloadunits are transmitted, instead for the family C only one or two payload units are trans-mitted.

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



Codingscheme


spare bits)

Net Data Rate Bits ofRLC/MAC

Header DL/UL(including

USF)

FBI+Efields(bits)

Total size ofthe RLC/MACblock DL/UL

(bits)

Tab. 4.3 EGPRS Coding Schemes

52 A30808-X3247-L24-5-7618


The Tab. 4.2.4 shows the correspondence between the families and the related codingschemes, whereas the "Fig. 4.5 EGPRS Coding Schemes and Families" represents thedifferent relationships among families, coding schemes and possible units of payload.

Fig. 4.5 EGPRS Coding Schemes and Families

When 4 payload units are transmitted (MCS7, MCS8 and MCS9), they are split into twoseparate RLC data fields of the same RLC/MAC block (that means with separatesequence numbers and BCSs, as reported in the "Fig. 3.11 RLC/MAC Block structurefor Data Transfer with two RLC Data block fields").

FAMILY CODING SCHEMES

A MSC-3, MSC-6, MSC-9

A Padding MSC-3, MSC-6, MSC-8

B MSC-2, MSC-5, MSC-7

C MSC-1, MSC-4

Tab. 4.2.4EGPRS Coding Schemes and Families

A30808-X3247-L24-5-7618 53

InformationSystem


This can be clearly seen by comparing the "Fig. 4.6 Interleaving of MCS9 Coded Datainto Two Consecutive Normal Bursts" (family A, MCS9) and the "Fig. 4.7 Interleaving ofMCS6 Coded Data into Four Consecutive Normal Bursts" (family A, MCS6).

After the reception of a RLC/MAC block from the BSC, the BTS executes the followingoperations:

1. the first step of the coding procedure of the data part of the RLC/MAC Block is toadd 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 puncturingschemes Pi (where i = 1..3), which has impact on Incremental Redundancy as LinkQuality Control method; the Pi for each MCS corresponds to different puncturingschemes achieving the same coding rate;

5. As fifth and last step , the radio block is rectangular interleaved over 4 bursts (seethe Fig. 4.6 and the 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).

The coding and puncturing scheme of a RLC/MAC radio block is clearly outlined in theRLC/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 theNormal 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 (8bits) 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.

iTo ensure strong header protection, the header part of the Radio Block (i.e., theRLC/MAC header) is independently coded from the data part of the Radio Block.

iFor MCS8 and MCS9, only the header is interleaved over 4 normal bursts. The datablocks are interleaved over 2 bursts only. The MCS7 header and data are interleavedover 4 bursts.

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

Tab. 4.2.5Coding of Stealing Bits for GPRS and EGPRS Radio Blocks

54 A30808-X3247-L24-5-7618


There are eight stealing bits for 8PSK mode which indicate four header formats. Thereare twelve stealing bits for GMSK mode which indicate two header formats: the first eightof the twelve stealing bits indicate CS4 to allow Mobile Stations supporting GPRSservices to decode the header type 3 and to read the USF field of the header (moredetails about the meaning of the USF field are described in the chapter: "4.3 TemporaryBlock Flow" ).

The USF field has eight states, which are represented by a binary 3 bit field in the MACHeader. The USF is encoded to twelve symbols similarly to GPRS, (that is 12 bits forGMSK modes and 36 bits for 8PSK modes). The FBI (Final Block Indicator) bit and theE (Extension) bit do not require extra protection: they are encoded along with the datapart.

Fig. 4.6 Interleaving of MCS9 Coded Data into Two Consecutive Normal Bursts

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

MSC5, MSC6 0,0,0,0,0,0,0,0

MSC7, MSC8, MSC9 1,1,1,0,0,1,1,1

Coding Scheme Stealing Bits

Tab. 4.2.5Coding of Stealing Bits for GPRS and EGPRS Radio Blocks

A30808-X3247-L24-5-7618 55

InformationSystem


Fig. 4.7 Interleaving of MCS6 Coded Data into Four Consecutive Normal Bursts

The user can also configure , on a cell basis, the coding scheme that has to be used aspreferred for the data transmission, when a new transmission is initiated (whereassignalling 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 EGPRSservices 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 theMCS to be used in the downlink direction for all the EGPRS Mobile Stations.

The link adaptation algorithm, if enabled, can change the coding scheme of the TBFaccording to the radio conditions. If the link adaptation algorithm is not enabled, theinitial coding scheme is the only one used for the data transmission in the cell (detailsabout the coding schemes’ management are described in the chapter "10.5 Link Adap-tation").For supporting the EGPRS coding schemes, concatenated PCU frames are used in the

iThe user has to set a value of the coding scheme to be used when a data transmissionstarts. This value is adopted only when the system does not know any other informationfor choosing the initial coding scheme (see the chapter "10.5.3 Selection of the Candi-date Initial Coding Scheme").

56 A30808-X3247-L24-5-7618


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 PCUFrames and Dynamic Allocation on the Abis Interface".

4.3 Temporary Block FlowThe Temporary Block Flow (TBF) is the physical connection, between the MobileStation and the network, used to support the unidirectional transfer of LLC PDUs onpacket data physical channels (PDCHs).

The TBF is characterized by a set of allocated radio resources on one or more PDCHs,and it comprises the transmission of a number of RLC/MAC blocks carrying one or moreLLC PDUs. A TBF is maintained only for the duration of the data transmission.

The TBF is established:• in uplink direction to transfer data (or signalling) from the Mobile Station to the

network;• in downlink direction to transfer data (or signalling) from the network to the Mobile

Station.

A TBF can operate in either GPRS or EGPRS mode; the network sets the TBF mode inthe PACKET UPLINK ASSIGNMENT, PACKET DOWNLINK ASSIGNMENT or IMME-DIATE ASSIGNMENT message (see "9.8 Access to the Network (Establishment of aTBF)").

For each TBF, the network assigns a Temporary Flow Identity (TFI) . The assigned TFIis unique among simultaneous TBFs in the same direction, i.e.:– TBFs belonging to the same direction of transmission must have different TFI

values;– TBFs belonging to different directions of transmission could have the same TFI

value.

The TFI is assigned to a Mobile Station in a resource assignment message thatprecedes 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 aparticular TBF, as well as in the control messages associated to the LLC frame transfer(e.g., 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 .

4.3.1 Multiplexing MSs on the same PDCH: Downlink DirectionA 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 thefollowing steps:

1. they read all the downlink blocks inside the multiframe, and decode the TFI value;

iThe EGPRS TBF mode is supported by EGPRS capable MSs only, see "9.1 MobileStations for Packet Switched Services".

halam

Highlight

halam

Highlight

halam

Highlight

A30808-X3247-L24-5-7618 57

InformationSystem


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)" representsthe mobile station behavior.

Fig. 4.8 Multiplexing Mobile Station on the same PDCH (Downlink)

4.3.2 Multiplexing MSs on the same PDCH: Uplink DirectionAn uplink TBF, associated to a single PDCH, is set up with the purpose to provide to theMobile 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 samePDCH.The USF is used in Dynamic Access Modes (see "9.8.1 Medium Access Modes"),and comprises 3 bits at the beginning of each Radio Block, that is sent in the down-link direction (the 3 bits belong to the MAC header, see "3.5 RLC/MAC Block andRadio Block Structures"). It enables the coding of 8 different USF states which areused to multiplex the uplink traffic.

Then all the mobile stations, which have an uplink TBF on the same PDCH, execute thefollowing 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.

The "Fig. 4.9 Multiplexing Mobile Station on the same PDCH (Uplink)" represents theMobile Station behavior in cases of uplink transmission on the next uplink block.

58 A30808-X3247-L24-5-7618


Fig. 4.9 Multiplexing Mobile Station on the same PDCH (Uplink)

The GPRS and EGPRS Mobile Stations can be multiplexed dynamically on the samePDCH by utilizing the USF. The only problem is that if 8PSK modulation is used in thedownlink blocks (because downlink blocks are related to a EDGE TBF), a GPRS mobilestation 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, toa GPRS mobile station;

– may use the 8PSK modulation for the other blocks.

The dynamic allocation using USF granularity requires that a GPRS Mobile Station isable to do what the USF in an EGPRS GMSK block. This is enabled by setting stealing

iOn PDCHs (not carrying PCCCH, see "4.4.2 Packet Common Control 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 thePacket Downlink Acknowledge message).So when the network wants to permit to one Mobile Stations, that doesn’t have an uplinkTBF, to transmit in uplink direction, it sets the USF field to this reserved value. In thisway, 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 Stationswith the downlink TBF, that it must transmit in the uplink block that the network hasreserved for it. To inform the Mobile Stations the network uses the RRBP field which iscontained in all the downlink blocks (it is contained in the MAC header of both data andcontrol blocks, see the chapter "3.5 RLC/MAC Block and Radio Block Structures"); withthe informations stored in this field, the network informs the Mobile Stations that theymust send a control block in the uplink direction (see the chapter "9.8.4 RelativeReserved Block Period Field (RRBP)").

A30808-X3247-L24-5-7618 59

InformationSystem


bits in the EGPRS GMSK blocks to indicate CS4 (see the chapter "4.2.2 EGPRSChannel 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 isassumed to be low;

– an EGPRS Mobile Station can not differentiate CS4 blocks and EGPRS GMSKblocks 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 EGPRSMS knows if it is in EGPRS or standard GPRS mode, it will only have to try to decodethe remainder of the GMSK blocks in one way in order to determine if they wereaimed for it.

Due to synchronization aspects related to the Mobile Station, if standard GPRS MobileStations are multiplexed on the PDCH, at least one Radio Block every 360 ms on thedownlink direction must use GMSK (i.e., standard GPRS or MCS-1 to MCS-4); thisbecause every Mobile Station shall receive a radio block at least every 360 ms.

4.3.3 Multiplexing MSs on the same PDCH: ConfigurationAs it has been described, more than one Mobile Station can be multiplexed, either in thedownlink 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 MobileStations on the same PDCH in the uplink direction;

– in the downlink direction, up to 16 Mobile Stations can be multiplexed on the samephysical data channel; this number is imposed by the Timing Advance Index (TAI)necessary for the Timing Advance Update procedure (see the chapter "4.6 PacketTiming Advance Estimation");

– in total (uplink and downlink) up to 16 Mobile Station can be multiplexed on the samephysical channel; this number is imposed by the Timing Advance Index (TAI)necessary for the Timing Advance Update procedure (see the chapter "4.6 PacketTiming Advance Estimation").If, for instance, 7 Mobile Stations are using a PDCH in the uplink direction, at most9 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 thatcan share the same timeslot (PDCH) in uplink (UL) and downlink (DL) direction. It iscomposed 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 ChannelsRegarding packet switched services (PS) the following Packet Data Logical Channelshave been defined:• Packet Broadcast Control Channel (PBCCH);• Packet Common Control Channel (PCCCH);• Packet Data Traffic Channel (PDTCH);• Packet dedicated control channels (PTCCH and PACCH).

60 A30808-X3247-L24-5-7618


These different packet data logical channels, which are specific for the GPRS/EGPRStechnology, can share the same physical channel (on the same PDCH), when thetimeslot is assigned to the GPRS/EGPRS users.

4.4.1 Packet Broadcast Control Channel (PBCCH)Within the GSM network, system information messages are regularly broadcasted bythe BCCH and busy TCHs. With the help of system information the Mobile Station is ableto 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 supportboth 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 isbroadcast on the BCCH (in the system information 13 message).

The following Packet System Information exists: PSI1, PSI2, PSI 3, PSI3 bis, PSI3 ter,PSI3 quater, PSI5, 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 ofcontrol channels and optional power control parameters;

• PSI2 message is sent by the network on the PBCCH channel, providing informationof reference frequency lists, mobile allocations and PCCCH channel descriptionsapplicable 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 selectionparameters 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 parametersfor non-serving cells;

• PSI3 ter message is sent by the network on the PBCCH or PACCH providing infor-mation on additional measurement and reporting parameters;

• PSI3 quater message is sent by the network on the PBCCH or PACCH providinginformation on 3G Neighbour Cells and additional measurement and reportingparameters;

• PSI5 message contains specific parameter for measurement reporting and networkcontrolled cell reselection;

• PSI13 message is sent by the network on the PACCH channel (when the PBCCHchannel is not configured), providing the Mobile Station with GPRS/EGPRS cellspecific access-related information (e.g., Page Mode, Routing Area Code, NetworkControl Order, Power Control Parameters).

When a GPRS mobile station camps on a cell, it starts reading the system informationon the BCCH channel. From the BCCH channel, the MS understands if the cell supportsthe GPRS service or not. If the cell supports the service, the Mobile Station startsreading the system information 13, that provides GPRS cell specific information. From

iThe sharing of the physical channel is based on blocks of 4 consecutive Normal Bursts,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.

A30808-X3247-L24-5-7618 61

InformationSystem


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 informationon 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 onthe BCCH channel. From the BCCH channel, it understands if the cell supports theGPRS service. If the cell supports the service, the Mobile Station starts reading thesystem information 13 message that provides information regarding the EGPRS avail-ability too. From the system information 13 the Mobile Station also learns if the PBCCHchannel is configured in the cell, then:

a) if the PBCCH is not supported, the Mobile Station knows that EGPRS is availablereading GPRS Cell Option IE in the System Information 13 message and finding theEGPRS Packet Channel Request support indication field. This field indicates if theEGPRS PACKET CHANNEL REQUEST message is supported in the cell (see formore details the chapter: "9.8.2.4 TBF Establishment for EDGE Mobile Stations").Additionally the PSI13 message within the PACCH contains GPRS Cell Optionsupdated for EGPRS.

b) if the PBCCH is supported, GPRS Cell Options, updated for EGPRS, will be presentin the PSI1 message,

Fig. 4.10 Example of Mapping of the PBCCH Channel.

4.4.2 Packet Common Control Channel (PCCCH)The PCCCH channel comprises logical channels used for common control signalling,introduced to support packet data services. These common channels are 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 usespaging groups in order to allow the usage of DRX mode.

– Packet Access Grant Channel (PAGCH): this channel is used, in the downlinkdirection only, in the packet transfer establishment phase, to send resource assign-ments to Mobile Stations prior to the packet transfer;

iThe PBCCH channel, when configured, is allocated on a PDCH physical channel(see Fig. 4.10). Only one PDCH can support the PBCCH channel, i.e., it is not possibleto configure the packet system information in two different PDCHs (it is like the GSMsystem, where the BCCH channel always resides in the slot 0 of the BCCH TRx).

TDMA frame

PDCH

BCCH PBCCH

0 7

iWhen, for GPRS/EGPRS mobile stations, the PBCCH is used instead of the BCCH,more information and parameters regarding packet switched (PS) data services aretransmitted; for example new cell re-selection criteria are implemented (see thechapter:"10.1 Cell Selection and Re-selection").

62 A30808-X3247-L24-5-7618


– Packet Random Access Channel (PRACH): this channel is used, in the uplinkdirection only, by a Mobile Station to initiate the uplink transfer for sending data orsignalling information. Access Bursts are used on the PRACH channel (see for moreinformations the chapter: "4.2 Channel Coding").

Fig. 4.11 Packet Common Control Channels

PCCCH channels do not have to be allocated permanently on the cell. Whenever thePCCCH channels are not allocated, the already configured CCCH channels (i.e.,thePCH, AGCH and RACH) are used to execute the described operations, in the same wayand with the same GSM functionalities. The existence and the location of the PCCCH(i.e., the existence and the location of the PDCH channel that support the PCCCH) arebroadcast on the cell.

Fig. 4.12 Example of Mapping of the PCCCH Channel.

Packet CommonControl Channels

PCCCH

Packet PagingChannelPPCH

Packet RandomAccess Channel

PRACH

Packet AccessGrant Channel

PAGCH

- to initiate uplink transfer- to request allocation of new PDTCHs

- to page a MS prior of a downlinktransfer

- to allocate resources

iThe first PCCCH channel is automatically allocated when the PBCCH channel is config-ured, and it resides in the same PDCH containing also the PBCCH as represented inthe "Fig. 4.12 Example of Mapping of the PCCCH Channel.".If the user needs more packet common signalling resources, it can configure anotherPCCCH in another PDCH as represented in the "Fig. 4.13 Example of Mapping of twoPCCCH Channels.".

TDMA frame

PDCH

BCCHPBCCH

PCCCH+

0 7

A30808-X3247-L24-5-7618 63

InformationSystem


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 oneMobile 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 PacketDedicated Control Channels").

Regarding the PDTCH assignment, according to the GMANMSAL attribute of thePTPPKF Managed Object, the following restrictions must be satisfied (see also thechapter: "4.3.3 Multiplexing MSs on the same PDCH: Configuration").

4.4.4 Packet Dedicated Control ChannelsTwo types of packet dedicated control channels are supported by the GPRS/EGPRSservices:• Packet Associated Control Channel (PACCH): The PACCH channel conveys

signalling information related to a given Mobile Station. The signalling informationincludes for example acknowledgements and power control information. PACCHalso carries resource assignment and reassignment messages, comprising theassignment of resources for PDTCH(s) and for further occurrences of PACCH.The PACCH channel is always associated to PDTCH channels: the PDTCH channelallows transmission of data blocks, while the PACCH channel allows transmission ofthe related signalling blocks; so the PACCH channel shares with PDTCHs theresources 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.

TDMA frame

PDCH

BCCH PCCCHPBCCH

PCCCH+

0 7

PDTCHUp<=7PDTCHDown<=16PDTCHUp + PDTCHDown <=16

64 A30808-X3247-L24-5-7618


Downlink Direction (DL):– Packet Uplink Ack/Nack;– Packet Power Control/timing Advance.

• Packet Timing Advance Control Channel (PTCCH): this type of channel is usedin 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; thePTCCH/D is used to transmit timing advance information updates to several MobileStations.

4.4.5 Coding of GPRS/EGPRS Logical ChannelsRegarding the coding of packet switched logical channels, the following considerationsare 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 8Bit or 11 Bit Uplink Access").

• PTCCH/D is coded using the CS1 coding scheme.

4.5 Mapping of Logical Channels onto Physical ChannelsA physical channel allocated to carry packet logical channels is called a Packet Datachannel (PDCH). A PDCH channel carries packet logical channels only.

The GPRS/EGPRS logical channels are mapped dynamically onto a 52-multiframe Seethe "Fig. 4.2 Multiframe Structure for a PDCH".

The 52-multiframe consists of 12 blocks of 4 consecutive frames, 2 idle frames and 2frames used for the PTCCH channel.

A block allocated to a given logical channel comprises one radio block or, in the uplinkdirection only, 4 random access bursts.

The type of channel may vary on a block by block basis. From the configuration point ofview 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’sactions done by the user or to the direction of transmission. The following configurationcan be used for a single PDCH:

iSometimes to allow the estimation of the timing advance, instead of transmitting a radioblock, 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 notcomposed of a single block of four frames, but it is composed of four access bursts.

A30808-X3247-L24-5-7618 65

InformationSystem


a) the PDCH does not carry the specific GPRS/EGPRS signalling (for example PBCCHand PCCCH channels);

b) the PDCH carries both PBCCH and PCCCH channels;c) the PDCH carries GPRS/EGPRS common signalling (for example PCCCH) but not

the PBCCH channel.

4.5.1 PDCH without the Specific GPRS/EGPRS SignallingWhen the PDCH does not carry GPRS/EGPRS specific signalling, the following state-ments are significant:• in the downlink direction (see the "Fig. 4.14 Example of Mapping of Logical Chan-

nels in the Physical Channel (Downlink Direction).") all blocks can be used asPDTCH/D or PACCH/D: the logical channel type is indicated in the block header. Themobile owner of the PDTCH/D or PACCH/D is indicated by the parameter TFI(Temporary Flow Identifier);

Fig. 4.14 Example of Mapping of Logical Channels in the Physical Channel(Downlink Direction).

• in the uplink direction (see the "Fig. 4.15 Example of Mapping of Logical Channelsin the Physical Channel (Uplink Direction).") all blocks can be used as PDTCH/U orPACCH/U: the occurrence of the PDTCH/U (and/or the PACCH/U) at the givenblock(s) Bx (where Bx = B0...B11) in the 52-multiframe structure for a given MobileStation 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 down-link of the same PDCH.The Mobile Station may transmit a PDTCH block or a PACCH block on any of theuplink blocks used for the purpose.The occurrence of the PACCH/U associated to a PDTCH/D is indicated by thenetwork by polling the Mobile Station to transmit the PACCH/U block (as describedin the chapter:"9.8.4 Relative Reserved Block Period Field (RRBP)".

Fig. 4.15 Example of Mapping of Logical Channels in the Physical Channel(Uplink Direction).

4.5.2 PDCH Carrying both PBCCH and PCCCHWhen the PDCH carries both the PBCCH and the PCCCH channels, the following state-ments are significant:

PDCH Multiframe (downlink direction)

PACCH/DPDTCH/D PACCH/D PDTCH/D PDTCH/D PDTCH/D

PDCH Multiframe (uplink direction)

PDTCH/UPDTCH/U PACCH/U PDTCH/U PACCH/U PDTCH/U

66 A30808-X3247-L24-5-7618


a) DOWNLINK DIRECTION:– the first block (B0) of the multiframe (see the "Fig. 4.2 Multiframe Structure for a

PDCH") is reserved for the PBCCH channel; the user can also configure up to 3more blocks as additional PBCCH. To configure additional blocks as PBCCHblocks, the BSPBBLK attribute can be configured by the user: this attribute allowsthe specification of at most four blocks, following the order: B0, B6, B3, B9.

– the next remaining blocks can be configured for PAGCH, PDTCH/D andPACCH/D. To configure additional blocks to carry PAGCH, PDTCH/D andPACCH/D, the BPAGCHR attribute can be configured by the user. This attributeallows 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 Example of Downlink Configuration with PBCCH and PCCCH Chan-nels" shows an example of one PDCH carrying both the PBCCH and the PCCCHchannels, where 3 blocks are dedicated to the PBCCH channel by setting the valueof the BSPBBLK attribute to 2. It can be noted how the number of blocks assignedto 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, atmost 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 blocksmust be reserved in a fixed way to the PRACH channel. The user can reserve upto 12 blocks (i.e., all the multiframe) for the PRACH channel. Remember that in aPRACH block, 4 random access bursts are always sent.

The "Fig. 4.17 Example of Uplink Configuration with PRACH Channel." shows anexample of one PDCH carrying PRACH channel; note how the blocks assigned tothe logical channels change according to the value given to the BPRACHR attribute.

A30808-X3247-L24-5-7618 67

InformationSystem


Fig. 4.16 Example of Downlink Configuration with PBCCH and PCCCH Channels

B11B10B9B8B7B6B5B4B3B2B1BOBPAGCHRBSPBBLK

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

B11B10B9B8B7B6B5B4B3B2B1BOBPRACHR

0

1

2

3

4

5

6

7

8

9

10

PRACH

PRACH + PDTCH + PACCH

11

12

68 A30808-X3247-L24-5-7618


Fig. 4.17 Example of Uplink Configuration with PRACH Channel.

4.5.3 PDCH Carrying PCCCHWhen the PDCH carries the PCCCH channel (without the PBCCH one), the followingstatements 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 BPAGCHRattribute can be configured by the user. This attribute allows the specification ofat 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 andPACCH/U; the BPRACHR attribute allows the user to indicate how many blocksmust be reserved in a fixed way to the PRACH channel. The user can reserve upto 12 blocks (i.e., all the multiframe) for the PRACH channel. It is important tooutline that in a PRACH block, 4 random access bursts are always sent.

4.6 Packet Timing Advance EstimationThe packet timing advance estimation procedure is used to derive the correct value fortiming advance that the Mobile Station has to use for the uplink transmission of radioblocks.

The timing advance procedure is organized into two parts:– initial timing advance estimation;– continuous timing advance update.

4.6.1 Initial Timing Advance EstimationThe initial timing advance estimation is based on the single access burst carrying thePacket Channel Request. The Packet Uplink Assignment or Packet Downlink Assign-ment (see the chapter: "9.8 Access to the Network (Establishment of a TBF)") thencarries the estimated timing advance value to the Mobile Station. This value is used forthe uplink transmissions until the continuous timing advance update provides a newvalue (see the chapter: "4.6.2 Continuous Timing Advance Update").

When Packet Downlink Assignment has to be sent without prior paging (i.e., when theMS in the Ready state, see "9.3.1 Mobility Management States"), no valid timingadvance value may be available.

When timing advance information is not provided in the assignment message, themobile station is not allowed to send normal bursts on the uplink direction until it receivesa valid timing advance value.

To get a valid timing advance value, the continuous timing advance update procedurehas been introduced by the specification (see the chapter: "4.6.2 Continuous TimingAdvance Update"). Since this procedure could create some delays between the packetdownlink 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

A30808-X3247-L24-5-7618 69

InformationSystem


the effective beginning of downlink data transmission, a specific polling procedure isexecuted 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 aPacket 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 UpdateThe Mobile Stations in Packet transfer mode use the continuous timing advance updateprocedure.

This procedure is carried on the PTCCH allocated to the Mobile Station. The followingstatements 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: TimingAdvance Index (TAI) and a PTCCH channel.

• For the downlink packet transfer, within the Packet Downlink Assignment, thenetwork assigns to the Mobile Station (besides the TFI) the parameter: TimingAdvance 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 advancevalue for all the Mobile Stations performing the continuous timing advance updateprocedure on that PDCH. The new timing advance value is sent via a downlink signallingmessage (TA-message) on PTCCH/D. The network can also send the timing advanceinformation within the Packet Timing Advance/Power Control and Packet UplinkAck/Nack messages on the PACCH.

The "Fig. 4.18 Continuous Timing Advance Update Feature" shows the mapping ofboth 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 numbern 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 advanceto be used) in the TA-message number 2. This TA-message is transmitted in the

70 A30808-X3247-L24-5-7618


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 timingadvance 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 framesnumber 16, 18, 20 and 22.

Fig. 4.18 Continuous Timing Advance Update Feature

4.7 Multislot ConfigurationMultiple packet data traffic channels can be allocated to the same Mobile Station. Thisis referred to as the “multislot packet” configuration. In this configuiration one MobileStation 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 thePDTCHs for that specific Mobile Station. The PACCH may be mapped onto any of theallocated PDCHs.

iThe continuous timing advance update procedure could create some delays betweenthe packet downlink assignment message and the beginning of the data transfer in thedownlink direction. In order to reduce the time between a packet downlink assignmentmessage and the effective beginning of downlink data transmission, a specific packetpolling procedure has to be executed (see the chapter: "9.8.5 Polling Procedures" formore details about the procedure).

A30808-X3247-L24-5-7618 71

InformationSystem


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 followingrules must be satisfied when more than one timeslot is assigned:

1. timeslots must belong to the same frequency (i.e., to the same TRX).2. timeslots must be adjacent (i.e., they must have neighboring timeslots numbers-TN).3. timeslots must belong to the same frequency hopping law, i.e., they must have the

same:– Mobile Allocation (MA);– Mobile Allocation Index Offset (MAIO);– Hopping Sequence Number (HSN);

4. timeslots shall have the same training sequence code (TSC).

4.7.1 Mobile Station Classes for Multislot CapabilitiesWhen 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 arerepresented in the table):

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 integervalues of timeslots (from 0 to Rx_max) in the downlink direction;

– Tx_max describes the maximum number of timeslots that the Mobile Station canuse per TDMA frame in the uplink direction. It shall be able to support all the integervalues of timeslots (from 0 to Tx_max) in the uplink direction;

iRegarding frequency hopping for GPRS/EGPRS services, both Base BandFrequency Hopping and Synthesizer Frequency Hopping are supported.

Multislotclass

Maximum number of slots Minimum number of slots

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

72 A30808-X3247-L24-5-7618


– Sum is the total number of uplink(Tx) and downlink(Rx) timeslots that the MobileStation 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 andTx 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. Thisminimum requirement is used when adjacent cell power measurements are notrequired by the service selected. For type 1 Mobile Station it is the minimum numberof timeslots that will be allowed between the end of the last previous receivedtimeslot and the first next transmit timeslot or between the previous transmit timeslotand 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 signallevel measurement and get ready to receive after it has transmitted in the uplinkdirection. For type 1 MS it is the minimum number of timeslots that are allowedbetween the previous transmit or receive timeslot and the next receive timeslot whenmeasurement is to be performed between. For type 2 MS it is the minimum numberof timeslots that are allowed between the end of the last receive burst in a TDMAframe and the first receive burst in the next TDMA frame.

The "Fig. 4.19 Example of Multislot Configuration" shows an example regarding aMobile Station with multislot class=8: the MS has established concurrent TBFs, and ithas 4 timeslots in the downlink direction and 1 timeslot in the uplink direction (betweendownlink and uplink TDMA frames there is a temporal offset of 3 timeslots). When theMobile Station has monitored its last downlink timeslot, it shall wait Ttb timeslots (i.e., 1timeslot) before transmitting; after having transmitted in the uplink direction, it shall waitTra timeslots (i.e., 2 timeslots) before starting to monitor on the downlink direction.

Fig. 4.19 Example of Multislot Configuration

4.7.2 Mapping of Uplink Packet Traffic Logical ChannelsThe PDCHs where the Mobile Station may expect occurrence of its PDTCH/U(s) orPACCH/U for a originated transfer is indicated in the resource allocation messages. The

iType 1 Mobile Station are not required to transmit and receive at the same time,whereas Type 2 Mobile Station are instead required.

TDMA frame - Downlink0

7

0 7

7

TDMA frame - Uplink

d d d d

u

Ttb Tra

0

d d

Mobile Class = 8Rx = 4Tx = 1

Ttb= 1Tra = 2

Sum = 5

A30808-X3247-L24-5-7618 73

InformationSystem


PACCH/U is allocated respecting the resources allocated to the Mobile Station and toits 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 besatisfied:– one common uplink TFI is available in all timeslots (TFI is the same on all the

PDCHs).– one USF is available for each PDCH in the set.– a TAI is available in one of the assigned timeslots.

4.7.3 Mapping of Downlink Packet Traffic Logical ChannelsThe PDCHs where the Mobile Station may expect occurrence of its PDTCH/D(s) orPACCH/D for a mobile terminated transfer is indicated within the resource allocationmessages.

The logical channel type is indicated in the block header. The Mobile Staiton owner ofthe PDTCH/D or PACCH/D is indicated by the related TFI parameter (Temporary FrameIdentifier).

To establish a multislot downlink Temporary Block Flow, the following conditions shallbe 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.

74 A30808-X3247-L24-5-7618


5 Radio Resources ManagementThe PTPPKF functional object represents point to point packet data services in a cell.

Point to point data services regard:• GPRS service, i.e., packet switched data services using the traditional GMSK modu-

lation;• EGPRS service: EGPRS introduces the 8PSK modulation in the existing GSM

network.

The creation of the PTPPKF object for a specific cell can be done only if:– the BTS object has been already created for the cell;– at least one PCU (see, "6 Hardware and Software Architecture") has been created;– at least one permanent virtual connection (see "7 Gb Interface") has been config-

ured for the PCU.

Either during or after having enabled GPRS/EGPRS services in a cell, the operator canconfigure, according to his needs, the radio resources of the cell.

A cell supporting GPRS/EGPRS may allocate resources on one or several physicalchannels in order to support the packet switched data traffic. The physical channels (i.e.,PDCHs), shared by GPRS/EGPRS MSs, are taken from the common pool of physicalchannels available in the cell. The allocation of physical channels to circuit switchedservices and packet switched services is done according to the following two principles:• Master-slave concept: at least one PDCH, acting as a master, accommodates:

– the packet broadcast channel (PBCCH);– the packet common control channel (i.e., PCCCH);– user data and dedicated signalling (i.e., PDTCH and PACCH).Other PDCHs, acting as slaves, are used for both user data transfer and dedicatedsignalling only (PACCH).The master-slave concept is only valid when control signalling is carried on PCCCH;if controllo signalling is carried by the existing CCCH, the concept is no longer valid.

• Capacity on demand concept: GPRS/EGPRS does not require permanently allo-cated PDCHs. The allocation of capacity for these services can be based on theneeds for actual packet transfers which is here referred to as the "capacity ondemand" principle.The operator can, as well, decide to dedicate permanently or temporarily somephysical resources (i.e., PDCHs) to the packet switched data trafficWhen the PDCHs are congested due to the GPRS/EGPRS traffic load and moreresources are available in the cell, the network can allocate more physical channelsas PDCHs. However, the existence of PDCH(s) does not imply the existence ofPBCCH/PCCCH.

iWhen no PBCCH/PCCCH channels are allocated in a cell, all GPRS/EGPRS attachedMSs camp on the BCCH/CCCH. When PCCCH is allocated in a cell, all GPRS/EGPRSattached MSs camp on it.PCCCH can be allocated either as the result of the increased demand for packet datatransfers or whenever there are enough available physical channels in a cell (toincrease the quality of service). When the PCCCH capacity is inadequate, it is possibleto allocate additional PCCCH resources on one or several PDCHs (see "6.4 PacketSwitched Services Supported on CCCH/PCCCH").

A30808-X3247-L24-5-7618 75

InformationSystem


According to previous concepts, the operator can use different strategies to configurepacket switched data services in a cell; e.g., he can:

a) reserve at least one static timeslot for GPRS/EGPRS specific signalling, andconfigure other dynamic timeslots (which will be shared with circuit switchedservices) for GPRS/EGPRS data;

b) reserve at least one timeslot for GPRS/EGPRS specific signalling, and configureother static timeslots (which will not be shared with circuit switched services) forGPRS/EGPRS data;

c) not reserve any timeslot for GPRS/EGPRS specific signalling, and configure somestatic timeslots for GPRS/EGPRS data;

d) not reserve any timeslot for GPRS/EGPRS specific signalling, and configure somedynamic timeslots for GPRS/EGPRS data;

e) not reserve any timeslot for GPRS/EGPRS specific signalling, and configure bothsome static and some dynamic timeslots.

5.1 Enabling Packet Switched Services in a CellWhen configuring GPRS/EGPRS services on a cell (i.e., when creating a PTPPKFobject instance), the user can specify some parameters (belonging to the PTPPKFobject) that allow him to configure the two services according to his needs.

Among the parameters of the PTPPKF object, two of them allow making available or notpacket data services in the referred cell. In fact, when a PTPPKF object instance iscreated, neither GPRS service nor EGPRS service are enabled as default. So theuser, to enable GPRS and EGPRS, has to manage two specific parameters; they are:

1. the EGPRS flag (enable GPRS) allows to make available or not available the wholePacket Data services in the cell, i.e., both GPRS (based on CS1,.., CS4), andEGPRS (based on MCS1,.., MCS9). The EGPRS flag has the same functionalbehavior as the command lock/unlock on the PTPPKF object; the only difference isthat, in cases of EGPRS=FALSE, the operational state of PTPPKF is disabled. Inthis way, the operator is clear that the PTPPKF cannot provide service, even if itunlocked.The default value of the EGPRS flag is FALSE; this means that when creating thePTPPKF object instance, the cell is disabled to support, in general, both (GPRS andEGPRS) packet data services. But it must be noted that:– before setting EGPRS=TRUE for a specific cell, the user will specify, for this cell,

at least one TRX that supports the GPRS service; i.e., he can choose, among thetotal number of TRXs configured for the cell, which of them will handle packet dataservices (see "5.1.1 Enabling GPRS Service in the Cell").

– to enable EGPRS services in the cell is not sufficient to set EGPRS=TRUE butother parameter settings are required (see below); but setting EGPRS=TRUE isthe first step in the procedure that allows the configuration of the EGPRS servicein the cell (see "5.1.2 Enabling EGPRS Service in the Cell").

2. the EEDGE (enable EDGE) flag allows making available or not available theEGPRS service in the cell, provided that the GPRS service is available and thereare radio resources configured to support EDGE. It is not allowed to make theEGPRS service available (EEDGE=TRUE) if the GPRS service is not available(EGPRS=FALSE) or if no TRX in the cell has been configured to support EDGE.Moreover, the EEDGE flag cannot be set to TRUE if CSCH3CSCH4SUP parameteris set to FALSE, meaning that the EGPRS service can be actiivated if the CS-3/CS-4 coding schemes are enabled.

76 A30808-X3247-L24-5-7618


Nevertheless, the EGPRS service can be also activate without activation of CS-3/CS-4 (see note below).

5.1.1 Enabling GPRS Service in the CellAs it has been described in "5.1 Enabling Packet Switched Services in a Cell", when aPTPPKF object instance is created, the EGPRS parameter, that allows making availableor not available the whole Packet Data services in a cell (both GPRS and EGPRS), isset to FALSE as a default value.

Before setting the EGPRS parameter to true, the user must enable the GPRS serviceon a TRX basis, i.e., the user must enable at least one TRX to support packet dataservices.

To enable, in general packet switched data services on a specific TRX, the user mustset to “TRUE” the GSUP attribute belonging to the TRX object.

Setting GSUP=TRUE means that the TRX is enabled to support, in general, both packetdata services, i.e., it is enabled to support both GPRS and EGPRS.

Fig. 5.1 shows an example of one cell with five TRXs, where three of them (i.e., TRX0,TRX3 and TRX4) have been enabled to support the packet switched services.

iTo make available the EGPRS service without activation of CS-3 /CS-4 codingschemes, the operator shall set the bit25 of MNTBMASK parameter to TRUE,meaningthat the max coding scheme usable will be CS-2 independently fromCSCH3CSCH4SUP value set to TRUE.Other parameter settings are required to enableEGPRS services in the cell(see "5.1.2 Enabling EGPRS Service in the Cell").Thedefault value of the EEDGE flag is FALSE.

!The GPRS service will not be enabled in a cell, if the user does not enable it on at leastone TRX of the cell, after having created the PTPPKF object.

A30808-X3247-L24-5-7618 77

InformationSystem


Fig. 5.1 Example of TRXs enabled to support Packet Switched Services.

BTSplus equipment can be equipped with two different types of carrier units (see 6.2):

1. GSM-CUs, i.e., carrier units able to support GSM and GPRS services;2. E-CUs (EDGE carrier units), i.e., carrier units able to support GSM, GPRS and

EGPRS services.

The user, beside enabling the TRX to support packet data services (with GSUP param-eter), can indicate if the TRX will be used for GSM/GPRS only, or if it will be used forEGPRS too. To indicate how the TRX has to be used, the TRXMD parameter is used; itcan assume two values:– GSM: it is the default value that means that the TRX can be used for GSM, and also

for GPRS if GSUP=TRUE;– EDGE: it means that the TRX can be used for GSM, and also for both GPRS and

EGPRS if GSUP=TRUE.

TDMA frame

BCCH

0 7

GSUP=TRUE

TDMA frame

0 7

GSUP=FALSE

TRX 0

TRX 1

0 7

GSUP=FALSE

TDMA frame

0 7

GSUP=TRUE

TRX 2

TRX 3

TDMA frame

0 7

GSUP=TRUETRX 4

TDMA frame

iRegarding the detailed procedure to enable EGPRS, please refer to "5.1.2 EnablingEGPRS Service in the Cell".

iFrom the BTS equipment point of view, the TRXMD parameter is the criterion used toallocate a carrier unit type (GSM-CU or E-CU) to the transceiver. The associationbetween a TRX and the boards (CU or E-CU) of a BTSplus is performed automaticallyby the BTS equipment, taking into account suggestion from the operator (i.e., theTRXMD setting).

78 A30808-X3247-L24-5-7618


After having enabled one or more TRXs to support GPRS, i.e., after having set for oneor more TRXs:– GSUP=TRUE– TRXMD=GSM

the user must set to TRUE the EGPRS parameter of the PTPPKF object, to definitelyenable the GPRS service in the cell.

It is possible to set GSUP =TRUE for whatever TRX of the cell, with the following excep-tions:– In cases of Concentric Cells, the TRXs supporting GPRS must always belong to the

complete cell area;– In cases of GSMDCS (common BCCH) cells, all the TRXs that support GPRS must

belong to the same band of the BCCH TRX (and this coincides with the band of theComplete Area). This is due to the fact that the two GSM and DCS bands havedifferent propagation factors, thus it could be that on cell borders only the frequencyof one band is received; one mobile that accessed the cell with one band could notwork with the other one;

– In cases of cells having SYSID=EXT900, only the TRXs with TRXFREQ belongingto BB900 band (that is, the same band of BCCH) can have GSUP=TRUE;

– In cases SYSID=F2ONLY, if the BCCH belongs to BB900 band, all the TRXs forwhich the GSUP is set at TRUE must belong to the BB900 band;

– In cases SYSID=F2ONLY, if the BCCH belongs to the extended band, all the TRXsfor which the GSUP is set at TRUE must belong to the extended band;

– It is possible to set as first GPRS TRX any TRX of the cell, that is: it is not mandatoryto set this attribute to TRUE first on the BCCH TRX;

– The setting of a TRX to GSUP = TRUE has to take into account the Multislotconstraints for TSC and Frequency Hopping parameters;

– The setting of a TRX to GSUP=TRUE must be executed only when all the TRX’schannels are not available to the service (this situation can be reached by executinga shutdown for all these TCHs: this is suggested to avoid impacts on CS calls.

Once one or more TRXs have been enabled to support the GPRS service, the user canconfigure, according to his needs, some static and dynamic GPRS channels on them(see "5.2 Configuration of GPRS Channels in a Cell").

5.1.2 Enabling EGPRS Service in the CellAs it has been described in "5.1.1 Enabling GPRS Service in the Cell", to enable GPRSon a cell and TRX basis, the user must set:– the GSUP parameter of the TRX object to TRUE (for each TRX he wants to enable

support of packet data services);– the EGPRS parameter of the PTPPKF object to TRUE;

After that if the user wants to enable EGPRS service in one or more cells of the BSC,he must execute a series of operations to enable it.

iBeside the TRXs of a cell on which the user wants to configure the packet switched dataservices, it is suggested to also configure GSUP =TRUE for the BCCH TRX. In this waythe condition of no TRXs with GSUP =TRUE (condition that puts the PTPPKF object inDISABLE state) also happens when there is a BCCH outage. In this case, the wholeBTS is put Out of Service from both circuit switched and packet switched services pointof view.

A30808-X3247-L24-5-7618 79

InformationSystem


The ESUP parameter of the BSC object allows the user to enable EGPRS services inthe whole BSC. If the user does not set to TRUE the ESUP parameter, EGPRS servicewill not be allowed in the BSC. Since EGPRS can only be enabled on high capacityBSCs, the ESUP parameter can not be set to true if the NTWCARD parameter (BSCobject) is not set to either SNAP or SNAP_STLP.

After the user has enabled EGPRS service on a BSC basis, he has to enable it both ona TRX basis and on a cell basis.

As described in "5.1.1 Enabling GPRS Service in the Cell", to enable, in general, packetdata services on a specific TRX, the user must set to “true” the GSUP attribute belongingto the TRX object.

Setting GSUP =TRUE means that the TRX is enabled to support in general both packetdata services, i.e., it is enabled to support both GPRS and EGPRS.

To activate EGPRS service on a specific TRX, beside enabling the TRX to supportpacket data services (with the GSUP parameter), the user has to indicate that the TRXwill also be used for EGPRS. To indicate how the TRX has to be used, the TRXMDparameter is used; it can assume two values:– GSM: it is the default value that means that the TRX can be used for GSM and also

for GPRS;– EDGE: it means that the TRX can be used for GSM and also for both GPRS and

EGPRS.

To enable EGPRS service on a TRX the user must set the TRXMD parameter to theEDGE value.

After having enabled EGPRS on a TRX basis, i.e., after having enabled at least oneTRX to support EGPRS, the user can enable EGPRS on a cell basis by setting to TRUEthe EEDGE parameter.

Fig. 5.2 shows an example of one cell with five TRXs, where two of them (i.e., TRX0,TRX3) have been enabled to support GPRS only and one of them (TRX5) has beenenable to support a EGPRS too.

80 A30808-X3247-L24-5-7618


Fig. 5.2 Example of TRXs enabled to support GPRS and EGPRS.

Once one or more TRXs have been enabled to support the EGPRS service, the usercan configure, according to his needs, some static and dynamic channels on them, tobe used for packet switched services (see "5.2 Configuration of GPRS Channels in aCell").

5.1.3 Aspects Related to Carrier ConfigurationAs described before, by means of the GSUP and TRXMD attributes, it is possible tospecify whether a TRX supports:– GSM services;– GPRS and/or EGPRS services

From the BTSE point of view, the EDGE capability of a Carrier Unit(CU) is modelled witha read only attribute called TRX CAPABILTY. It reflects the real capabilities of the TRXindependently of the TRXMD parameter setting. The attribute is available for the oper-ator by GETINFO TRX and GETINFO BTS commands, and it can assume the followingvalues:– GSM: the TRX is associated to a carrier Unit without EDGE capability;– EDGE: the TRX is associated to a carrier Unit with EDGE capability;– UNKNOWN: the BSC has no knowledge about the carrier Unit associated to TRX.

The following combinations of TRXMD and TRX CAPABILITY are possible(see Tab. 5.1):

TDMA frame

BCCH

0 7

GSUP=TRUE

TDMA frame

0 7

GSUP=FALSE

TRX 0

TRX 1

0 7

GSUP=FALSE

TDMA frame

0 7

GSUP=TRUE

TRX 2

TRX 3

TDMA frame

0 7

GSUP=TRUETRX 4

TDMA frame

TRXMD=GSM

TRXMD=GSM

TRXMD=EDGE

A30808-X3247-L24-5-7618 81

InformationSystem


TRX-CU assignment procedure

The BTSE shall try to find an optimal allocation between the required TRX operationmodes 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-CUs3. Try to allocate all GSM-TRX to GSM-CUs4. Try to allocate all remaining GSM-TRX to E-CUs5. 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 andCUs is still optimal. If necessary, an automatic reconfiguration according to the rulesshown above is performed.

A change of the functional configuration may 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 TRX configuration may lead to a loss of traffic for one ortwo TRX. It is an operator’s task to avoid the loss of traffic by taking the right measures.Therefore the appropriate configuration procedures have to be performed: Shut-down/Create/Unlock command sequence.

TRXMD TRX CAPABILTITY Meaning

GSM GSM The TRX is working with GSM functionality

GSM EDGE The TRX is working with GSM functionality

GSM UNKNOWN No CU is related

EDGE GSM The TRX is working with GSM functionalitysince no E-CU is available

EDGE EDGE The TRX is working with EDGE functionality

EDGE UNKNOWN No CU is related

Tab. 5.1 Combinations of TRXMD and TRX CAPABILITY Values

!If the BCCH-TRX is involved in the TRX-CU assignment procedure(it can happen,if aEDGE property of the BCCH-TRX itself is modified or if the BTSE-internal optimizationalgorithm touches the BCCH-TRX), the whole Cell involved.In this case, a shut-down/create/unlock procedure should be applied to the whole cell and not only to thesingle TRX involved.

82 A30808-X3247-L24-5-7618


Configuration of the BCCH Transceiver for EGPRS

The EGPRS PACKET CHANNEL REQUEST message, specific for EDGE mobilestations (see "4.4.1 Packet Broadcast Control Channel (PBCCH)" and "9.8.2.4 TBFEstablishment for EDGE Mobile Stations"), is only supported by EDGE-CUs. Thereforethe use of the EGPRS PACKET CHANNEL REQUEST message can be forced byconfiguring the BCCH-TRX in EDGE mode, which implies the allocation of a EDGE-CUto the TRX, using the TRXMD parameter.

The BCCH carrier is continuously transmitted on all timeslots and without variation of RFlevel; however, the RF power level may be ramped down between timeslots to facilitateswitching between RF transmitters. If 8PSK modulation is used for timeslots of theBCCH TRX, these timeslots may use an 8PSK mean power which is at most 4 dB lowerthan the power used for GMSK modulated timeslots. So, the use of the 8PSK modula-tion on the BCCH carrier is critical and the operator can enable/disable it.

By means of the EBCCHTRX attribute, the operator can decide whether the channelsof the BCCH-TRX are available for EDGE 8PSK services or not. So, if the BCCH TRXis enabled to support EDGE, but EBCCHTRX is set to FALSE, it means that only GMSKmodulated coding schemes of EDGE will be supported on the BCCH TRX (besidesGPRS coding schemes).

5.2 Configuration of GPRS Channels in a CellAfter having defined how many TRXs will support GPRS and EGPRS services (see 5.1),the user indicates how the slots belonging to these TRXs will be managed; the followingstatements show how the user can configure the GPRS/EGPRS service on the TRXswhere GSUP =TRUE:

1. the user can reserve, on a channel basis, some slots to packet switched servicesonly; these slots will be statically allocated to GPRS/EGPRS signalling (PBCCHand PCCCH) and will not be used for circuit switched services. The user can definethese “only GPRS/EGPRS slots” on a channel basis, by setting the GDCH attributeof the chosen CHAN object;The GDCH attribute can assume the following values:– PBCCH: i.e., the related channel is reserved for packet switched services, and

supports GPRS/EGPRS system information, common signalling, and data;

iIn case of Baseband frequency hopping all TRXs involved in the same hopping law mustbe homogeneus, i.e. they must have the same TRXMD value. If a TRX with TRXMD =EDGE gets TRX_CAPABLITY = GSM (e.g. due to a reconfiguration) the hopping for theTRX related to this hopping law is stopped in the cell, and the operator is informed.Synthesizer frequency hopping is not affected.

iEven if the BCCH TRX is created in EDGE mode to support 8PSK modulation, thetimeslot 0 is not allowed to use this modulation. This is necessary for compatibility withMobiles which do not support EDGE, in fact: - the timeslot 0 is used to trasmit system information and signalling.

A30808-X3247-L24-5-7618 83

InformationSystem


– PCCCH: i.e., the related channel is reserved for packet switched services, andsupports GPRS/EGPRS common signalling, and data.

2. the user can then configure, among the remaining timeslots, other static timeslotsfor PS services (i.e., not shared with CS services); the user can indicate this numberof static GPRS/EGPRS slots using the GMANPRES attribute of the PTPPKF object.The difference, with respect to the configuration of static slots using the GDCHattribute, is that with GDCH the configuration is made on a channel basis andregards GPRS/EGPRS signalling channels only, whereas using GMANPRES theconfiguration is made without indicating the channel, but only a “number of chan-nels”, and regards GPRS/EGPRS traffic channels only.If for example, the user defines 4 static slots for packet switched services, usingGMANPRES, then 4 slots will be reserved by the system for GPRS/EGPRS trafficon the TRXs where GSUP =TRUE;

3. the user can choose among the remaining available slots (on TRXs where GPRS issupported) the maximum number of dynamic GPRS/EGPRS channels; these chan-nels will be shared between PS and CS services, according to the actual request ofresources.To configure this number of shared slots, the user sets the GPDPDTCHA attribute(PTPPKF object).It indicates a percentage; this percentage is applied to the total number of availableslots (on TRXs where GPRS/EGPRS are supported) decreased by the number ofboth static GPRS/EGPRS slots and slots reserved for GSM signalling. Thepercentage indicates the maximum number of dynamic GPRS/EGPRS slots.

To clarify previous concepts, let’s suppose (see Fig. 5.3) that three TRXs of a cell areconfigured and enabled to support PS services (according to what has been describedin paragraph 5.1), and particularly:– 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; thesecond and the third TRXs (TRX1 and TRX2) are completely dedicated to circuitswitched services .

Then, on TRXs where packet switched services are supported, the total number of avail-able slots for PS and CS services is equal to 22, in fact:– 6 slots are available on TRX0;– 8 slots are available on TRX3;– 8 slots are available on TRX4.

iOnly one physical channel can be configured to carry the PBCCH logicalchannel (i.e., only one channel can be configured as the PBCCH); if theoperator then needs more PCCCHs, he must configure another channel asPCCCH.PBCCH and PCCCH channels can be defined on BCCH TRX only.

iAs it has been described, setting GSUP =TRUE means that that TRX is available for PSservices in general; then, according to the TRXMD parameter value and to the avail-ability of EDGE-CUs, TRXs are enabled to support GPRS only or both GPRS andEGPRS.So, if e.g. the user configure some static timeslots, according to the TRX where they areassigned they will be used for GPRS only or for EGPRS too (obviously only on TRXswith GSUP =TRUE).

84 A30808-X3247-L24-5-7618


Fig. 5.3 Example of GPRS/EGPRS configuration.

If the user sets:– GPDPDTCHA= 50 (i.e., 50%);– GDCH= PBCCH for one CHAN object (CHAN:6) of the BCCH TRX (see Fig. 5.3);– GMANPRES=1

then, the maximum number (N) of GPRS/EGPRS channels shared with CS services isobtained by the following formula:

N= [Total number of available timeslots on TRXs with GSUP=TRUE - Number ofGPRS/EGPRS static slots(defined by GDCH and GMANPRES)]* GPDPDTCHA/100 =

= ( 22 - 2 ) * 50/100 = 10

So, in this cell we will have (on TRXs where GSUP=TRUE):– 2 slots statically allocated for packet switched services (one signalling slot defined

on a channel basis using the GDCH attribute and the other one defined on a cellbasis using GMANPRES)

– 10 slots shared between PS and CS services (according to the previous formula andthe GPDPDTCHA setting);

TDMA frame

BCCH SDCCH

0 7

GSUP=TRUE

TDMA frame

0 7

GSUP=FALSE

TRX 0

TRX 1

SDCCH

0 7

GSUP=FALSE

TDMA frame

0 7

GSUP=TRUE

TRX 2

TRX 3

TDMA frame

0 7

GSUP=TRUETRX 4

SDCCH

TDMA frame

GDCH=PBCCH

TRXMD=GSM

TRXMD=EDGE

TRXMD=EDGETRXCapability=EDGE

TRXCapability=GSM

TRXCapability=EDGE

A30808-X3247-L24-5-7618 85

InformationSystem


– 10 slots reserved for CS services (i.e., the remaining slots on the TRXs whereGSUP=TRUE).

Obviously both the TRX1 and the TRX2 will be used for circuit switched services only.

Finally, to define how many users can be multiplexed in a PDCH, the GMANMSALattribute (PTPPKF object) is used. It defines the maximum number of GPRS/EGPRSusers that can share the same timeslot (PDCH); it is composed of two fields: the firstindicates the maximum number of users in the uplink direction, the second one specifiesthe maximum number of users in the downlink direction.

5.3 Management of Packet Data Channels

5.3.1 Generalities about Resource AssignmentsThe radio resource assignment to a mobile station requiring an uplink or a downlink TBFestablishment is performed under the BSC control, through co-operation between thePPCU/PPXU processors (involved in PDCH management and scheduling functions forUL and DL data transfer, see "6 Hardware and Software Architecture") and the TDPCprocessor (dedicated to resource management).

When a new GPRS/EGPRS request arrives at the BSC, the PPCU/PPXU, starting fromthe MS multislot class and the required peak throughput, estimates the number of radioresources (i.e., the number of PDCHs) requested for TBF establishment.

In order to provide the best possible throughput for each user, the system considers thePeak Throughput Class to calculate the number of resources to be assigned to a newTBF. The resource allocation algorithm tries to assign to each TBF a number of timeslotsthat depends on the required Peak Throughput Class, i.e.;

a) MS Multislot Class (it is sent from the MS to the network during the GPRS attachprocedure, see "9.3.2.1 Attach Function");

b) Peak Throughput:– when 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.

The PCU, after calculating the number of requested resources, checks if the actual usedstrategy is the vertical one or the horizontal one (see "5.3.2 Horizontal/Vertical Alloca-tion Strategies"). Then, according to the used strategy and to the needed resources, itsends the correct request to the TDPC.

According to the requests received by PPCU/PPXU, the TDPC is responsible for:

1. the assignment of the proper radio resources on the air interface (PDCHs);2. the assignment of the Abis interface subslots related to these PDCHs.

When the PCU request arrives at the TDPC, the TDPC tries to satisfy the request.

iIt must be underlined that the previous example is only valid if HOPMODE=SYNHOP.As soon as HOPMODE=BBHOP (independently of whether or not frequency hopping isenabled), timeslots 0 of all non-BCCH TRX are never allocated for GPRS/EGPRS.

iTrying to maximize the throughput is the most important criteria in radio resourcesearch.

86 A30808-X3247-L24-5-7618


If required channels are found, the TDPC sends the ACK message to the PCU, other-wise other actions have to be executed (see "5.3.3.2 TDPC Algorithm").

Note that, on a cell basis, the PPCU/PPXU knows:

1. the number of PDCHs in use at a given time; i.e., it knows:– the timeslots (PDCHs) with at least one TBF assigned;– PDCHs for which the Empty Channel Timer is running.In fact, when the last MS associated to a PDCH is released, the “virtual” assignmentpersists for the duration of the Empty Channel Timer. The value of this timer is set,by means of the TEMPCH parameter, to avoid continuous requests (in cases of highGPRS/EGPRS traffic) from the PPCU to the TDPC.When the timer is still active, the allocated PDCH(s) for the “released” TBF are stillseen as allocated even if they are no longer active.

2. the number of PTDs (equal to the number of Abis subslots) related to the PDCHsstill in use.From this point, it could happen that (according to what has been described in"6.3.1 Concatenated PCU Frames") for a PDCH one or more corresponding PDTsare useless, i.e., they are filled with idle PCU frames, due to downgrade to a codingscheme needing less PDTs than the initial ones. When a PDT is filled with idle PCUframes, the PCU, before releasing it waits until a timer defined by the TEMPPDTparameter expires.The timer is used to avoid continuous requests of Abis resources from the PPCU tothe TDPC; in fact to every PDT has corresonding Abis 16 kbit/s subslots that thePCU requires for the TDPC, since it is the TDPC that manages Abis resources.

5.3.2 Horizontal/Vertical Allocation StrategiesWhen a new request of GPRS/EGPRS resources arrives at the BSC, two different strat-egies are provided to assign packet switched data channels; they are:• the VERTICAL ALLOCATION (VA) strategy: before assigning a new slot to

GPRS/EGPRS service, the already used slots must be filled as much as it ispossible, according to the chosen GMANMSAL value (see 5.3.2.1);

• the HORIZONTAL ALLOCATION (HA) strategy: it is introduced in the system toallow higher bit data rates when the cell is not congested.This strategy is intended to distribute the incoming GPRS/EGPRS calls on all theavailable PDCHs. In this way not too many users are multiplexed on the samePDCH, increasing the data transfer throughput for all the involved mobiles(see 5.3.2.2).

The user can manage the allocation strategy according to his needs, by means ofspecific parameter settings. It is important to underline how the chosen strategydepends upon both from radio resources availability and Abis resources availability.

Chapter 5.3.2.3 describes how the radio interface situation triggers the switching fromHA to VA and vice versa, according to parameter settings; whereas chapter 5.3.2.4describes the analogous topics for what concerns the Abis interface. Finally, thecomplete algorithm is summarized in chapter 5.3.2.5.

5.3.2.1 Vertical Allocation Strategy (VA)When GPRS/EGPRS channels are handled using the Vertical Allocation (VA) algorithm,the criterion is to multiplex the maximum number of mobiles on each channel, before

A30808-X3247-L24-5-7618 87

InformationSystem


assigning a new PDCH. This is obtained by filling an already used PDCH, as much asit is possible, compatibly with:• network settings of GMANPRES, GPDPDTCHA and GMANMSAL attributes;• MS multislot capability.

If, for example, 2 mobile stations perform 3DL+1UL GPRS/EGPRS calls, the BSC e.g.,will assign them the timeslots number 2, 3 and 4.

In this way, timeslots from 5 to 7 remain free because the BSC multiplexes the 2 mobileson the same 3 PDCHs, as drawn in Fig. 5.4.

Fig. 5.4 Example of Vertical Allocation Algorithm

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 VAcondition and over each radio timeslot is multiplexed only one mobile station, if threeGPRS/EGPRS mobile requests (single slot) arrive to BSC, the BSC will multiplex the 3mobiles over 3 different radio channels trying to uniformly distribute the resources.

If flat distribution was not used, all the 3 mobiles would be multiplexed in the sametimeslot (compatibly with GMANMSAL setting).

5.3.2.2 Horizontal Allocation Strategy (HA)The Horizontal Allocation (HA) strategy is intended to distribute the incomingGPRS/EGPRS calls on all the available PDCHs. In this way not too many MSs are multi-plexed on the same PDCH increasing the data transfer throughput for all the involvedmobiles.

When a new request of PDCH channels arrives at the BSC and radio channels forGPRS service are still available, the BSC assigns new radio channels to theGPRS/EGPRS mobiles instead of increasing the number of mobiles multiplexed on thealready busy channels.

If, for example, 2 mobiles perform 3DL+1UL GPRS/EGPRS calls, the BSC will assigntimeslots number 2, 3 and 4 to the first call, then timeslots number 5, 6 and 7 to thesecond call.

In this way each timeslot is used for a lower number of calls and the throughput is betterthan that for the vertical allocation strategy, as drawn in Fig. 5.5.

BCCH TRX bcch sdcch

TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

MS1DL MS1DL MS1DL

MS1UL

MS2DL MS2DL MS2DL

MS2UL

88 A30808-X3247-L24-5-7618


Fig. 5.5 Example of Horizontal Allocation Algorithm

5.3.2.3 Switching between VA and HA According to Radio ConditionsTaking into account the radio interface, the BSC switches autonomously from VA to HA(and vice versa) in relation to the traffic load in the cell (i.e., in relation to the number ofbusy air timeslots).

The aim of this feature is to use the horizontal allocation when the cell is not loaded;otherwise the adopted strategy will be the vertical one.

To avoid frequent changes between HA and VA strategies, two thresholds are defined:– one threshold (ThresholdIdleChannelHV) represents the transaction from the hori-

zontal allocation to the vertical one;– the other threshold (ThresholdIdleChannelVH) represents the transaction from the

vertical allocation to the horizontal one.

These thresholds, used to activate horizontal/vertical allocation, are managed by theGASTRTH attribute (PTPPKF object).

The threshold, that causes the transaction from one allocation algorithm to the otherone, 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 tothe number of available channels in the cell (TCHs or PDCHs; do not consider slotscontaining GSM signalling, such as BCCH or SDCCHs slots, and also slots staticallyreserved to GPRS/EGPRS).

The number of available channels in the cell is calculated as:

Available Channels = Total number of configured channels - Number of OUT OFSERVICE channels - Number of GPRS/EGPRS static channels (defined by both GDCHand GMANPRES) - Number of GSM signalling channels

Obviously the number of Idle Channels is the number of “not busy” channels inside thepool of all the available channels of the cell.

Then the percentage of idle channels in the cell (to be compared with the thresholds ofthe GASTRTH parameter) is given by:

Percentage of Idle Channels in the cell = Idle Channels / Available Channels

BCCH TRX bcch sdcch

TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

MS1DL MS1DL MS1DL

MS1UL

MS2DL MS2DL MS2DL

MS2UL

iThe GASTRTH contains a third field, called ThresholdIdleChanEU; this field representsa threshold that is used in the radio resource upgrade strategy ("5.3.4.1 Upgrade ofRadio Resources").

A30808-X3247-L24-5-7618 89

InformationSystem


Let’s consider a cell with five configured TRXs, three of them supporting GPRS/EGPRS(see Fig. 5.6) where:– TRX0 contains BCCH and SDCCH logical channels;– TRX1 and TRX2 do not support GPRS/EGPRS;– TRX3 supports the GPRS/EGPRS service, but it is out of service.– the timeslots of the TRXs (with the exception of the BCCH and the SDCCH ones)

are defined as TCHF_HLF; then each timeslot represents, from the circuit switchedservices point of view, two available channels.

Fig. 5.6 Example of a Cell Configured with Five TRXs.

iIt is important to highlight that the evaluated value, that represents the percentage ofidle channels in the cell, is truncated, so decimals are not taken into account in thecomparison with thresholds. For example, if the internal evaluation estimates that thepercentage of idle channels in the cell is 10.9%, then the real value that is compared tothe thresholds is 10% and not 11%).

TDMA frame

BCCH SDCCH

0 7

GSUP=TRUE

TDMA frame

0 7

GSUP=FALSE

TRX 0

TRX 1

SDCCH

0 7

GSUP=FALSE

TDMA frame

0 7

GSUP=TRUE

TRX 2

TRX 3

TDMA frame

0 7

GSUP=TRUETRX 4

SDCCH

TDMA frame

90 A30808-X3247-L24-5-7618


In this case:• total number of configured traffic channels = (6 + 7 + 7 + 8 + 8 ) * 2 = 72;

• number of OUT OF SERVICE channels = (8 * 2) = 16;• if we set GMANPRES= 3 (without setting the GDCH value for any channel), then the

Number of static GPRS/EGPRS channels to be considered in the previous formulais equal to 6 (since each timeslot reserved to packet switched services represents,from the circuit switched services point of view, two available channels).

Then, according to the above formula (without considering GSM signalling channels):

Available channels = 72 - 16 - 6 = 50.

If, for instance, the GASTRTH parameter has been set with the following values:– ThresholdIdleChannelHV=30%, for the transaction from HA ---> VA;– ThresholdIdleChannelVH=40%, for the transaction from VA ---> HA.

when the percentage of idle slots is over 40%, horizontal allocation is used. In this case:

(100 * Idle channels) / Available channels > 40 ----> Idle channels = 21.

So, when in the cell the number of idle channels equals 21, the Horizontal Allocationstrategy is used.

If the percentage of idle slots falls under 30%, vertical allocation is used; in this case:

(100 * Idle channels) / Available channels < 30 ----> Idle channels = 14.

So, when in the cell the number of idle channels reaches 14, the vertical Allocationstrategy is used.

If the percentage again exceeds the 40% threshold, the horizontal allocation algorithmis restored.

iBCCH and SDCCH signalling channels are not considered, only traffic chan-nels are taken into account.

iThe difference between the two thresholds of the GASTRTH parameter should not betoo high, but the thresholds have to be set to reasonable values (also taking into accountthe number of configured TCHs in the cell). Otherwise it could happen that, whenVERTICAL allocation is used, a return back to HORIZONTAL one is applied only whenthe cell is completely idle, and this is not a real hysteresis behavior.

iIt should be noted that when horizontal allocation is used to assign GPRS/EGPRSresources, two conditions, related to radio interface, can determine the transition to thevertical one: the first condition occurs when, in the cell, the number of idle channels fallsbelow the threshold set by the GASTRTH parameter; the second one occurs when thenumber of channels assigned to GPRS/EGPRS users reaches the maximum number ofchannels configured for PS services by means of the GMANPRES, GDCH and GPDP-DTCHA parameters.

A30808-X3247-L24-5-7618 91

InformationSystem


5.3.2.4 Switching between VA and HA according to Abis Interface Condi-tionsTaking into account the Abis interface, the BSC switches autonomously from VA to HA(and vice versa) in relation to the number of exploited Abis resources (i.e., in relation tothe number of busy Abis subslots).

In fact, according to the flexible Abis allocation strategy (see 6.3), the number of usedAbis resources of a BTSM depends on which services are currently running on the cellsmanaged by the BTSM. Then it is very important to check, besides the radio interfacesituation, 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 alsoinfluenced from the Abis interface.

To manage the resource allocation process, a set of thresholds regarding Abis alloca-tion usage is introduced. The user can set these thresholds by the GASTRABISTHparameter (gprsAllocationStrategyAbisThresholds) of the BTSM object.

GASTRABISTH is composed of four fields, two of them allow management of thevertical/horizontal allocation strategy and are here described; the remaining two regardthe upgrade of Abis resources and are discussed in "5.3.4.2 Upgrade of AbisResources":• the first threshold (thresholdIdleAbisHV) defines the percentage of idle Abis subslots

of the BTSM (over the available Abis subslots of the BTSM) under which verticalallocation strategy for Abis scarcity is activated on the radio interface (for all the cellof the BTSM). Activating the vertical allocation in cases of Abis scarcity is useful tore-use in multiplexing the already allocated Abis subslots, slowing down the alloca-tion of new Abis resources;

• the second one (thresholdIdleAbisVH) defines the percentage of idle Abis subslotsof the BTSM (over the available Abis subslots of the BTSM) over which horizontalallocation can be activated again on the radio interface, if the thresholds on radioresources (on a cell basis) also allow that.

Constraints on these two Abis thresholds are:

5.3.2.5 Allocation of ResourcesBesides the situations described in 5.3.2.3 and 5.3.2.4, in the BR7.0 release, theswitching to vertical/horizontal allocation is also driven by the availability/unavailabilityof PDTs on PCU (remember that with the high capacity BSC, see "6.1 Supported BSCTypes", the maximum number of GPRS channels manageable by the single PCU, i.e.,the maximum number of PDT manageable by the single PCU, is fixed to 256).

Then according to the availability/unavailability of PDTs on the PCU side:– when the percentage of busy PDTs on a PCU is 100%, then vertical allocation is

applied;– when the percentage of busy PDTs on a PCU is less than100%, then horizontal allo-

cation is applied (provided that thresholds of GASTRTH and GASTRABISTHparameters do not lead to vertical allocation).

In summary, in cells belonging to a BTSM with dynamic Abis management, the followingsituations are possible during the allocation of radio resources, according to differentcontexts:

thresholdIdleAbisHV < thresholdIdleAbisVH

92 A30808-X3247-L24-5-7618


a) horizontal allocation in a cell is used if at the same time these three conditions aresatisfied:– there is no radio scarcity in the cell, i.e., the percentage of idle air timeslots in the

cell is greater than the ThresholdIdleChannelHV field of the GASTRTH param-eter;

– there is no Abis resources scarcity, i.e., the percentage of idle Abis subslots of theBTSM managing the cell is greater than the thresholdIdleAbisHV field of theGASTRABISTH parameter;

– there is no PDT exhaustion for the PCU that manages the cell.b) starting from horizontal allocation, if there is radio scarcity, i.e., the percentage of

idle air timeslots in the cell becomes lower than the ThresholdIdleChannelHV fieldof the GASTRTH parameter, than vertical allocation is triggered.

c) starting from horizontal allocation, if there is Abis scarcity, i.e., the percentage of idleAbis subslots in the BTSM becomes lower than the ThresholdIdleAbisHV field of theGASTRABISTH parameter, than vertical allocation is triggered; the PCUs that arehandling cells belonging to the impacted BTSM are informed.

d) starting from horizontal allocation, if there is PDT exhaustion in the PCU, thanvertical allocation is triggered.

e) if the vertical allocation of the cell is due to radio scarcity only, and the percentageof idle air timeslots in the cell becomes greater than the ThresholdIdleChannelVHfield 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 ofidle Abis subslots in the BTSM becomes greater than the ThresholdIdleAbisVH fieldof the GASTRABISTH parameter, than horizontal allocation is triggered; the PCUsthat are assigned cells belonging to the impacted BTSM are informed.

The allocation strategy used is managed and implemented in the TDPC. The TDPCinforms the PCU about the used strategy via the allocation flag (HA/VA). This flag isupdated each time the TDPC replies to PCU requests for resources.

To avoid possible misalignment between TDPC and PCU, as regards the allocation flag,a mechanism is foreseen for which an audit, running every 10 seconds for eachequipped and in service PCU, is sent to communicate to the PCU the current allocationstrategy used on the TDPC side.

5.3.3 Management of Incoming GPRS/EGPRS RequestsWith the introduction of packet switched data calls, a new clear and flexible strategy forchannel allocation is required. The introduction of channel allocation strategies requiresa mechanism to use/reuse the system resources, in order to better comply with the oper-ator’s choices. In this sense it is very important to optimize the resource allocation inorder to use each TRX in the best possible way, and to satisfy each new requestaccording to the customer’s setting (both for Data and for Speech calls).

Regarding the management of different services, the operator can configure in the cellstatic and dynamic GPRS/EGPRS timeslots (see "5.2 Configuration of GPRS Channelsin a Cell").

When a new GPRS/EGPRS request arrives at the BSC, it starts a process that isresponsible for the management of all the incoming requests: the PCU, when it isneeded, asks to the TDPC to set-up new channels for packet switched services. The aimof the task in PCU/TDPC is to allocate the requested resources according to the oper-ator setting and to the Mobile Station preferences.

A30808-X3247-L24-5-7618 93

InformationSystem


The radio resources allocation algorithm keeps into account the availability of EGPRSservice, and the presence of EDGE capable mobiles and TRXs: in fact MSs that supportEGPRS could be assigned either to TRX supporting EDGE (exploiting EGPRS codingschemes) or to TRX supporting GPRS (in this case, only GPRS coding schemes can beused).

To distinguish EDGE TRXs from non-EDGE TRXs, both on TDPC and PCU, theResource Manager looks at the ‘TRX availability’ dynamic attribute of the TRX (see"5.1.3 Aspects Related to Carrier Configuration"): TRX with ‘unknown’ ‘TRX availability’are not taken into account, since they are not available for service at all.

Both on TDPC and on PCCU, the radio resource research algorithm will also take intoaccount the EBCCHTRX attribute, that specifies whether the 8PSK modulation isallowed on the BCCH TRX (see " Configuration of the BCCH Transceiver for EGPRS").

The aim of the algorithm is: maximize the throughput in the limits of specified peakthroughput (if specified), minimizing the number of allocated radio resources.

Therefore, in principle, EDGE TRXs are preferable for EDGE-capable mobiles, becausehigher data rates are possible with a lower number of radio resources, and even whendata rates are comparable, or GPRS data rates are slightly better (e.g., CS4 versusMCS4), we can expect better performances from a TBF operating in EGPRS mode(instead of GPRS mode), due to specific retransmissions rules and incremental redun-dancy (see "9.9.1.2 EGPRS Acknowledged Mode").

But, for an EGPRS TBF, when the multislot capability of a mobile is high, and if radioresources are insufficient on EDGE TRXs and available on non-EDGE TRXs, a non-EDGE TRX could be preferable. In fact, as it has been said, trying to maximize thethroughput is the most important criteria in radio resource research. Let us consider anexample; a request to establish a TBF with the following requirements arrives at theBSC:

According to the request, the BSC finds two solutions; the first using NE timeslots on anEDGE TRX, the second using NG timeslots on a non EDGE TRX, where:

The ‘best’ solution is to allocate 2 radio timeslots on the EDGE TRX, because the peakthroughput is sustained with the minimum number of radio resources.

But if only 1 radio resource (NE’) is available on an EDGE TRX, the sustainablethroughput is only 59.2 kbit/s. In this case, 3 radio resources (62.4 kbit/s), or 4 radioresources (83.2 kbit/s), on a non-EDGE TRX allow sustaining 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 higherflexibility for different operator’s strategies, a parameter is provided. This parameter,called CPOLICY, allows the operator to indicate on which TRX (BCCH or not BCCH) acertain type of call (voice or data) will be preferably allocated. In this way, a clear usagepolicy for the BCCH TRX channel allocation is guaranteed. The PCU and the TDPC

Peak throughput = 80 kbit/sMulti-slot capability = 4 timeslots

NE = 2 (with MCS9)NG = 4 (with CS4)

94 A30808-X3247-L24-5-7618


administer this setting when they have to assign resources to GPRS users (see"5.3.3.1 PCU Algorithm" and "5.3.3.2 TDPC Algorithm").

So, taking account GPRS and EGPRS mobiles, TRXs supporting EGPRS or GPRSonly, and the CPOLICY parameter, the research algorithm basically follows these rules :• in cases of EDGE capable mobiles, TRXs are sorted giving priority to the EDGE

TRXs; this criterion is more important than the call policy. That is: if the CPOLICYparameter is set to DATA_CALL_ON_BCCH and the BCCH TRX is a non-EDGETRX, the BCCH TRX is checked AFTER all the EDGE TRXs and before all the othernon-EDGE TRXs.When the EDGE BCCH TRX doesn’t support 8PSK (EBCCHTRX=FALSE), the CallPolicy is disregarded: BCCH TRX will be considered after all the other EDGE TRXseven if the CPOLICY parameter is set to DATA_CALL_ON_BCCH. If the operatorwants to give more priority to the BCCH TRX, according to the Call Policy, theEBCCHTRX attribute should be set to TRUE;

• in cases of non-EDGE capable mobiles, TRXs are sorted giving priority to the nonEDGE TRXs; this criterion is more important than the call policy. That is: if theCPOLICY parameter is set to DATA_CALL_ON_BCCH and the BCCH TRX is aEDGE TRX, the BCCH TRX is checked AFTER all the non-EDGE TRXs and beforeall the other EDGE TRXs.

The horizontal/vertical allocation algorithm on TDPC receives as input aPDCH_Request message from the PCU containing, among other information, a list ofsuggestions for channels to be granted by TDPC. The “already busy for GPRS/EGPRS”channels can be assigned only by the PCU, while idle channels can be assigned onlyby the TDPC.

If the incoming GPRS request cannot be satisfied (because some timeslots have to befree for the GPRS multislot calls, or because the cell is congested), the request isinserted in a waiting queue (i.e., a ‘stand by’ queue), and it will be served as soon as theproper actions have been performed (see "5.3.6 Waiting Queue Management").

As it has been described, the algorithm used to assign GPRS resources is split in twoparts: one is performed on the PCU and the other one on the TDPC; in the followingsections the parts are described.

5.3.3.1 PCU AlgorithmWhen a new request of GPRS resources arrives at the BSC, the first actions are takenby the PCU that handles the cell from which the request is arrived.

When a new request is sent to the PCU, the following information is provided:• Mobile capability (GPRS or EGPRS);• required Peak throughput;• Multislot class;• Candidate Initial Coding Scheme (CS/MCS); as it has been described in

"4.2 Channel Coding", the user can set the preferred initial coding scheme, for both

!The

The waiting queue where the “not served GPRS requests” are inserted, is differentfrom the queue related to the Queuing feature. In fact the Queuing feature is related tocircuit switched calls only, and the related queue is called queuing list .

iThis chapter describes the PCU algorithm in cases of new GPRS/EGPRS calls. Theupgrading procedure, in cases of new resources requested for already establishedcalls, are discussed in "5.3.4 Upgrading Strategies".

A30808-X3247-L24-5-7618 95

InformationSystem


GPRS and EGPRS services, to be used when a new TBF starts. The O&M config-ured initial coding schemes are only used if no information about a MS in a cell isavailable when a new TBF starts. In fact, the PCU holds in memory, for each mobilestation, the last coding scheme (either CS or MCS) used in the uplink/downlinkdirections for TBFs associated to the MS; neverthless the PCU maintains this infor-mation only for a specific period of time. So the Candidate Initial Coding Scheme willbe:– the coding scheme stored in the PCU memory, if this information is still available;– otherwise the O&M configured value.

The aim of the search on the PCU side is to find a number of adjacent PDCHs in orderto maximize the throughput of the TBF.

The PCU, before starting to search radio resources on the TRXs, calculates the optimalnumber (N) of radio resources that allow the maximum “initial target throughput” of thedata transmission.

The general formula to calculate the number of “optimal” number of radio resources (N)is the following:

The optimal number of radio resources that the PCU calculates depends on:– the availability of the Peak Throughput in the request;– the mobile station capability, i.e., if the MS is EGPRS capable or not.

The different possibilities are described:

iTo get more detailed information about initial coding scheme handling,please refer to "10.5.3 Selection of the Candidate Initial Coding Scheme".

Peak Throughput Available Peak ThroughputNOT Available

N Min(ceil ( PT / (T_I_CS x (1-BLER) ), Multislot Class) Multislot Class

where:ceil = round up to the upper integerPT = required Peak ThroughputT_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 (i.e., the sum ofthe acknowledged blocks and the not acknowledged one, see "9.9 RLC Data BlockTransfer"):

BLER= NACK_Blocks/(ACK_Blocks+NACK_Blocks)

The user can define the initial BLER value, used in the resource assignment process,via the INIBLER parameter.The O&M configured initial BLER is only used if no information about a MS in a cell isavailable when a new TBF starts. In fact, the PCU stores in memory, for each mobilestation, besides the last coding scheme, the last measured BLER value (historicalBLER) associated to the MS; neverthless the PCU maintains this information only fora 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.

96 A30808-X3247-L24-5-7618


a) In cases of mobiles with EGPRS capability and in cases where the peak throughputis available, two calculations must be performed, for a ‘pure’ UL or DL TBF setup (noconcurrent 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 modeGPRS, only NG will be calculated; this is because, if a MS is assigned concurrentTBFs, these will be in the same TBF mode.

b) In cases of mobiles without EGPRS capability and in cases where the peakthroughput 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 interms of ‘initial target throughput’ instead of ‘number of timeslot’; the basic formula tocalculate the initial target throughput per timeslot is:

This value is multiplied by the number (NG or NE) of radio resources to get the bettersolution; the better solution is that which provides the highest Initial Target Throughput.

When the PCU has calculated the optimal number of radio resources, it starts executinga pre-search of radio resources on available TRXs; a different process is appliedaccording to the allocation strategy currently in use (the PCU algorithm is shown inFig. 5.7).

In cases of Horizontal Allocation strategy the PCU starts a search on all the TRXsusable for GPRS or EGPRS according to the kind of request. The criteria used to findresources are the following (in order of priority):

1. prefer EGPRS on EDGE TRXs and GPRS on non-EDGE TRXs;2. maximize the “Initial target throughput”;

Initial target throughput per timeslot = throughput (maximum data rate) of the candi-date initial CS/MCS

iWhen the initial target throughput per PDCH on GPRS TRXs is slightly better than theinitial target throughput per PDCH on EDGE TRXs, solutions allocating N radioresources on EDGE TRXs are preferred to solutions allocating N radio resources onGPRS TRXs, because better performances are expected from EGPRS specific retrans-mission rules and incremental redundancy (see "9.9.1.2 EGPRS AcknowledgedMode"). This situation can occur, for example, when the MCS and CS used to calculatethe ‘initial target throughput’ are ‘homologous’ (e.g., CS4/MCS4). For example, 3 radiotimeslots in EGPRS TBF mode are preferable to 3 radio timeslots in GPRS mode, incase the initial MCS in the cell is MCS4 (data rate 17,6) and the initial GPRS CS in thecell is CS4 (data rate 20,8).

iThe “Initial target throughput” is just an indicator, used to compare different radiotimeslot configurations; there is no guarantee that the ‘initial target throughput’ is reallyachieved, because the actual throughput depends on several factors: radio conditions,C/I, Link Adaptation, multiplexing factor, availability of Abis and PDT resources, etc. Inparticular, in cases of Abis/PDT resources scarcity it is not guaranteed that the resourceassignment will result in the best solution in terms of throughput (see "5.3.3.2 TDPCAlgorithm").

A30808-X3247-L24-5-7618 97

InformationSystem


3. maximize the number of empty channels (i.e., the channels already allocated inpacket transfer mode, but without assigned TBF; these channels are seen by thePCU as allocated until the TEMPCH timer expires);

4. minimize the overall weight on the affected PDCHs;

5. maximize the number of adjacent timeslots with respect to the ones already inpacket transfer mode;

6. choose the preferred TRXs according to the CPOLICY parameter.

The output of this algorithm is a possible configuration on one TRX. Two cases exist:

1. if all the chosen timeslots are already available at PCU side, i.e., the PCU does notneed to ask new idle PDCH channels to the TDPC, the timeslots are assigned byPCU immediately (i.e., no PDCH_Request message is sent to TDPC). But in thiscase, according to the flexible Abis allocation strategy, it could happen that, even ifno new PDCH has to be allocated, new PDT/Abis allocation is necessary to supportthe new TBF; this is because e.g., the current Abis allocation is not enough tosupport the candidate initial coding scheme. In this case, the PCU will sent a requestto the TDPC for additional Abis resources using the PDCH_Abis_Upgrade message(see "5.3.4.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 TEMPCHtimer is running (these channels are also called pre-allocated)

2. in case some timeslots are not immediately available, i.e., when new idle channelsare 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 ofAbis 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.

With the Vertical Allocation strategy , the idea is to reduce the number of new timeslotsto asked of the TDPC for the incoming request.

iThe following QoS parameters are taken into account in the resource allo-cation process 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 aunique ‘internal priority’ so that UL and DL TBFs are comparable. Internalpriority’ here mentioned coincides with the ‘scheduling priority’ used by thescheduler process (see "9.9.7 Notes About GPRS/EGPRS TBF Sched-uling" to read how Qos attributes are mapped to scheduling priority).According to its priority, each TBF is assigned a ‘weight’; as described in9.9.7, the association between priorities and weights is performed by thefollowing O&M attributes: SCHWEIPRI1, SCHWEIPRI2, SCHWEIPRI3,SCHWEIPRI4.So, each PDCH(i) is assigned a ‘total weight’ W(i) given by:W(i) = Sum of W(k)where W(k) is the weight of all the TBF(k) multiplexed on the PDCH(i).On PCU, the algorithm for radio resources presearch, in addition to theother criteria, tries then to minimize the total weight of the suggestions tobe sent to TDPC.

98 A30808-X3247-L24-5-7618


When the Vertical Allocation strategy is used, the layering method is the following (flatdistribution): instead of multiplexing continuously on the same timeslot (until theGMANMSAL value is reached), the TBFs are spread on all the already assignedtimeslots, on all the TRXs. This leads to better system performances in terms of TBFthroughput. This is done by multiplexing the new TBF on the timeslots already in packetmode 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):

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 according to the CPOLICY parameter.

The output of this algorithm is a possible configuration on one TRX. If all the chosentimeslots 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 PCUside 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 currentPDT/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 aboutupgrade of Abis resources, see "5.3.4.2 Upgrade of Abis Resources").

In case some timeslots are not immediately available, a PDCH_request message is sentto the TDPC indicating the suggestion to be preferred in the search. Also in this case, inorder to handle parallel requests, the TRX belonging to the suggestions is set as“frozen” and excluded from subsequent searches until either TDPC answers (positivelyor not) or a protection timer expires.

A30808-X3247-L24-5-7618 99

InformationSystem


Fig. 5.7 Allocation Algorithm followed by the PCU

Allocation type?

MS/SGSNrequest

Horizontal Vertical

Calculate the number ofrequested PDCHs according to:- Multislot Class- Peak Throughput

Find channelsaccording to HAcriteria

YESNO

PCU

Assign channels

Send PDCH_Request

needs new

channels?

to TDPC

already inPacket Mode

Find channelsaccording to VAcriteria

YESNOPCU

Send PDCH_Request

needs new

channels?

to TDPC

-Mobile Station Capability-Candidate Initial Coding Scheme

PDCH PDCH

PCUneeds newPDT?

NO

Send

to TDPCPDCH_Abis_Upgrade

YES

Assign channelsalready inPacket Mode

PCUneeds newPDT?

NO

Send

to TDPCPDCH_Abis_Upgrade

YES

100 A30808-X3247-L24-5-7618


5.3.3.2 TDPC AlgorithmAs it has been described (see 5.3.3.1), the PCU can send to the TDPC two kinds ofmessage:

a) the PDCH_Request message, when new PDCHs on the air interface must beassigned; this message also specifies the number of Abis resources needed tosupport 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 thefollowing 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 withTBF requiring less Abis resources;

– when the upgrade of the coding scheme of one TBF requires that more Abisresources are assigned.

The cases requiring the upgrade of already assigned resources (PDCHs or Abis) arediscussed in "5.3.4 Upgrading Strategies"; the case regarding new incoming PS calls ishere described.

When the PCU needs new PDCH channels to be assigned to the incomingGPRS/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 suggestedconfiguration;

• 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. Onlyif it is not possible to exactly satisfy the suggestion, it tries to satisfy the request usingas many pre-allocated channels as it can. If again the request is not satisfied, the TDPCgoes on to search through all the TRXs, in order to find out the best configuration thatmatches the requirement fixed further.

It is important to underline the following feature: Abis/PDT scarcity does not affect theradio resource assignment algorithm of TDPC. The only mandatory check (on TDPC)

iPre-allocated channels are the channels already in packet transfermode, but without assigned TBF; i.e., they are the channels for which theTEMPCH timer is still running (see "5.3.3.1 PCU Algorithm").

A30808-X3247-L24-5-7618 101

InformationSystem


concerns the availability of one Abis/PDT per new PDCHs in the selected radio timeslotconfiguration. No attempt is done to search radio resources minimizing the number ofnew allocated Abis/PDT resources. Hence, in case of Abis/PDT resources scarcity it isnot guaranteed that the initial coding scheme can be supported; and the initial targetthroughput 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 theGASTRABISTH parameter (see "5.3.4.2 Upgrade of Abis Resources"), the TDPCwill allocate new PDCHs trying to assign them the requested number of Abis/PDTsper PDCH and, if necessary and possible (see "5.3.4.2 Upgrade of AbisResources"), upgrade up to the requested number of PDTs per PDCH the alreadyallocated 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 numberof 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 necessaryand possible (see "5.3.4.2 Upgrade of Abis Resources"), upgrade up to therequested number of PDTs per PDCH the already allocated PDCHs in the configu-ration.

The TDPC algorithm is described in Fig. 5.8.

When the involved BTS is congested, if the incoming GPRS/EGPRS request is for morethan one timeslot, the TDPC distinguishes between upgrade requests and newrequests:– an upgrade request is detected each time the PCU requires additional timeslots for

GPRS/EGPRS service. This means that some timeslots are currently allocated forPS data transmission, and the request is for additional resources. In this case, whenthe BTS is congested, the request from the PCU is rejected and the TDPC sends aPDCH_KO message to the PCU.

– a different situation occurs when an incoming request arrives at the TDPC from thePCU and no channels are currently allocated for PS services. In this case, when theBTS is congested, the incoming multislot request is downgraded to a single timeslotrequest. At this time if the request cannot be served immediately, it will be includedin the waiting queue.

If the BTS is not congested, the TDPC verifies if there are some pending requests, firstin the queuing list and then in the waiting queue. If any pending request exists then theTDPC puts the incoming GPRS/EGPRS request in the waiting queue because it isnecessary to serve the old calls first.

So, when resources are available and either the queuing list or the waiting queue is filledwith some pending request, the new request will not be served immediately, even ifthere is no congestion from a BTS point of view. This is done in order to optimize theusage of resources and it can produce a short delay in serving the new requests.

iThis mechanism is not applied to timeslots reserved for exclusive use of theGPRS/EGPRS services. So if the incoming request can be satisfied using the timeslotsreserved exclusively for PS services (fixed by the operator using the GMANPRESattribute) no downgrade or reject is performed on the incoming request.

102 A30808-X3247-L24-5-7618


In case both the queues are empty, the TDPC has to check if the incoming request canbe 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 TRXs according to the CPOLICY parameter.

If the request is completely satisfied by the available resources, without the need toexecute forced intracell handovers, the request is served immediately; so the TDPC willanswer to the PCUC with a PDCH_Setup message. The PDCH_Setup message alwayscontains the current allocation value (VA/HA) on TDPC.

If one or more intracell handovers have to be executed, the request is put in waitingqueue and the management is delegated to the waiting queue manager process (see"5.3.6 Waiting Queue Management").

If no new idle channels are assigned, the TDPC will answer to the PCU with aPDCH_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 thesituation of radio interface and Abis interface, described in "5.3.2 Horizontal/VerticalAllocation 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 forGPRS/EGPRS is higher. This is done to reduce holes in the configuration and tofacilitate the assignment for new incoming GPRS/EGPRS calls when the VA isactive;

• it should be noted as the priority related to the preferred TRX is the lowest one; soif 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 ondifferent TRXs, the allocation is performed according to the order of priority listedabove.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 hasone “empty channel”, whereas TRX1 has no empty channels, then the allocation isperformed on TRX0 even if TRX1 may have more than the required timeslots free;

• for PDCH allocation in multislot configurations, the allocated PDCHs must have (seealso "4.7 Multislot Configuration"):– same frequency hopping law;– same training sequence code (TSC);– same MAIO;

iNote that for the previous algorithm, the search including forced intracell handovers isapplied only if forced intracell handovers have been enabled by the operator (see"5.3.6.3 Forced Intracell Handovers of Already Established CS Calls").

A30808-X3247-L24-5-7618 103

InformationSystem


– adjacent time slot numbers.The first three rules have to be followed during the configuration phase, that meansthat all timeslots (defined as TCH) must have the same hopping law and the sametraining 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 preallocated ones, the TDPC will force the VA. In this way the PCU will try to layer thecall on already busy for GPRS/EGPRS channels;

• the subsequent deallocation of the allocated PDCH occurs when all the TBFspresent 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 triesto expand the proposed configuration using timeslots already available and adjacent tothe new ones. For instance when the HA is used, if the PCU has to assign to aGPRS/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 PSchannels or the Vertical allocation threshold has been reached, it assigns these twochannels and also sets the VA/HA flag to VA.

The PCU then uses the two channels assigned by TDPC, plus another channel alreadyavailable at PCU side where another TBF is running (since there are not any pre allo-cated channels).

104 A30808-X3247-L24-5-7618


Fig. 5.8 Allocation Algorithm followed by the TDPC

Reception of

New call or

Set VA

New call

NO

Upgrade

YES Is the Cell

Downgrade the (E)GPRS

NOYES Threshold

Put the downgraded

overcome?

Calculate HA/VA

PDCH_Requestfrom PCU

congested?

Upgrade?

Send PDCH_KOto PCU

(if necessary set VA)

call to 1 timeslot

call in Waiting Queue

Are thereavailableresources

Assign the resources

threshold

Send PDCH_Setupto PCU

Is itpossible to free

resources usingIntracell Handover?

Put the multislotcall in Waiting Queue

Were therepre-allocated channels

in the PCU request?

Send PDCH_KOto PCU

(Set VA)

Calculate HA/VAAssign pre-allocatedthresholdPDCHs

Set VA

NOYES Thresholdovercome?

Send PDCH_KOto PCU

Are queuesempty?

Put the call inWaiting Queue

NO

NO

NO

NO

YES

YES

YES

YES

immediately?

A30808-X3247-L24-5-7618 105

InformationSystem


5.3.4 Upgrading StrategiesTwo kinds of upgrading strategies are defined according to different situations:

1. upgrading of radio resources: additional radio resources could become necessaryto sustain the peak throughput;

2. upgrading of Abis/PDT resources: it can be required by Link Adaptation (see 10.5)when conditions get better, or by the PCU when in the same PDCH has to fill a TBFwith an higher coding scheme with respect to those already substained.

As it can be seen, the upgrading of radio resources is different from the upgrading ofAbis/PDTs, that occurs under completely different conditions. So, these upgrading strat-egies are discussed separately.

5.3.4.1 Upgrade of Radio ResourcesAfter the first allocation of radio resources, additional radio resources could becomenecessary to sustain the peak throughput. Therefore a radio resource upgradingstrategy is necessary. The events triggering the radio resource upgrading (upgradingconditions) are:– increasing of the peak throughput requirement;– decreasing of the “maximum sustainable throughput”, due to the worsening of radio

conditions;– loss of radio resources due to pre-emption or O&M commands.

In general, once detected the upgrading condition, several additional radio resourcescould be necessary to fill the gap to the required number of radio resources. However,in the present release, for effort reasons, the upgrading of radio resources is performedone step a time; it means that radio resources are added one at a time, each time oneof the upgrading conditions is detected. The additional radio resource must belong tothe same TRX and must be adjacent to the radio resources already assigned to the TBF.The choice between the radio resource on the left or on the right of the current allocationis performed using the same criteria used in the first allocation of radio resources(see 5.3.3.1).

Note that in case the worsening of radio conditions would lead simultaneously to a stepof Link Adaptation (downgrading the CS/MCS and possibly the Abis/PDTs, see"10.5 Link Adaptation") and to upgrading of radio resources, the downgrading ofCS/MCS is managed before the upgrading of radio resources. It is a general rule onPCU that procedures cannot be nested: hence the upgrading of radio resources will bestarted, if necessary, only when the downgrading of CS/MCS procedure is completed.

The radio resources upgrade is attempted if the already allocated resources are lessthan what can be supported by the MS multislot class.

Depending on the position of the TBF on the TRX, the best additional PDCH could bealready allocated to GPRS/EGPRS, or it could be necessary to request it to TDPC. Aslong as vertical allocation is in progress, the PCU is not allowed to request new PDCHsto TDPC for upgrading reasons.

The additional PDCH can be requested only if both the following conditions are satisfied:

1. the horizontal allocation is in progress;

106 A30808-X3247-L24-5-7618


2. the number of idle radio timeslots in the cell is higher than the thresholdIdleChanEn-ableUpgrade field of the GASTRTH attribute.

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. Atsystem initialization, by default, the enableRadioUpgradingFlag is DISABLED both onPCU and TDPC sides, and is set to ENABLED at the first check detecting the horizontalallocation condition, unless the thresholdIdleChanEnableUpgrade value is 100 (thisvalue means: new PDCHs cannot be allocated to GPRS for upgrading reasons).

The thresholdIdleChanEnableUpgrade does not enable the ‘upgrading strategy’. Itenables 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 upgradingreasons no matter of the thresholdIdleChanEnableUpgrade value. Besides, the thresh-oldIdleChanEnableUpgrade threshold does not affect the assignment of resources fornew 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 throughputsubmitting a PACKET_RESOURCE_REQUEST message and specifying a differentvalue of peak throughput in the ‘Channel Request Description’ information element.

While a downlink TBF is in progress, the SGSN can request a variation in peakthroughput specifying a different value of throughput in the ‘QoS Profile’ informationelement of the DL-UNITDATA.

In both cases (DL/UL), the variation of peak throughput is taken into account only if apeak throughput value higher than the currently managed value (in the same UL or DLdirection) 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 requiredtimeslots is defined as:

The extension is tried by adding one adjacent TS to the actual configuration; so the PCUwill send to TPDC a PDCH_Upgrade_Reqeust message, but only if the conditionsregarding horizontal allocation and the percentage of idle timeslots are verified.

In case radio resources are missing and the upgrade is not possible, the upgradingrequest is dropped. The upgrading will be attempted again if a decreasing of maximumsustainable throughput is detected, as specified in 2) Change in “Maximum SustainableThroughput”.

iThe number of idle timeslot is calculated in the same manner as described in"5.3.2.3 Switching between VA and HA According to Radio Conditions".

Number of required TSs = min (ceil ( new PT / (T_A_CS x (1-BLER)), Multislot Class).

where:ceil = round up to the upper integernew PT = new required Peak ThroughputT_A_CS =throughput of the Actual Coding SchemeBLER = it is the actual BLER.

A30808-X3247-L24-5-7618 107

InformationSystem


2) Change in “Maximum Sustainable Throughput”

During a TBF lifetime, due to variations in radio conditions, either the BLER or the usedCS/MCS coding scheme can change, leading to a change in ‘Maximum sustainableThroughput’.

The Maximum sustainable throughput is defined as the maximum throughput that wouldbe achieved by a given TBF if it was alone on the multislot configuration, that is:

A check on the maximum sustainable throughput is performed periodically, with a perioddefined by the UPGRFREQ attribute.

As a general rule, only the decreasing in maximum sustainable throughput is taken intoaccount (increasing, hence the ‘downgrading’ of radio resources is not managed). More-over, since the variations in Maximum sustainable throughput can be very frequent, onlythe decreasing below a given threshold will be managed.

An extension to the number of allocated TSs is tried if:

So, when the maximum sustainable throughput becomes lower than the maximum toler-able degradation of the peak throughput, the upgrade is performed.

The extension is tried by adding one adjacent timeslot to the actual configuration; so thePCU will send to TPDC a PDCH_Upgrade_Reqeust message, but only if the conditionsregarding horizontal allocation and the percentage of idle timeslots are verified.

5.3.4.2 Upgrade of Abis ResourcesAccording to flexible Abis allocation strategy, for already assigned radio channels, newAbis resources could become necessary, e.g.:– it can be required by Link Adaptation when the radio conditions gets better (see

"10.5 Link Adaptation");– it can be required by the PCU when in the same PDCH has to set up a TBF with a

higher coding scheme with respect to those already multiplexed on the PDCH (see"5.3.3 Management of Incoming GPRS/EGPRS Requests").

Maximum sustainable throughput = T_A_CS x (1-BLER) x #TS

where:T_A_CS =throughput of the Actual Coding SchemeBLER = it is the actual BLER#TS = number of allocated timeslots to the TBF

T_A_CS x (1-BLER) x Currently allocated #TS < (1- ACCEPTGDEGR) x PT

where:T_A_CS = throughput of the Actual Coding SchemeBLER = it is the actual BLERPT = Peak ThroughputACCEPTGDEGR= it is an O&M parameter

iAs long as the ‘one radio resource a time’ algorithm is implemented, the ACCEPT-GDEGR attribute is suggested to be set to 0 (no degradation allowed, radio resourceupgrading always attempted as soon as the upgrading condition is detected), in orderto reach the required radio resource allocation in several steps.

108 A30808-X3247-L24-5-7618


The user can manage the upgrade strategy of Abis resources by two fields of theGASTRABISTH parameter. The two fields are:• thresholdIdleAbisStopUpgrade field: it defines the percentage of idle Abis subslots

of a BTSM (over the available Abis subslots managed by the BTSM) under whichthe PCU must disable the Abis upgrading requests to TDPC for all the cellsmanaged by the PCU and belonging to the involved BTSM. When this threshold isovercome, the first allocation of Abis resources to a TBF is performed with the samecriteria used under normal conditions (looking at the candidate initial codingscheme), but further upgrading of Abis resources is forbidden. Moreover, in case ofruntime Abis release (due to worsening of radio conditions, CS pre-emption or O&Mcommands), the released Abis is not allowed to be allocated again to running TBFs.The main aim of this threshold is to avoid useless signalling between PCU andTDPC in case of nearly complete Abis congestion, therefore, the default value of thethreshold is 0, meaning that the Abis upgrading is disabled only in case of completeAbis congestion. The secondary aim of this threshold is to avoid the allocation ofadditional Abis resources to running packet services in case of Abis scarcity, so thatthe residual Abis resources in the pool can be by preference available to set up newCS services (this will be the trend in case of vertical allocation) or even to new PSservices (in case horizontal allocation is still active). Note that moving this thresholdfrom the default value, a reduction in PS throughput is expected;

• thresholdIdleAbisRestoreUpgrade field: it defines the percentage of idle Abissubslots of a BTSM (over the available Abis subslots managed by the BTSM) overwhich the Abis upgrade requests to TDPC are restored for all the cells managed bythe PCU and belonging to the involved BTSM.

Constraints on the Abis thresholds are:

As a general configuration rule, in BTSMs where the Abis resources/radio resourcesratio is quite high, in order to obtain the highest benefit from Link Adaptation, the Abisupgrading should be disabled only in case of complete Abis congestion or at least afterthe switch to vertical allocation.

Instead, in BTSMs where the Abis resources/radio resources ratio is quite low, for someoperators it could be preferable to disable the Abis upgrading before the switch tovertical allocation.

In any case, the choice will depend on the relative preference given from the operatorto circuit switched calls versus packet switched TBFs, and to running TBFs versusincoming TBFs.

5.3.5 Incoming CS CallsWhen a circuit switched call (deriving from either a normal assignment or an externalincoming handover) comes into the cell with no free radio channels, the following algo-rithm is applied:

thresholdIdleAbisStopUpgrade < thresholdIdleAbisRestoreUpgrade

iThere is no constraint between the Abis threshold to switch to vertical allocation (see"5.3.2.4 Switching between VA and HA according to Abis Interface Conditions") and theAbis threshold to disable the ‘Abis upgrade requests’; the operator is free to set the onelowest than the other, and vice versa.

A30808-X3247-L24-5-7618 109

InformationSystem


1. if the incoming CS call finds the cell in a congested state, the first attempted task isto preempt one vulnerable CS call;

2. if preemption cannot be started for whatever reason (e.g., the feature is notenabled), the Directed Retry procedure is started;

3. if also the Directed Retry cannot be started (e.g., the feature is not enabled or thefeature is enabled but the Handover Condition Indication message does not containany cell) the queueing procedure is started, if enabled;

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 bedowngraded, 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"5.3.6 Waiting Queue Management").

According to the flexible Abis allocation strategy (see 6.3), it could also happen thatwhen the CS calls have to be served, no Abis resources are available to serve theincoming call. Even in this case, the call is put in the waiting queue in order to find therequired resources.

5.3.6 Waiting Queue ManagementAs it has been described in "5.3.3.2 TDPC Algorithm", there are some cases for whichthe TDPC inserts the incoming requests in the waiting queue; then the TDPC mustanalyze a second time these pending requests to serve them. The task is activated bya 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 callsare present in the cell; these calls are downgraded to 1 timeslot before beinginserted in the waiting queue;

b) GPRS requests that arrive when other calls are present in the waiting queue or inthe queuing list;

c) GPRS requests that must wait for intracell handovers; in these cases, the multislotcall is inserted in the waiting queue.

CS calls that arrive:

a) when no radio resources are available in the BTS; in fact, if both the pre-emptionand the directed retry fail or have not been enabled, these calls are put in thequeuing list (if the Queuing feature has been enabled).Otherwise, if the Queuing feature is not enabled, the CS calls are put in the waitingqueue (see "5.3.5 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.

The TDPC, before checking the waiting queue, analyses the queueing list. If thequeueing list contains some pending request (i.e., some CS calls), the TDPC will imme-diately manage resources of the queueing list.

iThe queuing procedure puts the CS call in the Queueing List that isdifferent from the Waiting Queue.

110 A30808-X3247-L24-5-7618


After this procedure, or if the queueing list is empty, the process will analyzes the waitingqueue.

Three types of action can be performed by the process to serve pending requests on thewaiting queue:

1. Use resources just released by the TDPC : in case the system had released anysystem resources, these have been included in the Idle List structure. Then thesystem finds the released resources which are available for the specific cell. If theresources are not enough to serve all the entries present in the waiting queue, thefollowing Downgrading mechanisms are activated;

2. Downgrading of already active HSCSD multislot calls : the downgrade of alreadyactive 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 "5.3.5 Incoming CS

Calls");The downgrade of an already active HSCSD call is executed only if the number ofused timeslots is greater than one (i.e., at least one timeslot must remain allocatedfor the HSCSD call)

3. Downgrading of already active PS multislot calls: the GPRS/EGPRS downgradeprocess, consists in a decrease of the number of timeslots already assigned to PSservices. When the downgrade of PS calls is performed, one of the GPRS/EGPRSchannels is “preempted” and the channel is released. In the case in which a PS datatransmission uses only one timeslot for GPRS/EGPRS, and the timeslot ispreempted for downgrading, the transmission is interrupted (to avoid GPRS/EGPRSdowngrading, the operator can assign static GPRS/EGPRS timeslots as explainedin "5.2 Configuration of GPRS Channels in a Cell"). As it has been described (see"5.3.5 Incoming CS Calls"), the downgrade of already active PS multislot calls isperformed to serve incoming CS requests in the waiting queue.

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 through the DownGradeStrategy parameter (DGRSTRGY). Thisattribute allows the user to choose among 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.3.6.1 Pre-emption of PDCH ChannelsThe preemtpion of a PDCH is executed to serve an incoming CS call (see"5.3.5 Incoming CS Calls"); the TDPC can send to the PCU the order to release one or

iNote, once more, that the resources that are released, are used first by the Queueingprocess and only later on by the Waiting Queue process. So the classic Queueingprocedure already implemented always has a higher priority than the waiting queuemanagement.

iNo active GPRS/EGPRS calls are downgraded to free resources for incomingGPRS/EGPRS calls.

A30808-X3247-L24-5-7618 111

InformationSystem


more PDCHs in a cell (PDCH_preemption_order), due to unavailability of radioresources in a cell.

On the PCU, PDCH pre-emption orders are sent:

1. first to PDCHs with the ‘PDCH empty timer’ still active; as described, the “PDCHempty timer” can be defined by the user via the TEMPCH parameter;

2. then to PS dynamic channels.note that:

Note that:– 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 (i.e., theCPOLICY parameter is negletted);

– independently on the value of the DGRSTRGY parameter, if there are some emptychannels (i.e., PDCH channels for which the PDCH empty timer is running), they areused to serve the CS call; if no empty channels exists, then the rules defined by theDGRSTRGY parameter are followed to free resources for the CS call. The down-grade of the PDCH channels is applied, until the number of the reserved channelsfor PS services is reached in the cell (reserved PS channels cannot be down-graded).

The preemption of some PDCHs can result in the reconfiguration of some TBFs (alsopartially allocated on ‘residual’ PDCHs) and in the release of some other TBFs(completely allocated on the preempted PDCHs).

5.3.6.2 Pre-emption of PDT ResourcesThe TDPC can send to the PCU a PDT pre-emption order in case no PDT or Abisresources are available for PBCCH/PCCCH activation, or in case no Abis resources areavailable to serve incoming CS requests put in the waiting queue.

Cells belonging to the ‘exhausted’ BTSM are spread over several PCUs (see "8 LoadControl for Packet Switched Services"), so, in case of unavailability of Abis resources ina BTSM pool, the TDPC selects the PCU with the highest number of PDTs allocated tothe ‘exhausted’ BTSM, and sends it a pre-emption order.

In case of unavailability of Abis resources, the same ‘pre-emption level’ used when radioresources unavailability is applied. For example, in case of CS pre-emption due tounavailability of Abis resources, the pre-emption management will not cause the releaseof PBCCHs and PCCCHs (or the pre-emption of static GPRS/EGPRS channels). Thatis: only PDTs with SFC=1..4 can be removed from PBCCHs and PCCHs.

On PCU, PDT pre-emption orders are managed with the aim to balance the distributionof PDTs among cells and to disturb as little as possible the running TBFs. In eachselected cell, the algorithm selects, in the order:

1. PDTs with ‘PDT empty timer’ still active (as it has been described in"5.3.1 Generalities about Resource Assignments", the “PDT empty timer” can bedefined by the user via the TEMPPDTparameter);

2. starting from the first TRX and highest timeslot numer and removing one PDT pertimeslot, then moving on the next TRX; this step is repeated until the requirednumber of PDTs is found.

Since the PDT pre-emption management can result in the release of some PDCHs, itcan 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

112 A30808-X3247-L24-5-7618


PDCHs). PDCHs can be released provided that the number of residual PDCHs allo-cated 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 forceddowngrade of the coding scheme is performed for all the TBFs multiplexed on theinvolved PDTs. Otherwise (release of the whole PDCH), the same behavior imple-mented in case of PDCH pre-emption (see 5.3.6.1) is ensured.

5.3.6.3 Forced Intracell Handovers of Already Established CS CallsWhen a request comes from the PCU for a new PDCH, the TDPC tries to allocate it.

It could happen that in the transceivers supporting GPRS/EGPRS there are not free andconsecutive timeslots, e.g., because the already assigned PDCHs are full and theremaining timeslots are dedicated to circuit switched calls. In this case, if there is at leastone free channel in the cell (and the maximum number of timeslots assigned to PSservices has not been reached), a forced intracell handover starts to free timeslots forGPRS users. The forced intracell handover allows the moving of a CS call from onetimeslot, to another one in the same cell.

iThe decision whether pre-emption may be made on circuit switched services is takenby the TDPC, causing a forced intracell handover for circuit switched calls.To enable forced intracell handover, the user must set the ENFOIAHO parameter(Enable Forced Intracell Handover) to TRUE.

A30808-X3247-L24-5-7618 113

InformationSystem


6 Hardware and Software ArchitectureFor the management of Packet Switched Services in the SBS system, the PacketControl Unit (PCU) has been designed for the BSC. It supports the packet data inter-working between the “Gb” interface and the “Abis” interface.

The functionalities of the PCU are supported by the Channel Codec Units (CCUs) whichhave been implemented in the BTSs (see the "Fig. 6.1 Hardware and Software Entitiessupporting the GPRS/EGPRS technology"). The CCU software is downloaded to theBTS from the BSC.

Fig. 6.1 Hardware and Software Entities supporting the GPRS/EGPRS technology

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.

The CCU unit within the 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 models the physical packet control unit designedto implement the packet switched services (PS) in the SBS system.


PCU This Functional Managed Object (FMO)represents the Packet Control Unit designedto implement GPRS services in the SBSsystem. Depending on the BSC type thisFMO can be implemented by means of theboards PPCU (for the standard BSC) orPPXU (for the High Capacity BSC).

Tab. 6.1 PCU Functional Managed Object (FMO)

114 A30808-X3247-L24-5-7618


In case of PPCU boards for the standard BSC each PCU can handle up to 64 PDTs onthe Abis interface with a maximum number of 16 FRLs on the Gb interface. FRL is theFunctional Managed Object that models the physical link connection on the “Gb” inter-face. The connection can be realised through the A interface (PCMA link) or directly tothe SGSN through the PCMG link. The Packet Data Terminal (PDT) represents a basic16 kbit/s resource for the packet switched services manageable by the PCU.

In case of PPXU boards for the High Capacity BSC each PCU can handle 256 PDTs onthe Abis interface and up to 64 FRLs on the Gb interface.

In the next chapters it will be described in detail the difference that the support of theGPRS/EGPRS technology requires in terms of hardware supported and software appli-cations to the standard and High Capacity BSC and also to the different BTS types.

6.1 Supported BSC TypesIn the current BR 7.0 release the BSCs that can be installed in the Siemens customers’mobile networks are the following:

1. the BSC equipped with the SN16 switching matrix and with older peripheral proces-sors called “standard BSC” (see the chapter: "6.1.1 “Standard” BSC").

2. the High capacity BSC based on the same rack as the “standard” one, but equippedwith the new SNAP switching matrix called “High capacity BSC with the old rack”(see the chapter: "6.1.2 High Capacity BSC with the Old Rack"), that provides betterperformances in terms of:– connectivity (i.e., number of supported PCM lines).– packet data handling capability.– LAPD signalling.

3. the High capacity BSC based on a new rack called “High capacity BSC with the newrack” (see the chapter: "6.1.3 High Capacity BSC with the New Rack"), that providesbetter capabilities with respect to the “High capacity BSC with the old rack” due tothe installation of the new LICD cards.

iAccording to the maximum number of supported PCM line interfaces, High CapacityBSC with Standard Rack is also called HC BSC 72, whereas High Capacity BSC withnew Rack is called HC BSC 120.

A30808-X3247-L24-5-7618 115

InformationSystem


6.1.1 “Standard” BSCIn the Standard BSC, the PPCU processors are used to implement the PCU unit; eachPCU unit consists of two PPCU boards:– one of them is in Providing Service state;– the other one is in Cold Stand-by state, and it is used as a spare board.

The PPCU boards are inserted in the BSC rack in place of some PPLDs, as it is shownin the Fig. 6.2.

iIn the next paragraphs the different BSC types are described, taking into particularaccount their hardware and software resources configured for supporting the GPRS andEGPRS technology. It is also important to make a distinction between the terms “PacketData Channel (PDCH)” and “Packet Data Terminal (PDT)”.The Packet Data Channel (PDCH), as it has been described in the chapter "4 RadioInterface Description", is the radio timeslot associated to packet switched services (thatmeans when the timeslot is associated to the packet switched services, it is calledPDCH).The Packet Data Terminal (PDT) represents a basic 16 kbit/s resource for the packetswitched services manageable by the PCU. The capacity of the PCU, from packetswitched data services point of view, is assigned in terms of Packet Data Terminals,thatmeans that a PCU supports a certain number of Packet Data Terminals. This numberof 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 GPRSuser using CS1 coding scheme, it is also associated to a single Abis subslot, and so onlyone PDT is busy in the PCU that manages this PDCH (in this case, there is a one to onerelationship between PDCH and PDT); but when a single PDCH is associated to anEGPRS user using MCS9 coding scheme, five Abis subslots are associated to thisPDCH (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).

116 A30808-X3247-L24-5-7618


Fig. 6.2 View of the BSC Rack with and without PPCU Boards.

Two instances of the PCU object can be created:– PCU:0;– PCU:1.

The creation of one PCU object implies the consequent creation of the two relatedPPCU boards (active and cold-standby):• the creation of the PCU:0 involves the creation of both the PPCU:0 and the PPCU:1;• the creation of the PCU:1 involves the creation of both the PPCU:2 and the PPCU:3.

The system firstly creates the two PPCU objects, and then the PCU object. After the firstcard reaches the Providing Service state, the PCU starts the configuration alignment.

Since the PPCUs are inserted in the BSC rack in substitution of some PPLDs, when theuser creates a PCU object instance, some PPLDs may not be equipped. The rule isshown in Tab. 6.2.

A30808-X3247-L24-5-7618 117

InformationSystem


Each PPLD board can manage up to 8 LAPD channels; so, when 14 PPLD boards areused, 112 LAPD channels are available in the BSS. When some PPLD boards areremoved to introduce PPCU boards, the number of LAPD channels decreases, reducingthe signalling capability of the BSC.

When only one PCU is created, the number of PPLD boards becomes 10, and thenumber of configurable LAPD channels is 80; when both the PCU instances are created,the number of PPLD boards decreases to 6, and the number of configurable LAPDchannels is 48.

Each Packet Control Unit is able to handle at most a data rate of 2 Mbit/s. This data flowis divided in two data rates of 1 Mbit/s each one:

1. a data rate of 1 Mbit/s towards the Abis interface; this flow allows the managementof the Abis interface at most 64 GPRS channels (16 kbit/s each one), i.e., 64 PDTs;

2. a data rate of 1 Mbit/s towards the Gb interface; this flow allows the management ofthe Gb interface at most 16 Frame Relay Links (64 kbit/s each one, see "7 Gb Inter-face").

When the standard BSC is fully equipped with two PCUs, it can handle up to 128 GPRSchannels (PDCHs).

For each BSC, it is possible to configure up to 150 cells and, as a consequence, up to150 PTPPKF object instances.

PCU instance PPLDs to beremoved

PCU:0 PPLD:11

PPLD:12

PPLD:13

PPLD:14

PCU:1 PPLD:7

PPLD:8

PPLD:9

PPLD:10

Tab. 6.2 PPLD Boards to Be Removed according to the PCU Object Instance.

iEGPRS is not supported by the standard BSC due to its low capacity in terms of PDTs.

118 A30808-X3247-L24-5-7618


6.1.2 High Capacity BSC with the Old RackUsing the same rack of the previous releases, it is possible to get a BSC with a highercapacity by changing some boards (see Fig. 6.3).

Fig. 6.3 View of the “High Capacity” BSC with the Traditional Rack.

In order to get a High Capacity BSC using the traditional rack, the following boards areused:• a new switching matrix board, called SNAP;• new peripheral processor boards i.e.;

– PPXL boards to manage both LAPD and SS7L signalling;– PPXU boards to manage GPRS and EGPRS services.

In comparison with the SN16 (i.e., the switching matrix of the “standard” BSC), theSNAP card 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).

iIt is important to underline that the hardware of both PPXLs and PPXUs is namedPPXX; depending on the slot position inside the BSC rack, the same board (i.e., thePPXX one) acts, from the functionality point of view, as PPXU or PPXL.

A30808-X3247-L24-5-7618 119

InformationSystem


This doubled number of lines increases independently (i.e., without trade-off) bothGPRS/EGPRS and LAPD channels.

The new switching matrix is introduced in the system through the handling of theNTWCARD attribute; this attribute can assume the values:– NTWSN16, when SN16 switching matrix is used (standard BSC);– NTWSNAP, when the SNAP switching matrix is used (high capacity BSC with the

old rack).

In the high capacity BSC, to get more GPRS/EGPRS channels it has been necessaryto increase the number of boards assigned to packet switched functionality and toincrease also their capability. This is allowed by the SNAP switching matrix, whichprovides 8 lines at 8 Mbit/s towards PPXXs. Two lines are used for handling LAPD andSS7 level 2 signalling protocols with the new PPXL boards; and the remaining six areused for PPXU boards (each PPXU board has its own 8 Mbit/s line).

The PPXUs are all placed in the extended rack (as it is for the PPCUs).

To handle packet switched services, six instances of the PCU object can be created:– PCU:0;– PCU:1;– PCU:2;– PCU:3;– PCU:4;– PCU:5.

The creation of one PCU object implies the consequent creation of one PPXU board: i.ethe creation of the PCU:0 involves the creation of the PPXU:0; the creation of the PCU:1involves the creation of the PPXU:1, and so on.

Tab. 6.3 shows the correspondence between the boards of the “standard” BSC andthose of the high capacity BSC from packet switched services point of view.

iWhen the NTWCARD is set to NTWSN16, the BSC works with PPCC, PPLD and PPCUboards.When the attribute value is NTWSNAP, only the SNAP and the new PPXU and PPXLboards are allowed.Mixed configurations are not possible .

iA PPXU card is automatically created when the PCU object with the same instance iscreated, if NTWCARD= NTWSNAP. Otherwise (if NTWCARD=NTWSN16), a couple ofPPCUs are created (PPCU 0,1 for PCU-0; PPCU 2,3 for PCU-1).

Standard BSC (noGPRS)

Standard BSC (fullGPRS configuration)

High capacityBSC

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

Tab. 6.3 Correspondence between the Boards of the Two Types of BSC

120 A30808-X3247-L24-5-7618


Since each PPXU is connected to the SNAP matrix by an 8 Mbit/s line, each PPXUboard, and as a consequence each PCU, is able to handle at most a data rate of 8Mbit/s.This data rate of 8 Mbit/s is split into 128 time slots of 64 kbit/s each. Since one of thesetime slots is used to transmit the CRC related to the others, then 127 timeslots can beused effectively.

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; thisflow allows the management of the Abis interface at most 64 X 4 = 256GPRS/EGPRS channels (16 kbit/s each one), i.e., 256 PDTs

2. a data rate constituted of 63 time slots of 64 kbit/s towards the Gb interface; this flowallows the management of the Gb interface at most 63 Frame Relay Links (64 kbit/seach one, see "7 Gb Interface").

Each PPXU board and, as a consequence, each PCU can handle up to 256 PDTs; toreach 1280 PDTs (that is the number of packet switched resources provided by the highcapacity BSC), 5 boards (i.e., 1280/256 boards) have to be considered in service simul-taneously; this means that 1+1 redundancy (used in the standard BSC) is no longerpossible and a different redundancy schema is provided.

The redundancy schema used is called “load balancing”: with this schema all six boardsare simultaneously in service and the packet switched traffic is distributed among all sixboards (see "8 Load Control for Packet Switched Services"); this implies that eachboard will normally work in relax (the required real time traffic can be spread over 6boards instead of 5).

When the BSC is fully equipped with six PCUs, it can handle up to 1536 PDTs (256 X6) and 378 Frame Relay Links (63 X 6). If the 6th board is used for redundancypurposes, the number of handled PDTs becomes 1280 (256 X 5).

With the high capacity BSC it is possible to configure up to 250 cells and, as a conse-quence, up to 250 PTPPKF object instances.

PPLD-9 PPCU-3 PPXU-3

PPLD-10

PPLD-11 PPXU-4

PPLD-12 PPCU-1

PPLD-13 PPXU-5

PPLD-14

PPCU-0

Standard BSC (noGPRS)

Standard BSC (fullGPRS configuration)

High capacityBSC

Tab. 6.3 Correspondence between the Boards of the Two Types of BSC

iPlease remember that, if either GPRS CS3 and CS4 coding schemes, orEGPRS coding schemes are used, 256 PDTs do not strictly correspond to256 PDCHs.

A30808-X3247-L24-5-7618 121

InformationSystem


6.1.3 High Capacity BSC with the New RackThe current release foresees a new BSC rack to get a new BSC with high capacity.

Fig. 6.4 shows the high capacity BSC with the new rack.

The new rack contains the SNAP matrix and new PPXU, PPXL boards already presentin the high capacity BSC with the old rack; these boards have the same characteristicsalready described in "6.1.2 High Capacity BSC with the Old Rack".

With respect to the old rack, the new BSC rack provides the following innovations:• support to the new line interface card, the STLP, which is used in place of the QTLP

in the new rack; this includes the increase from 9 to 10 of the LICD number, and from4 to 6 of the circuit number of LICD on which a PCM line can be created;

• support of 12 PCUs and PPXUs;• new rack configuration and back plane: this will allow doubling the number of used

PPXU (PPXX supporting GPRS/EGPRS) from 6 to 12; it will also allow housing10+2 STLP, i.e., one more card than QTLPs equipped in the old rack.

• new fan box for heat dissipation.

In order to achieve these goals, the following additional changes are introduced:• the 2 EPWR (power supply devices in the expansion module) are removed to make

room for PPXU and STLP. For this reason, the PPXX and the STLP are provided withan internal power supply, directly fed by the 48 V;

• on the top of the BSC, a box containing 6 fans has been introduced, powered by the48 V, to cope with the increased heat generated by the BSC;

• sense points in the new board CPEX for monitoring the fan alarms have been intro-duced.

As previously described (see "6.1.1 “Standard” BSC" and "6.1.2 High Capacity BSCwith the Old Rack"), the NTWCARD attribute allows specification of the BSC type. In factif NTWCARD is set to NTWSN16, the BSC is made by the old rack and it works withSN16, PPCC, PPLD and PPCU boards; if the attribute value is NTWSNAP, then the oldrack is still used but in this case only the SNAP matrix and new PPXU and PPXL boardsare allowed.

If the user wants to use the new BSC rack, with new STLP boards (and obviously alsowith SNAP and PPXU/PPXL boards), he must set the NTWCARD attribute equal to theNTWSNAP_STLP value.

Regarding PPXU boards, the redundancy schema is always the “load balancing” one:all the twelve boards are simultaneously in service and the packet switched traffic isdistributed among all the twelve boards (see "8 Load Control for Packet SwitchedServices"); this implies that each board will normally work in relax (the required real timetraffic can be spread over 12 boards instead of 11).

When the BSC is fully equipped with twelve PCUs, it can handle up to 3072GPRS/EGPRS PDTs (256 X 12) and 756 Frame Relay Links (63 X 12). If the 12th boardis used for redundancy purposes, the number of handled PDTs becomes 2816 (256 X11).

With the high capacity BSC it is possible to configure up to 400 cells and, as a conse-quence, up to 400 PTPPKF object instances.

iPlease remember that, if either GPRS CS3 and CS4 coding schemes, or EGPRScoding schemes are used, 756 PDTs do not strictly correspond to 756 PDCHs.

122 A30808-X3247-L24-5-7618


Fig. 6.4 High Capacity BSC with the New Rack

6.1.4 PPCU and PPXU Redundancy and Configuration RulesAs previously described, with the standard BSC two boards are deputed to manageGPRS service: they are named PPCU. For safety reasons both boards have a sparecopy. No dynamic data is present on the spare board so the redundancy schema isdefined, in BSC terminology, as cold standby. The creation of one PCU object impliesthe consequent creation of the two related PPCU boards (active and standby).

When the high capacity BSCs are used, six or twelve boards are deputed to manageGPRS and EGPRS services: they are named PPXU. In this case the 1+1 redundancyis no longer possible and a different redundancy schema called “load balancing” isprovided (see 6.1.2 and 6.1.3)

A30808-X3247-L24-5-7618 123

InformationSystem


It has been described that:• the standard BSC can manage up to 150 GPRS cells, so the user can configure only

up to 150 PTPPKF object instances;• the high capacity BSC with old rack can manage up to 250 GPRS/EGPRS cells, so

the user can configure up to 250 PTPPKF object instances;• the high capacity BSC with old rack can manage up to 400 GPRS/EGPRS cells, so

the user can configure up to 400 PTPPKF object instances.

An important thing to be underlined (for all the BSC types) is that when the user config-ures a cell to be used for packet switched services, i.e., when the user creates aPTPPKF object instance, he does not have to assign the GPRS (or EGPRS) cell to aspecific PCU, but it is the system that assigns the cell dynamically to one of the availablePCUs.

This behavior, during PTPPKF creation, is a direct consequence of the load balancingredundancy of the PPXUs:– 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 also regards the PPCUs even if they use the cold stand-by redundancy.

In fact, using the standard BSC:– when a new cell is created, the system assigns it to one of the two PCUs (the less

busy);– when the active PPCU board fails, the stand-by one will replace the damaged one

(according to stand-by redundancy); if a couple of PPCU boards fails (i.e., if a PCUbecomes unavailable), all the GPRS/EGPRS traffic of the PCU will be managed bythe other couple of PPCU boards (i.e., by the other PCU) according to the loadbalancing criteria (as it happens in the high capacity BSC).

The algorithm, that is used to distribute and redistribute the GPRS/EGPRS cells of oneBSC among the available PCUs, is described in "8 Load Control for Packet SwitchedServices" chapter.

6.2 BTS Equipment Supporting GPRS and EGPRSRegarding BTS equipment, different solution can be adopted according to the operator’sneeds. In fact, speaking about GPRS and EGPRS services, different kind of features areprovided according to the equipment used; the following solutions are available:

1. BTS equipment supporting EDGE and all GPRS coding schemes2. BTS equipment supporting CS1 and CS2 coding schemes only3. BTS equipment supporting GPRS CS3 and CS4 but not EDGE

EDGE support is limited to the BTSplus platform. To introduce EDGE into the network,existing BTSplus sites must be upgraded with EDGE capable carrier units (E-CU)featuring the new 8-PSK modulation technique. The E-CU hardware is able to handle:– GSM, HSCSD and GPRS (with all its coding schemes) services;– enhanced GPRS service (EGPRS).

To implement EGPRS, some GSM-CUs can be replaced by E-CUs at any arbitrary CUrack position; mixed configurations with CUs and E-CUs as well as configurations withE-CUs only are possible, but, as it has been said, the upgrade is only supported forBTSE types belonging to the BTSplus generation.

Regarding GPRS coding schemes, the requirements are the following:

124 A30808-X3247-L24-5-7618


• BTS1 base stations support GPRS CS3/CS4 coding schemes;• BTS+, e-microBTS, picoBTS, support GPRS CS3/CS4 coding schemes (also if a

mixed configuration of GSM-CU and EDGE-CU boards is present);

6.3 PCU Frames and Dynamic Allocation on the Abis InterfaceThis chapter describes the distribution of GPRS/EGPRS traffic channels on the Abisinterface.

The Flexible Abis allocation strategy (Dynamic Allocation) is a general strategy used tohandle 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 schemesrequiring 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 toa radio timeslot depends on the service type.

From the hardware platforms point of view, the following equipment support the flexibleAbis allocation strategy:• all the possible BSC configurations (standard BSC and high capacity BSCs,

see"6.1 Supported BSC Types");• the BTSplus mainline with GSM-CU and EDGE-CU; picoBTS and enhanced micro

BTS; BTS1.

The introduction of CS3 and CS4 coding schemes for GPRS, and the EDGE featurealso have big impacts on the existing Abis interface, which must be modified:• 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 notmanage the transport of high data rates per air timeslot exploited by GPRSCS3/CS4 coding schemes and EGPRS.The EGPRS data is submitted via "concatenated PCU frames" (see 6.3.1), as wellas the GPRS data, in cases where the higher coding schemes (CS3/CS4) areenabled. Hence the flexible Abis allocation strategy provides the opportunity toassign to each air interface 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 Abiscapacity to the required air interface capacity (in cases of Link Adaptation/new TBFestablishments/old TBF releases). Note that the flexible Abis allocation strategy is aslow process compared to GPRS/EGPRS Link Adaptation (see "10.5 Link Adapta-tion"), hence the two processes must be synchronized;

• the total Abis capacity per BTS increases with the introduction of higher data ratesat the Um interface. Then, the flexible Abis allocation strategy must be coupled withthe management of up to 4 Abis PCM lines per BTS.

Tab. 6.4 shows how packet switched services can be mapped in 16 kbit/s, or N*16 kbit/sAbis resources (per radio timeslot).

iNote that it is up to the operator to ensure the consistency between software configura-tion and BTS hardware.

A30808-X3247-L24-5-7618 125

InformationSystem


The flexible Abis allocation strategy coupled with the concept of concatenated PCUframes gives the operator the following advantages:– 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 differenttimeslots, carriers and even between different cells of the same base station site;

– EGPRS and GPRS Link Adaptation can be performed during runtime without lossof service;

– unused capacity of an air interface timeslot can be released in the Abis interface andexploited by other air interface timeslots;

– it is possible to reach a data rate up to about 60 kbit/s per packet data channel(PDCH) on the Abis interface.

Generally speaking, the flexible Abis allocation strategy is managed by two differentprocesses:

1. the first task is the configuration one: the operator can assign to every BTSM a poolof Abis timeslots. These timeslots will be used to transfer information between theBTSM and the BSC;

2. the second task relies on the flexible allocation and release of resources taken fromthe 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.

It must be clear that:• flexible abis allocation means that the association between radio timeslots and

Abis timeslots is performed by radio signalling procedures. There is not a fixedone-to-one (1 x 16 kbit/s) or one-to-two (2 x 16 kbit/s) association from air interfacetimeslots to Abis subslots, in the BSC database;

• static abis allocation means that the association between radio timeslots and Abistimeslots is performed during O&M procedures, stored into BSC database andsignalled to BTSM by O&M signalling procedures. The association is fixed duringruntime 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 (see 6.3.1);– hardware supporting flexible Abis allocation and concatenated PCU frames

(see 6.3.2);

16 kbit/s N x 16 kbit/s

GPRS channels supportingCS1 and CS2 only

EGPRS (up to 5x16 kbit/s)

GPRS channels supportingCS3/CS4 (up to 2x16 kbit/s)

Tab. 6.4Mapping of Services onto Abis Resources

iThe traditional Static Abis management is kept for backward compatibility with theprevious releases, harmonizing the O&M management of “flexible” and “static” BTSM.

126 A30808-X3247-L24-5-7618


– configuration of the Abis interface (see 6.3.3);– algorithms regarding flexible Abis allocation (see 6.3.4).

6.3.1 Concatenated PCU FramesThe PCU frame is used to transmit packet data traffic on the Abis interface, whereas totransmit voice traffic, the similar TRAU frames are used.

Concatenated PCU can handle:– EGPRS (MCS1,…., MCS9)– GPRS Step II (CS3/CS4 data rates)– GPRS Step I (CS1/CS2 data rates)

Concatenated PCU frames require partially more bandwidth (e.g., with 32 kbit/s, 48kbit/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 5EDGE subframes). In total, 5 subframes (instead of 4) are necessary for 60 kbit/sMCS8/MCS9 because of the huge in band signaling overhead.

A PDCH with multiplexed EDGE and GPRS TBFs requires an Abis allocation due to thehighest used coding scheme. At the moment, a PDCH with a MCS9 TBF on it requires16 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 thesequence order of the 16 kbit/s channels. The SFC is coded by 5 bits, which allow amaximum chain of up to 32 concatenated PCU subframes (see Fig. 6.5).

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.

Fig. 6.5 Fundamental Principle of Concatenated PCU Frames

Concatenated PCU frames transport, for each coding scheme of GPRS/EGPRSservices, the following number of bits, in the downlink and in the uplink direction respec-tively (that represents the size of the transmitted RLC/MAC Block, see Tab. 4.2 andTab. 4.3):

SFC=00000

MCS/CS

1st Subframe

SFC=00001

Following Subframes

SFC=00010 SFC=000100

Last Subframe

Data Data

A30808-X3247-L24-5-7618 127

InformationSystem


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

Header Check Sequences (HCS), Block Check Sequences (BCS) and Tail Bits areadded by the BTS coder.

MSs using different coding schemes can be multiplexed on the same timeslots (PDCH)on the air interface. Multiplexing of GPRS and EGPRS mobile stations is also possibleif concatenated PCU frames are used in both cases (i.e., on the same timeslot it is notpossible to multiplex users which are exploiting new concatenated PCU frames andothers working with the standard PCU frames).

The BTS and the BSC know how many Abis subslot are allocated to an air interfacechannel and both know which PCU subframe with which SFC is mapped on each 16kbit/s Abis subslot. That means: in cases of multiplexing several TBFs on the samePDCH, for this PDCH, all TBFs have PCU frames with the same SFC on a specific Abissubslot. Hence, due to the selected Coding Scheme, which is outlined in the control bitsof the first subframe, the mapping of the radio block payload to the PCU frame data bitsis given and it is also clear which PCU frame data bits must be filled with the pattern andwhich (maybe) are idle.

The n*16 kbit/s subframes of an air interface timeslot are arbitrarily distributed over PCM24/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 PCMlines of the BTSM as long as they are within the defined pool of the BTSM. They do nothave to guarantee any ordered sequence in ascending way due to increasing SFC.

Codingscheme

Number of bits transmitted in DL/UL(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.5

128 A30808-X3247-L24-5-7618


But, as it has been said, for a given PDCH, all allocated TBFs use the same Abissubslots for concatenated PCU frames with the same SFC.

Although all subframes have an equal size of 40 Octets = 320 bit (16 kbit/s bit rate), theshape of the first subframe and the other consecutive subframes is a little bit different.

Fig. 6.6 shows an example of the Abis mapping for a DL MCS9 radio block requiring 5Abis subslots; the first subframe in Fig. 6.6 has a payload of maximum 216 bits, allothers can carry up to 272 bit. As soon as a selected coding scheme requires less thanthe full number of data bits, the rest in the last data subframe are filled with a predefinedbit pattern, e.g., 11111111...... In cases of a coding scheme, which requires lesssubframes than the PDCH has allocated, those completely unused subframes are idlesubframes also filled with the bit pattern 111111.... . These idle subframes are based onthe coding of the additional subframes.

Fig. 6.6 Abis Mapping for a downlink MCS9 radio block requiring 5 Abis subslots

Concatenated PCU Frames

SFC=00000 SFC=00001 SFC=00010 SFC=00011 SFC=00100

216 bits 272 bits

174DataBits

272DataBits

146DataBits

124DataBits

272DataBits

40 BitsRLC/MACHeader(incl. USF)

2 bitsE, FBI

2 bitsE, FBI

196DataBits

76 bits(11111..11)Filling Pattern

1st RLC Data Block 2nd RLC Data Block

A30808-X3247-L24-5-7618 129

InformationSystem


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 subslotsnot carrying data payload, in order to extend all the concatenated PCU frames to thesame MCS-j (j=1,..., 9) configuration.

Let us consider an Abis channel that is allocated for a maximum bandwidth for a MSusing MCS9; in this case, MSs using MCSs lower than MCS9 have some idle PCUframes with a filling pattern (e.g. 1111111...), due to the requirement that all TBFs on aparticular 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 Abiscapacity is when a Link Adaptation of a TBF to a lower data rates occurs (i.e.,MCS9/MCS6, because of the impossibility of the air interface to maintain MCS9 withgood quality). The “unused” Abis capacity is filled with idle PCU sub-frames with fillingpattern, because to reduce signalling overhead, the release of allocated Abis capacityis not executed immediately.

6.3.2 Hardware supporting Flexible Abis Allocation and ConcatenatedPCU FramesAs it has been described, dynamic Abis allocation does not imply “concatenated PCUframe” usage in packet flows.

Fig. 6.7 and Fig. 6.8 show the relationship among standard/concatenated PCU framesand flexible/static Abis allocation, depending on the BTSE type and on the BSC type(i.e., standard or high capacity BSC).

iStandard PCU frames can be still used even combined with the flexible Abis allocationstrategy; in fact dynamic Abis allocation does not imply the usage of concatenated PCUframes. Standard PCU frames are used whenever the BTS does not support concate-nated ones (see "6.3.2 Hardware supporting Flexible Abis Allocation and ConcatenatedPCU Frames").

130 A30808-X3247-L24-5-7618


Fig. 6.7 High Capacity BSC: Relationship between PCU Frames and Abis Allocation according to the BTSEType

Fig. 6.8 Standard BSC: Relationship between PCU Frames and Abis Allocation according to the BTSE Type

- Standard/Concatenated PCU frames supported- CS1...CS4 supported- MCS1...MCS9 supported on EDGE carriers-Dynamic Abis allocation supported

BTSplus, E-microBTS II

- Standard/Concatenated PCU frames supported- CS1...CS4 supported

BTS1 with BBSIG44, picoBTS, E-microBTS

- Only Standard PCU frames supported- Only CS1 and CS2 supported- Dynamic Abis allocation supported

BTS1 without BBSIG44

- Dynamic Abis allocation supported

High Capacity BSC

Both standard andconcatenated PCU framesare supported.

Dynamic Abisallocation

Concatenated PCU frames

Concatenated PCU frames

Standard PCU frames

- Standard/Concatenated PCU frames supported- CS1...CS4 supported- MCS1...MCS9 supported on EDGE carriers-Dynamic Abis allocation supported

BTSplus, E-microBTS II

- Standard/Concatenated PCU frames supported- CS1...CS4 supported

BTS1 with BBSIG44, picoBTS, E-microBTS

- Only Standard PCU frames supported- Only CS1 and CS2 supported- Dynamic Abis allocation supported

BTS1 without BBSIG44

- Dynamic Abis allocation supported

Standard BSC

Only standardPCU framesare supported.


Standard PCU frames

Standard PCU frames

Standard PCU frames

A30808-X3247-L24-5-7618 131

InformationSystem


The following considerations can be done:– standard PCU frames are used whenever GPRS CS3/CS4 and EDGE are not

supported;– concatenated PCU frames are used whenever EDGE and/or CS3 and CS4 (more

than 16 kbit/s per radio timeslot) are supported;– in all the previous cases, the mapping between radio timeslots and Abis timeslots is

dynamic (at channel activation);– GPRS CS3/CS4 and EGPRS are not supported on “standard” BSC, due to its “low”

GPRS capacity (max. 128 PDCHs, decreasing to 64 PDCHs in case of CS3/CS4);in this case, GPRS CS3/CS4 and EGPRS are not supported, and standard PCUframes are always used.

The BSC software is backward compatible and it is able to handle BTSs running with oldsoftware releases, supporting only static Abis allocation. Fig. 6.9 gives such anexample, when BTSs with old software releases are connected to a BSC with a releasesupporting the flexible Abis allocation strategy. In this case only GPRS CS1/CS2 radiochannels 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 BSC;– operator commands for a release supporting the flexible Abis allocation strategy

have a “backward compatible” meaning and management (Abis pool definition isinternally handled in a “static” way for “old” BTS software releases);

– the BSC is able to reject operator commands not compatible with “old” BTS softwarereleases.

Fig. 6.9 BSC handling of BTS Equipment with Software Releases not supporting the Abis Dynamic Allocation

6.3.3 Configuration of the Abis InterfaceAs 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

All BTS Hardware with

BSC Hardware

Software Releasesupporting Dynamic

Static Abisallocation

Standard PCU frames

Static Abis Software Release

- Only Standard PCU frames supported- Only CS1 and CS2 supported- Only Static Abis allocation supported


Allocation

132 A30808-X3247-L24-5-7618


(BSC) at configuration time. As a consequence, all the concepts explained below, arevalid, unless differently stated, for both “flexible” and “static” Abis allocations.

To manage the Abis allocations two concepts are introduced: the Abis Subpool and theAbis Pool .

Referring to a specific BTSM, the Abis Subpool is a set of 16 kbit/s Abis subslotsbelonging to a single PCMB line , routed together with the LPDLM instance (previouslyassociated to the BTSM) configured on the same PCMB line.

This is an operator constraint, valid for all kind of BSS configuration (star, loop, multidropwith/without cross connections) and also for cross connectors external to the BSSnetwork elements. The “subpool” concept is necessary for O&M purposes, to manage acorrect fault propagation from LPDLM to Abis resources.

So, the user to connect the BSC to a specific BTSM can create a certain number ofsubpools that will contain a specific number of timeslots of the Abis interface.

To configure an Abis subpool the SUBTSLB object is used. The SUBTSLB objectindicates one subslot of a PCMB line; when creating a SUBTSLB instance the user mustspecify 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.

So, to create on a PCMB line a subpool for a specific BTSM, the user must create moreinstances of the SUBTSLB object, linking them to the same LPDLM instance (i.e., to thesame BTSM) by the ASSLAPD parameter.

Referring to a BTSM, the Abis Pool is the amount of 16 kbit/s Abis subslots reserved tothe BTSM for traffic services (i.e., it is the amount of SUBTSLB instances, configured ondifferent PCMB lines and associated, through the ASSLAPD, to the LPDLMs related tothe BTSM).

One more time it must 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 ofGPRS and EGPRS, changes of the Abis resources assigned to an air interfacetimeslot are possible during TBF-operation via the channel modification command;

– in cases of static Abis allocation, Abis subslots are selected from the Abis Pool andstatically allocated to radio channels by O&M procedures; the relationship betweenradio channels and Abis subslots is sent to the BTS by O&M Abis signalling (at radiochannel creation). The number of Abis subslots to be statically associated to the airtimeslot is always 1 for BTSs running with old SW releases.

Abis pools and subpools have the following properties and features:• different Abis subpools, belonging to the same or different Abis pools, can be

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 thesubslots neighbor each other;

iRemember that a BTSM can be connected to the BSC by, at most, four PCMB lines,and each line must contain at least one LPDLM related to the BTSM.

A30808-X3247-L24-5-7618 133

InformationSystem


• overlaps between different pools and subpools are forbidden.

So, the PCU subframes belonging to a specific PDCH (or air interface timeslot) can bedistributed via all available Abis subpools, even if the subpools are located on differentPCMB lines.

6.3.4 Algorithms Regarding Flexible Abis AllocationRegarding 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 oneor more idle and in service Abis subslots, belonging to the pool associated to the BTSMthat contains the cell; this selection is executed by the BSC during the channel activationprocedure; then the BSC informs the BTS by the CHANNEL ACTIVATION message.Changes of the Abis resources assigned to a PDCH are also possible during TBF oper-ations by the MODIFY ABIS CHANNEL message.

The Abis pools are present on TDPC database, related to the list of BTS (cells) fed bythe pool. Abis idle lists are built and updated according to the O&M operator commandsissued on the SUBTSLB object.

In cases of GPRS/EGPRS services, the number of Abis resources actually allocated atservice setup depends on several factors: required peak throughput, default applicablecoding scheme, Abis resources actual availability, PCU resources actual availability.

The 16 kbit/s Abis subslots, which are assigned to a Radio Channel (PDCH), can belocated arbitrarily at the Abis pool/subpools and must not obey any rules due toincreasing or decreasing subframe counter (SFC). The Abis subslots allocated to thesame radio channel may be distributed over different PCMB lines and it is not necessaryat all to guarantee that the subslots are adjacent to each other. As far as possible, theAbis subslots for the same PDCH are selected from the same PCMB. For each allocatedAbis subslot, one PDT is allocated. But each Abis subslot of a Radio Channel is coupledwith a specific SFC, such that in cases of multiplexing several GPRS/EGPRS TBFs onthe same PDCH, the data of each TBF is transported in a fixed, predetermined way. AllPCU frames with the same SFC must be transported with the same 16 kbit/s Abissubslot.

In cases of packet switched services, the initial Abis assignment can be changeddynamically during operation due to:– radio propagation conditions of the channels (Link Adaptation, see 10.5);– pre-emption of circuit switched services over packet switched services (see

"5.3.6.2 Pre-emption of PDT Resources").

iIn cases of static Abis allocation, Abis subslots are selected from the pool and allocatedto radio channels by O&M procedures; the radio channel/Abis subslot relationship issent to the BTS by O&M Abis signalling.

134 A30808-X3247-L24-5-7618


The pool is managed with a “soft boundary policy”, which guarantees a minimumpercentage of Abis subslots for each cell. All the cells belonging to the same BTSMshare the same Abis pool; each cell may pick up Abis resources from the pool as longas the ‘guaranteed minimum’ is left at the other cells’ disposal. The operator can set theguaranteed minimum number of subslots per cell by the GUARMABIS parameter (BTSobject).

As it has been said, the BSC informs the BTS about the Air timeslots/Abis subslots rela-tionship 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.

In the following sections the two case are discussed.

CHANNEL ACTIVATION Message

Both air interface (carrier, timeslot) and Abis resources (subslots from the Abis pool) areincluded in the CHANNEL ACTIVATION message sent from the BSC to the BTS. Afterhaving received the CHANNEL ACTIVATION message, the BTS connects the indicatedAbis 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;• the PCU frame format type: it can be standard or concatenated.

If the CHANNEL ACTIVATION message activates a GPRS or EGPRS PDCH, the BTSconnects the concatenated PCU frames depending on their SFC with the particular Abischannel(s). If the activation is successful, the BTS sends CHANNEL ACTIVATION ACKto the BSC, otherwise it sends the CHANNEL ACTIVATION NACK.

MODIFY ABIS CHANNEL Message

If a GPRS/EGPRS channel changes its properties (e.g. according to link adaptationprocedure, the used coding scheme must be changed), the following sequence must berespected in Abis Allocation and coding scheme change:

a) if there is a downgrading capacity, first the coding scheme of (all) TBFs on the PDCHis adapted by PCU RLC/MAC signalling messages, then the Abis capacity ischanged by the MODIFY ABIS CHANNEL message; however that superfluous Abisresources are not immediately released; unused PCU/Abis resources are releasedafter a given amount of time;

b) if there is an upgrading capacity, first the Abis capacity is changed by the MODIFYABIS CHANNEL message, then the Abis subslots are aligned and finally the codingscheme of the TBF(s) can be switched. This process is possible only if enough Abiscapacity 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 correspondingsubframe 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 subframeswith the highest SFCs in cases of downgrading and adds subframes with adjacenthigher SFCs in case of upgrading. It is not allowed to modify the SFC to an already allo-cated Abis subslot.

A30808-X3247-L24-5-7618 135

InformationSystem


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 linksThe Abis interface is supported over satellite links. This transmission mode is the mostcommon implementation and it is often used to extend the GSM and GPRS/EGPRSservices to new locations with minimal infrastructure costs. For the reason that GSMtraffic grows also at remote sites, additional BTSs or a BSC may be deployed to supporthigher traffic loads and/or a larger geographical area.

The satellite Abis configuration has the advantage that a minimal expense is requestedfor deploying the service. An existing MSC and BSC can be used, which could possiblysupport satellite connections to several remote locations.

The main disadvantage of the satellite Abis configuration is that the remote locationsrelies heavily on the equipment located at the hub side so hand-offs and also eventualsubscriber to subscriber calls must go over the satellite link increasing load and traffic.Besides the feature “AMR Link Adaptation” does not work together with the Abis Satel-lite link.

The configuration’s parameters toghether with the related commands requested for theAbis over satellite links are described in the manual: “CML:BSC”.

Besides the value of the attribute: “nRLCMAX” (this attribute determines the number ofthe RLC data blocks before the Ack/Nack block is requested) of the PCU ManagedObject has been changed from “20” to “15” for reducing the problem related to the Abissatellite’s delay. This attribute is not configurable.

6.4 Packet Switched Services Supported on CCCH/PCCCHIn the previous chapters (see 4.4.2) it has been described how it is possible to supportGPRS/EGPRS common signalling either on already existing CCCHs (shared CCCHs)or on dedicated CCCHs (PCCCHs).

To avoid packet switched signalling load on traditional CCCHs, it is convenient to useGPRS/EGPRS PCCCHs as soon as packet switched traffic increases beyond a certainthreshold, so that packet switched signalling traffic has no influence on normal signal-ling, and the overall traffic capacity is improved.

These logical channels are mapped on different physical resources (see Fig. 6.10):

a) Dedicated CCCH : PCCCH is mapped in the multiframe of a Packet Data Channel(PDCH); in this case, the common control signalling is carried in a logical channeldedicated to GPRS/EGPRS traffic.

b) Shared CCCH : no dedicated control signalling channels exist for packet switcheddata services, so that GPRS/EGPRS common control signalling packets access aCCCH following its mapping rules. This mechanism is mandatory, whenever a dedi-cated CCCH is not allocated.

136 A30808-X3247-L24-5-7618


Fig. 6.10 Mapping of CCCH/PCCCH Channels on the Abis Interface.

In both cases signalling messages are processed in the PCU, which is realized in BSCby means of PPCU/PPXU cards (Peripheral Processors for GPRS/EGPRS).

In the following sections a short description is given about the message handling whichis implied by the described mechanisms (see Fig. 6.11):

a) Dedicated CCCH: messages are carried in a PCU frame on the 16 kbit/s timeslotrelated to the physical PDCH, where the PCCCH is mapped. The timeslot is routedvia switching matrix directly to the PPCU/PPXU where the channel is processed.

b) Shared CCCH: messages are carried in the LAPD channel related to the BTSE. Thechannel is routed via switching matrix to a PPLD where the LAPD protocol isprocessed. The extracted messages are read by TDPC via Telephonic Bus from thePPLD Dual Port RAM.In the TDPC, the messages are analyzed: GPRS/EGPRS related messages arewritten by TDPC via Telephonic Bus in the Dual Port RAM of the PPCU/PPXU,where they are processed.

TDMA frame

PDCH

CCCH PCCCH

PCMB line

0 31

LAPD

A30808-X3247-L24-5-7618 137

InformationSystem


Fig. 6.11 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 LAPDs the messages received from the PPCUs– the Telephonic Bus is not loaded (twice) by the exchange of messages among

PPLD, PPCU/PPXU and TDPC.

On the other side shared CCCHs is supported in any case to provide the first accesswhen no specific GPRS/EGPRS signalling channels are allocated.

Shared CCCHs are the only way to allow Class B MSs (see "9.1 Mobile Stations forPacket Switched Services") attached to GPRS/EGPRS to listen to their circuit switchedpaging channel on CCCH, when the optional Gs interface between the MSC and theSGSN is not implemented (see "9.8.3.1 Network Operation Modes for Paging").

138 A30808-X3247-L24-5-7618


7 Gb InterfaceThe Gb interface connects the BSC to the SGSN, transferring signalling information anduser data. Several BSCs may be interfaced to one SGSN on the Gb interface.

The main characteristics of the Gb interface are:

a) The resources are given to a user upon activity (when data is sent or received) andthey are reallocated immediately thereafter; this is in contrast to the A interface,where a single user has the only use of a dedicated physical resource throughoutthe lifetime of a call, irrespective of activity;

b) GPRS/EGPRS signalling and user data are sent in the same physical channel. Nodedicated physical resources are required to be allocated for signalling purposes(like e.g., the A interface where SS7 links are used to transmit signalling betweenthe BSC and the MSC).

c) The Gb interface is supported also over satellite links. Specific procedures fordefining the multiple frame operation mode necessary for the transmission of the “I”frames have been implemented. The “T200” and “k” attributes are not configurableby the user because they are not used. The transmission of information at applica-tion level is supported by UI frames (Unacknowledged information/Downlink-Unit-data). As a consequence of this the matter than the Gb interface can be suppportedalso by satellite links is not relevant.In any case only the parameters defined in thespecification: “Q933” can be configurable, but their values do not depend from datalink/physical layer over satellite.

The protocol stack of the “Gb” interface is illustrated in the Fig. 7.1.

Fig. 7.1 Gb Interface: Protocol Stack

The several layers realize 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 NS Service Data Units (SDU)

between the SGSN and BSS. The Gb interface is based on Frame Relay (FR) asspecified in GSM 08.16.

A30808-X3247-L24-5-7618 139

InformationSystem


FR supports high data rate transmission with low delay. Frames of different sizesmay be transmitted. FR performs congestion control and error detection, howevererror correction is not supported.

• BSSGP: the primary functions of the Base Station Subsystem GPRS protocol(BSSGP) are:– providing connection-less links between the SGSN and the BSS (layer 2 level);– providing tools for bi-directional control of data flow;– handling paging requests from the SGSN to the BSS.

• LLC (Logical Link Control layer): provides logical links between a MS and the corre-sponding SGSN. The transport of both data and signalling is supported;

• SNDCP (SubNetwork Dependent Convergence Protocol): supports a direct peer topeer (i.e.,, point-to-point) communication between a MS and a SGSN. User data istransported from a network layer protocol, e.g. IP or X.25.

The NS layer of the Gb interface is split into a Network Service Control part and a SubNetwork 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 Relayprotocol.

7.1 Physical LayerFour types of configurations are possible to connect the BSC to the SGSN:

1. a direct line (e.g., PCM30, PCM24) between the two entities (static and permanentphysical point to point connections);

2. an intermediate frame relay network;3. Nailed Up Connection (NUC) through the MSC via a frame relay network;4. NUC through MSC, without using an intermediate frame relay network.

The different configurations are illustrated in Fig. 7.2.

140 A30808-X3247-L24-5-7618


Fig. 7.2 Different Connection Types between the BSC and the SGSN.

The Gb interface is realized by PCM lines:• in cases of direct connections between the BSC and the SGSN, PCM lines are

called PCMG;• in cases of connections through the MSC (and TRAU), PCMA lines are used.

The PCMG object represents the PCM line used to connect the BSC and the SGSN,without passing through the MSC.

On the PCMG line, 31 physical channels, of 64 kbit/s each one, can be handled (slot 0is always use for synchronization purposes).

In case of standard BSC (see 6.1.1), up to two PCMG lines can be configured:– PCMG:0;– PCMG:1.

In fact in this case two PCMG lines are enough to handle the 32 X 64 kbit/s channels(16 channels for each PCU) that can be equipped toward the Gb interface, alsoproviding the possibility to have fault redundancy.

When the high capacity BSC with the old rack is used (see 6.1.2), in order to completelyexploit the bandwidth that the 6 PPXUs offer toward the Gb interface (in total 378 timeslots at 64 kbit/s), an increase of the PCMG number is necessary. For E1 lines (31 timeslots), 12 lines are enough, while for the T1 lines (PCM24 mode), 16 PCMG lines arenecessary: so this is the number of PCMG that is possible to configure at most with thiskind of BSC.

When the high capacity BSC with the new rack is used (see 6.1.3), in order to completelyexploit the bandwidth that 12 PPXUs offer toward the Gb interface (in total 756 time slotsat 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 neces-sary: so this is the number of PCMG that is possible to configure at most when the newBSC rack is used.

As it has been described in "6 Hardware and Software Architecture", each PCUmanages the packet switched data traffic of a specific number of cells; to transmit packetdata (or signalling) related to these cells, each PCU can use all the PCMG lines config-ured for the BSC. In other words, the PCM line is not statically assigned to one PCU, butto the whole BSC.

This line can be connected in one circuit of LICD without any restrictions. The LICDcircuit using QTLP V2 can be programmed in transparent mode and in this way we canconnect 2 PCM lines to 1 LICD circuit.

The following attributes are involved in PCMG configuration:


PCMG Represents the direct physical connectionbetween BSC and SGSN.

Tab. 7.1 PCMG Object

A30808-X3247-L24-5-7618 141

InformationSystem


• 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;

• CRC: this attribute indicates if CRC-4 signal handling for PCM 30 line or CRC-6signal handling for PCM 24 line is Enabled on PCMG line;

• CODE: this attribute selects the line transmission code to be provided on the line;• NUA: this attribute enables or disables handling of not urgent alarms on PCMG line;• 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 GSM 08.14; 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 timeslots of the PCM line; more than one physical channel can be created over a single line(see Fig. 7.3).

Fig. 7.3 Example of Frame Relay Links

In case of direct connections between the BSC and the SGSN, frame relay links arecreated over PCMG lines, whereas in case of connections through the MSC, the FRlinks are created over PCMA lines.

The FRL object represents the physical channel over the Gb interface between theBSC and the SGSN.

iThe range 0..5 of the CIRCUIT number is valid when STLP boards are usedin the BSC (i.e.,, when the new BSC rack is used), otherwise that admittedrange is 0..3.

PCM line

0 31

PCM line

0 31

FRL_1 (Channelized FRL))

FRL_2 FRL_3(Fractional FRL) (Fractional FRL)

142 A30808-X3247-L24-5-7618


In case of A interface connections, the 64 kbit/s time slots are reserved on PCMS (andPCMA) lines and handled in TRAU as transparent channel. In case of direct Gb interfaceconnections (i.e., connections built without passing through the MSC), PCMG lines arededicated to SGSN connection, and the FRL occupies one or more 64 kbit/s timeslots.The choice between direct connections or A interface connections can be done in baseof the bandwidth required on Gb interface (in case of a small number of FRL links, it isadvantageous to use A interface connections).

In case of A interface connections, with multislot links, the customer must guarantee thatthe MSC is able to ensure the sequence. If the MSC is not able to guarantee this feature,only single timeslot frame relay links can be configured.

When a standard BSC is used (see 6.1.1), up to 32 frame relay links can be created foreach BSC (with range 0 to 31). As described in "6 Hardware and Software Architecture",each PCU is able to handle 1 Mbit/s data flow towards the Gb interface. This flow corre-sponds to a flow obtained by 16 slots (64 kbit/s each one) on a PCM line. This factordetermines the maximum number of Frame Relay links that can be configured for eachPCU, 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 high capacity BSC with the old rack is used (see 6.1.2), up to 378 frame relaylinks can be created for each BSC (with range 0 to 377). As described in "6 Hardwareand Software Architecture", each PCU is able to handle a 4 Mbit/s data flow towards theGb 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 thatcan be configured for each PCU, and the capacity in terms of bit/rate; in fact for eachPCU at most 63 FRLs of 64 kbit/s can be configured.

When the high capacity BSC with the new rack is used (see 6.1.3), up to 756 frame relaylinks can be created for each BSC (with range 0 to 755). As described in "6 Hardwareand Software Architecture", each PCU is able to handle a 4 Mbit/s data flow towards theGb 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 thatcan be configured for each PCU, and the capacity in terms of bit/rate; in fact for eachPCU 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, usingthe PCUID attribute. This attribute indicates the pathname of the PCU managing theFRL.

The operator indicates:

1. the PCM line on which the link is created, using the GLK attribute;2. the number of slots that constitutes the FRL, using the GTS attribute.

For example:– setting GTS= 3, allows 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 (see Fig. 7.4);


FRL Represents the physical link connection onGb interface.

Tab. 7.2 FRL Object

A30808-X3247-L24-5-7618 143

InformationSystem


– setting GTS= 3&4&5&6, allows configuration of a 256 kbit/s Frame Relay link onslots number 3, 4, 5 and 6 of the PCM line which is specified by the GLK attribute(see Fig. 7.5);

– setting GTS= 3&4&7&8, allows configuration of a 256 kbit/s Frame Relay link onslots number 3, 4, 7 and 8 of the PCM line which is specified by the GLK attribute(see Fig. 7.6).

Fig. 7.4 Example of Frame Relay Link (GTS=3).

Fig. 7.5 Example of Frame Relay Link (GTS=3&4&5&6).

Fig. 7.6 Example of Frame Relay Link (GTS=3&4&7&8).

The operator, by the FRSTD attribute, can also optionally indicate the frame relay stan-dard to be used (regarding the frame relay structure, see 7.2.1.2).

Supposing to configure, for each PCU, 2 FRLs, these links can be distributed on the Gbinterface in different manners, by setting the GTS attribute, e.g.:– 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; infact in case of fault of one PCMG line, the other one allows the connection betweenthe BSC and the SGSN to be maintained);

– it is possible to put one of them on one PCMG line, and the remaining one on onePCMA line;

– it is possible to put both of the links over PCMA lines.

0 31

64 kbit/s Frame Relay Link

0 31


0 31


144 A30808-X3247-L24-5-7618


When the links are created over different PCMA lines, and these lines belong to thesame TRAU module (i.e., the lines correspond to the same PCMS line), the FR linksmust have different timeslot values for the GTS attribute.

Instead, if the lines belong to different TRAU modules this problem does not exist. Thislast solution is obviously better than the previous one, since it provides the redundancyof FRLs.

7.2 Network Service LayerThe Network Service layer provides a reliable connection between the BSC and theSGSN; this reliable connection is realized:

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 (see Fig. 7.7):

1. the Sub-Network Service (i.e., the Frame Relay protocol), which is an entity depen-dent on the intermediate Gb interface network;

2. the Network Service Control, i.e., a control entity independent from that network.

Fig. 7.7 Network Service Layer

7.2.1 Sub-Network Service: Frame Relay on Gb InterfaceOn the Gb interface, and specifically inside each Frame Relay physical link, only Perma-nent Virtual Circuits are implemented.

A Permanent Virtual Circuit (PVC) is an end-to-end logical communication link betweenthe 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 morethan one PVC.

For PVCs there is no call set-up or clearing: a connection to the frame relaying nodemust be in place from the configuration point of view.

iRemember that the PCMG/PCMA lines are shared between the configured PCUs,whereas each Frame Relay Link is associated to a specific PCU according to the PCUIDvalue.

A30808-X3247-L24-5-7618 145

InformationSystem


The NSVC (Network Service Virtual Connection) object represents the end-to-endpermanent virtual connection between the BSC and the SGSN.

Each NSVC is identified by the Network Service Virtual Connection Identifier (NSVCI).Up to 65536 NSVCIs can be created between a BSC and the SGSN. For each FRL (i.e.,for each Frame Relay physical link) more than one NSVC can be created.

Referring to Fig. 7.8 there is a set of principles that apply to the Gb FR network:• the physical link is the Frame Relay bearer channel (allocated timeslots in a PCMG

or a PCMA line);• the NSVC is the FR PVC;• the FR PVC (NSVC) provides an end-to-end connection through the FR network.

The Network Service Virtual Link (NSVL) is the local link in one end of the FR PVC,i.e it is the link at the User Network Interface (UNI);

• the Data Link Connection (DLC) defines the entry point to the FR network. A DLC isidentified by a DLC Identifier (DLCI);

• the Network Service Virtual Link Identifier (NSVLI) is the DLCI together with thebearer channel identifier (FRL). A physical link supports one or more NSVLs; eachone is identified by a NSVLI.

Fig. 7.8 Gb Interface with a Frame Relay Network


NSVC Represents the end-to-end communicationbetween BSS and SGSN.

Tab. 7.3 NSVC Object

Frame Relay physical link

146 A30808-X3247-L24-5-7618


When creating a new PVC, i.e., when creating a new instance of the NSVC object, theuser must specify the following:

1. the Network Service Virtual Connection Identifier (NSVCI) of the NSVC, i.e., thecommon and absolute identification of the virtual connection between the SGSN andthe BSS; to specify this value he uses the NSVCI parameter;

2. the Network Service Virtual Link Identifier (NSVLI) to identify the NSVC on the local(BSS) side. To specify this value he uses the NSVLI parameter; this parameter iscomposed 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 Frame Relay packets, see "7.2.1.2 Frame Relay Structure") allows adistinction between different NSVCs that belong to the same physical FrameRelay link.The mapping of the DLCI parameter is as follows:

DLCI value Mapping

0 In band signalling1-15 Reserved16-511 Available for user information512-991 Available for user information

iSince Frame Relay Physical links are statically associated to a single PCU, even theNSVCs created inside this FRL are handled by a single PCU. The PCU will then shareits 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.

iAll the NSVCs configured for a PCU constitute the so called NSVC group; this group isidentified 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 ControlUnit.The NSEI value, that identifies the PCU and its NSVCs is configured by the NSEIparameter.

iIf a direct end-to-end PCMG line connection is used between the BSC and the SGSN(i.e., if a Frame Relay Network is not used), the two values related to one NSVC are thesame; i.e., the NSVLI value at the BSS side is equal to the NSVLI value at the SGSNside.When an intermediate FR network is used in connecting the BSS and the SGSN, theNSVLI values, of the same NSVC, can have a different value at the SGSN side and atthe BSS side.

A30808-X3247-L24-5-7618 147

InformationSystem


7.2.1.1 Examples of AddressingIn 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 ServiceVirtual Connection (NSVC) is used. At each side of the Gb interface there is a one-to-one correspondence between NSVCs and NSVLs.

The creation of a NSVC may be as follows (see Fig. 7.9):

Fig. 7.9 Creation of a NSVC

To well understand previous concepts, some examples regarding the configuration ofboth Frame Relay Links and Permanent Virtual Connections (NSVCs) are described.Let’s consider a BSC that is connected to the SGSN by two direct PCMG lines (PCMG-0 and PCMG-1).

EXAMPLE 1: BSC Configured with One PCU and Two Frame Relay Links of 64kbit/s each.

Two frame relay links of 64 kbit/s each have been created for a BSC configured with asingle 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).

Database object instance: NSVC-3 Defining the end-to-end connec-tion between the SGSN and theBSC/PCU.

Parameters for NSVC-3: NSVCI=5 Internal identifier of the FRnetwork connecting each side ofthe network.

NSVLI=0-111 FRL object 0, DLCI 111.Local connection at BSC/PCUside.Similarly a NSVLI value must bedefined at the SGSN side.

148 A30808-X3247-L24-5-7618


Fig. 7.10 BSC Configured with One PCU and Two FR Links (64 kbit/s each).

Supposing now to create a PVC for each FRL; Tab. 7.4 shows possible values that canbe used to create the two virtual connections. As it can be seen, DLCI values of the twocreated NSVCs can be equal, since the two NSVCs belong to two different FRLs.

EXAMPLE 2: BSC Configured with One PCU and Two Frame Relay Links of 128kbit/s each.

Two frame relay links of 128 kbit/s each have been created for a BSC configured with asingle 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).

NSVC belonging to FRL:0

NSVCI 494

NSVLIFRLN 0

DLCI 100


NSVC 512

NSVLIFRLN 1

DLCI 100

Tab. 7.4 Example of Setting of NSVC Values.

0 31

0 31

PCU- 0 PCMG-0

PCMG-1

PCUID:PCU-0GLK:PCMG-0GTS:2

FRL:0

PCUID:PCU-0GLK:PCMG-1GTS:5

FRL:1

NSEI = 2354

A30808-X3247-L24-5-7618 149

InformationSystem


Fig. 7.11 BSC Configured with One PCU and Two FR Links (128 kbit/s each one).

Supposing now to create a PVC for each FRL; Tab. 7.4 shows possible values that canbe used to create the two virtual connections.

It can be seen, that from the NSVC configuration point of view, there isn’t any differencewith respect to the previous example, even if the FRL:1 has been created using two non-adjacent timeslots.

Obviously the network must 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 128kbit/s each.

In this case, the BSC contains two PCUs. The PCU-0 has been configured with a NSEIvalue 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 seesa total bandwidth of 256 kbit/s (128 kbit/s + 128 kbit/s).

0 31

0 31

PCU- 0 PCMG-0

PCMG-1

PCUID:PCU-0GLK:PCMG-0GTS:2&3

FRL:0


FRL:1

NSEI = 2354

150 A30808-X3247-L24-5-7618


Fig. 7.12 BSC Configured with Two PCUs and Two FR Links each one.

Supposing now to create a PVC for each FRL; Tab. 7.5 shows possible values that canbe used to create the two virtual connections for the PCU-0, and possible values thatcan 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 NSVCs used tosupport the traffic of the PCU-0; in the same way the NSEI identifier of the PCU-1, notonly identifies the PCU-1, but also NSVCs used to support its traffic.


NSVCI 480

NSVLIFRLN 0

DLCI 163


NSVCI 555

NSVLIFRLN 1

DLCI 100


NSVCI 574

NSVLIFRLN 2

DLCI 100

Tab. 7.5 Example of Setting of NSVC Values for both PCU-0 and PCU-1

0 31

0 31

PCU- 0 PCMG-0

PCMG-1


FRL:0


FRL:1


FRL:2

PCU- 1


FRL:3

NSEI = 2354

NSEI = 7564

A30808-X3247-L24-5-7618 151

InformationSystem


7.2.1.2 Frame Relay StructureCore functions of the NS Sub Network Service provide necessary data link functions topermit routing and relaying, but excludes those associated with sequencing, most formsof error detection, error recovery and flow control.

Referring to the Frame Relay frame format (see Fig. 7.14), the Sub Network Servicefunctionality provides for:

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 occurredduring the transmission from source to destination. Frame Relay reduces networkoverhead by implementing error checking rather than error correction. Frame Relaytypically is implemented on reliable network media, so data integrity is not sacrificedbecause error correction can be left to higher-layer protocols running on top ofFrame Relay.

d) Congestion control using the “FECN”, “BECN”, and ”DE” fields. This functionpermits core entities to detect congestion, to optionally notify peer entities ofcongestion 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 FrameRelay 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 droppedduring periods of congestion.The FECN mechanism is initiated when a DTE device (e.g., in our case the SGSN)sends Frame Relay frames into the network (see Fig. 7.13).


NSVCI 575

NSVLIFRLN 3

DLCI 216

Tab. 7.5 Example of Setting of NSVC Values for both PCU-0 and PCU-1

152 A30808-X3247-L24-5-7618


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 pathfrom source to destination. The DTE device can relay this information to a higher-layer protocol for processing. Depending on the implementation, flow-control may beinitiated, or the indication may be ignored.DCE devices set the value of the BECN bit to 1 in frames travelling in the oppositedirection of frames with their FECN bit set. This informs the receiving DTE devicethat a particular path through the network is congested. The DTE device can thenrelay this information to a higher-layer protocol for processing. Depending on theimplementation, 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 importancethan other frames. DTE devices can set the value of the DE bit of a frame to 1 toindicate that the frame has lower importance than other frames. When the networkbecomes congested, DCE devices will discard frames with the DE bit set, beforediscarding those that do not. This reduces the likelihood of critical data beingdropped 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 congestion detection. The congestion detection regards the pathfrom the SGSN to the BSC (i.e., it regards the frame relay frames sent by theSGSN to the BSS).If, during the time defined by TCONG, the number of frames indicating congestionis equal or greater than the number of frames indicating no congestion, thecongestion state is notified to upper layers;

– TCONOFF: after a congestion notification to upper layers, no other notificationsare foreseen for a length of time defined by TCONOFF. This timer is needed toprovide a hysteresis time in order to ensure that the traffic reduction at mobilestation can be effective.

A30808-X3247-L24-5-7618 153

InformationSystem


All data link peer to peer communications use frames conforming to the format shownin Fig. 7.14.

Fig. 7.14 Frame Relay Frame Structure

The basic Frame Relay fields are the following:• Flags: delimits the beginning and end of the frame. The value of this field is always

the same and is represented either as the hexadecimal number 7E or the binarynumber 01111110.

• Address: 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 virtualconnection that is multiplexed onto the physical channel will be represented by aunique DLCI. The DLCI values have local significance only, which means thatthey are unique only to the physical channel on which they reside. Therefore,devices at opposite ends of a connection can use different DLCI values to refer tothe same virtual connection. Since there is neither D-channel nor layer 2 manage-ment functionality, the available DLCI values usable for user information arealmost the whole DLCI range but DLCI 0, which is reserved for layer 3 messagetransfer (STATUS and STATUS_ENQUIRY, see "7.2.1.3 Procedures for PVCs");

– Extended Address (EA): it is used to indicate whether the byte in which the EAvalue is 1 is the last addressing field. If the value is 1, then the current byte isdetermined 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 inthe future. The eighth bit of each byte of the Address field is used to indicate theEA.

– 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

154 A30808-X3247-L24-5-7618


– congestion-notification mechanisms. These are the FECN, BECN, and DE bits,which are the last three bits in the Address field.

• Data: contains encapsulated upper-layer data. Each frame in this variable-lengthfield 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 FrameRelay network.

• Frame Check Sequence: ensures the integrity of transmitted data. This value iscomputed by the source device and verified by the receiver to ensure integrity oftransmission.

7.2.1.3 Procedures for PVCsFor each group of PVCs belonging to a FRL, a periodic polling procedure is used inacquiring general status about the connection between the BSC and the SGSN. Thepolling interval is defined by the T391 timer. Every T391 seconds the PCU sends aSTATUS ENQUIRY message to the network to retrieve some information (optionally thenetwork may initiate the polling procedure).The information regards:

a) notification of the addition of a PVC: used to notify users of newly added permanentvirtual circuits;

b) detection of the deletion of a PVC: used to notify users of deleted permanent virtualcircuits;

c) notification of the availability (active) or unavailability (inactive) state of a configuredPVC: used to determine changes in status of configured PVCs;

d) link integrity verification: used in determining the in-channel signalling link DLCI-0.Establishing and releasing a logical connection is accomplished by exchangingmessages via DLCI-0. The Link Integrity verification procedure is required sinceDLCI-0 contains unnumbered information (UI) frames at Level 2.

The periodic polling procedure allows the PCU to retrieve the previous information; theprocedure is shown in Fig. 7.15.:

1. every T391 seconds, the PCU sends a STATUS_ENQUIRY message to the network;2. the network answers with a STATUS message; two types of STATUS messages can

be used:– if no PVCs have been added to or deleted from the FRL, or if the state of 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 doesn’t contain the state ofthe configured PVCs because nothing is changed);

– if one (or more) PVC has been added to or deleted from the FRL, or if the stateof any configured PVCs is changed, the network answers with a FULL STATUSmessage, reporting the status of ALL the PVCs (this message is also used toverify the link integrity);

3. after N391 polling cycles (i.e., after N391 expirations of the T391 timer), the PCUsends to the network a STATUS_ENQUIRY message requiring a FULL STATUSanswer;

4. every time the PCU doesn’t receive an answer from the SGSN, an “error counter” isincremented;

A30808-X3247-L24-5-7618 155

InformationSystem


5. if the “error counter” reaches the N392 value during the error observation windowdefined by:

N393 * T391

the Frame Relay link is put into Disable state, and all the contained PVCs are, as aconsequence, put in Disable state;

6. if the N392 threshold is not reached during the error observation window, the “errorcounter” is restarted.

Fig. 7.15 Periodic Polling Procedure

7.2.2 Network Service ControlThe 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 turnare 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 theavailable (i.e., unblocked) 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;

SGSNPCU

STATUS_ENQUIRYExpiration ofT391

STATUS

STATUS_ENQUIRY

STATUS

STATUS_ENQUIRY

FULL_STATUS

Expiration ofT391

Expiration ofT391

N391 pollingcycles reached

Reset andrestart T392

Reset andrestart T392

iThe value of the T391 timer set on the BSC side must be lower than the value of theT392 timer set on the SGSN side.

156 A30808-X3247-L24-5-7618


– a reset procedure is used between peer NS entities in order to set an NSVC to adetermined state, after events resulting in possibly inconsistent states of theNSVC at both sides of the Gb interface;

– a test procedure is used to check that an NSVC is properly operating betweenpeer NS entities.

7.2.2.1 Load SharingAll NS SDUs to be transmitted over the Gb interface are passed to the load sharing func-tion. The load sharing function is used by NS entities to select, among unblockedNSVCs of the addressed BVC, where to send NS SDUs.

The mapping between NS SDUs and NSVCs is based on an implementation dependentfunction that meets the following requirements:• for each BVC (i.e., for each cell), the load sharing function chooses the NSVC over

which the current NS SDU must be transmitted;• thus, the load sharing function guarantees that, for each BVC, the order of all NS

SDUs is preserved;• load sharing functions at the BSS and the SGSN are independent. Therefore, uplink

and downlink NS SDUs for a subscriber may be transferred over different NSVCs;• a change in the number of available NSVCs for NS user traffic (i.e., one or more

NSVCs become blocked or unblocked) results in a reorganization of the NS SDUtraffic among the unblocked NSVCs;

• for a BVC, when there are no unblocked NSVCs between a BSS and a SGSN, thecorresponding traffic is discarded by the NS at the sending side.

7.2.2.2 Control ProceduresThe procedures concerning the management of NSVCs are:• block/unblock of NSVCs by the operator• reset and test the status of NSVCs.

The Block Procedure inhibits an NSVC from carrying traffic. For instance, the BSC mayblock 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 SDUto other unblocked NSVCs; the NS entity is informed via NS_STATUS_INDICATIONprimitive 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 procedureat the BSS side.

When the PCU has sent an NS_BLOCK_PDU, it waits TNSVCBLK seconds foracknowledgement from the SGSN. The NNSVCBLKR parameter specifies the

iEach BVC represents a GPRS/EGPRS cell in the PCU (see "7.3 BSSGP Protocol"); theload sharing function allows transmission of the NS SDUs related to a cell among theavailable NSVCs.

iLoad sharing applies only to NS SDUs, not to NS signalling, such as NSVC manage-ment PDUs (e.g., NS_BLOCK_PDU used in the NSVC block/unblock procedures, see"7.2.2.2 Control Procedures").

A30808-X3247-L24-5-7618 157

InformationSystem


maximum number of performed retries by the PCU in the NSVC block procedure; i.e., ifthe SGSN does not answer the block procedure, the PCU retries the procedure at mostNNSVCBLKR times.

The Unblock Procedure allows the return of a previously blocked NSVC back toservice. The procedure is analogue to the BLOCK one.

When the PCU has sent the NS_UNBLOCK_PDU, it waits TNSVCBLK seconds foracknowledgement from the SGSN. The NNSVCUBLR parameter specifies themaximum number of performed retries in the NSVC unblock procedure; i.e., if the SGSNdoes not respond to the unblock procedure, the procedure is retried NNSVCUBLRtimes.

The Reset Procedure is used:– when a new NSVC is set up between a BSS and the SGSN;– after processor restart;– after failure recovery or any local event restoring an existing NSVC which was in

dead state;– when the state of an NSVC is undetermined between remote NS entities.

Upon completion of the reset procedure, the successfully reset NSVC is marked asblocked and alive at both sides of the Gb interface.

The BSS (or the SGSN) sends the NS_RESET_PDU to its peer entity indicating theNSVCI. 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 inthe NSVC reset procedure, before generating any alarm; i.e., if the SGSN does notrespond to the reset procedure, the procedure is retried infinitely times, but afterNNSVCRR times an O&M alarm 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 onan NSVC. Both sides of the Gb interface must initiate this procedure independently fromeach other. This procedure is initiated upon successful completion of the reset proce-dure (as specified in sub-clause "Reset procedure") and will then be periodicallyrepeated. After unsuccessful attempts, the procedure is stopped; the NSVC is markedas 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; i.e., when an

NSVC is available, the test message is sent to the SGSN every TNSVCTSTseconds;

– if after TNSVCPTST seconds no answer to the test is received from the SGSN, theprocedure is retried;

– after NNSVCTSTR repetitions, without any answer, the link is declared not available.

7.3 BSSGP ProtocolThe Gb interface allows many users to be multiplexed over a common physicalresource. Both GPRS/EGPRS signalling and user data may be sent on the same phys-ical resource.

The primary functions of the BSSGP protocol include:

158 A30808-X3247-L24-5-7618


• transmit LLC frames from the SGSN to the BSS, with radio related information (suchas Quality of Service and routing information) which is used by the RLC/MAC func-tion;

• transmit LLC frames from the BSS to the SGSN, with radio related information (suchas Quality of Service and routing information) which is derived from the RLC/MACfunction;

• provide functionalities to enable both the SGSN and the BSS to perform manage-ment control functions (e.g., SGSN-BSS flow control).

7.3.1 BSSGP Addressing: BSSGP Virtual Connections (BVCs)The BSSGP protocol establishes the connection between the SGSN and the PCU interms of BSSGP virtual connections (BVCs).

Each BVC is used in transporting BSSGP PDUs between PTP (point to point) functionalentities; a PTP functional entity is constituted by a cell. Note following concepts:• 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 GSM 08.18 – for point-to-point packet transfer – it’s specified that a cell is identifiedby a BVCI, so there is a one to one relationship between a cell and a BVCI.

In Siemens implementation, the PTPPKF object represents the presence of packetswitched data services in a specific cell and the state of this object allows or disallowsthe service in the cell.

The dependency from the BTS object is one to one; then all state changes on BTSobjects are reflected on PTPPKF objects.

The NSVC-BVCI hierarchy is not one to one but one PTPPKF can be reached fromdifferent NSVCs, which are connected to the same PCU; in fact, the NSEI identifies theNSVC group, i.e., the group of all the NSVCs that provide service for a PCU: to one PCUcorresponds 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 NSVC state change, is handled by the system thatputs the PTPPKF object into the disabled state when the associated BVCI is no longeraccessible. All state transitions for PTPPKF objects are notified to the remote end viathe BVCI Block/Unblock procedure (see 7.3.1.1). The PCU restart or the BSS initializa-tion are handled generating a reset procedure with the SGSN. Needed timers forhandling Block/Unblock and Reset procedures are defined in the PCU object (see"7.3.1.1 BVC Procedures").

The PTPPKF object is always created with the instance equal to 0 since it is subordinateto the BTSM and BTS object following this path:

BTSM:m/BTS:n/PTPPKF:0

The BVCI number associated to a PTPPKF object instance is fixed, and the relation is:

A30808-X3247-L24-5-7618 159

InformationSystem


The 0 and 1 values are reserved respectively for signalling and PTM links.

To summarize the previous concepts, let us consider a SGSN that manages four PCUs:• PCU:0, PCU:1 and PCU:2 configured on BSC:1;• PCU:0 configured on BSC:2.

Reflected in 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);

c) each cell is identified in the PCU by the 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.

BVCI number = (number of creation of the PTPPKF in the database) + 2

iWhen an upgrade from the Release BR5.5 to BR7.0 is executed, some changes in theSGSN database must be executed. This is due to the fact that, according to the loadbalancing schema that is used for the PCUs (see "6.1 Supported BSC Types"), thePTPPKFs (i.e., the BVCIs) are no longer statically assigned to a single NSEI (i.e., to asingle PCU) but they can be moved from one PCU to another one following the PTPPKFdistribution algorithm (see "8 Load Control for Packet Switched Services"); so in theSGSN, the BVCIs of one BSC have to be configured on all the NSEIs (PCUs) related tothe BSC.

iObviously, the NSVCI values, related to the different NSVCs created forthe four PCUs must be different from each other.

160 A30808-X3247-L24-5-7618


Fig. 7.16 Distribution of Packet Switched Data Traffic among Different Cells

GPRS

BVCI= 6NSEI_A

SGSN

NSVC:0

BSC:1\PCU:0Cell

GPRS

BVCI= 2

Cell

NSVC:1

NSVC:2

GPRS

BVCI= 5

NSEI_B

NSVC:3BSC:1\PCU:1

Cell

GPRS

BVCI= 4

Cell

NSVC:4

GPRS

BVCI= 2NSEI_D

NSVC:0

BSC:2\PCU:0Cell

GPRS

BVCI= 4

Cell

GPRS

BVCI= 3

Cell

NSVC:1

NSVC:2

GPRS

BVCI= 3

NSEI_C

NSVC:5

BSC:1\PCU:2

Cell

GPRS

BVCI= 7

Cell

NSVC:6

NSVC:7

BVCI=2

BVCI=6NSEI_A

BVCI=4

BVCI=5NSEI_B

BVCI=3

BVCI=7NSEI_C

BVCI=2

BVCI=3 NSEI_D

BVCI=4

FRL:0

FRL:1

FRL:2

FRL:3

FRL:4

FRL:5

FRL:0

FRL:1

NSVC group identified by NSEI_A

NSVC group identified by NSEI_B

NSVC group identified by NSEI_C

NSVC group identified by NSEI_D

A30808-X3247-L24-5-7618 161

InformationSystem


7.3.1.1 BVC ProceduresFor BVCs associated to PTPPKF objects, the following procedures with remote end areimplemented:• BLOCK;• UNBLOCK;• RESET.

The BLOCK Procedure inhibits a BVCI from carrying traffic. It’s performed when thePTPPKF object is locked by the operator or when it reaches a disable-dependencystate. All PDTCHs of the cell are released and system information, reportingGPRS/EGPRS service not allowed in the cell, is sent in the BCCH or the PBCCH.

If, after a Block Procedure attempt, the PCU doesn’t receive a response from the SGSN,it retries the procedure. The waiting time for the block procedure is defined by the T1parameter: after sending a BVCI block message, the PCU waits T1 seconds foracknowledgement. After NBVCBR consecutive repetitions, without any answer from theSGSN, an O&M alarm is sent.

The UNBLOCK Procedure allows the traffic back on the previous blocked BVCI. ThePTPPKF is put in enabled state. System information, reporting GPRS/EGPRS serviceallowed in the cell, is sent in the BCCH or the PBCCH.

If, after an Unblock Procedure attempt, the PCU doesn’t receive a response from theSGSN, it retries the procedure. The waiting time for the unblock procedure is defined bythe TF1 parameter: after sending a BVCI unblock message, the PCU waits T1 secondsfor acknowledgement. After NBVCUR consecutive repetitions, without any answer fromthe SGSN, an O&M alarm is sent.

The RESET Procedure is used when a new BVCI is set up between the SGSN and theBSS, or after each event (processor restart, failure recovery, etc.) that needs to clearand to synchronize BVCI status on both sides. Both sides must initiate the procedureindependently.

If, after a Reset Procedure attempt, the PCU doesn’t receive a response from the SGSN,it retries the procedure. The waiting time for the reset procedure is defined by the T2parameter: after sending a BVCI reset message, the PCU waits T2 seconds foracknowledgement. After NBVCRR consecutive repetitions, without any answer from theSGSN, an O&M alarm is sent.

7.3.2 Quality of Service (QoS)For an uplink data transfer, the QoS profile is communicated by the MS as a priorityinformation in the PACKET_CHANNEL_REQUEST message. For a downlink datatransfer, the BSSGP protocol provides the means to transfer the full QoS profile togetherwith each downlink LLC PDU. In the latter case, the following QoS parameters areincluded in each LLC-PDU transferred to the BSS:– precedence class;– peak throughput;– LLC-PDU lifetime.

The PCU, taking into account the available radio resources and the multislot capabilitiesof the MS, decides if and how the requested QoS may be satisfied. This means that thecore algorithm of the PCU would try to satisfy the requested QoS by acting on manyfactors.

162 A30808-X3247-L24-5-7618


Regarding the QoS, as described in "5.3 Management of Packet Data Channels", theresource allocation algorithm allows the consideration of the required peak throughputclass.

No QoS related to BSSGP flow control ("7.3.3 SGSN-BSS Flow Control") is now imple-mented.

7.3.3 SGSN-BSS Flow ControlPacket switched data traffic exhibits large statistical fluctuations both for the flow-in intothe PCU as well as for the flow-out over the air interface. The former depends on thevolatility of Internet traffic; the latter is caused by the speciality of the air interface.Strongly varying C/I leads to variations of the RLC blocks re-transmission rates. GSMvoice calls have pre-emptive priority and may thus steel time slots allocated to PSservices (but not the GPRS/EGPRS reserved timeslots).

For these reasons two different types of flow control are implemented in the BSS:– 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 ratecontrol schemes are used to smooth traffic and thus reduce variance. This reducestransmission delays for the user. Additionally, flow control should minimise the prob-ability of BVC buffer over flow.

– MS Flow Control: without mobile specific flow control, mobiles with low individualflow rate (caused for example by being capable of only one timeslot, multiplexedwith other TBFs onto the same timeslot, and large retransmission rates) might slowdown all other mobiles within the same cell. Because these mobiles cannot get theirdata out of the common BVC buffer fast enough, the buffer filling might increaseabove a threshold, and the mean BVC flow rate R might slow down. Thus, the SGSNmight narrow the throttle for all other mobiles, too.

For packet transfer from the SGSN to the BSS, the BSSGP protocol uses an addresswhich is composed of three parts:• cell Identity (BVCI);• QoS profile;• MS identification (e.g. TLLI).

These three parts are then used to dynamically queues and contexts in both the SGSNand the BSS. The flow control mechanism is then based on these queues and contexts.

The principle of flow control is based on the following:

a) in the SGSN, queues are provided per MS. The SGSN sends PDUs to the LLC layeras a function of the requested service type and the Mobility Management state (see"9.3.1 Mobility Management States");

b) in the BSS, queues per cell (BVC) and per MS (TLLI) are provided at the BSSGPlevel;

c) signalling has its own queue.

The BSS controls the flow of packet data units (PDUs) to its BVC buffer for an individualMS, by indicating to the SGSN the maximum allowed throughput for a certain TLLI.

The BSS controls the flow of packet data units to its BVC buffers by indicating to theSGSN the maximum allowed throughput for each BVC.

iThe Temporary Logical Link Identity (TLLI) identifies univocally a GPRS/EGPRS user,who is engaged in data transfer, inside a cell (see also "9.8.2.5 Contention Resolution").

A30808-X3247-L24-5-7618 163

InformationSystem


The amount of buffered packet data units for a given TLLI or BVC has to be optimizedto 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 isdeleted from the BSS and the deletion is signalled to the SGSN by the LLC-DISCARDED PDU message.

It is foreseen a cascaded mobile (MS) and cell (BVC) oriented “flow control scheme”(see 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 sched-ules the MS accesses, according to its own radio capacity). A LLC PDU must first haveobtained 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 in the followingway (see Fig. 7.18): there is a queue of LLC frames without a permit for transmission tothe PCU, and a bucket of permits (“tokens”). The LLC frame at the head of the framequeue 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 isdeleted. Permits are generated at the rate R as long as the number in the permit bucketdoes not exceed a certain threshold Bmax. When frames have different sizes, a tokenshould be thought as the permission to transmit one byte. A frame p of size L(p) willobtain the permit for transmission, if at least L(p) tokens are available in the bucket.

164 A30808-X3247-L24-5-7618


Fig. 7.18 Token Leaky Bucket (in SGSN)

On the PCU side, there is for each BVC or MS a buffer which is filled by the segmenta-tion of the arriving LLC PDUs and empties when these blocks are transmitted over theair interface. PCU calculates the control variables R and Bmax and transmits them withflow control commands to the SGSN at every expiration of the TF1 timer. Thus a closed-loop control is realised (see Fig. 7.19). In the PCU the real rate Rpcu (towards the Abisinterface) can be different from the value R sent to SGSN.

In other words, SGSN uses parameters sent by BSC in order to decide if it can senddata or not. The principle is that periocally BSC can send new parameters and SGSNupdates the internal values related.

A30808-X3247-L24-5-7618 165

InformationSystem


Fig. 7.19 Closed Loop Control

Every TF1 timer expiration, the BSC can send a new BVC or MS Flow Control withfollowing 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 FlowControl and another one for the MS Flow Control. As a consequence, the followingparameters 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 guaranteea continuous data flow to the MSs.Following things have to be taken into account:– a too low Leak rate respect to the maximum rate possible prevents SGSN from

sending data to BSC;– Bmax has to be high enough in order to guarantee that BSC has always “something

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;

166 A30808-X3247-L24-5-7618


– the discarding of packets because of lifetime expiration will be an exceptional case.

7.3.3.1 MS Flow Control MessageDuring active Downlink TBF, the BSC sends a MS-FLOW-CONTROL (see Fig. 7.19)message in order to inform SGSN about the quantity of memory reserved for that TBFand the rate at which bytes are sent.

At each TF1 timer expiration, the BSC computes BmaxBasicMS value according to thefollowing formula:

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 isreached when in the previous interval the number of bytes related to expired LLC ismore than 30% of LLC bytes sent for that MS;

• nGPRS_TS is the number of timeslots assigned for GPRS/EGPRS services at timerexpiration at this MS;

• RmaxMS is the teorical MS Maximum Rate according to resources assigned to MSand to used coding scheme (CS/MCS); it is defined as:

In order to allow more flexibility in flow control management, some parameters are intro-duced.

One of these parameters is MSBMAPER (MsBucketMaxPercentage), defined as:

iThe current Bucket Level procedure is used only if SISGSNREL99 parameter (PCUobject) is set to the TRUE value.

BmaxBasicMS = f *(1s +TF1) * RmaxMS

where:

f = 1 if no large amount of LLC lifetime expiration occurs;f =1/ ((nGPRS_TS +1) * TF1 * i) otherwise.

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 (inpercentage) by the MS, when it shares the timeslot with other MSs. For exampleTSPercentage=30% means that 30/100 * RTS is the rate for the MS in that timeslot.

RmaxMS TSPercentageRTSk

k 1=

K

∑=

iThe purpose of these parameter is for testing purposes and for special application. It willnot be guaranteed that the BSC works with all combination and it is suggested tomantain default value.

A30808-X3247-L24-5-7618 167

InformationSystem


Through this parameter the operator can reduce the value of BmaxBasicMS automati-cally computed by BSC.

Another parameter is called MSBSPPER (MsBucketSizePcuPercentage) and repre-sents a relationship between BmaxPCUMS and BmaxMS . The exact definition is:

As can be seen in Fig. 7.19, BmaxPCUMS must be higher than BmaxMS, so MSBSPPERis 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 twothresholds through the parameters: MSBHIPER (MsBucketHighPercentage) andMSBLPER (MsBucketLowPercentage). They are defined through the following formula:

If the state is “non-congested”, and BucketLevelPCU MS (the current Bucket Level inPCU) crosses BhighMS from below, the state is set to “congested”.

If the state is “congested”, and BucketLevelPCUMS crosses BlowMS from above, thestate is set to “non-congested”.

For what concerns the MS Bucket Leak Rate, different behaviours are foreseen,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 toBmax. For example if BucketLevelPCU is 40% of Bmax, Bucket Full Ratio = 40. IfBucketLevelPCU 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 followingway:

(8 is due to the fact that Bucket Leak rate is in 100 bits/s unit, Bucket size is 100 octetincrements).

In the normal case the BSC sends to SGSN the following value for RMS:

Otherwise the BSC sends the following value:

BmaxMS = MSBMAPER * BmaxBasicMS

BmaxPCUMS = MSBSPPER *BmaxMS

BhighMS = MSBHIPER * BmaxPCUMS

BlowMS = MSBLPER *BmaxPCUMS

MS Bucket Leak rate = RMS*8/100

RMS= RmaxMS

168 A30808-X3247-L24-5-7618


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 rateis reduced as following:

2. If MS buffer is congested:

– i is the consecutive number of times that the LLC PDU lifetime expirationthreshold is found to be present;

– nGPRS_TS is the number of TS assigned for GPRS/EGPRSD services at timerexpiration for this MS.

Bucket_Full Ratio is implemented in SGSN

In this case, the value MS Bucket Leak rate, is sent always without correction factor.

7.3.3.2 BVC Flow Control MessageBmaxBVC (see Fig. 7.19 ) is a value not corresponding to real BVC memory capacity onPCU, but a value to be communicate to SGSN 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:

where:

RMS=f* RmaxMS

Retrasm_rate = Bytes retransmitted/ Byte transmitted

if Retrasm_rate < 10 % no correction.if 10 % < Retransm_rate < 20 % then Leak rate = 0.9 * Leak Rateif 20 % < Retransm_rate < 30 % then Leak rate = 0.8 * Leak Rateif 30 % < Retransm_rate < 40 % then Leak rate = 0.7 * Leak Rateif 40 % < Retransm_rate < 50 % then Leak rate = 0.6 * Leak Rateif 50 % < Retransm_rate < 60 % then Leak rate = 0.5 * Leak Rateif 60 % < Retransm_rate < 70 % then Leak rate = 0.4 * Leak Rateif 70 % < Retransm_rate < 80 % then Leak rate = 0.3 * Leak Rateif 80 % < Retransm_rate < 90 % then Leak rate = 0.2 * Leak Rateif 90 % < Retransm_rate < 100 % then Leak rate = 0.1 * Leak Rate

f = 1/((nGPRS_TS +1) * TF1 * i)where:

MS Bucket Leak Rate = RmaxMS

BmaxBasicBVC= f*(1s + TF1) * RmaxBVC

A30808-X3247-L24-5-7618 169

InformationSystem


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 isreached when in the previous interval the number of bytes related to expired LLC ismore than 10% of LLC bytes sent for all BVC;

• nGPRS_TS is the number of timeslots assigned for GPRS/EGPRS services at timerexpiration;

• RmaxBVC depends on the number of timeslots that can be assigned toGPRS/EGPRS, and on the data rate on these timeslots, basing on initial CS or initialMCS (see 10.5.3) or in case Link Adaptation is enable on the maximum CS or MCS;it is defined as:

Besides, the following definitions are necessary:

f = 1 if no large amount of LLC lifetime expiration occurs;f =1/ ((nGPRS_TS +1) * TF1 * i) otherwise.

where:

K = NPCCH + KEDGE + KGPRS

NPCCH: is the number of configured packet control channels;

KEDGE: maximum number of channels (configured, unlocked andenabled) can be assigned to EDGE after applying GPDPDTCHAparameter.

KGPRS: maximum number of channels (configured, unlocked andenabled) can be assigned to GPRS (but not to EGPRS) afterapplying GPDPDTCHA parameter. In this number timeslotsbelonging to EDGE capable TRXs are not considered (they arecounted in the KEDGE value).

Ndinamic: maximum number of channels (configured, unlocked and enabled)can be theoretically used to either PS services or CS services in thecell;

NdinamicEDGE: maximum number of channels (configured, unlocked and enabled)can be theoretically used for EGPRS service on EDGE capableTRXs.The number refers to timeslots without applying GPDPDTCHAparameter.

NdinamicGPRS: maximum number of channels (configured, unlocked and enabled)can be theoretically used for GPRS service on GPRS capableTRXs.The number refers to timeslots without applying GPDPDTCHAparameter.

RmaxBVC RTSk

k 1=

K

∑ RTSk RTSk RTSk

k 1=

KGPRS

∑+k 1=

KEDGE

∑+k 1=

NPCCH

∑= =

170 A30808-X3247-L24-5-7618


To understand previous definitions let us suppose that a cell (BVC) has the configurationshown in Fig. 7.20.

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 toNreserved, 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 - NdinamicEDGEKEDGE = K_EG + Nreserved - KGPRSotherwiseKGPRS = 0KEDGE = K_EG + Nreserved

Example 1

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. Thenumber refers to timeslots after applying GPDPDTCHA parameter.

TDMA frame

BCCH

0 7

GPRS

TDMA frame

0 7

EGPRS

TRX 0

TRX 1

0 7

EGPRSTRX 2

TDMA frame

SDCCH PBCCH

SDCCH

SDCCH

Capable

Capable

Capable

GMAPERTCHRES=4GPDPDTCHA=50%Configured Packet Control Channels=1

A30808-X3247-L24-5-7618 171

InformationSystem


Configuration as in Fig. 7.20, if all channels are enabled/unlocked (GPDP-DTCHA=50%).

NPCCH = 1Ndinamic =19NdinamicEDGE =7NdinamicGPRS =12Nreserved =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 2The TRX1 becomes disabled (GPDPDTCHA=50%).

NPCCH = 1Ndinamic =12NdinamicEDGE =7NdinamicGPRS = 5Nreserved =4

K_EG = 0.5 *(12-4)=0.5*(8)=4KGPRS = K_EG + Nreserved - NdinamicEDGE = 4 + 4 - 7 = 1KEDGE = K_EG + Nreserved - KGPRS = 4 + 4 - 1 = 7

K = 1 + 4 + 4 = 9

Also in case of BVC flow control, two new parameters have been introduced BVCB-MAPER (BvcBucketMaxPercentage) and BVCBSPPER (BvcBucketSizePcuPer-centage). Through them the operator can modify the values automatically computed bythe BSC. The new parameters are defined in the following way:

The states “congested” and “non-congested” are determined using the two thresholdsBhighBVC and BlowBVC of the BmaxPCUBVC.

Two parameters allow the operator to express them as a function of BmaxPCUBVC:

BVCBHIPER (BvcBucketHighPercentage) and BVCBLPER (BvcBucketLowPer-centage). These new parameters are contained in the following formulas:

BmaxBVC = BVCBMAPER * [(1+TF1) * RmaxBVC ]BmaxPCUBVC = BVCBSPPER *BmaxBVC.

172 A30808-X3247-L24-5-7618


If the state is “non-congested”, and BucketLevelPCU BVC (the current bucket level inPCU) crosses BhighBVC from below, the state is set to “congested”.

If the state is “congested”, and BucketLevelPCU BVC crosses BlowBVC from above, thestate is set to “non-congested”.

For what concerns the BVC Bucket Full Ratio, the same criteria as in section 7.3.3.1 areapplied.

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 orderto reduce the number of FLOW-CONTROL messages sent, they will be sent only when:– Bmax or R is changed compared to the previous parameter sent, i.e., 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 isassumed in order to prevent possible misalignment between Bucket at SGSN sideand at BSC side; it is possible that bucket in BSC is more or less zero and completelyfull at SGSN side due to SW error whatever.

If SGSN does not answer to BVC FLOW control, the PTPPKF object is put disable andBVC RESET procedure starts.If SGSN does not answer to MS Flow Control, BSC stops sending FLOW_CONTROLmessages for that TBF.Fig. 7.21 and Fig. 7.22 show the message flow related to MS-Control Flow for twodifferent cases: the normal case and the case in which the SGSN does not answer.

BhighBVC = BVCBHIPER * BmaxPCUBVC

BlowBVC = BVCBLPER * BmaxPCUBVC

A30808-X3247-L24-5-7618 173

InformationSystem


Fig. 7.21 MS-FLOW-CONTROL

Fig. 7.22 SGSN does not answer with MS-FLOW-CONTROL-ACK message

174 A30808-X3247-L24-5-7618


It must be noted that in case redundant NSVC links are created on the Gb-interface, thefollowing rule must be obeyed to avoid unnecessary GPRS/EGPRS blocking for certaincells (see "7.2.1.3 Procedures for PVCs"): if NS-ALIVE-ACK is not received because oflink problems, the respective NSVC is put into disabled state after a maximum timedefined by:

The PTPPKF object is put into disabled state if FLOW-CONTROL-ACK is not receivedduring the time defined by:

In case of link problems it could therefore happen that the PTPPKF object is disabledwhile the NSVC is still enabled. To avoid this situation, the following rule has to befollowed:

The default value of "Number of Flow Control Retries" is fixed to the value 15. The ruleis therefore fulfilled with the database default values for the following parameters:– TNSVCTST;– TNSVCPTST;– NNSVCTSTR;– TF1.

Time_1= TNSVCTST+ TNSVCPTST * NNSVCTSTR

Time_2 = TF1* Number of Flow Control Retries

Time_2 > Time_1

A30808-X3247-L24-5-7618 175

InformationSystem


8 Load Control for Packet Switched ServicesAs described in "6.1.4 PPCU and PPXU Redundancy and Configuration Rules", whenthe user configures a GPRS/EGPRS cell, i.e., when the user creates a PTPPKF objectinstance, he does not have to assign the cell to a specific PCU, but it is the system thatdynamically assigns the cell to one of the PCUs. This is a direct consequence of the loadbalancing redundancy.

When one PCU fails (e.g., when a PPXU fails in cases of high capacity BSCs, or whena couple of PPCUs fail in cases of standard BSCs), the system redistributes the PStraffic among the remaining PCUs.

In the BSC, there is a load control system that manages the PTPPKFs distributionamong the PCUs available in the system.

This kind of calculation is established taking into account the number of created andavailable PCUs, and the number of PTPPKF already associated to each PCU.

In case one PCU becomes unavailable for any reason, all PTPPKFs belonging to thatPCU are moved to other PCUs; the algorithm evaluates new PTPPKFs distributionconsidering the number of PTPPKF already present on each PCU and the number ofresources reserved to packet switched services for each PTPPKF (see "8.1 DynamicPTPPKF Reconfiguration").

If one PCU becomes available the first time (i.e., after its creation), a new computationis started in order to distribute PTPPKFs configured in the system on all PCUs.

Besides, the PTPPKF distribution process implements a mechanism based on a Guardtimer, in order to avoid oscillation in case of fast PCU state changes (see "8.1.5 TimeNeeded to Execute PTPPKF Reconfiguration").

8.1 Dynamic PTPPKF ReconfigurationThe PTPPKFs distribution/redistribution algorithm is performed by the GPRS/EGPRSload control process implemented on TDPC board.

The PTPPKFs reconfiguration is performed in the following cases:• when the boards related to the PCU become unavailable; this situation could happen

when:– a PPXU board fails, in cases of high capacity BSCs;– a couple of PPCU boards fail (the couple PPCU:0/1 or the PPCU2/3), in cases of

standard BSC;– the PPXU or the couple of PPCUs is locked.

• the connection of the PCU towards the SGSN goes down, that means that the lastNSVC connection from the PCU to the SGSN is no longer available; this situationcould 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 becomesunavailable);

– the PCMA line containing the last available FRL (if the last available FRL iscreated on it) is locked or goes down (as a consequence, the last NSVC becomesunavailable);

iIn order to enable the movement of one PTPPKF from one PCU to another, all PCUsmust contain the same database as far as the PTPPKF configuration is concerned.

176 A30808-X3247-L24-5-7618


– the last FRL is locked or goes down, and as a consequence, the last NSVC isdisabled;

– the last NSVC is locked or goes down;– the PCU is locked;

• the connection of the PCU towards the SGSN comes back, that means that the lastNSVC connection from the PCU to the SGSN is now available.

• a PTPPKF is deleted, but only if this operation causes an unbalanced distribution ofPTPPKFs among the PCUs.

It must be noted that:

1. the PTPPKF creation is not included as a trigger for PTPPKFs reconfiguration (whena 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 (i.e. whenthe connection on the Gb interface is available);

3. the PCU overload (see "8.2 PCU Overload Management") does not trigger thePTPPKF 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 "7 Gb

Interface").

If we define:

iIn general, the PTPPKFs reconfiguration is triggered from all the operationsthat generate a PCU/Gb down-restart.So the previous causes can be summarized with these sentences: “any timethe Gb interface related to any PCU is no longer available, the reallocation istriggered” or “when a PCU <<can not see>> the SGSN, the PTPPKF allocatedto that PCU should be moved to another PCU that can <<see>> the SGSN“.

PCU_TS_Gb Number of timeslots of 64 kbit/s related to the FR links associ-ated to a specific PCU

PTPPKF_load(i) Number of GPRS/EGPRS channels (static and dynamic)configured for a specific PTPPKF(i)

Then the load of a single PCU can be considered as the sum of the PTPPKF_load ofall the PTPPKF associated to the PCU divided by the PCU_TS_Gb of the PCU (that ishow the FR links associated to the PCU can manage all the radio channels associatedto the PCU); so:

A30808-X3247-L24-5-7618 177

InformationSystem


Then the algorithm tries to distribute the packet switched traffic among the configuredand 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 TBFsassociated with that PTPPKF. To avoid, as much as possible, this situation, the set ofPTPPKF is divided in 3 sub sets (the three sets are considered by the general algorithmthat calculates and moves PTPPKFs from one PCU to another one):• PTPPKF_DIED: this set contains PTPPKFs belonging to PCUs without the Gb in

service that have to be moved to PCUs in service; this set is taken into account assoon as the algorithm runs after the PCU/Gb fault;

• PTPPKF_KO: it includes PTPPKFs that are not carrying traffic because they aredisabled or have been locked; this set is first analyzed for a possible moving ofPTPPKFs, when a new PCU goes into service.

• PTPPKF_ENABLE: it includes all the other PTPPKFs, that are considered forpossible moving; this set is the second analyzed for possible moving of PTPPKFs,when a new PCU goes into service. The set is considered after the previous set (i.e.PTPPKF_KO) has become void.

According to different situations, different handling is provided even if the general rule isalways to redistribute the traffic in the better way.The following examples are shown:– System initialization (Bring-Up and Full Init), see 8.1.1;– Creation of a new PCU object (new PPXU board, or new PPCU couple of boards),

see 8.1.2;– PCU crash (see 8.1.3);– PCU comes back in service (see 8.1.4).

8.1.1 System InitializationWhen the system is initialized, BVCI synchronization is performed, between the BSCand the SGSN, using the BVC RESET procedure (see "7.3.1.1 BVC Procedures"). Thenthe distribution algorithm (see Fig. 8.1) distributes the configured PTPPKFs among theconfigured and available PCUs; the algorithm takes into account, besides the PCUloads, the Routing Area of the PTPPKFs (regarding routing areas, see "9.2 NetworkStructure").

In fact, to reduce the paging load, (if the SGSN is intuitive enough) the algorithm tries, ifpossible, to associate a Routing area to just one PCU.

These constraints could collide with the balancing of the PCU loads. In this case, theconstraint related to the loads of the PCUs has an higher priority.

PCU_load = (Sum PTPPKF_load(i) [i=1..n]) / PCU_TS_Gbwhere n is the number of PTPPKFs associated to the PCU

iThe algorithm considers the Routing Areas only at init time.

178 A30808-X3247-L24-5-7618


Fig. 8.1 Example of PTPPKF Distribution During System Initialization

8.1.2 Creation of a PCU Object and Enabling a NSVC for ItWhen a new PCU is created and the first NSVC is created and enabled, the algorithmredistributes the already configured PTPPKFs among the available PCUs, taking intoaccount the new one.

On the Gb interface, the BVC BLOCK procedure (see 7.3.1.1) is performed on thePTPPKFs to be moved, before moving them (see Fig. 8.2).

Then, when the cells are shifted to the new PCU, the BVC RESET and UNBLOCKprocedures (see 7.3.1.1) are performed for the same cells (see Fig. 8.3).

In the Siemens-BSS implementation, neither the Cell Identifier nor the BVCI of themoved cells change.

PTPPKFRA=21 PDCHBVC=4





PCU:0NSEI:0PCU_load=9/3=3




SGSN

PCU_TS_Gb= 3

PCU_TS_Gb= 1

A30808-X3247-L24-5-7618 179

InformationSystem


Fig. 8.2 Example of PTPPKF Distribution when a New PCU is Created - Step 1






PCU:0NSEI:0old_PCU_load=9/3=3


SGSN

PCU_TS_Gb= 3

PCU_TS_Gb= 2




PCU_TS_Gb= 1

New PCU is created

new_PCU_load=6/3=2

new_PCU_load=2/1=2

BSSGP:BVC_BLOCK_34

BSSGP:BVC_BLOCK_ACK_34

BSSGP:BVC_BLOCK_77


180 A30808-X3247-L24-5-7618


Fig. 8.3 Example of PTPPKF Distribution when a New PCU is Created - Step 2







SGSN

PCU_TS_Gb= 3

PCU_TS_Gb= 2




PCU_TS_Gb= 1

BSSGP:BVC_RESET_34:Cell Identifier

BSSGP:BVC_RESET_ACK_34

BSSGP:BVC_UNBLOCK_34

BSSGP:BVC_UNBLOCK_ACK_34






A30808-X3247-L24-5-7618 181

InformationSystem


8.1.3 PCU CrashWhen a PCU crashes, the algorithm redistributes the configured PTPPKFs among theremaining PCUs.

Since the PCU is crashed, it is not possible to perform the BVC BLOCK procedure onthe damaged PCU (in any case the SGSN can detect this anomaly because the L2 layeris nolonger working).

The PTPPKFs are moved onto healthy PCUs, and then a BVC RESET procedure isstarted for each shifted PTPPKF object (see Fig. 8.4).

The routing area information is not considered by the algorithm, to save the time of theelaboration.

Fig. 8.4 Example of PTPPKF Distribution in Case of PCU Crash






PCU:2NSEI:2FAILED

SGSN

PCU_TS_Gb= 3

PCU_TS_Gb= 2




PCU_TS_Gb= 1

new_PCU_load=3/1=3









PCU:0NSEI:0old_PCU_load=6/3=2new_PCU_load=9/3=3



NO block procedureson Gb interface.The PCU fails suddenly

182 A30808-X3247-L24-5-7618


8.1.4 PCU Comes Back in ServiceWhen the PCU comes back in service, the PTPPKFs related to this PCU, before thefault, are put back on it (see 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 comesback in service after a fault, but the PTPPKFs belonging to this PCU will be put back onit.

Eventually, the PTPPKFs that belonged to the other faulty PCUs are involved in thisreallocation 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 thefirst time (i.e. it was created), then the algorithm performs a total reconfiguration;

2. if some modifications regarding the FRLs allocation of the PCU has been doneduring the period of time the PCU/Gb was down, then the algorithm performs a totalreconfiguration.

In fact there is a difference between putting back PTPPKFs to the PCU they belongedbefore and a total redistribution itself.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 dueto the need of managing short downs of Gb or PCU: it makes no sense to redistributeeverything again and again simply because, for example, a PCM line (containing the lastFRL of a PCU) is not stable.

A30808-X3247-L24-5-7618 183

InformationSystem


Fig. 8.5 Example of PTPPKF Distribution when a PCU Comes Back in Service






PCU:2NSEI:2IN-SERVICE

SGSN

PCU_TS_Gb= 3

PCU_TS_Gb= 2












PCU:0NSEI:0old_PCU_load=9/3=3new_PCU_load=6/3=2

new_PCU_load=2/1=2



BSSGP:BVC_BLOCK_77


BSSGP:BVC_BLOCK_34


184 A30808-X3247-L24-5-7618


8.1.5 Time Needed to Execute PTPPKF ReconfigurationFor what concerns the PTPPKFs distribution/redistribution algorithm, to avoid oscillationin cases of fast PCU changes, a mechanism based on a Guard Timer is provided.

This timer lasts 5 seconds and it starts each time there is a modification in Gb/PCUstatus. When the timer runs no calculations are executed to redistribute GPRS/EGPRScells (even if there are some changes in Gb/PCU status).

Obviously, this timer does not regard newly created PTPPKFs, because in this casethere is not a balancing procedure, but the created PTPPKF is simply put on the lessloaded PCU available in that moment.

In any case, the calculation algorithm is always executed in a few milliseconds, apartfromsome 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 during normal TDPC working. Thus they are done only atinit phase (see "8.1.1 System Initialization").

The redistribution procedure takes, in general, some seconds. The worst case concernsthe moving of a PTPPKF from one PCU to another one: the PTPPKF needs to beblocked and internally deleted on the old PCU, then created and unblocked on the newone. This process takes about 7 seconds in total. This time, added to the 5 seconds ofthe guard timer, makes a total of 12 seconds that are needed to redistributes PTPPKFsto a PCU going into service.

This time is more or less independent from the number of involved PTPPKFs being donein burst parallel on the various PTPPKFs. There are no significant differences betweenthe handling of PPCU and PPXU boards.

8.2 PCU Overload ManagementFor what concerns the PTPPKFs distribution/redistribution algorithm, no reconfigurationis foreseen due to Overload reasons, since as it has been described in 8.1, the only trig-gers are Down/Restart of PCU/Gb.

The overload prevention mechanism is based on the real time of the card.

The PCU overload management alarm is started when PCU processor real timeexceeds a threshold. The operating system measures the PCU processor real time. APCU 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 indicatingthat the machine is overloaded to the GPRS/EGPRS overload handler process.

The cyclic task stops the overload message sending to the GPRS/EGPRS overloadhandler 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 andBTS overload handlers.At the very first signal of PCU Overload, an alarm is emitted towards the LMT/RC. Theoverload process is controlled by BSCT17 and BSCT18 timers and it is based upon theprogressive 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 PSservice traffic, is based upon the sending of System Information indicating thatGPRS/EGPRS services are not present in the cell. This is done for a progressively

A30808-X3247-L24-5-7618 185

InformationSystem


increasing number of cells (at steps of 10 cells) allocated on the involved PCU, if theoverload situation persists.

On the contrary, if the overload finishes, System Information indicating thatGPRS/EGPRS service is present again are sent; this is done in steps of 5 cells that wereformerly "GPRS/EGPRS barred". When all cells are in the original situation, the PCUoverload alarm is ceased.

186 A30808-X3247-L24-5-7618


9 GPRS/EGPRS Procedures

9.1 Mobile Stations for Packet Switched ServicesA GPRS/EGPRS MS can operate in one of three modes of operation. The mode of oper-ation depends on:– the services that the MS is attached to, i.e., only PS services or both PS and CS

services;– the MS capabilities to operate GPRS/EGPRS and other GSM services simulta-

neously.

The three modes of operation are:• Class-A mode of operation: the MS is attached to both GPRS/EGPRS and other

GSM services, and the MS supports simultaneous operation of GPRS/EGPRS andother GSM services;

• Class-B mode of operation: the MS is attached to both GPRS/EGPRS and otherGSM services, but the MS can only operate one set of services at a time. In networkoperation mode III (see "9.8.3.1 Network Operation Modes for Paging"), a MS thatis capable of monitoring only one paging channel at a time cannot operate in classB mode of operation. In this case, such a MS reverts to class-C mode of operation.

• Class-C mode of operation: the MS is exclusively attached to GPRS/EGPRSservices.

For what concerns EGPRS mobiles only, a supplementary distinction exists. Two mobileclasses are foreseen:– the first class of mobiles, which allows a cost efficient and fast implementation,

supports the 8PSK modulation in downlink direction and the GMSK modulation inuplink direction;

– the second class of mobiles has a more advanced capability, supporting the 8PSKmodulation in both uplink and downlink directions.

9.2 Network StructureOn the air interface, the network organization structure remains the same as in the GSMimplementation. An additional identifier is introduced to group cells that support packetswitched 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 theGPRS/EGPRS mobile station; one LA can include up to 256 RAs.

Routing Area numbering is not unique in the network, but it is unique in the LocationArea domain; to identify a Routing Area two parameters 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 differentLocation Areas.

Fig. 9.1 shows an example of network structure.

A30808-X3247-L24-5-7618 187

InformationSystem


Fig. 9.1 Network Structure: Example

9.3 Mobility Management Functionalities

9.3.1 Mobility Management StatesThe Mobility Management (MM) activities related to a GPRS/EGPRS subscriber arecharacterized by one of three different MM states (see Fig. 9.2). Each state describesa certain level of functionality and allocated information. The information, which is heldon both MS and SGSN sides, is denoted MM context.

Location Area

Routing Area

188 A30808-X3247-L24-5-7618


Fig. 9.2 Mobility Management States

9.3.1.1 IDLE StateIn GPRS IDLE state the subscriber is not attached to the GPRS/EGPRS mobilitymanagement. Both the MS and the SGSN contexts hold no valid location or routinginformation for the subscriber. The subscriber-related mobility management proceduresare not performed.

PLMN selection and GPRS/EGPRS cell selection and re-selection processes (see 10.1)are performed by the MS.

In order to establish MM contexts in the MS and in the SGSN, the MS will perform theGPRS Attach procedure (see "9.3.2.1 Attach Function").

When the GPRS attach procedure has been executed, the MM state moves from IDLEto READY: the MS requests access and a logical link to an SGSN is established.

9.3.1.2 STAND-BY StateIn STANDBY state the subscriber is attached to GPRS/EGPRS mobility management.The MS and the SGSN have established MM contexts for the subscriber.

Pages for PTP data transfers or signaling information transfers may be received. It isalso possible to receive pages for CS services via the SGSN (only if the Gs interfacebetween the MSC and the SGSN is implemented). PTP data reception and transmissionare not possible in stand-by state.

The MS performs Routing Area updates and GPRS/EGPRS cell selection and re-selec-tion locally. The MS executes mobility management procedures to inform the SGSNwhen it has entered a new RA. The MS does not inform the SGSN on a change of cell

A30808-X3247-L24-5-7618 189

InformationSystem


in the same RA. Therefore, for MSs in STANDBY state, the location information in theSGSN MM context contains only the routing area identity (RAI).

The MS may initiate activation or deactivation of PDP contexts while it is in STANDBYstate. A PDP context must be activated before data can be transmitted or received forthis PDP context.

The SGSN may have to send data or signalling information to a MS in STANDBY state;in this case the SGSN sends a Paging Request in the routing area where the MS islocated. The MM state in the MS changes to READY when the MS responds to the page,and in the SGSN when the response to paging is received. The MM state in the MS alsochanges to READY when data or signaling information is sent from the MS and the MMstate in the SGSN changes to READY when data or signalling information is receivedfrom the MS.

The MS or the network may initiate the GPRS Detach procedure to move to the IDLEstate. After expiry of the mobile reachable timer, the SGSN may perform an implicitdetach in order to return the MM contexts in the SGSN to IDLE state. The MM and PDPcontexts may then be deleted.

In particular, the following procedures cause the transition from the standby state to theother 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 MS.

9.3.1.3 READY StateIn READY state the MM context corresponds to the STANDBY MM context extended bylocation information for the subscriber on the cell level. The MS performs mobilitymanagement procedures to provide the network with the actual selected cell.GPRS/EGPRS cell selection and re-selection is done locally by the MS, or optionallymay be controlled by the network (see "10.3 Network Controlled Cell Reselection andTraffic Control Management").

The MS may send and receive PDP PDUs in this state. The network does not initiate PSpages for a MS in READY state; pages for other services may be done via the SGSN.The MS may activate or deactivate PDP contexts while in READY state. The READYstate is supervised by a timer. A MM context moves from READY state to STANDBYstate when the READY timer expires.

iThe Routing Area Identity is defined as:RAI = MCC + MNC + LAC + RACwhere:- MCC = mobile country code- MNC = mobile network code- LAC = location area code- RAC = routing area code

190 A30808-X3247-L24-5-7618


In order to move from READY state to IDLE state, the MS initiates the GPRS Detachprocedure.

The following procedures cause the transition from the ready state to the other MMstates:• moving from READY to STANDBY:

– READY timer expiry (see " READY TIMER"): the MS and the SGSN MM contextsreturn to STANDBY state;

– Force to STANDBY: the SGSN indicates an immediate return to STANDBY statebefore the READY timer expires;

– abnormal RLC condition: the SGSN MM context returns to STANDBY state incase 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 deletethe MM and PDP contexts. The PDP contexts in the GGSN are deleted.

– Cancel Location: the SGSN receives a Cancel Location message from the HLRand removes the MM and PDP contexts.

READY TIMER

The READY timer controls the time that a MS remains in READY state before going tothe STANDY state. In the MS the READY timer is reset and begins running when a LLCPDU is transmitted; in the SGSN the timer begins running when a LLC PDU is correctlyreceived. When the READY timer expires, both the MS and SGSN MM contexts returnto STANDBY state. The length of the READY timer is the same in the MS and in theSGSN. If the READY timer length is set to zero, the MS is immediately forced intoSTANDBY state.

9.3.2 Mobility Management ProceduresMM procedures use the LLC and RLC/MAC protocols for message transmission acrossthe Um interface. The MM procedures provide information to the underlying layers toenable reliable transmission of MM messages on the Um interface. User data can betransmitted during MM signalling procedures.

User data transmitted during attach, authentication, and routing area update proceduresmay be lost and therefore may have to be retransmitted. In order to minimize the needfor retransmission, the MS and the SGSN do not transmit user data during the attach,authentication, and routing area update procedures.

9.3.2.1 Attach FunctionThe GPRS/EGPRS attach procedure is executed by the MS. In the attach procedure,the MS provides its identity and an indication of which type of attach it wants to execute.

Two different types of attach are foreseen (both of them executed towards the SGSN):– the GPRS attach;– the combined GPRS/IMSI attach.

The combined attach allows the MS to register itself both in the SGSN and in the MSC,but this procedure can be executed only when the network works in a co-ordinated way,

A30808-X3247-L24-5-7618 191

InformationSystem


i.e., only when the Gs interface between the MSC and the SGSN is configured (see also"9.8.3.1 Network Operation Modes for Paging").

After having executed the GPRS attach procedure, the MS is in READY state and MMcontexts are established in both the MS and the SGSN. The MS may then activate PDPcontexts as described in "9.7 Activation and Deactivation of a PDP Context".

An IMSI-attached MS that can only operate in class-C mode of operation follows thenormal IMSI detach procedure before making a GPRS attach. A GPRS-attached MS inclass-C mode of operation will always perform a GPRS detach before making an IMSIattach.

The steps of the Attach procedure are illustrated below:

1. The MS initiates the attach procedure by the transmission of the Attach Requestmessage 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 areincluded;

– Classmark: it contains the MS's multislot capabilities and supported cipheringalgorithms for PS services;

– Attach Type: it indicates which type of attach that must be performed, i.e.,GPRS/EGPRS attach only, GPRS/EGPRS Attach while already IMSI attached, orcombined (E)GPRS/IMSI attach;

– DRX Parameters: indicate when the MS is in a non-sleep mode and when it isable to receive paging requests and channel assignments (see"9.8.3.2 Discontinuous Reception").

2. The SGSN sends the Attach Accept message to the MS; P-TMSI is included if theSGSN allocates a new P-TMSI;

3. If P-TMSI has been changed, the MS acknowledges the received P-TMSI by theAttach Complete message.

iIf the network operates in Mode I (see "9.8.3.1 Network Operation Modes for Paging"),then a MS that is both GPRS/EGPRS-attached and IMSI-attached performs thecombined RA/LA update procedure.If the network operates in Mode II or III, then a GPRS/EGPRS-attached MS, that hasthe capability to be simultaneously GPRS/EGPRS attached and IMSI-attached,performs the (not-combined) Routing Area Update procedure, and accesses the CCCHchannel for CS operation.

iP-TMSI (Packet Temporary Mobile Subscriber Identity) is optionally sent by the SGSNto the MS in Attach Accept and Routing Area Update Accept messages. If the P-TMSIsignature 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 nextRouting Area Update Request or in the next Attach Request for identification checkingpurposes. In both the Attach and Routing Area Update procedures, the SGSNcompares 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 authenticatethe MS. The P-TMSI signature parameter has only local significance in the SGSN thatallocated the signature.P-TMSI is similar the GSM T-IMSI (temporary IMSI).

192 A30808-X3247-L24-5-7618


If the Attach Request cannot be accepted, the SGSN returns the Attach Rejectmessage to the MS. The message contains the cause that has generated the rejection.

A GPRS/EGPRS-attached MS makes IMSI attach via the SGSN with the combinedRA/LA update procedure if the network operation mode is I. In network operation modesII and III, or if the MS is not GPRS/EGPRS-attached, the MS makes IMSI attach asdefined in GSM.

9.3.2.2 Detach FunctionThe Detach function allows a MS to inform the network that it wants to make aGPRS/EGPRS and/or IMSI detach, and allows the network to inform a MS that it hasbeen GPRS/EGPRS-detached or IMSI-detached by the network.

A GPRS/EGPRS-attached MS sends a Detach Request message to the SGSN, indi-cating a GPRS/EGPRS detach.

The Detach Request message contains an indication to determine if the detach is dueto switch off or not. The indication is needed to determine whether or not a DetachAccept message will be returned.

9.4 Radio Resource ManagementRadio Resource (RR) management procedures are characterized by two different RRoperating modes (see Fig. 9.3). Each mode describes a certain amount of functional-ities and information allocated.

Fig. 9.3 Radio Resource States

9.4.1 Packet Idle StateIn packet idle mode no Temporary Block Flows exist (see "4.3 Temporary Block Flow").Upper layers can require the transfer of LLC PDUs which, implicitly, may trigger theestablishment of a TBF and the transition to packet transfer mode (see Fig. 9.3).

In packet idle mode the MS listens to the PBCCH and to the paging sub-channel for thepaging group to which the MS belongs. If the PCCCH is not present in the cell, themobile station listens to the BCCH and to the relevant paging sub-channels.

Packet Idle State - No RLC context inMS & SGSN

Packet Transfer - RLC context in MS & SGSN

State - Routing context betweenMS & SGSN

- Mobile originatedcall

- Answer to paging- Deactivation of RLC context

A30808-X3247-L24-5-7618 193

InformationSystem


9.4.2 Packet Transfer StateIn packet transfer mode, the mobile station uses the allocated radio resources totransmit radio blocks. Continuous transfer of one or more LLC PDUs is possible.Concurrent TBFs may be established in opposite directions. Transfer of LLC PDUs ineither RLC acknowledged or RLC unacknowledged mode is provided.

When selecting a new cell, a mobile station:

1. leaves the packet transfer mode2. enters the packet idle mode3. switches to the new cell4. reads the system information of the new cell5. resumes the packet transfer mode in the new cell.

While operating in packet transfer mode, a mobile station belonging to GPRS/EGPRSclass A may simultaneously enter the CS dedicated (connected) mode. A mobile stationbelonging to GPRS/EGPRS class B leaves the packet transfer modes before enteringthe CS dedicated mode.

9.5 Correspondence between RR States and MM StatesTab. 9.1 provides the correspondence between Radio Resource states and MobilityManagement states.

9.6 Packet Data Protocol FunctionalitiesThe subscription of a point to point PS service contains one or more PDP addresses.Each PDP address is described by an individual PDP context in the MS, in the SGSN,and in the GGSN.

Every PDP context exists independently in one of two PDP states. The PDP state indi-cates whether or not the PDP address is activated for data transfer. Activation and deac-tivation procedures are described in section 9.7. All PDP contexts of a subscriber areassociated with the same MM context for the IMSI of that subscriber.

MM States READY STAND-BY

RR States Packet Transferstate

Packet Idle state Packet Idle state

Tab. 9.1 Correspondence between MM States and RR States

194 A30808-X3247-L24-5-7618


Fig. 9.4 Packet Data Protocol States

9.6.1 INACTIVE StateThe INACTIVE state characterizes the data service for a certain PDP address of thesubscriber as not activated. The PDP context contains no routing or mapping informa-tion to process PDUs related to that PDP address. No data can be transferred.

A changing location of a subscriber causes no update for the PDP context in INACTIVEstate even if the subscriber is attached to the PS MM.

If the GGSN is allowed to initiate the activation of the PDP context for that PDP address,mobile-terminated PTP packets, received in INACTIVE state by the GGSN, may initiatethe 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 may be introduced onthe application level, but this is outside of the scope of the current document.

The MS initiates the transition from the INACTIVE state to the ACTIVE state by initiatingthe PDP Context Activation procedure (see "9.7.1 PDP Context Activation").

9.6.2 ACTIVE StateIn ACTIVE state, the PDP context for a specific PDP address is activated in the MS, inthe SGSN and in the GGSN. The PDP context contains mapping and routing informationfor transferring PDUs (for that particular PDP address) between the MS and the GGSN.The ACTIVE PDP state is permitted only when the mobility management state of thesubscriber is STANDBY or READY.

A30808-X3247-L24-5-7618 195

InformationSystem


An active PDP context for a MS is moved to the INACTIVE state when the deactivationprocedure is initiated. All active PDP contexts for a MS are moved to the INACTIVE statewhen the MM state changes to IDLE.

9.7 Activation and Deactivation of a PDP ContextThese functions are only meaningful at the NSS level and in the MS, and do not directlyinvolve the BSS. A MS in STANDBY or READY state can initiate these functions at anytime to activate or deactivate a PDP context in the MS, in the SGSN, and in the GGSN.

Upon receiving an Activate PDP Context Request message, the SGSN initiates proce-dures to set up PDP contexts.

Upon receiving a Deactivate PDP Context Request message, the SGSN initiates proce-dures to deactivate PDP contexts.

9.7.1 PDP Context ActivationThe PDP context activation procedure is used by the mobile station to obtain an IPaddress from the network, and to negotiate service parameters such as delay class(average and peak) and throughput (average and peak). Currently the network foreseesonly the ‘best effort’ quality of service, giving the available resources to the MS, withouttaking into account any mobile request.

In the following, the PDP Context Activation procedure is described:

1. In order to activate a PDP context, the mobile station sends a CHANNEL REQUESTmessage to the network. The network, after having reserved a channel on the BTS,sends an IMMEDIATE ASSIGNMENT message carrying the PACKET UPLINKASSIGNMENT information element. This message reserves an uplink resource (atime slot, with TFI and USF) to the mobile station, allowing it to transmit the ACTI-VATE PDP CONTEXT REQUEST;

2. The MS sends the ACTIVATE PDP CONTEXT REQUEST message to the SGSN.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 MSwill leave the PDP Address empty to request a dynamic PDP address;

– Access Point Name: it is a logical name referring to the external packet datanetwork 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 ACTIVATE PDP CONTEXT REQUEST using PDP Type,

PDP Address, and Access Point Name provided by the MS and the PDP contextsubscription records;

5. The SGSN sends a CREATE PDP CONTEXT REQUEST (PDP Type, PDP Address,Access Point Name, Negotiated QoS) message to the affected GGSN;

6. The GGSN uses the Access Point Name to find an external network. The GGSNcreates a new entry in its PDP context table and generates a Charging ID. The newentry allows the GGSN to route PDP PDUs between the SGSN and the externalPDP network, and to start charging;

7. The GGSN then returns a CREATE PDP CONTEXT RESPONSE message to theSGSN. PDP Address is included if the GGSN has allocated a PDP address;

196 A30808-X3247-L24-5-7618


8. The SGSN selects the Radio Priority based on the Negotiated QoS, and returns theACTIVATE PDP CONTEXT ACCEPT message to the MS.

9.7.2 PDP Context DeactivationThe 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 CONTEXTRESPONSE message to the SGSN. If the MS used a dynamic PDP address, thenthe 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.

9.8 Access to the Network (Establishment of a TBF)The establishment of a Temporary Block Flow (TBF) is initiated to transfer LLC PDUsbetween 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 exists:– TBF establishment initiated by the MS, i.e., a MS initiated packet transfer (see 9.8.2)– TBF establishment initiated by the network, i.e., a network initiated packet transfer

(see 9.8.3).

9.8.1 Medium Access ModesTwo types of access modes exist:

a) Dynamic Allocation: the assignment message includes the list of PDCHs and thecorresponding USF value for each assigned PDCH. A unique TFI is allocated and isthereafter included in each RLC Data and Control Block related to that TBF. Dynamicallocation is characterized by the MS that monitors the USF values on the allocatedPDCHs and transmits Radio blocks on those that currently bear the USF valuereserved for the usage of the MS;

iThe RLC/MAC layer supports four Radio Priority levels and an additional level for signal-ling messages as defined in GSM 04.60. Upon uplink access, the MS can indicate oneof the four priority levels, and whether the cause for the uplink access is user data orsignalling message transmission. This information is used by the BSS to determine theradio access precedence (i.e., access priority) and the service precedence (i.e., transferpriority under congested situation).The Radio Priority concept is related to the QoS one, i.e., a higher Quality of Servicecorresponds to a higher Radio Priority. The Radio Priority is coded as follows:- 0: Radio Priority 1 (Highest priority, used also for signalling)- 1: Radio Priority 2- 2: Radio Priority 3- 3: Radio Priority 4 (Lower priority)

iAt GPRS/EGPRS detach, all PDP contexts for the MS are implicitly deactivated.

A30808-X3247-L24-5-7618 197

InformationSystem


b) Fixed Allocation: it is characterized by fixed allocation of radio blocks and PDCHs inthe assignment message, without assigning USF values. In Release BR7.0 FixedAllocation is not supported.

9.8.2 TBF Establishment Initiated by the MS on CCCH/PCCCHThe purpose of the packet access procedure is to establish a TBF to support the transferof LLC PDUs in the direction from the mobile station to the network. Packet access isdone on the PCCCH if it exists, otherwise packet access is done on the CCCH.

The packet access procedure is initiated by the mobile station when a request to transferLLC PDUs comes from upper layers.

Two different access types exist:• one phase access: the network responds reserving resources on the PDCH(s) to

allow uplink packet transfer of a number of Radio Blocks;• two phase access: the network responds reserving resources for transmitting a

PACKET RESOURCE REQUEST message; this message is used by the MS tobetter define the needed radio resources.

In both cases, when the uplink TBF is set up, the following parameters and radioresources 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 mobilestation will use the continuous update timing advance mechanism, using PTCCH inthe same timeslot as the assigned PDCH (see 4.6). If a timing advance index (TAI)field is not included, the continuous update timing advance mechanism will not beused;

– MAC access mode (always set to dynamic in BR7.0, see "9.8.1 Medium AccessModes").

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 GPATH parameter indicates if the MS,according to its priority class, is authorized to perform a random access to requestpacket switched services.

9.8.2.1 8 Bit or 11 Bit Uplink AccessTo access the GSM network, a slotted-aloha protocol is used; the access is performedsending a traditional 8 bit Access Burst type.

iIn the following, messages that are exchanged either on the CCCH or PCCCH channelare shown using the following method: messages exchanged on CCCH are normallyused, whereas the corresponding PCCCH messages are inserted in brackets.

198 A30808-X3247-L24-5-7618


According to ETSI specifications, a new enhanced Access Burst type with 11 informa-tion bit can be sent by the mobile station to try to access the network. In fact, 8 bit ofinformation does not allow to widely specify the needed resources. To overcome thisbottleneck, an access burst using 11 information bit is defined. Fig. 9.5 shows thecoding process of the 11 bit access burst.

Therefore, a GPRS/EGPRS mobile station can access the network by using an 8 bit oran 11 bit access burst, in particular:• the CHANNEL REQUEST message sent on RACH is always formatted with 8 bit of

information;• the PACKET CHANNEL REQUEST sent on PRACH can be formatted either with 8

or 11 bit.The possibility of using one message type or the other one for the PACKETCHANNEL REQUEST depends on network settings: the capability of the network toreceive 8 or 11 bit length message is broadcast by the System Information param-eter ABUTYP, that indicates the allowed type of access.

The ABUTYP parameter 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;– in the PTCCH channel, for the continuous timing advance estimation (see 4.6).

The advantages of the 11 bit uplink access are the following:– it more often allows a one phase access instead of a two phases access;– it speeds up the call set-up and decreases the signalling load.

The 8 bit access on PRACH or RACH is used in case of PAGING RESPONSE, CELLUPDATE, MM PROCEDUREs and in all cases that the MS requires sending no moreinformation than the MS class and priority.

The 11 bit access on PRACH is used in all cases described for 8 bit access, but withadditional information to be carried in the access phase, e.g., an enhanced randomreference number leading to less probability of MS collision when trying to establish anuplink TBF.

Fig. 9.5 Coding of the 11 Bit Access Burst

iBesides, the 11 bit access burst is the only one supporting the EGPRS PACKETCHANNEL REQUEST message, that can be used from EDGE mobile stations to accessa cell, see "9.8.2.4 TBF Establishment for EDGE Mobile Stations".

Synchronization SequenceTail Information bit Tail Guard period

36 bit

Access Burst

11 information bit

6 parity bit

4 tail bit

+

+

1/2Convolutionalcoder

6 bitpuncturing

36 encryptedbit

halam

Highlight

halam

Highlight

A30808-X3247-L24-5-7618 199

InformationSystem


9.8.2.2 Establishment using a One Phase AccessA mobile station initiates the packet access procedure by scheduling the sending ofCHANNEL REQUEST (PACKET CHANNEL REQUEST) messages on the RACH(PRACH), and simultaneously leaving the packet idle mode.

Then, the mobile station monitors the full CCCH (PCCCH) corresponding to its RACH(PRACH) to wait for the network answer.

When the MS has sent the CHANNEL REQUEST (PACKET CHANNEL REQUEST)message, the following behaviors will occur, according to its class:– 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 switchedconnections;

– mobile stations in class C mode of operation will not respond to any type of pagingmessages during the packet access procedure.

CHANNEL REQUEST (PACKET CHANNEL REQUEST) messages are sent on theRACH (PRACH) and contain, beside the indication of the type of access, the requiredparameters to indicate the demand of radio resources from the MS.

When the network receives the CHANNEL REQUEST (PACKET CHANNELREQUEST) message, it may assign radio resources on one or more PDCHs, to be usedby the mobile station for the TBF.

The allocated PDTCH(s) and PACCH resources are assigned to the mobile station inthe IMMEDIATE ASSIGNMENT (PACKET UPLINK ASSIGNMENT) message, sent onany AGCH (PAGCH) block on the same CCCH (PCCCH) on which the network hasreceived the CHANNEL REQUEST (PACKET CHANNEL REQUEST) message.

In the one phase access, the reservation is done according to the information about therequested resources, comprised in the channel request.

On the RACH, 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 usedto request limited resources in the one phase access (EGPRS TBFs cannot be openedusing a one phase access on RACH, using the CHANNEL REQUEST message, see"9.8.2.4 TBF Establishment for EDGE Mobile Stations") or to request a two phaseaccess.

On the PRACH, the PACKET CHANNEL REQUEST may contain more adequate infor-mation about the requested resources and, consequently, uplink resources on one orseveral PDCHs can be assigned by using the PACKET UPLINK ASSIGNMENTmessage.

Fig. 9.6 shows a one phase access procedure on PCCCH.

iThe topics described in this chapter are valid for GPRS MSs and also for EDGE MSswhen the EGPRS PACKET CHANNEL REQUEST is not supported in the cell (see"9.8.2.4 TBF Establishment for EDGE Mobile Stations").

iIf the PCCCH is configured and the mobile station receives the PERSISTENCE_LEVELparameter from the network, the value of the PERSISTENCE_LEVEL parameter istaken into account at the next PACKET CHANNEL REQUEST attempt (see"9.8.2.6 Uplink Access on PRACH (Access Persistence Control)").

200 A30808-X3247-L24-5-7618


Fig. 9.6 One Phase Access on PCCCH

9.8.2.3 TBF Establishment using a Two Phases AccessIn the first phase of a two phase access, the same procedure as for one phase accessis used, until the network sends the IMMEDIATE ASSIGNMENT (PACKET UPLINKASSIGNMENT) 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 onePDCH to the mobile station, where the mobile station transmits a PACKET RESOURCEREQUEST message.

The two phase access can be initiated either by the MS or the network, following theserules:• 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 RESOURCEREQUEST message. The order is sent implicitly to the mobile station in thePACKET UPLINK ASSIGNMENT message by including the Single Block Alloca-tion structure;

– by a mobile station, by requiring a two phase access in the PACKET CHANNELREQUEST message. In this case, if access is granted, the network will order themobile station to send a PACKET RESOURCE REQUEST message. The orderis sent implicitly to the mobile station in the PACKET UPLINK ASSIGNMENTmessage by including the Single Block Allocation Structure.

A30808-X3247-L24-5-7618 201

InformationSystem


• if no PCCCH is provided in the cell, a two phase access can be only initiated by amobile station, by requiring this type of access within the CHANNEL REQUESTmessage.

When the network receives the PACKET RESOURCE REQUEST message, it respondsby 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 PACKETACCESS REJECT message to the MS.

Fig. 9.7 shows a two phases access procedure on CCCH.

Fig. 9.7 Two Phases Access on CCCH

n the current release an improvement of the GAP between the Assignment and PacketResource Request (PRR) and/or the TBF start has been implemented. A gap of about350, 450 ms has been detected between the IACMD and the PRR in case of two phaseaccess. For this reason a reduction and optimization of the overall delay for all the typesof PRR/TBF start has been applied for both idle channels and active channels. Theimprovement has been achieved with the optimization of the commanded TBF startingtime.

In case of active channels it is not necessary the syncronization of the PDTs. As aconsequence the PRR/TBF start can be commanded without risk accordingly to theinternal RNLC timing.

In case of idle channels the Immediate Assignment (IACMD) is submitted by the PCUparallel to the ongoing channel synchronization roughly before the ending of the channelsynchronization itself. Considering that the channel synchronization has a final cyclewithout any TA and FN changes and an additional virtual cycle should be taken intoaccount as reserve (60-100ms) the PRR delay or the TBF start could be improved byabout 200ms.

202 A30808-X3247-L24-5-7618


9.8.2.4 TBF Establishment for EDGE Mobile StationsAs described in "4.4.1 Packet Broadcast Control Channel (PBCCH)", the MS knows thatEGPRS is available in the cell, reading the GPRS Cell Option IE in SI13 or in PSI1 andfinding the EGPRS_PACKET_CHANNEL_REQUEST support indication field.

The EGPRS_PACKET_CHANNEL_REQUEST support indication field, is representedby 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 TBFestablishment on the PRACH when there is a PBCCH in the cell;

– the EGPRS PACKET CHANNEL REQUEST message for EGPRS uplink TBFestablishment 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 usestwo different training sequences, TS1 and TS2, to allow a mobile station to signal to thenetwork, during the access phase, its uplink capability. In fact, as described in"9.1 Mobile Stations for Packet Switched Services" two mobile classes are foreseen forwhat 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 trainingsequence already used for GSM (TS GSM).

It is important to note that only EDGE CUs are able to manage access bursts containingTS1 and TS2 (and as a consequence the EGPRS PACKET CHANNEL REQUESTmessage), so the EGPRS PACKET CHANNEL REQUEST message will be used toaccess a cell only if the BCCH carrier supports EDGE, i.e., (see "5.1.2 Enabling EGPRSService in the Cell"):

a) at least one EDGE CU is configured in the BTS equipment handling the cellb) the TRXMD parameter of the BCCH carrier is set to EDGEc) the TrxCapability of the BCCH carrier is set to EDGE

Besides, the ABUTYP parameter that indicates the format of the information field ofaccess bursts must be set to ACBU11BIT.

Therefore, if the SI13 (or the PSI1) indicates that the cell is EGPRS capable, andEGPRS PACKET CHANNEL REQUEST on RACH (PRACH) is supported in the cell, anEGPRS mobile station sends the 11 bit EGPRS PACKET CHANNEL REQUESTmessage.

If the SI 13 (or the PSI1) indicates that the cell is EGPRS capable and EGPRS PACKETCHANNEL REQUEST on RACH /PRACH) is not supported in the cell, the EGPRSmobile station will use the CHANNEL REQUEST message on RACH (or PACKETCHANNEL REQUEST message on PRACH) message and initiates a two phasesaccess request. In the following, the access procedures are described in more detail.

halam

Underline

halam

Note

If in SI13 the EGPRS_PACKET_CHANNEL_REQUEST field is 0, it will be a single phase access otherwise it will be a two phase access.

halam

Highlight

halam

Underline

halam

Highlight

halam

Highlight

A30808-X3247-L24-5-7618 203

InformationSystem


EGPRS Uplink TBF Establishment using a One Phase Access

Regarding this kind of Uplink TBF establishment, different cases exist:

a) EGPRS PACKET CHANNEL REQUEST is supported:– if the PBCCH channel is not supported, the MS sends an EGPRS PACKET

CHANNEL REQUEST message on the RACH channel.The procedure is similar to those described in "9.8.2.2 Establishment using a OnePhase Access": the BSC answers with the IMMEDIATE ASSIGNMENT messagefor Uplink EGPRS TBF, and then it sends a Packet Uplink Assignment for UplinkEGPRS TBF if the TBF is multislot;

– if the PBCCH channel is supported, the MS sends an EGPRS PACKETCHANNEL REQUEST message on the PRACH channel.The procedure is similar to those described in "9.8.2.2 Establishment using a OnePhase Access": the BSC answers with a Packet Uplink Assignment for UplinkEGPRS TBF.

b) EGPRS PACKET CHANNEL REQUEST is NOT supported: in this case, the onephase access does not allow establishing an EGPRS TBF; a GPRS TBF will be allo-cated following the procedure described in "9.8.2.2 Establishment using a OnePhase 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 sendsa Packet Resource Request message following the procedure described in"9.8.2.3 TBF Establishment using a Two Phases Access";

– if the PBCCH channel is supported, the MS sends an EGPRS PACKETCHANNEL REQUEST message on PRACH channel.The BSC answers with a Packet Uplink Assignment message, then the MS sendsa Packet Resource Request message following the procedure described in"9.8.2.3 TBF Establishment using a Two Phases Access";

b) EGPRS PACKET CHANNEL REQUEST is NOT supported:– if the PBCCH channel is not supported, the MS sends a Channel Request (with

two phase indication) on RACH channel. The BSC answers with IMMEDIATEASSIGNMENT (single block), then the MS sends a Packet Resource Requestmessage following the procedure described in "9.8.2.3 TBF Establishment usinga Two Phases Access";

– if the PBCCH is supported, the MS sends a Packet Channel Request (with twophase indication) on PRACH channel. The BSC answers with PACKET UPLINKASSIGNMENT (single block), then the MS sends a Packet Resource Requestmessage following the procedure described in "9.8.2.3 TBF Establishment usinga Two Phases Access";

9.8.2.5 Contention ResolutionContention resolution is an important part of RLC/MAC protocol operations, especiallybecause 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 onephase and the two phase access.

204 A30808-X3247-L24-5-7618


The two phase access is inherently immune from the possibility that two MSs canperceive the same channel allocation as their own. Namely, the second access phase,i.e., the Packet Resource Request, uniquely identifies the MS by its TLLI. The sameTLLI is included in the Packet Uplink Assignment/Packet Downlink Assignment and nomistakes are possible.

The one phase access is somewhat insecure, and an efficient contention resolutionmechanism must be introduced.

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 contention resolution, but alsoto be able to establish the RLC protocol entity for that Temporary Block Flow on thenetwork side. Additionally, TLLI is necessary to be able to match simultaneous uplinkand downlink packet transfers by taking into consideration multislot capability of thatMS. In order to uniquely identify the MS when sending on uplink, the RLC Header for allof the RLC Data Blocks on the uplink is extended to include the TLLI, until the contentionresolution is completed on the MS side.

The second part of the solution is the notification from the network side about who ownsthe allocation. That is solved by the inclusion of the TLLI in the PACKET UPLINKACK/NACK and PACKET DOWNLINK ACK/NACK messages. By doing so, the conten-tion is resolved after the first occurrence of Packet Ack/Nack.

9.8.2.6 Uplink Access on PRACH (Access Persistence Control)The mobile station makes at most MAX_RETRANS + 1 attempts to send a PACKETCHANNEL REQUEST message. After sending each PACKET CHANNEL REQUESTmessage, the mobile station listens to the full PCCCH that corresponds to the PRACH(i.e., carried by the same PDCH).

The Control Parameters Information Element of PRACH contains the access persis-tence control parameters, and it is broadcast on PBCCH and PCCCH. The parametersincluded 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 CHANNELREQUEST message; it corresponds to the GMANRETS database parameter

– PERSISTENCE_LEVEL, which consists of the PERSISTENCE_LEVEL P(i) foreach 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 thePERSISTENCE_LEVEL parameter, this will be interpreted as if P(i)=0 for all radiopriorities. The user can set the four PERSISTENCE_LEVEL values (one for eachpriority) 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 initiatedat the first possible TDMA frame containing PRACH, on the PDCH matching the mobilestation’s PCCCH_GROUP.

iThe Temporary Logical Link Identity (TLLI) identifies a GPRS/EGPRS user inside thecell. 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 MSfrom the packet data transfer point of view.

A30808-X3247-L24-5-7618 205

InformationSystem


After each attempt, S and TX_INT parameters are used to determine the next TDMAframe in which the MS is allowed to make a successive attempt. The number of TDMAframes between two successive attempts to send a PACKET CHANNEL REQUESTmessage, excluding the TDMA frames potentially containing the messages themselves,is a random value drawn, for each transmission, with a uniform probability distribution inthe set {S, S + 1, …, S + TX_INT - 1}.

When the MS has made MAX_RETRANS + 1 attempts to send a PACKET CHANNELREQUEST message, the packet access procedure is aborted, a packet access failureis indicated to upper layers and the mobile station returns to packet idle mode.

When the MS initiates a packet access procedure and receives from the network aPacket Access Reject message from the network, corresponding to one of the 3 lastPACKET CHANNEL REQUESTs sent by the MS, it starts the T3172 timer; while thetimer is running, the MS is not allowed to access to the cell (i.e., it cannot send any otherPACKET CHANNEL REQUEST messages). Then one of the following situations canoccur (see Fig. 9.8):– if the MS receives the Packet Uplink Assignment message, it stops the T3172 timer– it the T3172 timer expires, the MS can start new transmissions of packet channel

requests

Fig. 9.8 Packet Access Reject Procedure

9.8.3 TBF Establishment Initiated by the Network on CCCH/PCCCHWhen the GPRS/EGPRS MS is in standby state and the PCCCH channel is configuredin the serving cell, the mobile station listens to the paging sub-channels on PCCCH. IfPCCCH is not present in the considered cell, the mobile station listens to paging sub-channels on CCCH.

If the MS is in Standby state, the SGSN only knows the Routing Area on which the MSis camped on. In order to initiate a downlink packet transfer, the SGSN sends to the MSone or more PACKET PAGING REQUEST messages on the downlink PCH (PPCH).

The MS responds to one PACKET PAGING REQUEST message by initiating a mobileoriginated packet transfer, as described in "9.8.2 TBF Establishment Initiated by the MSon CCCH/PCCCH".

This mobile originated packet transfer allows the MS to send a PACKET PAGINGRESPONSE to the network. The packet paging response is one or more RLC/MAC datablocks containing an arbitrary LLC frame.

t

Start T3172(Reception of a PacketAccess Reject message)

Stop T3172(Reception of a PacketUplink Assignment message)

T3172 ExpiredAccess in the cell isno longer prohibited

iPaging sub-channels are, in any case, monitored according to the paging groupsdefined for the mobile station and its current DRX mode (see "9.8.3.2 DiscontinuousReception"). Paging for GPRS/EGPRS is performed on Routing Areas.

206 A30808-X3247-L24-5-7618


When the packet paging response has been sent by the MS and received by thenetwork, the mobility management state of the MS changes from standby to ready.

The transmission of RLC/MAC blocks to a MS in the ready state is initiated by thenetwork using the packet downlink assignment procedure. The network initiates thepacket downlink assignment procedure by sending the IMMEDIATE ASSIGNMENT(PACKET DOWNLINK ASSIGNMENT) message on the CCCH (PCCCH) timeslotcorresponding to CCCH (PCCCH) group to which the mobile station belongs. If themobile station does not apply DRX, there is no further restriction on what part of thedownlink CCCH (PCCCH) timeslot an IMMEDIATE ASSIGNMENT (PACKET DOWN-LINK ASSIGNMENT) message can be sent. If the mobile station applies DRX, themessage 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 fordownlink 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 "9.8.1 Medium Access Modes")– optionally, for EGPRS MSs, the EGPRS window size

The TBF establishment initiated by the network is shown in Fig. 9.9 in case of PCCCH.

iIf the MS is already in READY state, the SGSN knows the exact cell where the MS iscamped 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 ASSIGNMENTmessage is transmitted on PACCH.

A30808-X3247-L24-5-7618 207

InformationSystem


Fig. 9.9 TBF Establishment Initiated by the Network on PCCCH

9.8.3.1 Network Operation Modes for PagingThe network may provide co-ordination of paging for circuit-switched and packet-switched services. Paging coordination means that the network sends paging messagesfor circuit switched services on the same channel as used for packet switched services,i.e.;– on the PPCH paging channel, if the MS is in packet idle mode– on the PDCH if the MS is in packet transfer mode

Then the MS must only monitor one channel at any time.

Three network operation modes are defined (see Tab. 9.2):• Network operation mode I : the network sends CS paging messages for a

GPRS/EGPRS-attached MS, either on the same channel as the PS paging channel(i.e., the PCCCH if it is configured, otherwise the CCCH), or on a PDCH trafficchannel. This means that the MS must monitor one paging channel, and that itreceives CS paging messages on the packet data channel when it has beenassigned a packet data channel. When the network operation mode I is used, thenetwork works in a coordinated way.

• Network operation mode II : the network sends CS paging messages for aGPRS/EGPRS-attached MS on the CCCH paging channel, and this channel is alsoused for PS paging. This means that the MS must monitor the CCCH pagingchannel, but that CS paging continues on this paging channel even if the MS hasbeen assigned a packet data channel.

• Network operation mode III : the network sends CS paging messages for aGPRS/EGPRS-attached MS on the CCCH paging channel, and sends PS paging

208 A30808-X3247-L24-5-7618


messages either on PCCCH (if it is allocated in the cell) or on the CCCH pagingchannel. Therefore a MS that wants to receive pages for both circuit-switched andpacket-switched services will monitor both paging channels if the packet pagingchannel is allocated in the cell. No paging co-ordination is performed by the network.

When the Gs interface exists, all MSC-originated pages of GPRS/EGPRS-attachedMSs go via the SGSN, thus allowing network co-ordination of paging. Paging co-ordina-tion is made by the SGSN based on the IMSI, and it is provided independently ofwhether the MS is in STANDBY or READY state. The network operates in mode I.

When the Gs interface does not exist, all MSC-originated pages of GPRS/EGPRS-attached MSs goes via the A interface, and co-ordination of paging cannot beperformed. Then the network will either:– operate in mode II, meaning that the packet common control channel is not allocated

in the cell;– operate in mode III, meaning that the packet common control channel is used for PS

paging when the packet paging channel is allocated in the cell.

The network operation modes (mode I, II, or III) are indicated as system information tothe MSs. The user sets this value with the NMO parameter. For proper operation, themode 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, orto both of them.

9.8.3.2 Discontinuous ReceptionPaging is used to send paging information to mobile stations in packet idle mode (apartfrom the current MM state, i.e., ready state or standby state), so a mobile station inpacket idle mode listens to radio blocks on CCCH or PCCCH.

For PS services, as for the CS service, it is also possible to organize paging channelsin combination with discontinuous reception (DRX). DRX allows MSs to reduce powerconsumption.

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 DRXparameters that indicate the delay for the network to send page requests or channelassignments to the MS.

Mode CS services pagingchannel

PS paging channel Pagingco-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 pagingchannel

NO

CCCH paging channel CCCH paging channel

Tab. 9.2 Network Operation Modes

A30808-X3247-L24-5-7618 209

InformationSystem


DRX parameters are indicated by the MS in the Attach procedure (see 9.3.2.1). Thenthe then in each page request sends these parameters to the BSS, that uses both thisinformation 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: indicates whether or not the MS uses DRX.• DRX period: indicates the period of time between two consecutive paging blocks

(within a timeslot used as CCCH or PCCCH) where a MS, which is using DRX mode,can receive its paging messages.When PCCCH is used, the DRX period is defined by the SPLIT_PG_CYCLE param-eter. The mobile station requests values for the SPLIT_PG_CYCLE parameter to beapplied on PCCCH.The SPLIT_PG_CYCLE parameter handles the occurrence of paging blocks onPCCCH monitored by the mobile station in DRX mode.

• Non-DRX timer: is used to determine the duration of the non-DRX mode period tobe applied by the mobile station when it has left the packet transfer mode and entersthe packet idle mode. A MS in non-DRX mode is required to monitor all of the radioblocks of the PCCCH or CCCH channel; therefore the required time to execute thepaging procedure is reduced. As long as the timer is running (hence the MS is innon-DRX mode), the BSC sends downlink assignments on the AGCH or PAGCH(and not in paging blocks that the MS monitors when DRX mode is active, and thatoccur with a low frequency) reducing the time to allocate resources.So, when the MS changes from packet transfer mode to packet idle mode, the BSCstarts a timer; the duration of this timer is determined by the following:

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-

dureDuring this period, the MS is in non-DRX mode; when the timer expires, the MSresumes discontinuous reception.

iThe support of the SPLIT_PG_CYCLE parameter on CCCH is optional. TheSPGC_CCCH_SUP parameter (not configurable in the database) indicates the supportof the SPLIT_PG_CYCLE on CCCH from the network side.If SPLIT_PG_CYCLE is not supported on CCCH, the period of monitoring paging blockson CCCHs is defined by the GSM NFRAMEPG parameter. The NFRAMEPG parameterdetermines 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 are shown inTab. 9.3, with the corresponding GSM parameters.

timer = min (DRX_TIMER_MAX, NON_DRX_TIMER)

210 A30808-X3247-L24-5-7618


When the mobile station receives a new value of the DRXTMA parameter, themobile station is not required to consider the new value until the next time it enterspacket idle mode.

GPRS/EGPRS Paging using CCCH

A mobile station using DRX is only required to monitor the PCH blocks belonging to itspaging group. The network sends the paging subchannel for a given MS everyNFRAMEPG multiframes, or every 64/SPLIT_PG_CYCLE multiframes ifSPLIT_PG_CYCLE is supported.

A mobile station not using DRX is required to monitor every PCH block on the sameCCCH as for DRX.

The network internal message flow is as follows:

iIn applications such as WAP, the time needed to get a reply is a key factor for end useracceptance. Because of highly interactive behavior of WAP with few seconds betweenanswers from network and subsequent user actions (for example navigating throughmenus), response times are drastically reduced by sending the immediate assign-ment/packet downlink assignment messages (polling requests) on the AGCH/PAGCHinstead of PCH/PPCH. So, when the DRX mode is temporarily disabled, the time thatoccurs to receive at the MS side a data block that has been sent from the Gb interface,is in average reduced by 50%.

iThere is another case when the MS enters the non-DRX mode: when initiating the MMprocedures for PS attach and routing area update, the mobile station enters the MMnon-DRX mode period. This period ends when the corresponding MM proceduresterminate.

Subjects GPRS/EGPRS Corresponding GSMparameters

PCCCH CCCH CCCH

DRX period SPLIT_PG_CYCLE NFRAMEPG (*)SPLIT_PG_CYCLE (**)

NFRAMEPG

Blocks not available forpaging per multiframe

BSPBBLK + BPAGCHR NBLKACGR NBLKACGR (***)

Number of timeslots (phys-ical channels) containingpaging

Depending on the numberof slots reserved forPCCCH by means of theGDCH parameter.

Depending on the numberof slots reserved forCCCH.

Depending on thenumber of slots reservedfor CCCH.

(*) only when DRX period split is not supported.(**) only when DRX period split is supported.(***) NBLKACGR is a GSM parameter the indicates the number of CCCH blocks reserved for the access grantsignalling during a period of a 51 TDMA frames (that means during a period of a 51 TDMA multiframe). Its valuehas to be always > 0, to support mobile stations which do not handle SI2quater correctly.

Tab. 9.3 Parameters for DRX Operation

A30808-X3247-L24-5-7618 211

InformationSystem


1. the SGSN, which has the information about the usage of DRX, sends a pagingmessage to all PCUs that are supporting the right Routing Area. This messageincludes the information on whether or not DRX is used, and additionally, if theenhanced 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 therequested paging parameters over the internal interface to the TDPC;

3. the TDPC calculates the right paging group and forwards per LAPD connection thePacket Paging Request message to the paging queues inside the BTS. Additionallythe BSC evaluates all needed DRX parameters that must be broadcast on theBCCH;

4. the BTS queues all Packet Paging Request messages and sends them in first-infirst-out order on the PCHs in the CCCH multiframe.

GPRS/EGPRS Paging using PCCCH

A MS using DRX is required to monitor the PPCH. The network sends the pagingsubchannel 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 samePCCCH as for DRX.

The network internal message flow as follows:

1. The SGSN, which has the information about the usage of DRX, sends a pagingmessage to all PCUs located in the right Routing Area. This message includes theinformation about whether or not DRX is used and additionally (if the enhanced DRXmechanism is used) the SPLIT_PG_CYCLE parameter;

2. The PCU calculates the right paging group and adds all Packet Paging Requestmessages on its paging group queues. Additionally, the PCU evaluates all neededDRX parameters that must be broadcast on PBCCH;

3. The PCU includes the Packet Paging Request messages into RLC/MAC blocks andschedules the messages into the PDCH multiframes, which contain PCCCH. TheRLC/MAC blocks are transferred via PCU frames to the BTS, which immediatlytransmits 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 willtransmit either a PACKET CONTROL ACKNOWLEDGEMENT message (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 anymessage except Packet Paging Request, Packet Access Reject, and Packet QueueingNotification, 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 PacketPaging Request, Packet Access Reject, or Packet Queueing Notification message, themobile station ignores this RRBP field.

If the RRBP field is received as part of a RLC/MAC data block , the mobile station willtransmit a PACCH block (e.g., a PACKET UPLINK ACK/NACK message to acknowl-edge the downlink data block) in the specified uplink radio block.

212 A30808-X3247-L24-5-7618


The mobile station will always transmit the uplink radio block on the same timeslot asthe block where the RRBP has been received.

To indicate to the MS whether or not the received RRBP field is valid, a bit of the MACheader is used; according to the value of this bit, the MS knows if, in the received block,the RRBP field is meaningful.

9.8.5 Polling ProceduresAs described in "4.6 Packet Timing Advance Estimation", the initial timing advance esti-mation is based on the single access burst carrying the Packet Channel Request. ThePacket Uplink Assignment or Packet Downlink Assignment (or the Immediate Assign-ment if the PCCCH is not configured) carries the estimated timing advance value to theMS.

But, when Packet Downlink Assignment must be sent without prior paging (i.e., in theReady 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 triggerthe transmission of the PACKET CONTROL ACKNOWLEDGEMENT message (see"9.8.4 Relative Reserved Block Period Field (RRBP)"). This can be used only if theSystem information indicates that acknowledgement is access bursts, i.e., it can beused only if CACKTYP is set to 0;

2. Packet Downlink Assignments can be sent without timing advance information. Inthat case, it is indicated to the MS that it can only start the uplink transmission afterthe timing advance value has been obtained by the continuous timing advanceupdate procedure.

The continuous timing advance update procedure can create some delays between thepacket downlink assignment message and the beginning of data transfer in downlinkdirection (this delay is due to the time needed to exchange timing advance informationbetween the network and the MS). In order to reduce the time between a packet down-link assignment message and the effective beginning of downlink data transmission, apolling procedure is executed by the network to order the MS to send a Packet ControlAcknowledgment message, formatted as four Access Bursts. This procedure foreseespolling the MS by means of the RRBP field of the assignment message; as a conse-quence, the CACKTYP parameter must be set to 0 , to force the MS to respond withfour Access Burst.

Different procedures are executed according to whether or not the PBCCH is config-ured.

iThe multislot class of the MS limits allowed combinations and configurations when theMS supports multislot communications. When an MS has established a downlink TBF,it cannot transmit in uplink direction (after a polling by the network) on any timeslot; infact for each mobile station, according to its multislot class, downlink and uplinktimeslots usage is specified (see "4.7.1 Mobile Station Classes for Multislot Capabili-ties"). Therefore, to poll the MS, the network must send the downlink block with a validRRBP field on a timeslot where the polled MS is able to answer.

iThe CACKTYP parameter is hard-coded to the value 0.

A30808-X3247-L24-5-7618 213

InformationSystem


Procedure when PBCCH is configured

If PBCCH is configured, the following steps are executed:– the BSC sends the PACKET DOWNLINK ASSIGNMENT message (on the

PPCH/PAGCH) setting the RRPB field to poll the MS;– upon reception of the PACKET CONTROL ACKNOWLEDGEMENT message from

the MS, the BSC can immediately start downlink transmission of data blocks;– as soon as possible (also before the transmission of the first downlink data block)

the BSC must send the PACKET POWER CONTROL/TIMING ADVANCE messageto the MS, including the estimated timing advance value.

Procedure when PBCCH is not configured

If PBCCH is not configured, the following steps are executed:– the BSC sends the IMMEDIATE ASSIGNMENT message for downlink TBF on

PCH/AGCH;– then the BSC sends on the assigned PDCH(s) a PACKET DOWNLINK ASSIGN-

MENT message setting the RRPB field to poll the MS;– upon reception of the PACKET CONTROL ACKNOWLEDGEMENT message from

the MS, the BSC can immediately start downlink transmission of data blocks;– as soon as possible (also before the transmission of the first downlink data block)

the BSC must send the PACKET POWER CONTROL/TIMING ADVANCE message,including the estimated timing advance value, to the MS.

9.9 RLC Data Block TransferThe RLC functions support two modes of operation:• RLC acknowledged mode: this mode is used for data applications where the

payload content must be preserved. It is the typical mode for Background class(background delivery of e-mails, SMS, download of databases) and Interactive classapplications (web browsing).

• RLC unacknowledged mode: this mode is used for delay-sensitive services, such asConversational class (voice, video conference) and Streaming class applications(one-way real time audio and video).

A TBF may operate in either RLC acknowledged mode or RLC unacknowledged mode.

9.9.1 Acknowledged Mode for RLC/MAC OperationThere are some differences regarding GPRS and EGPRS acknowledged modes; thesedifferences are described below.

9.9.1.1 GPRS Acknowledged ModeGPRS acknowledged operation mode uses retransmission of RLC data blocks toachieve high reliability. The transfer of RLC Data Blocks in the RLC/MAC acknowledgedmode is controlled by a selective ARQ mechanism (type I ARQ) coupled with thenumbering 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 isfixed to 64 blocks) and the receiving side sends a Packet Uplink Ack/Nack or a PacketDownlink Ack/Nack message when needed. The transmitting side numbers the RLCdata blocks via the block sequence number (BSN), which is used for retransmission andreassembly. Every such message acknowledges all correctly received RLC Data Blocks

214 A30808-X3247-L24-5-7618


up to an indicated block sequence number (BSN), thus “moving” the beginning of thesending window on the sending side. Additionally, the bitmap that starts at the sameRLC Data Block is used to selectively request erroneously received RLC Data Blocksfor retransmission. The sending side then retransmits the erroneous RLC Data Blocks,eventually resulting in further sliding of the sending window. A missing Packet Ack/Nackis not critical and a new one can be issued whenever.

9.9.1.2 EGPRS Acknowledged ModeThe transfer of RLC Data Blocks in the EGPRS acknowledged RLC/MAC mode can becontrolled by the following:

a) a selective type I ARQ mechanism, where coding of a RLC Data Block is solelybased on the prevailing transmission (i.e., 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 transmissionsis done.

Both methods are coupled with the numbering of the RLC Data Blocks within oneTemporary Block Flow.

The sending side (the MS or the network) transmits blocks within a window and thereceiving side sends Packet Uplink Ack/Nack or Packet Downlink Ack/Nack messagewhen needed.

For EGPRS, the window size (WS) will be set by the operator according to the numberof timeslots allocated in the direction of the TBF (uplink or downlink). The operator canset 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 an RLC block. For retransmis-sion, the same or another MCS from the same family of MCSs can be selected (see"10.5 Link Adaptation"). For example if MCS-7 is selected for the first transmission of anRLC 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 tworadio blocks. In this case, the split block field in the header is set to indicate that the RLCdata block is split, and the order of the two parts. For blocks initially transmitted withMCS8 that are retransmitted using MCS6 or MCS3, padding of the first six octets in thedata 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 isused to indicate to the MS whether or not the block has been segmented. In fact, thefollowing must be noted:

iIn Release BR7.0 , the Incremental Redundancy mechanism for EGPRS is only used inthe downlink direction; in the uplink direction, only the selective type I ARQ mechanismis used.

A30808-X3247-L24-5-7618 215

InformationSystem


a) when ARQ mode type I is used, the retransmission is executed with a codingscheme of the same family of the block received with errors, and block splitting ispossible;

b) when ARQ mode type II is used, the retransmission is executed with a codingscheme 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 initialcode rates (i.e., the rate 1/3 encoded data is punctured with the puncturing scheme (PS)1 of the selected MCS). If the RLC Data Block is received in error, additional coded bit(i.e., the output of the rate 1/3 encoded data that is punctured with PS 2 of the prevailingMCS) are sent and decoded with the previously received code-words until decodingsucceeds. If all of the code-words (different punctured versions of the encoded datablock) have been sent, the procedure will start over, and the first code-word (which ispunctured 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 Tab. 9.4, at the first transmission after the MCS switch.

In the EGPRS type I ARQ, the operation is similar to one of the EGPRS type II hybridARQ, except that the decoding of an RLC Data Block is solely based on the prevailingtransmission (i.e., erroneous blocks are not stored).

Therefore, the MS can use either the type I ARQ or the type II ARQ mode, according tothe current situation .

If the memory for IR operation run out in the MS, the MSwill indicate this by setting theLA/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.5 LinkAdaptation"), then the PCU may decide to re-segment the not acknowledged blocks.Therefore, for retransmissions, an MCS within the same family as the initial transmissionmay 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 MCSwithin 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 jointdecoding among blocks with different MCSs if the combination of MCSs is one of thefollowing:

MCS switchedfrom

MCS switched to PS of last transmis-sion before MCS

switch

PS of first trans-mission after MCS

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

216 A30808-X3247-L24-5-7618


– MCS5 and MCS7– MCS6 and MCS9

9.9.2 Unacknowledged Mode for RLC/MAC OperationRLC unacknowledged operation mode does not include any retransmission. Thetransfer of RLC Data Blocks in the RLC/MAC unacknowledged mode is controlled by thenumbering of the RLC Data Blocks within one Temporary Block Flow. The blocksequence number (BSN) in the RLC data block header is used to number the RLC datablocks for reassembly. The receiving side extracts user data from the received RLCData Blocks and attempts to preserve the user information length by replacing missingRLC Data Blocks by dummy information bit. To convey the necessary control signalling(e.g., monitoring of channel quality for downlink channel or timing advance correction foruplink transfers) temporary acknowledgement messages are transmitted, with the samemechanisms and the same message format used by the RLC/MAC acknowledgedmode. The fields for denoting the erroneous RLC blocks may be used as an additionalmeasure for channel quality (i.e., parameter for link adaptation). The sending side (theMS or the network) transmits a number of radio blocks and then polls the receiving sideto send an acknowledgement message. A missing acknowledgement message is notcritical 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 thelink adaptation algorithm could work in a similar way to the acknowledged mode case.However the unacknowledged mode is typically used to support real time applicationsand in this case minimizing the data unit error ratio, i.e., the fraction of data unit lost ordetected as erroneous, is much more important than maximizing throughput.

9.9.3 Operations on Uplink TBF

9.9.3.1 Uplink TBF Using the Acknowledged ModeThe mobile station transmits RLC/MAC blocks in each assigned uplink data block.RLC/MAC control blocks take precedence over RLC data blocks, i.e., temporarilyreplacing the PDTCH with PACCH. The network sends PACKET UPLINK ACK/NACKmessages when needed.

In case of GPRS service, where the window size is fixed to 64 blocks (see"9.9.1.1 GPRS Acknowledged Mode"), to indicate to the network when it must send aPACKET UPLINK ACK/NACK, the NRLCMAX parameter is defined: by this parameter,the user can configure how many blocks must be transmitted by the MS, beforereceiving a PACKET UPLINK ACK/NACK message. The NRLCMAX value is chosen asa compromise between two necessities:– 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, where, according to the number of timeslots assigned to theMSs, a specific window size is used (see "9.9.1.2 EGPRS Acknowledged Mode"), toindicate to the network when it must send a PACKET UPLINK ACK/NACK, differentparameters are provided:

A30808-X3247-L24-5-7618 217

InformationSystem


– 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.

By these parameter the user can configure how many blocks must be transmitted by theMS, before receiving a PACKET UPLINK ACK/NACK message, according to thenumber of assigned PDCHs. The value of these parameters is chosen as a compromisebetween two necessities:– 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 thatallows it to advance the transmitting window, the transmitting window stall condition isreached: upon detecting this condition, the mobile station sets the Stall indicator (SI) bitin all subsequent uplink RLC data block, until the stall condition ceases to exist (i.e.,when a valid PACKET UPLINK ACK/NACK message is received).

Upon detecting the stall condition, the mobile station also starts the T3182 timer. T3182timer is stopped upon the reception of a PACKET UPLINK ACK/NACK message, thatallows terminating 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 and initiates the establishment of a new uplink TBF, otherwise theMS performs an abnormal release with cell reselection (see below).

Whenever the mobile station receives a PACKET UPLINK ACK/NACK message thatallows the advancement of the sending window, the mobile station increments theN3102 counter by the PAN_INC value, however N3102 will never exceed the PAN_MAXvalue.

The user can configure PAN_INC and PAN_MAX values by PKTNINC and PKTNMAparameters 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 cellre-selection (see Abnormal Cell Re-selection).

iIf PAN_DEC, PAN_INC, or PAN_MAX are set to the value 0, counter N3102 is disabled.

halam

Highlight

218 A30808-X3247-L24-5-7618


Fig. 9.10 Behavior of T3182 Timer and N3102 Counter

9.9.3.2 Uplink TBF Using the Unacknowledged ModeWhen the unacknowledged mode is used, the network sends PACKET UPLINKACK/NACK messages when needed, while the mobile station sets the Stall indicator bitto ‘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(i.e., 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, withoutreceiving a PACKET UPLINK ACK/NACK message, the mobile station starts T3182timer. T3182 will be stopped upon reception of a PACKET UPLINK ACK/NACKmessage.

If timer T3182 expires, the mobile station decrements the N3102 counter by thePAN_DEC (PKTNDEC) value, aborts all TBFs in progress and its associated resources,returns to CCCH or PCCCH and initiates the establishment of a new uplink TBF.

Whenever the mobile station receives a PACKET UPLINK ACK/NACK message, themobile station will increment N3102 by PAN_INC (PKTNINC), however N3102 will neverexceed the value PAN_MAX (PKTNMA).

Upon cell reselection, the mobile station will set counter N3102 to the PAN_MAX value.When N3102 = 0 is reached, the mobile station performs an abnormal release with cellre-selection.

9.9.3.3 Anomalies During an Uplink TBF

Mobile Station Side

When the mobile station transmits an RLC/MAC block to the network, it starts timerT3180. When the mobile station detects an assigned USF value on an assigned PDCH,the mobile station reset the T3180 timer. If the T3180 timer expires, the mobile stationaborts all TBFs in progress and its associated resources, returns to the CCCH orPCCCH, and initiates the establishment of a new uplink TBF.

t

Start T3182 Stop T3182(Reception of a PacketUplink Acknowledge)

T3182 ExpiredAbort all TBFs

Cell reselectionN3102 = PAN_MAX

N3102 = N3102 + PAN_INC N3102 = N3102 - PAN_DEC

Stall condition

iIf PAN_DEC, PAN_INC, or PAN_MAX are set to the value 0, the N3102 counter isdisabled.

A30808-X3247-L24-5-7618 219

InformationSystem


Network Side

Whenever the network receives a valid RLC/MAC block from the mobile station, it resetsthe N3101 counter. The network increments the N3101 counter for each allocated radioblock to that mobile station, for which no data is received.

If N3101 reaches the N3101 maximum value, the network stops the scheduling ofRLC/MAC blocks from the mobile station and starts the T3169 timer. When T3169expires, the network may reuse the USF and TFI values (the procedure is shown inFig. 9.11).

The user can also define the N3101 maximum value by the N3101 parameter.

Fig. 9.11 Detection of Anomalies during an Uplink TBF on the Network Side

9.9.3.4 Release of an Uplink TBFThe release of resources is normally initiated from the MS by counting down the lastblocks. 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 PacketUplink 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. TheMS sends the Countdown Value (CV) in each uplink RLC data block to indicate to thenetwork the absolute BSN (Block Sequence Number) of the last RLC data block, thatwill be sent in the uplink TBF.

The CV value is calculated as follows:

then

time

Data is

Start T3169

T3169 ExpiredReuse of TFI

NW sends

N3101 = 0

Data is not receivedNW sends USF

N3101 = N3101+1= N3101max

from the MS.

communication withMS is broken.

and USFUSF

from thereceived

MS.

Data is notNW sendsUSF

from thereceived

MS.

N3101 = N3101 + 1

x roundTBC BSN′– 1–

NTS----------------------------------------

=

CVx if x BSCVMAX≤15 otherwise

=

220 A30808-X3247-L24-5-7618


where:

The final RLC data block transmitted in the TBF (i.e., the RLC data block with BSN’ =TBC - 1) will have CV set to the value ‘0’. Once the mobile station transmits a value ofCV other than 15, the MS will not queue any new RLC data blocks, and any data thatarrives after the commencement of the countdown process will be sent within a futureTBF.

After the MS has sent its last RLC Data Block (indicated by the countdown field), theacknowledgement is expected from the network side. By sending the last block, the MSmay 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 assoon as all of the RLC Data Blocks belonging to that Temporary Block Flow are correctlyreceived. 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 PacketUplink Ack/Nack message to the MS that must be immediately acknowledged by the MSin the reserved uplink block period (the network also resets the N3103 counter).

If T3182 timer expires, before the MS receives the Packet Uplink Ack/Nack message,then the mobile station aborts all TBFs in progress and its associated resources, returnsto the CCCH/PCCCH and initiates the establishment of a new uplink TBF.

When the MS receives the Packet Uplink Ack/Nack message, it responds to the networkby the Packet Control Acknowledgment message in the reserved uplink block period.Upon reception of the acknowledgement, the network can reuse the TFI and USFvalues.

- 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 0to (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 operationis non-integer and the result is 0 only for (TBC - BSN’ - 1) = 0.

A30808-X3247-L24-5-7618 221

InformationSystem


Fig. 9.12 Release of an Uplink TBF

If the network does not receive the PACKET CONTROL ACKNOWLEDGEMENTmessage in the radio block indicated by the RRBP field (see "9.8.4 Relative ReservedBlock Period Field (RRBP)"), it increments the N3103 counter and retransmits thePACKET UPLINK ACK/NACK message. If counter N3103 exceeds its limit, which theuser can define with the N3103 parameter, the network starts the T3169 timer. Whenthe T3169 timer expires, the network may reuse the TFI and USF resources(see Fig. 9.13).

Fig. 9.13 Release of Resources on the Network Side during an Uplink TBF (in case of T3169 timer expiration)

t

NW has not received any

Start T3169

T3169 ExpiredReuse of TFI and USF

NW waits foracknowledgment

N3103 = N3103 + 1

ackn. from the MS.

N3103 = N3103+1= N3103max

communication withMS is broken.

NW has not received anyackn. from the MS.

222 A30808-X3247-L24-5-7618


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 TBFrelease procedure is introduced (see Fig. 9.12).

The BSC delays sending the final PACKET UPLINK ACK/NACK message. Thisbehavior is introduced to save time when a downlink LLC PDU arrives from SGSN justafter the reception of the RLC Block with CV = 0. In this case, the BSC can open thedownlink TBF as a concurrent case, that is faster than the normal procedure (wherenormal means assignment messages sent on control channel, after the PACKETCONTROL 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 UPLINKACK/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 TBFsThe mobile station receives RLC/MAC blocks on the assigned downlink PDCHs. Oneach assigned PDCH, the mobile station decodes the TFI value, and decodes the RLCdata blocks intended for the mobile station.

In acknowledged mode, to indicate to the MS when it must send a PACKET DOWNLINKACK/NACK message different parameters are provided according to the service type:• in case of GPRS, the NRLCMAX parameter is provided; by this parameter, the user

can configure how many blocks must be transmitted by the network, beforereceiving a PACKET DOWNLINK ACK/NACK message;

• in case of EGPRS eight parameters are provided (depending on the defined windowsize (see 9.9.1.2):– 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;by these parameters the user can configure how many blocks have to be transmittedby the network, before receiving a PACKET DOWNLINK ACK/NACK message,according to the number of PDCHs assigned to the MS.

In unacknowledged mode, the MS must send a PACKET DOWNLINK ACK/NACKmessage after:• it has received 64 blocks (i.e., the window size) in case of GPRS;• it has received a number of blocks equal to the configured window size, in case of

EGPRS.

halam

Highlight

A30808-X3247-L24-5-7618 223

InformationSystem


In both unacknowledged cases (GPRS and EGPRS) the PACKET DOWNLINKACK/NACK message is used to check the connection between the MS and the network(see below).

For both of the operation modes, a control procedure is used by the network to verify ifthe MS is correctly receiving the downlink RLC/MAC blocks. The network, using theRRBP field (see "9.8.4 Relative Reserved Block Period Field (RRBP)"), reserves theuplink resource to transmit control messages.

The N3105 parameter implements the threshold for unreceived control messages fromthe MS, after sending the RRPB field in downlink direction. If the threshold is reached,the communication with the associated MS is broken.

Every time the network does not receive the control message from the MS, the N3105counter is increased; every time the network receives the control message from the MS,the N3105 counter is reset. When the N3105 counter reaches its maximum value(N3105max), the communication with the MS is broken (see Fig. 9.14).

The user can configure the N3105max threshold with the N3105 parameter.

Fig. 9.14 Control Procedure Executed by the Network during a Downlink TBF

9.9.4.2 Release of a Downlink TBFThe release of resources (see Fig. 9.15) is initiated by the network by terminating thedownlink 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 Indicatorbit (FBI) to 1.

It is possible for the network to change the current downlink assignment by using thePacket Downlink Assignment or Packet Timeslot Reconfigure message, which thenmust 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

Therefore, upon reception of the final Packet Downlink Ack/Nack from the MS (with FinalAckn = 1), the T3193 timer is started on the network side (and the T3191 timer is

t

NW has not received anyNW sets RRPBin DL data block

N3105 = N3105 + 1

control message

N3105 = N3105 +1= N3105max

Communication withMS is broken.

NW has not received anycontrol message

from the MS. from the MS.

NW has received acontrol messagefrom the MS.

Reset N3105

halam

Note

T3192: internal processing timer for MS after which MS releases TFI

halam

Note

T3193: Internal processing time for NW after which it will release the TFI

224 A30808-X3247-L24-5-7618


stopped). When it expires, the current assignment becomes invalid for the network, andTFI can be reused by the network.

Fig. 9.15 Release of a Downlink TBF

If the mobile station (in acknowledged mode), after having received a RLC data blockwith FBI=1, transmits a PACKET DOWNLINK ACK/NACK message with the Final Ackindicator not set to 1, it will continue to monitor all assigned PDCHs; in this case thenetwork must retransmit some RLC blocks.

If the network receives a PACKET DOWNLINK ACK/NACK message before the T3191timer expires, and if retransmissions are required, then the network stops the T3191timer 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 9.9.3.4, the continuous interruptions of data flow due to frequent estab-lishments and releases of TBFs, reduce the performances of many TCP/IP based appli-cations.

To reduce these disadvantages during downlink data transfer, a delay into the downlinkTBF release procedure is introduced (see Fig. 9.15).

The BSC, before sending the FBI=1, waits for the expiration of a timer. The operator canset this timer using the TIMEDTBFREL attribute.

During this time, the BSC maintains opened the downlink TBF, by sending Dummy LLCframes included in single RLC Blocks, with the polling bit (RRBP) set to one.

There are two advantages when Dummy LLC frames are used:

iSetting the TIMEDTBFREL attribute to 0 means no delay in TBF downlink releases.

A30808-X3247-L24-5-7618 225

InformationSystem


1. The MS may request UL resource in the PACKET DOWNLINK ACK/NACKmessage; with these Dummy frames, the BSC presses the MS for an answer, i.e.,if the MS has data to send, it will send it quickly.The delay time is not only influenced by the network, but also by the MS, so the delaytime can be different using different mobile stations;

2. If a new LLC should arrive from the SGSN, it is possible to send the relative RLCblock immediately (without an explicit assignment procedure). In this manner thereis an unique long single DL TBF, rather than several DL TBFs with a lot of assign-ment messages.

In order to speed up the uplink establishment during the Delay TBF Release time, pollingperiods should be quite low.

In current release, the delay between two subsequent pings is reduced due to the factthat the block containing the Dummy LLC is sent (polled) every 50 ms (alternating 40/60ms) for a duration of 450 ms; in this way 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 isa compromise between speed up of procedure, battery saving and resource usage. Withthis strategy the MS uplink establishment is speed up during the delay downlink TBFrelease time; infact improvements of about 80 ms are expected on Ping Delay timemeasured 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 radioblocks, obtaining a quite immediate sending of data when available. This improvementcan save approximately 20-40 msec per direction and it is implemented only on PPXUs.

A further improvement for the current release is related to the First Ping. The worstcondition in a cell with all the PDCHs being idle is a a value of 1.55 seconds for the FirstPing. The implemented solution is general and it applies also to other GMM and SMprocedures as well as to Data Transfer. The number of PDT assigned to a single blockhas to be set to the value “2” if concatenated PCU frames are used in the cell. In casestandard 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 foravoiding an unnecessary alignment of 2 Uplink Timeslot (for Mobile Stations that havemore than 1 Timeslot in Uplink direction).

With this improvement two sequential PDT/PDCH alignment are executed instead ofthree. The improvement of the First Ping is expected to be very near to 200 msec and itis valid for each GPRS and also for almost all EGPRS access cases.

9.9.5 Notes About Concurrent TBFsWhen concurrent TBFs must be established during either the resource allocation or theresource upgrade strategy (see "5.3 Management of Packet Data Channels"), and whenthe multislot class of the mobile station allows a degree of freedom on how to assignresources between uplink and downlink, it is necessary to manage resources in anoptimal way to balance the traffic of the two directions.

iMobile stations for which this problem arises are those providing a dynamic allocationof the number of resources, i.e., those belonging to the following multislot classes(see Tab. 4.6): 6, 7, 10, 11, 12.For example 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.

226 A30808-X3247-L24-5-7618


Tests with a mobile station with multislot class 6 have shown that with two simultaneousFTP connections, one in uplink and the other in downlink direction (duplex FTP), in caseof downlink preferred configuration (3+1) the downlink throughput is worse than in uplinkpreferred configuration (2+2). This is due to the fact that FTP connections are based onthe 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 biased (i.e., 3+1), also pure uplink trafficsuch FTP put would not be handled optimally, since the network would change to down-link preferred allocation as soon as first downlink TBFs for TCP/IP acknowledgmentsarrives.

The current implementation to manage concurrent TBFs is as follows.

When a downlink data transfer is set up, data transfer is always allocated with downlinkpriority.

Regarding the uplink direction, the mobile station might request the uplink TBF witheither the Packet_Resource_Request or the Packet_Downlink_Ack/Nack message(PDAN). Within these messages there is the Channel_Request_Description informationelement that contains a field called RLC_Octet_Count.

The RLC_Octet_Count field indicates the number of RLC data octets that the mobilestation wishes to transfer; its range is from 0 to 65535, and:– the value 0 is interpreted as a request for an open-ended TBF by the mobile station

(i.e., the mobile station does not specify the number of blocks it must transmit);– all other values are interpreted as a request for a close ended TBF (i.e., the

RLC_Octet_Count value indicates the number of blocks the MS must transmit).

The RLC_Octet_Count field is also used to change the priority between uplink anddownlink, such that the uplink allocation is extended.

When the MS asks for uplink resources, if RLC_Octet_Count=0 or if RLC_Octet_Countis more than a value defined by the THSULBAL parameter, then a switch from downlinkpriority to uplink priority is executed; in this case, the number of blocks the MS musttransmit is supposed to be quite big.

Otherwise a timer defined by TSULBAL is activated. If the uplink TBF is closed until thetimer is running, then the timer is stopped and downlink priority in maintained; if the timerelapses and the uplink TBF is still opened, a switch from downlink priority to the uplinkone is executed.

9.9.6 Suspend/Resume ProceduresThese procedures are used when the Circuit Switched dedicated mode is entered andit is temporarily needed to suspend GPRS/EGPRS service.

In fact, when a GPRS/EGPRS-attached MS enters the Circuit Switched dedicatedmode, and when the MS limitations make it unable to handle both the CS dedicatedmode and the packet switched transfer mode, the MS requests the network to suspendPS services.

This is the case of an MS operating in Class B mode. The MS is attached to both the PSand other CS services, but it can only operate one set of services at a time (see"9.1 Mobile Stations for Packet Switched Services").

A30808-X3247-L24-5-7618 227

InformationSystem


For instance, an ongoing downlink transmission can be suspended, a circuit switchedcall accepted and, after the call release, the packet switched data transmissioncontinued.

The suspend procedure is explained in the following (see 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 REQUESTmessage contains the following:– 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 aSUSPEND message to the SGSN containing the TLLI and the RAI; when themessage is sent, the T3 timer is started.If the T3 timer expires without receiving the ACK message from the SGSN, theSUSPEND message will be sent again and the T3 timer is restarted. This retry stepis repeated up to SUSPEND-RETRIES times (SUSPEND-RETRIES=3.)If the T3 timer expires SUSPEND-RETRIES times or a SUSPEND NACK is receivedfrom the SGSN, the suspend procedure is considered unsuccessful and an AlarmReporting notification is sent to LMT/RC.

4. If the SGSN acknowledges the SUSPEND message by returning the SUSPENDACK one, while the T3 timer is running, the procedure is considered successful. TheBSS will store TLLI and RAI in order to be able to request the SGSN to resume PSservices 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.

iEach received SUSPEND-ACK message is discarded (without notification towardsRC/LMT) by the BSC either if the MS related to the received TLLI/RAI is already"Suspended" or if the received TLLI/RAI does not correspond to an MS requiring thesuspension.

iThe BSC will suspend the GPRS/EGPRS service for the relevant MS, meaning thatno traffic for the MS (TLLI/RAI) will be forwarded to the MS, even if the radioresources are kept allocated to be available for the following Resume.

228 A30808-X3247-L24-5-7618


Fig. 9.16 Suspend Procedure

The BSC will start the resume procedure as soon as the circuit switched dedicated modeis left, that is when the MS is disconnected from the MSC.

Two cases must be distinguished:

a) during the suspension period, the MS has remained in the same cell;b) during the suspension period, the MS has changed cell or routing area.

In case a), the resumption request is managed with the SGSN; in the following thisprocedure is explained (the procedure in case of successful resume is shown inFig. 9.17):

1. The BSC starts the resume procedure sending the RESUME message containingthe 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, theRESUME message will be sent again and the T4 timer is restarted. This retry stepis repeated up to RESUME-RETRIES times (RESUME-RETRIES=3).In case the T4 timer expires RESUME-RETRIES times or a RESUME NACK isreceived from the SGSN, the resume procedure is considered unsuccessful and anAlarm Reporting notification is sent to the LMT/RC.

2. If the SGSN acknowledges the RESUME message by returning the RESUME ACKone while the T4 timer is running, the procedure is considered successful and theT4 timer is stopped.

3. In both cases, successful and unsuccessful, the involved TLLI is marked as "NotSuspended" in the BSC. Moreover, the BSC removes the information related to theprevious suspend request and, in both cases, it closes the procedure by sending aCHANNEL-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";

MS BSC SGSN MSC/VLR

Dedicated Mode is entered

GPRS SUSPENSION REQUEST

SUSPEND (TLLI, RAI)

SUSPEND ACK (TLLI, RAI, SRN)

Start T3

Stop T3

A30808-X3247-L24-5-7618 229

InformationSystem


– otherwise, the "GPRS Resumption" will be set to "resumption of PS services notsuccessfully acknowledged"

In the former case, the MS will consider the GPRS/EGPRS service resumed, in thelatter, it will be invited to initiate a Routing Area Update procedure.

4. Eventually, the BSS determines that the circuit-switched radio channel will bereleased. If the BSS is able to request the SGSN to resume PS services, the BSSwill send a Resume (TLLI, RAI) message to the SGSN. The SGSN acknowledgesthe successful outcome of the resume by returning Resume Ack;

5. The BSS sends an RR Channel Release (Resume) message to the MS. Resumeindicates whether the BSS has successfully requested the SGSN to resumeGPRS/EGPRS services for the MS, i.e., whether Resume Ack was received in theBSS before the RR Channel Release message was transmitted. The MS leavesdedicated mode;

6. If the BSS did not successfully request the SGSN to resume PS services, or if theRR 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 UpdateRequest message to the SGSN, as described in subclause "Routing Area UpdateProcedure".

Fig. 9.17 Resume Procedure (the MS has remained in the same cell - SuccessfulResume)

In case b), the resume procedure towards the SGSN is skipped; in the following, thisprocedure is explained (the procedure is shown in Fig. 9.18):

1. The BSC removes the information related to the previous suspend request and itimmediately sends a CHANNEL-RELEASE message to the MS. The informationelement "GPRS Resumption" will not be included in the message.

iEach received RESUME-ACK message is discarded if either the MS related to thereceived TLLI/RAI is already "Resumed" or the received TLLI/RAI does not corre-spond to a MS for which the resumption has been required.

MS BSC SGSN MSC/VLR

RESUME (TLLI, RAI, SRN)

RESUME ACK (TLLI, RAI)

Channel Release

Start T4

Stop T4

230 A30808-X3247-L24-5-7618


2. As a result, if the Routing Area was changed, a Routing Area Update procedure isinitiated by the MS; if the cell was changed but not the Routing Area, depending onits state, the MS will continue in the following way:– Ready state: a Cell Update procedure is initiated by the MS. The SGSN is aware

of the cell to which the MS currently belongs.– Standby state: the MS does nothing. When the SGSN side Ready Timer expires,

the SGSN will page the MS in the Routing Area it knows, to find the right cell.

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 containsthe “GPRS Suspend information” field (this field contains the SUSPEND ACK PDUmessage sent on the Gb interface.

With this information the new BSC is able to resume the MS that was suspended in theold BSC, without executing any routing area update procedure.

9.9.7 Notes About GPRS/EGPRS TBF SchedulingThe distribution of the active TBFs over the available GPRS/EGPRS carriers, and themultislot allocation of a particular TBF on the timeslots of the correspondingGPRS/EGPRS carrier, is done by the resource allocation algorithm, which is describedin "5.3 Management of Packet Data Channels".

Once resources have been allocated, allowing each TBF to reach the maximumrequired throughput, it is up to the scheduler to dynamically assign permissions toaccess the physical channels, when several TBFs are multiplexed on the sameresources.

Therefore, the scheduler is able to handle the case when EGPRS and GPRS mobilesare multiplexed on the same PDCHs: in this case, the main problem is due to the fact

MS BSC SGSN MSC/VLR

Channel Release

Routing Area Update Request

(no Resumption Result)

iIn BR7.0, the GPRS/EGPRS Suspend/Resume feature is automatically enabled in thesystem, and both T3 and T4 timers cannot be set by the operator, but assume thefollowing default values:- T3 = 5 s- T4 = 1 s

A30808-X3247-L24-5-7618 231

InformationSystem


that GPRS mobiles are not able to read the USF in downlink blocks transmitted with8PSK modulation; 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 intoaccount their different QoS requirements. The scheduler then assures that each TBF isserved according to its own priority.

9.9.7.1 Supported QoS AttributesAs previously mentioned, the task of the scheduler is to distribute permissions to accessthe 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 behandled by the BSS; these attributes are different between the uplink and downlinkdirections.

Regarding downlink scheduling, the BSC handles the following two R97/98 attributesspecified in the DL-UNITDATAs coming from the Gb interface:– Peak Throughput (used in the allocation phase)– Service Precedence

The Service Precedence, strictly speaking, indicates the relative importance of main-taining the service commitments under abnormal conditions, for example which packetsare 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 seemsreasonable 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 thesame resources) are defined as follows:

When multiple TBFs are allocated on the same physical resources, they will be servedaccording to their own scheduling priorities, see next paragraphs for details.

Regarding the scheduling of uplink TBFs, the Radio Priority attribute is used. Such anattribute is mapped one to one to uplink scheduling priority as follows:

9.9.7.2 Scheduling ProcessAs a general rule, the scheduling algorithm for each PDCH checks the active TBFs ontothat timeslot, both in uplink and downlink directions; then it verifies the scheduling prior-

QoS Attribute Scheduling PriorityService Precedence = 1 1Service Precedence = 2 2Service Precedence = 3 3

QoS Attribute Scheduling PriorityRadio Priority = 1 1Radio Priority = 2 2Radio Priority = 3 3Radio Priority = 4 4

232 A30808-X3247-L24-5-7618


ities of each TBF, and associates the corresponding scheduling weights Wk to eachpriority.

In fact, each scheduling priority is associated with a specific scheduling weight: theassociation between priorities and weights can be performed by the user with thefollowing parameters:– SCHWEIPRI1: weight associated to scheduling priority 1– SCHWEIPRI2: weight associated to scheduling priority 2– SCHWEIPRI3: weight associated to scheduling priority 3– SCHWEIPRI4: weight associated to scheduling priority 4

For each direction of transmission and for each timeslot, the algorithm selects a TBFusing an approach that guarantees that each TBF(i) is selected W(i) times eachsum(Wk) extractions, where W(i) is the scheduling weight of TBF(i) and sum(Wk) is thesum 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 anduplink directions. These cases are as follows:• Polling Requests: when an MS must be polled, the scheduler manages the down-

link block (containing the RRBP value) for this MS, with a higher priority than otherblocks to be sent in downlink direction;

• Downlink Control Blocks for uplink TBFs: when a downlink control block (i.e.,Packet Uplink Ack/Nack message) must be sent for an uplink TBF, the schedulermanages the downlink block for this uplink TBF, with a higher priority than otherblocks to be sent in downlink direction;

• Constraint due to PCCCH Scheduling: if the PCCCH channel is allocated on acertain timeslot, some radio blocks in a multiframe should be reserved for PCCCH.Therefore, the scheduler manages, on this timeslot, both the downlink PCCCHblocks (PBCCH, PAGCH, PPCH) and the uplink PCCCH blocks (PRACH) with ahigher priority than other blocks to be sent in downlink/uplink direction on the sametimeslot.

Besides, when EGPRS and GPRS mobiles are multiplexed on the same PDCHs someadditionally constraints must be taken into account. The main problem is due to the factthat GPRS mobiles are not able to read the USF in downlink blocks transmitted with8PSK modulation. Therefore, uplink and downlink scheduling must be performed jointly,trying to avoid setting USFs for GPRS mobiles in 8PSK-coded downlink blocks.

In this case, the problem arises when, e.g., a downlink block coded with 8PSK modula-tion must be sent and at the same time the USF should be coded with GMSK modulationallowing to a GPRS-only mobile station to read the USF value and transmit on the nextuplink 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 isselected; if there are no GMSK USF, then an 8PSK one is selected, because thischoice 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 isselected; if there are no more 8PSK USF to be scheduled (in the list), then:– one more 8PSK USF is selected (starting from UL TBFs with higher

priority/weight)– at the same time one “GMSK USF” is cancelled from the list– after a few cancellations for a given TBF, a GMSK USF for that TBF is inserted in

an High_priority list (i.e., a list of TBF to be served with an higher priority). This

A30808-X3247-L24-5-7618 233

InformationSystem


guarantees that, even in worst case scenarios (only 8PSK TBFs in downlink),some GMSK USFs are still transmitted.

234 A30808-X3247-L24-5-7618


10 GPRS/EGPRS Functionalities

10.1 Cell Selection and Re-selectionNo Handover functionality is foreseen for PS services: the MS selects the best cellfollowing cell re-selection criteria.

If the MS is involved in data transfer, packets may be lost during cell re-selection. Upperlayers will then recognize the inconsistency, discard the frame and ask for a retransmis-sion.

In GPRS standby and ready states (see "9.3.1 Mobility Management States"), cell re-selection is performed by the MS.

The only exception regards class A mobile stations in dedicated mode of a circuitswitched connection: in this case the cell is determined by the network according to thehandover procedures, since the handover takes precedence over GPRS/EGPRS cellre-selection. When the circuit switched connection is released, the MS resumes the cellre-selection process.

For GPRS/EGPRS mobile stations, new re-selection criteria (C1, C31 and C32) can beused. These new algorithms apply to the MSs attached to GPRS/EGPRS if the PBCCHexists in the serving cell.

If PBCCH exists, the MS is not required to monitor system information on both theserving cell and non-serving cells, but is only required to monitor system information onPBCCH of the serving cell. In other words:• if PBCCH is configured, the GPRS/EGPRS MS retrieves all of the information,

regarding both the serving cell and neighboring cells, from the serving PBCCH; theMS monitors the other BCCH carriers only to take signal level measurements;

• if PBCCH is not configured, the GPRS/EGPRS MS retrieves all of the informationregarding the serving cell from the serving BCCH, while the information about neigh-boring cells are taken from the BCCH carriers of the neighboring cells; the MS alsomonitors the other BCCH carriers to take signal level measurements.

If PBCCH is not configured, i.e., PS services are supported only on BCCH, “old” C1 andC2 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 (see "10.3 Network Controlled Cell Reselection and Traffic ControlManagement"), where the network may control the cell selection process.

If the PBCCH is configured, cells to be monitored for cell re-selection are defined in theBA(GPRS) list, which is broadcast on PBCCH. This list could be different from theBA(BCCH) list, that is used for GSM. If PBCCH does not exist, BA(GPRS) list is equalto the BA(BCCH) one (see "10.1.4 Management of GPRS/EGPRS Neighboring Cells").

10.1.1 Measurements for Cell Selection and Re-selectionThe MS measures the received RF signal level on the following:– BCCH carrier of the serving cell– BCCH carriers of surrounding cells as indicated in the BA(GPRS) list

iThe C1 criterion is the same criterion used in GSM cell selection and re-selectionprocesses, but it makes use of new parameters (see "10.1.2.1 GPRS/EGPRS PathLoss Criterion (C1 Criterion)").

A30808-X3247-L24-5-7618 235

InformationSystem


Then it calculates the average received level (RLA_P) for each carrier. In addition theMS verifies the BSIC of the BCCH carriers. Only cells with allowed BSIC are consideredfor re-selection purposes.

A distinction must be done between mobile stations in packet idle mode and mobilestations in packet transfer mode:

a) Packet Idle Mode: whilst in packet idle mode a MS monitors continuously all BCCHcarriers 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 istaken for each paging block monitored by the MS according to its current DRX modeand its paging group (see "9.8.3.2 Discontinuous Reception").The MS will take at least one measurement for each BCCH carrier for every 4seconds. The MS is not required to take more than 1 sample per second for eachBCCH carrier. RLA_P is an average level determined using samples collected overa period of 5 s, and is maintained for each BCCH carrier. The same number ofmeasurement samples is taken for all BCCH carriers, and the samples allocated toeach carrier will as far as possible be uniformly distributed over the evaluationperiod. At least 5 received signal level measurement samples are required for a validRLA_P value. The list of the 6 strongest non serving carriers are updated at a rateof at least once per running average period.The MS will attempt to check the BSIC for each of the 6 strongest non serving cellBCCH carriers at least every 14 consecutive paging blocks of that MS, or 10seconds, whichever is greater. If a change of BSIC is detected then the carrier willbe treated as a new carrier.In the case of a multiband MS, the MS will attempt to decode the BSIC, if any BCCHcarrier with unknown BSIC is detected among the number of strongest BCCHcarriers in each band, as indicated by the GNMULBAC parameter(MULTIBAND_REPORTING); this parameter is broadcast on PBCCH, or if PBCCHdoes not exist, on BCCH.

b) Packet Transfer Mode: while in packet transfer mode, a MS continuously monitorsall BCCH carriers as indicated by the BA(GPRS) list and the BCCH carrier of theserving cell. In every TDMA frame, a received signal level measurement sample istaken on at least one of the BCCH carriers, one after the another. RLA_P is anaverage value determined using samples collected over a period of 5 s, and is main-tained for each BCCH carrier. The samples allocated to each carrier will as far aspossible be uniformly distributed over the evaluation period. At least 5 receivedsignal level measurement samples are required for a valid RLA_P value. The MS willattempt to check the BSIC for each of the 6 strongest non serving cell BCCH carriersas 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 celllist contains cells from other RATs and if indicated by the GUMTSSRHPRI param-eter.The MS will use the two Idle frames of the PDCH multiframe for this purpose. Theseframes are termed “search” frames.In the case of a multiband MS, the MS will attempt to decode the BSIC, if any BCCHcarrier with unknown BSIC is detected, among the number of strongest BCCHcarriers in each band, as indicated by the GNMULBAC parameter(MULTIBAND_REPORTING); this parameter is broadcast on PBCCH, or if PBCCHdoes not exist, on BCCH.

236 A30808-X3247-L24-5-7618


10.1.2 Cell selection and Re-selection Criteria

10.1.2.1 GPRS/EGPRS Path Loss Criterion (C1 Criterion)The MS measures the received signal level on the PBCCH carriers of the serving celland the surrounding cells and calculates the mean received level (RLA_P) for eachcarrier, where:– RLA_P(s) is the averaged level for the serving cell– RLA_P(n) are the averaged levels for neighboring cells

Cells to be monitored for cell reselection are defined by the BA(GPRS) list, which isbroadcast on PBCCH. At least 5 received signal level measurement samples arerequired for a valid RLA_P:

The path loss criterion C1, i.e., the minimum signal level criterion for GPRS/EGPRS cellselection and cell re-selection, is defined by the following:

Where:

The path loss criterion is satisfied if C1>0.

This means that the minimum allowed received downlink level to access the networkmust be above a threshold defined by GRXLAMI value.

To ensure a sufficient uplink received level even for MS of low transmit power level P,the C1 criteria works as follows:

RLA_P = 1/5 * (GPRS_RXLEV1 + GPRS_RXLEV2 + ...+ GPRS_RXLEV5)

C1 = RLA_P – GPRS_RXLEV_ACCESS_MIN – Max(0, GPRS_MS_TXPWR_MAX_CCH–P)

- P is the Power Class of the MS- GPRS_RXLEV_ACCESS_MIN is the minimum allowed received level to access acell; the user can define this value with the GRXLAMI parameter- GPRS_MS_TXPWR_MAX_CCH is the maximum power that the Mobile Station canuse to access the cell; the user can define this value when configuring theGMSTXPMAC parameter related to the Managed Object PTPPKF. This attribute spec-ifies the maximum TX power level that a Mobile Station may use when accessing thesystem in presence of the PBCCH. In case the PBCCH does not exist the MobileStation uses the MSTXPMAXCH attribute to evaluate the path loss criterion parameter“C1” whereas the BSC uses the GMSTXPMAC attribute for the evaluation of the sameparameter. For the serving and neighbour cells the GMSTXPMAC value is sent inbroadcast on the PBCCH of the serving cell.

If P < GPRS_MS_TXPWR_MAX_CCHC1 = RLA_P – GPRS_RXLEV_ACCESS_MIN – (GPRS_MS_TXPWR_MAX_CCH– P)

A30808-X3247-L24-5-7618 237

InformationSystem


Beside the C1 radio criterion, there are some other criteria for a cell to be suitable forGPRS/EGPRS cell selection purpose: a cell is considered suitable for GPRS/EGPRScell selection if:

1. C1 is greater than 02. the cell belongs the selected PLMN3. the cell supports PS services4. the cell is not barred

10.1.2.2 C31 CriterionThe C31 signal level threshold criterion for hierarchical cell structures (HSCs) is used todetermine whether prioritized hierarchical GPRS/EGPRS cell re-selection is applied. Itis defined by:

i.e., the received level must be higher than the access threshold(GPRS_RXLEV_ACCESS_MIN) plus another term, given by the difference betweenthe 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_CCHC1 = RLA_P – GPRS_RXLEV_ACCESS_MIN

i.e., the received level must only be higher than the access threshold(GPRS_RXLEV_ACCESS_MIN); in this case, the nominal power of the MS is higherthan GPRS_MS_TXPWR_MAX_CCH.

iC1 criterion is an assessment about the field strengths (on both uplink and downlinkdirections).If PBCCH is used, the C1 criterion is calculated by the same formula used in GSM, butwith a separate parameter set (i.e., GRXLAMI and GMSTXPMAC), which is transmittedon the PBCCH. With this separate parameter set, it is possible for the network operatorto configure, in a different way, the cell selection and reselection procedures, forGPRS/EGPRS and not-GPRS/EGPRS subscribers.If PBCCH is not configured, the C1 criterion is calculated by means of the same formulaand parameters (i.e., RXLEVAMI and MSTXPMAXCH) used for GSM cell selection andre-selection.Please remember that on PBCCH the network has the chance to indicate in theBA(GPRS) list a different set of neighboring cells with respect to the BA list transmittedon BCCH (see 10.1.4).

Serving CellC31(s) = RLA_P(s) – HCS_THR(s)

Neighboring CellPRIORITY_CLASS(n) = PRIORITY_CLASS (s)C31(n) = RLA_P(n) – HCS_THR(n)

238 A30808-X3247-L24-5-7618


Where:• HCS_THR is the signal threshold for applying GPRS/EGPRS hierarchical cell struc-

tures criteria in cell reselection. The user can define this threshold using theGHCSTH parameter. The user defines the threshold both for the cell and for itsneighboring cells, in fact:– HCS_THR(s) represents the threshold of the serving cell; the user specifies it by

the GHCSTH parameter of the PTPPKF object;– HCS_THR(n) represents the thresholds of neighboring cells; the user sets a

HCS_THR(n) value for every adjacent relationship, by the GHCSTH parameter ofthe ADJC object;

• PRIORITY_CLASS is the priority of each cell. The user can define this priority by theGHCSPC parameter (a higher value means a higher priority). The user defines thepriority 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 GHCSPCparameter of the ADJC object;

• GPRS_TEMPORARY_OFFSET(n) applies a negative offset to C31 for the durationof GPRS_PENALTY_TIME(n) after the timer T has started for that cell.The T timer is started in the MS for each cell in the list of the 6 strongest neighboringcells, as soon as it is placed in the list. T is reset to 0 if the cell is removed from thelist.GPRS_PENALTY_TIME is the duration for which GPRS_TEMPORARY_OFFSETapplies.The user sets a GPRS_TEMPORARY_OFFSET(n) value and aGPRS_PENALTY_TIME(n) value for every adjacent relationship, by GTEMPOFFand GPENTIME parameters of the ADJC object.

Regarding the previous parameters, it is important to underline that their values arebroadcasted on the PBCCH of the serving cell, i.e., the MS can retrieve all of the cell re-selection information from the PBCCH of the serving cell without monitoring the otherneighboring carriers. To understand how this feature is implemented, refer to"10.1.4 Management of GPRS/EGPRS Neighboring Cells". This is different from thetraditional GSM implementation for which the MS must retrieve the cell re-selectionparameters of the neighboring cells, by reading their BCCH carriers.

Neighboring CellPRIORITY_CLASS(n) < > PRIORITY_CLASS (s)There are two cases:If T<=GPRS_PENALTY_TIMEC31(n) = RLA_P(n) – HCS_THR(n) – GPRS_TEMPORARY_OFFSET(n)

If T > GPRS_PENALTY_TIMEC31(n) = RLA_P(n) – HCS_THR(n)

A30808-X3247-L24-5-7618 239

InformationSystem


10.1.2.3 C32 CriterionThe C32 cell ranking criterion is used to select cells among those with the same priority.It is defined by:

Where:• PRIORITY_CLASS is the priority of each cell. The user can define this priority by the

GHCSPC parameter (a higher value means a higher priority). The user defines thepriority 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 the neighboring cells; the user

sets a PRIORITY_CLASS(n) value for every adjacent relationship, by theGHCSPC parameter of the ADJC object;

• GPRS_RESELECT_OFFSET(n) is a positive offset that increases the priority of cellin the list of the strongest neighbor cells. The user sets aGPRS_RESELECT_OFFSET(n) value for every adjacent relationship, byGRESOFF parameter of the ADJC object;

iC31 is used for hierarchical cell structures; the advantage is that C31 also uses a prioritymechanism. It is necessary to introduce C31 into GPRS/EGPRS, to make re-selectionfor PS services similar to the GSM handover algorithm.The MS needs to get information of the neighbor cells (e.g., in which layer the neigh-boring 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 itis not necessary to give additional information to the MS.

Serving CellC32(s) = C1(s)

Neighboring CellPRIORITY_CLASS(n) = PRIORITY_CLASS (s)There are two cases:If T <= GPRS_PENALTY_TIMEC32(n) = C1(n) + GPRS_RESELECT_OFFSET(n) –GPRS_TEMPORARY_OFFSET(n)

If T > GPRS_PENALTY_TIMEC32(n) = C1(n) + GPRS_RESELECT_OFFSET(n)

Neighboring CellPRIORITY_CLASS(n) < > PRIORITY_CLASS (s)C32(n) = C1(n) + GPRS_RESELECT_OFFSET(n)

240 A30808-X3247-L24-5-7618


• GPRS_TEMPORARY_OFFSET(n) applies a negative offset to C32 for the durationof GPRS_PENALTY_TIME(n) after the timer T has started for that cell.The T timer is started in the MS for each cell in the list of the 6 strongest neighboringcells, as soon as it is placed on the list. T is reset to 0 if the cell is removed from thelist.GPRS_PENALTY_TIME is the duration for which GPRS_TEMPORARY_OFFSETapplies.The user sets a GPRS_TEMPORARY_OFFSET(n) value and aGPRS_PENALTY_TIME(n) value for every adjacent relationship, by GTEMPOFFand GPENTIME parameters of the ADJC object.

GPRS_RESELECT_OFFSET, GPRS_TEMPORARY_OFFSET, PRIORITY_CLASSand GPRS_PENALTY_TIME are broadcast on PBCCH of the serving cell.

Regarding the previous parameters it is important to underline that their values arebroadcasted on the PBCCH of the serving cell, i.e., the MS can retrieve all of the cell re-selection information from the PBCCH of the serving cell without monitoring the otherneighboring carriers. To understand how this feature is implemented, see"10.1.4 Management of GPRS/EGPRS Neighboring Cells". This is different from thetraditional GSM implementation for which the MS must retrieve the cell re-selectionparameters of the neighboring cells, by reading their BCCH carriers.

10.1.3 Cell Re-selection AlgorithmThe MS makes a cell reselection if:• C1 (serving cell) < 0 for a period of 5 seconds• MS detects DL Signalling failure (e.g., no paging has been possible)• Cell becomes barred

Beside these conditions that regard only the serving cell, other conditions derive fromthe 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 BCCH;

b) Both GPRS/EGPRS serving cell and GPRS/EGPRS neighboring cells config-ured with PBCCH.

a) GPRS/EGPRS serving cell and GPRS/EGPRS neighboring cells configured withBCCH

C2 (GSM) criteria is switched on; a cell reselection is executed if:

C2 (GPRS/EGPRS serving cell) < C2 (suitable GPRS/EGPRS neighboring cell)

If the suitable neighboring cell is in the same location area for a period of 5sec.

iC32 is similar to the C2 criteria used for GSM, but it makes use of GPRS/EGPRSparameters.C32 contains, in addition to C1, an offset (to make a cell better or worse than another)and a temporary offset, which is used to make the cell worse during the first x seconds(i.e., the MS must "see" that cell for that period of time before it may re-select it; this canbe used to prevent some cells from beeing re-selected by a fast driving MS).

A30808-X3247-L24-5-7618 241

InformationSystem


C2 (GPRS/EGPRS serving cell) + CELL_RESELECT_HYST < C2 (suitableGPRS/EGPRS neighboring cell)

If the suitable neighboring cell is in another location area for a period of 5 s.

C2 (GSM) criteria is not switched on; a cell reselection is executed if:

C1 (GPRS/EGPRS serving cell) < C1 (suitable GPRS/EGPRS neighboring cell)

If the suitable neighboring cell is in the same location area for a period of 5 seconds.

C1 (GPRS/EGPRS serving Cell) + CELL_RESELECT_HYST < C1 (suitableGPRS/EGPRS neighboring cell)

If the suitable neighboring cell is in another location area for a period of 5 s.

b) GPRS/EGPRS serving cell and GPRS/EGPRS neighboring cells configured withPBCCH

First, the C31 criterion for the serving cell and all neighboring cells is calculated.

The best cells are found under all of these cells, therefore the following is checked:

If there are cells for which C31>=0 , then the PRIORITY_CLASS is checked only forthese cells.

If there is only one cell with the highest PRIORITY_CLASS, then this cell will be the bestcell to make cell reselection on.

If there are more cells with the highest PRIORITY_CLASS, then the C32 criterion will becalculated for these cells. The cell with the highest C32 criterion will be the best cell onwhich to make 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 fromthe C32 value of the neighboring cells:

a) in standby state, if the new cell is in the same routing area no hysteresis values aresubtracted;

b) in ready state, if the new cell is in the same routing area, aGPRS_CELL_RESELECT_HYSTERESIS value is subtracted to delay a cell re-selection, since a TBF might be interrupted; the user sets this hysteresis with theGCELLRESH parameter.

c) in standby or ready state, if the new cell is in a different routing area aRA_RESELECT_HYSTERESIS value is subtracted to delay a cell re-selection,

iThe C1 value of the neighboring cell must obviously be greater than 0.

iThe CELL_RESELECT_HYST value is defined by the user through the GSM CELL-RESH parameter.

iIf the C31H parameter (C31_HYST) is set to TRUE, and the MS is in MMready state, the GPRS_CELL_RESELECT_HYSTERESIS is alsosubtracted from the C31 value for the neighboring cells.

242 A30808-X3247-L24-5-7618


because routing area changes will produce a lot of extra signalling; the user sets thishysteresis using the RARESH parameter.

d) if a cell re-selection occurred within the previous 15 seconds, a value of 5dB issubtracted.

C31_HYST, RA_RESELECT_HYSTERESIS, and RA_RESELECT_HYSTERESIS arebroadcast on the PBCCH of the serving cell.

Cell re-selection for any other reason (see GSM 03.22) takes place immediately, but thecell that the MS was camped on will not be returned to within 5 seconds, if another suit-able cell can be found. If valid RLA_P values are not available, the MS will wait untilthese values are available and then perform the cell re-selection if it is required. The MSmay accelerate the measurement procedure within the requirements to minimize the cellreselection delay. If no suitable cells are found within 10 seconds, the cell selection algo-rithm will be performed. Since information concerning a number of channels is alreadyknown by the MS, it may assign high priority to measurements on the strongest carriersfrom which it has not previously made attempts to obtain BCCH information and omitrepeated measurements on the known ones.

10.1.4 Management of GPRS/EGPRS Neighboring Cells

10.1.4.1 Handling of Neighboring CellsA mechanism has been introduced to manage both internal adjacent cells (i.e., cellsbelonging to the same BSC) and external adjacent cells (i.e., cells belonging to otherBSCs).

The management of both internal and external adjacent cells is provided by using theTGTCELL attribute of the ADJC object; this attribute is a mandatory one that specifiesthe path of the target cell instance (see the explanation below).

Upon creating an adjacent cell relationship, a distinction will be made between twopossible situations:• adjacency between cells supporting only GSM service (adjacent relationships

between BTSs)• adjacency between cells supporting GPRS/EGPRS service too (adjacent relation-

ships between PTPPKFs)

ADJACENT RELATIONSHIPS BETWEEN BTSs

In case of an adjacency to an internal BTS, the TGTCELL attribute will contain a refer-ence (i.e., the complete path) to the internal target BTS.

In case of external adjacency, the TGTCELL attribute will contain a reference to a newobject, namely the TGTBTS object. A TGTBTS managed object instance contains acopy of the attributes of an external BTS MOI, to which an adjacent relationship must bemade up. Once a TGTBTS MOI is configured, it will be treated by the system for themanagement of the adjacencies, as the other internal target BTSs.

iIf the parameter C32QUAL (C32_QUAL) is set to TRUE, positiveGPRS_RESELECT_OFFSET values are only applied to the neighbors with the highestRLA_P value, among those cells for which C32 is compared above.

A30808-X3247-L24-5-7618 243

InformationSystem


This means that, in the case in which the external target BTS is adjacent to more thanone internal serving BTS, it will no longer be necessary to replicate all of the attributevalues in every ADJC managed object instance, but it will be enough that the differentADJC MOIs refer to the same TGTBTS MOI.

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 attributesthat are not enclosed in BTS:2 (i.e., handover management attributes), while for theother attributes (i.e., BCCH, BSIC, CELLGLID, etc.) the TGTCELL attribute provides thereference to BTS:2.

When the user creates the ADJC2 instance, he/she must specify only those attributesthat are not enclosed in BTS:5 (i.e., handover management attributes). The TGTCELLattribute will provide the reference to the TGTBTS:0 instance, that contains all of theattributes (i.e., BCCH, BSIC, CELLGLID, etc.) enclosed in BTS:5.

Therefore, the user must create the TGTBTS instance containing the attributesbelonging to the external cell, before creating an external adjacent relationship.

244 A30808-X3247-L24-5-7618


ADJACENT RELATIONSHIPS BETWEEN PTPPKFs

The same considerations apply for the management of the adjacencies betweenPTPPKFs. The TGTPTPPKF object class is introduced to configure, in the BSC data-base, external GPRS/EGPRS neighboring cells.

The TGTPTPPKF object class is hierarchically dependent on the TGTBTS object classin the containment tree. A TGTPTPPKF managed object instance will contain a copy ofthe attributes, of an external PTPPKF instance, involved in the management of the adja-cency. Once a TGTPTPPKF object instance is configured, it is treated by the system forthe management of the adjacencies, as the other internal target PTPPKFs.

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 will identify the TGTPTPPKF object

instance, through the reference to the superordinate TGTBTS object instance

10.1.4.2 GPRS/EGPRS Neighboring Cells and Involved ParametersAs described in the previous chapters, cell re-selection parameters of both the servingcell and its neighboring cells are transmitted on the PBCCH of the serving cell. In thisway, a MS camped on a cell can read all of the re-selection parameters without synchro-nizing to the other cells.

This happens only if the PBCCH is configured on the serving cell; if the PBCCH is notconfigured on the serving cell:

1. “old” C1 and C2 GSM criteria, and “old” GSM parameters are used for cell re-selec-tion;

2. the MS takes the re-selection parameters of the neighboring cells from the BCCHsof those cells; i.e., the MS must synchronize to these cells to read their data.

To allow the MS to read from the PBCCH of the serving cell, the re-selection parametersof neighboring cells, the involved parameters are specified either in the PTPPKF or inthe ADJC/TGTPTPPKF objects. Tab. 10.2 illustrates these parameters.


TGTPTPPKF Configure external GPRS/EGPRS neighboringcells.

Tab. 10.1 TGTPTPPKF Object

iFor each serving cell, it is possible to configure up to 32 neighboring cells supportingGPRS/EGPRS.

Siemens ETSI

GRXLAMI GPRS_RXLEV_ACCESS_MIN

GMSTXPMAC GPRS_MS_TXPWR_MAX_CCH

GHCSTH HCS_THR

Tab. 10.2 Parameters involved in the management of GPRS/EGPRS neighboringcells

A30808-X3247-L24-5-7618 245

InformationSystem


Among parameters shown in Tab. 10.2, a distinction must be made with the following:

a) GRXLAMI and GMSTXPMAC parameters are only cell parameters; i.e., they mustbe defined only on a cell basis, using the PTPPKF object. Nevertheless, to allow thetransmission of the neighboring cell parameters in the packet system information ofthe serving cell, they will also be defined for every adjacent relationship; they mustbe defined in the TGTPTPPKF object, only if the adjacent cell does not belong to thesame BSC of the serving one;

b) GHCSTH and GHCSPC parameters are defined both on a cell basis and on theadjacent relationship basis;– they are defined on a cell basis in the PTPPKF object to define the cell values;– for each neighboring cell of the involved cell, the two parameters are specified in

the ADJC object, to specifies the values of the neighboring cells.c) GRESOFF, GTEMPOFF, and GPENTIME parameters regard only adjacent rela-

tionships; i.e., for each neighboring cell of the involved cell, the parameter values arespecified in the ADJC object to indicate the values of the neighboring cells.

To manage the previous features, the following parameters (belonging to the ADJCobject) are involved:

1. The GSUP parameter is meaningful only if the PBCCH is configured on the servingcell. It enables the transmission of parameters of the neighboring cell to which itrefers, in the packet system information of the serving cell. Besides the GSUPparameter can be set also in a different band than the BCCH one. leaving to theoperator choice whether enable GPRs on extended band or not. A The followingconsiderations apply to the GSUP parameter:– if the PBCCH is not enabled in the serving cell, the GSUP in meaningless, but PS

sevices are active in the neighboring cell. So, if the GSUP attribute of one of itsneighboring cell is set to FALSE in the serving cell, the MS can re-select the cell(with GSM C1 and C2) without any problem.

– if the PBCCH is enabled in the serving cell, the neighborhoods that will be consid-ered in the BA(GPRS) list will be those cells for which the GSUP attribute hasbeen set to TRUE in the adjacent relationship.

2. TGTCELL when the cell is internal, this parameter allows making a link to the BTS(PTPPKF) object that defines this cell in the database; if the cell is external, thisparameter allows to making a link to the TGTBTS (TGTPTPPKF) object that definesthis cell in the database.

10.1.4.3 Configuration of an Adjacent Cell with GSUP= TRUEWhen the PBCCH is configured on the serving cell and the user configures a neigh-boring cell with GSUP =TRUE two cases exists:

GHCSPC PRIORITY_CLASS

GRESOFF GPRS_RESELECT_OFFSET

GTEMPOFF GPRS_TEMPORARY_OFFSET

GPENTIME GPRS_PENALTY_TIME

Siemens ETSI

Tab. 10.2 Parameters involved in the management of GPRS/EGPRS neighboringcells

246 A30808-X3247-L24-5-7618


1. the neighboring cell is internal2. the neighboring cell is external

In the following, these two possibilities are examined from the point of view of theGPRS/EGPRS parameters shown in Tab. 10.2.

The Neighboring Cell is INTERNAL

If the target cell is internal, the user, with the TGTCELL attribute, executes a link to theBTS object (and as a consequence to the PTPPKF one) related to this cell.

Regarding parameters shown in Tab. 10.2, the following considerations can be made:

1. GRXLAMI and GMSTXPMAC parameters must not be defined in the TGTPTPPKFobject (because this object, in this case, does not exist for the neighboring cell),since they are cell parameters and are directly taken from the linked PTPPKF object;

2. GHCSPC and GHCSTH parameters could be specified in the ADJC object; if theyare not specified, their default values are taken;

3. GPENTIME, GRESOFF, and GTEMPOFF parameters could be specified in theADJC object; if they are not specified, their default values are taken.

The Neighboring Cell is EXTERNAL

If the target cell is external, the user, with the TGTCELL attribute, executes a link to theTGTBTS object (and as a consequence to the TGTPTPPKF one) related to this cell,since this object does not belong to the same BSC.

Regarding the parameter shown in Tab. 10.2, the following considerations can bemade:

1. GRXLAMI and GMSTXPMAC parameters must be defined in the TGTPTPPKFobject; they must have the same values that have in the PTPPKF object of the BSCdatabase where they have been defined;

2. GHCSPC and GHCSTH parameters could be specified in the ADJC object; if theyare not specified, their default values are taken;

3. GPENTIME, GRESOFF, and GTEMPOFF parameters should be specified in theADJC object; if they are not specified, their default values are taken.

10.1.4.4 Configuration of an Adjacent Cell with GSUP= FALSESince the GSUP attribute is set to FALSE for the neighboring cell, the GPRS/EGPRSre-selection parameters of the neighboring cell are not transmitted in the serving cell.Besides, this cell is not included in the BA(GPRS) list, i.e., the list of cells over whichGPRS/EGPRS re-selection can be done; from the GSM point-of-view, the cell is alwaysconsidered for cell re-selection purposes (using GSM C1 and C2 criteria).

To understand, consider the following example referred to a cell (in which the PBCCHis configured) that has 10 neighboring cells. If:– for 6 neighboring cells, the GSUP attribute is set to TRUE;– for the remaining 4 cells, the GSUP attribute is set to FALSE;

then starting from the serving cell:– 6 cells can be re-selected from the PS/CS services point-of-view by means of C1

(with GPRS/EGPRS parameters), C31 and C32 criteria;

iWhen the target cell is external, both RACODE and RACOL parameters (see"9.2 Network Structure") must be specified in the TGTPTPPKF object; they must havethe same values that they have in the database where they have been defined.

A30808-X3247-L24-5-7618 247

InformationSystem


– 4 cells can be re-selected only from GSM mobile stations by means of C1 (with GSMparameters) and C2 criteria.

In this case, we have a BA(GPRS) list containing 6 cells, and a BA(GSM) list containing10 cells.

When the PBCCH is configured on the serving cell and the user configures a neigh-boring cell with GSUP = FALSE, independently if the neighboring cell is internal orexternal, the GPRS/EGPRS re-selection parameters must not be specified in the ADJCobject, since they are not transmitted on the serving cell.

10.1.5 Abnormal Cell Re-selectionIn the event of an “abnormal release with cell reselection” when PBCCH exists, anabnormal cell reselection based on BA(GPRS) list is attempted.

To enable the abnormal cell re-selection, the RAARET (RANDOM_ACCESS_RETRY)parameter must be set to TRUE. This parameter allows enabling the abnormal cell rese-lection starting from the serving cell, when an abnormal release with cell reselectionoccurs.

The MS performs the following algorithm to determine which cell is to be used for thiscell 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; thecarrier with the highest received average level (RLA) and with a permitted BSIC istaken;

2. on this carrier, the MS attempts to decode the PBCCH data block containing theparameters affecting cell selection;

3. if:– the C1 parameter is greater than zero– the cell belongs to the selected PLMN– the cell is not barred– access in another cell is allowed, i.e., RAARET parameter is set to TRUE, the abnormal cell reselection is attempted on this cell;

4. if the MS is unable to decode the PBCCH data block, or if the conditions in step 3.are not met, the carrier with the next highest received average level (RLA) and witha permitted BSIC is taken; then the MS repeats steps 2. and 3.;

5. if the cells with the 6 strongest received average level values (and with permittedBSICs) have been tried, but cannot be used, the abnormal cell reselection attemptis abandoned, and the usual reselection algorithm (see "10.1.3 Cell Re-selectionAlgorithm") is performed.

When an MS has executed an abnormal cell reselection, it is not allowed to reselect theoriginal cell for a number of seconds specified by the TRESEL parameter.

iConsidering the previous example, if the PBCCH is not configured in the same cell, boththe BA(GPRS) list and the BA(GSM) list are comprised of 10 neighboring cells, sincethe GSUP attribute is meaningless.

iFor example the mobile station starts the “abnormal release with cell reselection” proce-dure after having made M+1 attempts to send a Packet Channel Request on PRACH,without receiving any answer from the network (see "9.8.2.6 Uplink Access on PRACH(Access Persistence Control)").

248 A30808-X3247-L24-5-7618


The MS is under no circumstances allowed to access a cell to attempt abnormal cellreselection later than 20 seconds after the detection within the MS of the abnormalrelease causing the abnormal cell reselection attempt. In the case where the 20 secondselapses without a successful abnormal cell reselection, the attempt is abandoned andthe usual reselection algorithm (see "10.1.3 Cell Re-selection Algorithm") is performed.

In the event of an abnormal release with cell reselection when only BCCH exists, the MSperforms only the usual reselection algorithm, using the C1 and C2 criteria of GSM.

10.2 Cell Re-selection from GSM/GPRS/EGPRS Network toUMTS NetworkWith the introduction of the UMTS network, it becomes very important to allow a dualmode mobile station to re-select a UMTS cell starting from a GSM one.

Without this feature, once a dual mode GSM/UMTS terminal is camped on theGSM/GPRS/EGPRS network, it does not have the possibility to select the UMTSnetwork.

To allow this feature, the UMTS adjacent cell information must be sent (in the 3G CellReselection List) on the broadcast carrier of the GSM network, to inform the UE/MSwhich UMTS frequencies must be monitored for re-selection purposes.

For this monitoring, the MS may use search frames that are not required for BSICdecoding. If indicated by the parameter GUMTSSRHPRI, the MS may use up to 25search frames per 13 seconds without considering the need for BSIC decoding in theseframes.

According to both the type of service that the MS supports and the configuration of theserving GSM cell, two different algorithms are defined to reselect a UMTS cell (eitherFDD cell or TDD one), starting from a GPRS/EGPRS one; so we can have:

1. re-selection of the UMTS cell in case of circuit switched modality; this type of 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 has been configuredin the serving cell.

The two cases are briefly discussed, in the following sections.

10.2.1 GSM-UMTS Re-selection Algorithm: Circuit Switched CaseWhen the PBCCH is not configured in the serving cell, the MS performs a cell re-selec-tion to an adjacent UMTS (FDD or TDD) cell, only if the following conditions are satisfiedfor a period of 5 seconds:

iOnly the re-selection of a UMTS cell starting from the GSM network is considered; theopposite case is outside the scope of this chapter.

for the serving cell:RSCP(UTRAN cell) >= RLA_C_s + XXX_Qoffset

A30808-X3247-L24-5-7618 249

InformationSystem


where:– RSCP (Received Signal Code Power): is the power level received from the UMTS

cell– Ec/No: is the signal/noise ratio regarding the UMTS FDD cell– RLA_C_s: is the power level received from the serving cell– RLA_C_n: is the power level received from neighboring cells– XXX_Qoffset: offset for cell reselection for UMTS cells; the user sets this value by

the FDDQO parameter (BTS object) for FDD cells, or by TDDQO parameter (BTSobject) for TDD cells

– FDD_Qmin: minimum threshold for Ec/No for UMTS FDD cell re-selection; the usersets this value with the FDDQMI parameter of the BTS object

If the 3G Cell Reselection list (sent by the network to the MS) includes UTRAN frequen-cies, the MS will, at least every 5 seconds update the RLA_C value for the serving celland each of the at least 6 strongest non-serving GSM cells.

The MS will then reselect a suitable UTRAN cell if its measured RSCP value exceedsthe value of RLA_C for the serving cell and all of the suitable non-serving GSM cells bythe value XXX_Qoffset for a period of 5 seconds, and (only in case of FDD cells) theUTRAN cells measured Ec/No value is equal or greater than the value FDD_Qmin. Incase of a cell reselection occurring within the previous 15 seconds, XXX_Qoffset isincreased by 5 dB.

If more than one UTRAN cell fulfills the above criteria, the MS selects the cell with thehighest RSCP value.

If the MS has reselected a GSM cell from an UTRAN one, cell reselection to UTRANdoes not occur within 5 seconds, if a suitable GSM cell can be found.

There is also a threshold by which the network indicates whether or not the measure-ments for the cell reselection of the UMTS cells should be performed; the threshold indi-cates if the signal level of the serving cell should be below or above it, in order to performUMTS cells measurements; the user sets this value by the QSRHI parameter of the BTSobject.

10.2.2 GSM-UMTS Re-selection Algorithm: Packet Switched CaseWhen the PBCCH is configured in the serving cell, the MS performs a cell re-selectionto an adjacent UMTS (FDD or TDD) cell, only if the following three conditions are satis-fied for a period of 5 seconds:

for all of the suitable GSM neighboring cells:RSCP(UTRAN cell) >= RLA_C_n + XXX_Qoffset

and also (only for FDD cells):Ec/No (UTRAN FDD cell) >= FDD_Qmin

iFDDQO, TDDQO, FDDQMI, and QSRHI parameters are broadcast on the BCCH of theserving cell.

for the serving cell:RSCP(UTRAN cell) >= RLA_P_s + XXX_GPRS_Qoffset

for all of the suitable GSM neighboring cells:

250 A30808-X3247-L24-5-7618


where:– RSCP (Received Signal Code Power): it is the power level received from the UMTS

cell– Ec/No: is the signal/noise ratio– RLA_P_s: is the power level received from the serving cell– RLA_P_n: is the power level received from the neighboring cells– XXX_GPRS_Qoffset: offset for cell reselection for FDD cells; the user sets this value

with the FDDGQO parameter of the PTPPKF object for FDD cells, or by theTDDGQO parameter of the PTPPKF object for TDD cells

– GFDD_Qmin: minimum threshold for Ec/No for UMTS FDD cell re-selection; theuser sets this value by the GFDDQMI parameter of the PTPPKF object

If the GPRS 3G Cell Reselection list includes UTRAN frequencies, the MS will, at leastevery 5 second, update the value RLA_P for the serving cell and each of the at least 6strongest non-serving GSM cells.

The MS will then reselect a suitable UTRAN cell if its measured RSCP value exceedsthe value of RLA_P for the serving cell and all of the suitable non-serving GSM cells bythe value XXX_GPRS_Qoffset for a period of 5 seconds and (only in case of FDD cells)the UTRAN cells measured Ec/No value is equal or greater than the value FDD_Qmin.If a cell reselection occurrs within the previous 15 seconds, XXX_GPRS_Qoffset isincreased by 5 dB.

If more than one UTRAN cell fulfills the above criteria, the MS selects the cell with thehighest RSCP value.

If the MS has reselected a GSM cell from an UTRAN one, cell reselection to UTRANdoes not occur within 5 seconds, if a suitable GSM cell can be found.

There is also a threshold by which the network indicates whether or not the measure-ments for the cell reselection of the UMTS cells should be performed; the threshold indi-cates if the signal level of the serving cell should be below or above it, in order to performUMTS cells measurements; the user sets this value by the QSRHPRI parameter of thePTPPKF object.

10.2.3 Handling of UMTS Neighboring CellsBesides defining the re-selection criteria, the user must also define the UMTS neigh-boring cells to be re-selected (obviously a UMTS cell is always considered an externalcell, i.e., a cell that does not belong to the BSC). To define a UMTS neighboring cell for

RSCP(UTRAN cell) >= RLA_P_n + XXX_GPRS_Qoffset

and also (only for FDD cells):Ec/No (UTRAN FDD cell) >= GFDD_Qmin

iFDDGQO, TDDGQO, GFDDQMI, and QSRHPRI parameters are broadcast on thePBCCH of the serving cell.

A30808-X3247-L24-5-7618 251

InformationSystem


a specific BTS object instance, the user create an instance of the ADJC3G object(subordinated to the BTS one).

The TGTCELL parameter of the ADJC3G object contains a reference to the following:• a TGTFDD object instance, in case of FDD neighboring cell; a TGTFDD managed

object instance contains all of the parameters that allow describing, in the BSC data-base, the external UMTS FDD cell (the same principle as described in"10.1.4.1 Handling of Neighboring Cells" is also used to manage external UMTScells).The following are the more important parameters of the TGTFDD object:– CELLGLID (C-ID cell identifier): identifies univocally the UMTS FDD cell in the

UMTS/GSM networks and it is composed by MCC (Mobile Country Code), MNC(Mobile Network Code), LAC (Location Area Code) and CI (Cell Identifier)

– FDDARFCN: defines the frequency of the cell– RNCID: identifies the RNC– FDDSCRMC: defines the scrambling code– FDDDIV: indicates if diversity is applied for the cell

• a TGTTDD object instance, in case of TDD neighboring cell; a TGTTDD managedobject instance contains all the parameters that allow describing, in the BSC data-base, the external UMTS TDD cell.The following are the more important parameters of the TGTTDD object:– CELLGLID (C-ID cell identifier): it identifies univocally the UMTS TDD cell in the

UMTS/GSM networks and it is composed by MCC (Mobile Country Code), MNC(Mobile Network Code), LAC (Location Area Code) and CI (Cell 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 object related to an UMTS neighboring cell of aspecific BTS, the user must already have created either the TGTFDD or the TGTTDDobject defining the UMTS cell.

In this way, different BTS objects, that have the same UMTS cell as neighboring cell, willindicate the same TGTFDD (or the same TGTTDD) object instance in the adjacent rela-tionship defined by the subordinate ADJC3G object instance.

EXAMPLE: if the TGTFDD:0 instance has been created to define a UMTS cell in theBSC database, this UMTS cell can be defined as adjacent to both the BTS:1 and BTS:5cells 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, theuser sets the TGTCELL attribute equal to TGTFDD:0;

– 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, theuser sets the TGTCELL attribute equal to TGTFDD:0.

iFor each BTS object instance the user can define up to 64 neighboring UMTS cells(ADJC3G object).For each BTS object instance, the user can define up to 32 neighboringGSM/GPRS/EGPRS cells (ADJC object) if there are no UMTS neighboring cells, andup to 31 neighboring GSM/GPRS/EGPRS cells (ADJC object) if UMTS neighboringcells are defined.

252 A30808-X3247-L24-5-7618


10.3 Network Controlled Cell Reselection and Traffic ControlManagementAs described in "10.1 Cell Selection and Re-selection", the cell reselection algorithm isexecuted normally by the mobile station. Every MS in packet idle mode and in packettransfer mode measures received signals from both the serving cell and neighboringcells, and performs autonomously cell reselection.

The Network Controlled Cell Reselection is another available cell reselection method:the network may request the measurement reports from the MSs and control their cellreselection.

Therefore, if the user enables this feature, the network can ask the mobile to transmitthe 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 aanother cell, which is better from a radio condition point-of-view. This algorithm is calledRadio Link Network Controlled Cell Reselection because the network cell reselectionbrings 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 aslong as there are available resources in a given cell. This might lead to congestion,although traffic capacity might be available in neighboring cells. Therefore, if the userenables the Traffic Control feature, the network may redistribute MSs among cells tosatisfy the maximum number of service requests, i.e., the Traffic Control NetworkControlled Cell Reselection can be executed.

The Traffic Control network controlled cell reselection guarantees the optimum usage ofresources, i.e., the better traffic distribution among the available channels in all of theavailable cells. So, even if the handover functionality is not foreseen for GPRS/EGPRSservices, the functionality of the traffic control network controlled cell re-selection hasthe same purpose of the handover due to traffic, i.e., the distribution of MSs among cellsaccording to network criteria.

The following must be clear:

a) if the user enables only the network controlled cell reselection feature, only theRadio Link controlled cell reselection is enabled;

b) if the user wants to enable the Traffic Control controlled cell reselection, he/she mustenable, besides the network controlled cell reselection, the traffic control strategy.

The topics below are described in the following paragraphs:– 10.3.1 describes how the network controlled cell reselection works– 10.3.1.1 describes some notes about packet measurement reports– 10.3.1.2 describes the Radio Link network controlled cell reselection algorithm– 10.3.1 and 10.3.2.1 describe the Traffic Control strategy and the related traffic

control network controlled cell reselection algorithm

10.3.1 Network Controlled Cell ReselectionWith Network controlled cell reselection, the network may request measurement reportsfrom the MSs and control their cell re-selection.

The NTWCOR (NETWORK_CONTROL_ORDER) parameter indicates if and how thenetwork controls the reselection process. The meaning of different values of theNTWCOR parameter is specified as follows:

A30808-X3247-L24-5-7618 253

InformationSystem


• NC0: normal MS control; the MS performs autonomous cell re-selection asdescribed in "10.1 Cell Selection and Re-selection"

• NC1: MS control with measurement reports; the MS sends measurement reports tothe network, but it performs autonomous cell re-selection

• NC2: network control; the MS sends measurement reports to the network, and itdoes not perform autonomous cell re-selection

The NETWORK_CONTROL_ORDER parameter is broadcast from the network to allMS in the cell, by PSI5 on PBCCH or SI13 on BCCH. Alternatively, the network can usethe Packet_Measurement_Order or Packet_Cell_Change_Order messages on PACCHto address a particular MS.

To enable the Network Controlled Cell Reselection feature, the user must set the NCRE-SELFLAG parameter, belonging to the BSC object, at ENABLE.

When the feature is enabled, the network can ask the mobile (by setting the NTWCORparameter for that mobile, see below) to transmit the carrier level of both serving andadjacent cells; then the MS sends measurement reports periodically. The period isdefined by two attributes:– NTWCREPPIDL (NC_REPORTING_PERIOD_I) for MS in idle mode– NTWCREPPTR (NC_REPORTING_PERIOD_T) for MS in transfer mode

GPRS and EGPRS mobiles in packet idle mode always work in NC0 mode, otherwisethe network would have to manage the packet measurement reports and associatedaccess requests needed by mobiles to transmit periodically packet measurementreports. In fact, taking into account that the longest period of transmission of packetmeasurement report for mobile in packet idle mode is about 60 seconds, at least 60channel requests per mobile per hour must be considered only for measurement reporttransmission; this would hardly increase PCU real time requirements. In addition, thereare impacts even on battery power safe.

Consequently, NC2 will be used only for mobiles in packet transfer mode, which will thensubmit measurement reports with the reporting period defined by NTWCREPPTR.

Therefore, if the network controlled cell reselection is enabled (NCRESELFLAG set atENABLE) things work in the following way.

The NTWCOR broadcast value (PSI5 on PBCCH or SI13 on BCCH) is always NCO, soevery mobile station in packet idle mode does not transmit any packet measurementreport to the BTS.

When a GPRS/EGPRS mobile station is involved in a TBF (uplink or downlink), the BSCmodifies the NTWCOR mode value, from NC0 to NC2, by the Packet MeasurementOrder message, transmitted to that single mobile on PACCH. This message also carriesthe NTWCREPPTR parameter, which overwrites the correspondent value optionallybroadcasted by PSI5 or SI13. In the Packet Measurement Order message, NTWCN-DRXP and NTWCREPPIDL have no significant value (MS transmits packet measure-ment report only in packet transfer mode).

iRemember that when the user set the NCRESELFLAG parameter at ENABLE, only theradio link controlled cell reselection is enabled.

iRegarding measurement reports, there is also the NTWCNDRXP parameter thatdefines the minimum time the mobile station will stay in non-DRX mode after a measure-ment report has been sent with the mobile in packet idle mode; however this parameteris not used, since MSs in packet idle mode do not send measurement reports.

254 A30808-X3247-L24-5-7618


After this change, mobile working in NC2 control mode periodically transmits PacketMeasurement 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 needed conditions are verified (see "10.3.1.2 Radio Link Network Controlled CellReselection Algorithm" and "10.3.2.1 Network Controlled Cell Reselection Algorithm forTraffic Control Strategy") the BSC may transfer the MS to another cell by a Packet CellChange Order message; this message contains the following:– characteristics of the new cell that are necessary to identify it (i.e., BSIC + BCCH

frequency)– network controlled measurement parameters valid for the mobile station in the new

cell (e.g., NTWCREPPTR)– IMMEDIATE_REL parameter

Upon receipt of the Packet Cell Change Order message the mobile station starts timerT3174. When a network controlled cell reselection is made, the mobile station will actupon the IMMEDIATE_REL value which has been received in the Packet Cell ChangeOrder. If required, it will immediately abort any TBF in progress by immediately ceasingto decode the downlink and transmit on the uplink, stopping all RLC/MAC timers exceptfor timers related to measurement reporting, otherwise the mobile station may continueits operation in the old serving cell until TBF end. The mobile station will then switch tothe identified new cell and will obey the relevant RLC/MAC procedures on this new cell.

The mobile station regards the procedure as completed when it has received asuccessful response to its access request on the new cell.

If timer T3174 expires before a response to the access request message has beenreceived on the new cell, or if an IMMEDIATE ASSIGNMENT REJECT or PACKETACCESS REJECT message is received from the new cell, or if the contention resolutionprocedure fails on the new cell, then the mobile station will start the T3176 timer andreturn to the old cell.

If the mobile station was in uplink packet transfer mode or in a simultaneous uplink anddownlink packet transfer mode before the cell change, the mobile station will establisha new uplink TBF and send the PACKET CELL CHANGE FAILURE message on thisTBF. The mobile station will then resume its uplink transfer on this TBF. When themobile station has sent a PACKET CELL CHANGE FAILURE message, timer T3176 willbe stopped. If T3176 expires and the mobile station was previously in an uplink packettransfer mode or in a simultaneous uplink and downlink packet transfer mode on the oldcell, the mobile station will perform the abnormal release with random access.

If the mobile station was previously in a downlink packet transfer mode only on the oldcell, the mobile station will perform an abnormal release with return to CCCH or PCCCH.

On the mobile station side, if the Packet Cell Change Order message instructs themobile station to use a frequency that it is not capable of using, then the mobile stationwill return a PACKET CELL CHANGE FAILURE message with cause "frequency notimplemented". If the Packet Cell Change Order message is received by the mobile whilea circuit switched connection is on-going, then the mobile station will return a PACKETCELL CHANGE FAILURE message with the cause "on-going CS connection".

When a network controlled cell reselection occurs (ordered by the BSC), the BSS willsignal this exception condition to a SGSN by sending a RADIO-STATUS PDU (RadioCause value: cell reselection ordered). It will contain a reference to the MS, (either TLLIor TMSI or IMSI).

A30808-X3247-L24-5-7618 255

InformationSystem


This condition indicates that the SGSN should wait for a cell update or a routing areaupdate before resuming the transmission of LLC PDU to the BSS.

When the MS changes the cell, it starts a cell update procedure or a routing area updateprocedure towards the SGSN.

After this procedure, the SGSN transmits the FLUSH_LL message towards the BSCindicating the new cell where the MS is entered.

The BSC uses this indication to route the queued RLC blocks related to that MS; if thecell belongs to a different PPXU, the queued RLC blocks are discarded. Then the BSCtransmits the FLUSH_LL_ACK message to the SGSN, indicating if re-route or discardis made. It is responsibility of the higher layer protocols in the SGSN to cope withdiscarded LLC frames. If new cell belongs to another SGSN, an inter_SGSN routingarea update is required before the TBF starts in the new cell (Fig. 10.2 shows thisprocedure).

Before ending TBF, the BSC changes the network control mode to NC0, so when thismobile station enters the packet idle mode, it no longer transfers packet measurementreports.

Fig. 10.2 Network Controlled Cell Reselection Procedure

10.3.1.1 Measurement ReportingAfter each reporting period defined by NTWCREPPTR, the MS sends a measurementreport to the BSS.

The MS will then discard any previous measurement report, that it has not been able tosend. The Packet Measurement Report contains:

MS BSC SGSN

Packet Cell Change Order

Radio Status

Cell Change

Start T3174

Packet Channel Request

Packet Uplink Assignment

Stop T3174

LLC (Cell Update)

Flush LL

RLC Block

RLC Block

256 A30808-X3247-L24-5-7618


– 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 6strongest carriers and BSIC is successfully decoded and allowed i.e., either equal to theBSIC of the list or with allowed NCC part of BSIC. In the latter case, which applies forBA(BCCH) where no BSIC is given, the decoded BSIC will be included in the report.

In the case of a multiband MS, the MS will report the number of the strongest BCCHcarriers in each band as indicated by the GNMULBAC parameter, broadcast onPBCCH, or if PBCCH does not exist, on BCCH.

For multi-RAT MS, the MS will report the number of valid cells in each other radio accesstechnology as indicated by specific parameters: GFDDMURREP (GPRS FDDMULTIRAT REPORTING) and GTDDMURREP (GPRS TDD MULTIRAT REPORTING)parameters define the number of valid UMTS neighbor cells (FDD and TDD) which willbe reported by the MS/UE. The remaining positions in the measurement report will beused for reporting of GSM cells. If remaining positions still exist, these will be used toreport the next valid UMTS cells. In this case, the received signal level is replaced by therelevant measurement quantity.

10.3.1.2 Radio Link Network Controlled Cell Reselection AlgorithmWhen the network controlled cell reselection is enabled (i.e., the NCRESELFLAGparameter is set at ENABLE) the radio link controlled cell reselection algorithm isexecuted by the BSC.

When the radio scenario of the mobile station is degraded, the BSC chooses a betterneighboring cell and commands that mobile to move on this new cell.

According to what was described in "10.3.1 Network Controlled Cell Reselection", themobile station sends measurement reports to the BSC; when the BSC receives a packetmeasurement report from a mobile, the following values are calculated:– the C1 value for the serving cell [C1(s)]– and the C1 value for each adjacent cell [C1(n)] reported in the packet measurement

report

The C1 value for both serving and neighboring cells is calculated with the followingcriteria:

!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 areceived level parameter.Therefore, the GFDDREPQTY parameter (FDD_REP_QUANT) is introduced in order totell the GPRS/EGPRS attached MS/UE whether to report the RSCP value(GFDDREPQTY=RSCP) or the Ec/No one (GFDDREPQTY=EC_NO) to the BTS.

iNetwork Controlled Cell Reselection towards the UMTS network is not supported inBR7.0.

iThe algorithm works independently if the GPRS/EGPRS control strategy (see"10.3.2 GPRS/EGPRS Traffic Control Strategy") has been enabled by the operator.

C1 = RLA_P – GPRS_RXLEV_ACCESS_MIN – Max( 0,GPRS_MS_TXPWR_MAX_CCH – P)

A30808-X3247-L24-5-7618 257

InformationSystem


Where:

If C1(s) < NCC1TH, the mobile must be moved to another cell, to avoide losing it.

First of all, among the neighboring cells reported in the packet measurement report, onlythose for which C1 (n) > NCC1THADJC are selected.

Then, according to the value of the NCSARA attribute, the selected cells are orderedaccording to different priorities.

If NCSARA = TRUE, the adjacent cell is searched, before, among cells belonging to thesame routing area of serving cell; therefore the following priorities are used to ordercells:

1. target cell with the same Routing Area on the same PPXU/PPCU2. target cell with different Routing Area but on the same PPXU/PPCU3. target cell with the same Routing Area on different PPXU/PPCU and same BSC4. target cell with different Routing Area on different PPXU/PPCU and same BSC5. target cell on different PPXU/PPCU and different BSC

If NCSARA = FALSE, adjacent cells of the same routing area have no priority comparedto adjacent cells of other routing areas; therefore the following priorities are used toorder cells:

1. target cell with the same RA or target cell with different RA, but on the samePPXU/PPCU

2. target cell on different PPUX/PPCU and same BSC3. target cell on different PPUX/PPCU and different BSC

Among neighboring cells with the same priority, the cell with the highest C32(n) value ischosen. The C32(n) value is calculated as follows:

Where:• NC_GPRS_RESELECT_OFFSET(n) is a positive offset that increases the priority

of cell in the list of the strongest neighbor cells. The user sets a

- P is the Power Class of the MS- GPRS_RXLEV_ACCESS_MIN is the minimum allowed received level to access acell; the user can define this value by the GRXLAMI parameter (for the serving cell thisparameter is set in the PTPPKF object, for neighboring cells it is set in the TGTPTPPKFone)- GPRS_MS_TXPWR_MAX_CCH is the maximum power that the MS can use toaccess the cell; the user can define this value by the GMSTXPMAC parameter (for theserving cell this parameter is set in the PTPPKF object, for neighboring cells it is set inthe TGTPTPPKF one).

iThe PKTMEASREPCNT parameter specifies how many consecutive measurements ofthe BCCH carrier of the serving cell, under the NCC1TH threshold, are necessary toorder a cell change.

there are two cases:If T <= NC_GPRS_PENALTY_TIMEC32(n) = C1(n) + NC_GPRS_RESELECT_OFFSET(n) –NC_GPRS_TEMPORARY_OFFSET(n)

If T > NC_GPRS_PENALTY_TIMEC32(n) = C1(n) + NC_GPRS_RESELECT_OFFSET(n)

258 A30808-X3247-L24-5-7618


NC_GPRS_RESELECT_OFFSET(n) value for every adjacent relationship, byNCGRESOFF parameter of the ADJC object;

• NC_GPRS_TEMPORARY_OFFSET(n) applies a negative offset to C32 for theduration of NC_GPRS_PENALTY_TIME(n) after the timer T has started for that cell.The T timer is started for each cell in the list of the 6 strongest neighboring cells, assoon 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 whichNC_GPRS_TEMPORARY_OFFSET applies.The user sets a NC_GPRS_TEMPORARY_OFFSET(n) value and aNC_GPRS_PENALTY_TIME(n) value for every adjacent relationship, by NCGTEM-POFF and NCGPENTIME parameters of the ADJC object.

When NCSARA is set at FALSE, a hysteresis value is subtracted from the C32 value forthe neighbor cells. The hysteresis value can be set by the user via the NCRARESHparameter belonging to the PTPPKF object. NCRARESH must be set at DB00 (defaultvalue) when NCSARA is set at TRUE.

Moreover, in order to prevent “ping_pong” effect due to questionable MS behaviourduring Network Controlled Cell Reselection, the TRFPSCTRL parameter in the objectPTPPKF is used to avoid too frequent cell reselection of the same adjacent cell.To thisend, BSC doesn’t order to MS to move again into same adjacent target cell where aNCCR failed,in spite of good radio link scenario ,until timer TRFPSCTRL is expired andthe following condition is satisfyied:– STGTTLLIINF > TRFPSCTRL

10.3.2 GPRS/EGPRS Traffic Control StrategyThe GPRS/EGPRS Traffic Control Strategy feature makes it possible to control the trafficdistribution among cells belonging to the same PCU; the feature is based on theNetwork Controlled Cell Reselection one (see 10.3.1) and on appropriate traffic thresh-olds set in each cell.

In fact, the Network Controlled Cell Re-Selection feature introduces the management ofmeasurements related to the neighboring cells reported by the GPRS/EGPRS MS, butit does not specify any traffic control strategy on how to run this available information(only radio link conditions are taken into account); the GPRS/EGPRS Traffic ControlStrategy feature exploits this information to distribute the traffic among all availablenetwork resources.

To enable the Traffic Control Strategy feature at BSC level, the user must set the TRFPS(trafficPs) parameter to TRUE

When TRFPS is set to TRUE, the traffic control algorithm is applied (see"10.3.2.1 Network Controlled Cell Reselection Algorithm for Traffic Control Strategy").The feature goal is to spread the cell traffic on more than one cell, that is to move MSsinside a high traffic cell towards available resources in neighboring cells.

iIf the STGTTLLIINF parameter set to NULL, this means that no TBF temporary data isstored and therefore the ping pong NCCR cannot be avoided.

iThe feature can be enabled only if Network Controlled Cell Reselection feature(see 10.3.1) is already enabled.

iTraffic control algorithm is applied only to cells belonging to the same PCU, becauseevery PCU knows only its own traffic.

A30808-X3247-L24-5-7618 259

InformationSystem


Traffic control algorithm performs an evaluation of the radio resource occupation intoeach cell, based on the number of channels configured, and in service available forGPRS/EGPRS, and the type of strategy set by the operator.

10.3.2.1 Network Controlled Cell Reselection Algorithm for Traffic ControlStrategyWhen the Traffic control strategy is enabled, every TBF activation is checked if, for aspecific cell, the radio resource occupation has reached or exceeded a threshold,defined by the CRESELTRHSOUT parameter.

In the positive case, the algorithm looks for MSs candidates to be forced to a cell rese-lection. The mobile(s) to move are chosen among those in packet transfer mode,applying the following criteria for the choice of target cell.

First of all, among the neighboring cells reported in the packet measurement report, onlythose for which C1 (n) > NCC1THADJC are selected.

Then, according to the value of the NCSARA attribute, the selected cells are orderedaccording to different priorities.

If NCSARA = TRUE, the adjacent cell is searched, before, among cells belonging to thesame routing area of serving cell; therefore the following priorities are used to ordercells:

1. target cell with the same Routing Area on the same PPXU/PPCU2. target cell with different Routing Area, but on the same PPXU/PPCU

If NCSARA = FALSE, adjacent cells of the same routing area have no priority comparedto adjacent cells of other routing areas; therefore only priority level exists, i.e., target cellwith the same RA or target cell with different RA, but on the same PPXU/PPCU

Among neighboring cells with the same priority, the cell with the highest C32(n) value ischosen. The C32(n) value is calculated as follows:

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 aNC_GPRS_RESELECT_OFFSET(n) value for every adjacent relationship, byNCGRESOFF parameter of the ADJC object;

iThe radio link criteria, described in "10.3.1.2 Radio Link Network Controlled Cell Rese-lection Algorithm" is maintained also when Traffic Control Strategy is enabled.

there are two cases:If T <= NC_GPRS_PENALTY_TIMEC32(n) = C1(n) + NC_GPRS_RESELECT_OFFSET(n) –NC_GPRS_TEMPORARY_OFFSET(n)

If T > NC_GPRS_PENALTY_TIMEC32(n) = C1(n) + NC_GPRS_RESELECT_OFFSET(n)

260 A30808-X3247-L24-5-7618


• NC_GPRS_TEMPORARY_OFFSET(n) applies a negative offset to C32 for theduration of NC_GPRS_PENALTY_TIME(n) after the timer T has started for that cell.The T timer is started for each cell in the list of the 6 strongest neighboring cells, assoon 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 whichNC_GPRS_TEMPORARY_OFFSET applies.The user sets a NC_GPRS_TEMPORARY_OFFSET(n) value and aNC_GPRS_PENALTY_TIME(n) value for every adjacent relationship, by NCGTEM-POFF and NCGPENTIME parameters of the ADJC object.

When NCSARA is set to FALSE, a hysteresis value is subtracted from the C32 value forthe neighbor cells. The hysteresis value can be set by the user via the NCRARESHparameter, belonging to the PTPPKF object. NCRARESH must be set at DB00 (defaultvalue) when NCSARA is set at TRUE.

The algorithm also looks for a possible candidate cell into which to move a MS. A cellcan be a candidate for this procedure only if:– it belongs to the same PCU of the serving cell– it is adjacent to the origin cell (i.e., the relevant ADJC object already exists)– it is not barred– it supports the GPRS service and its resource occupation is under a threshold. This

threshold can be set by the user by means of the CRESELTRSHINP parameter.

Then, the number of MSs to be forced in reselection is determined taking as many MSsas the radio resources that must be released, in order to put the traffic load under theNCTRFPSCTH parameter.

The network sends to each concerned MS a PACKET CELL CHANGE ORDERmessage with the indication of the new cell where the MS must perform the cell reselec-tion.

Details About the Calculation of the “Allocated Resources”.

As described, when the traffic control strategy is enabled, the following statements arevalid:– every TBF activation is checked if the radio resource occupation has reached or

exceeded a threshold, defined by the CRESELTRHSOUT parameter, for a specificcell

– the algorithm looks for a possible candidate cell into which to move a MS; theresource occupation of the candidate cell must be under a threshold. This thresholdcan be set by the user with the CRESELTRSHINP parameter

– the number of MSs to be forced in reselection is determined taking as many MSs asthe radio resources that have to be released, in order to put the traffic load under theNCTRFPSCTH parameter.

The traffic control strategy is active when vertical allocation is present and it is based onthe calculation of the “allocated resources”, according to the following rules.

The calculation is applied both to uplink and downlink TBFs: it considers the number ofallocated timeslots, the GMANMSAL attribute value and weight factors, which take intoaccount 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:

A30808-X3247-L24-5-7618 261

InformationSystem


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 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:

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 andaver_ass_ts_dl.

If TRFPS is set to TRUE and if the vertical allocation is used, the system checks thefollowing conditions:

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 servingcell to a suitable adjacent cell; this process of moving suitable mobile stationscontinues until condition 2) is reached;

b) when condition 2) is satisfied, the system stops moving mobiles to the adjacent cellfor traffic reason;

c) when, for an adjacent cell, condition 3) is verified, this adjacent cell is no longer suit-able to accept mobile from a congested cell.

The process is stopped when a transition from the vertical allocation to the horizontalallocation is executed.

10.4 Power ControlThe objective of the power control feature is to adapt the transmitted power of the MS,as well as of the BTS, to the reception conditions. The following are the two advantagesof the power control algorithm:

1. reduction of the power consumption of the MS’s batteries2. reduction of the interference which is experienced by both co-channel and neigh-

boring channel users.

For the uplink, the MS follows a flexible power control algorithm, which the network canoptimize through a set of parameters. The algorithm can be used for both of the followingpower control methods:

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

PercTrfUL = TBF_UL / AVAL_TBF_ULPercTrfDL = TBF_DL / AVAL_TBF_DL

262 A30808-X3247-L24-5-7618


– open loop power control: the MS output power is based on the received signalstrength at the MS side, assuming the same path loss in uplink and downlink direc-tions

– closed loop power control: the MS output power is commanded by the networkbased on signal measurements made in the BTS.

In BR7.0 only open loop power control is supported.

For the downlink, the power control is performed in the BTS. Therefore, there is no needto specify the actual algorithm, but information about the downlink performance isneeded. Therefore, the MSs must transfer Channel Quality reports to the BTS.

In BR7.0 downlink power control is not supported : power control is a mandatoryfeature for the MS, while it is optional for the network.

10.4.1 Power Control Algorithm

The RF output power, Pch, to be employed by the MS on each individual uplink PDCHis given by the following formula:

where:

When the MS receives either a new GAM or ALPHA value, the MS will use the newvalue to update Pch according to equation (1).

The MS uses the same output power on all four bursts within one radio block.

When accessing a cell on PRACH or RACH (random access) and before receiving thefirst power control parameters during packet transfer on PDCH, the MS will use theoutput power defined by Pmax.

If a calculated output power is not supported by the MS, the MS uses the supportedoutput power that is closest to the calculated output power.

iEven if the BSS functionality is not directly involved, this paragraph provides a briefdescription of the power control algorithm implemented in the mobile stations.

Pch= min (GAMMA0 - GAMMAch - ALPHA * (C+48), Pmax) (1)

GAMMAch: is a MS and channel specific power control parameter, sent to the MSin control messages such as IMMEDIATE ASSIGNMENT, PACKETUPLINK/DOWNLINK ASSIGNMENT, PACKET UPLINK ACK/NACK.The operator can set this value using the GAM parameter of thePTPPKF object.

GAMMA0: = 39 dBm for GSM900= 36 dBm for GSM1800.

ALPHA: is the ALPHA system parameter, which is broadcast on theBCCH/PBCCH or optionally sent to MS in a control message.

C: is the normalized received signal level at the MS sidePmax: is the maximum allowed output power in the cell. It is equal to:

- GMSTXPMAC if PBCCH is configured in the serving cell- MSTXPMAXCH (i.e., the analogous GSM parameter) otherwise

Power levels are expressed in dBm.

A30808-X3247-L24-5-7618 263

InformationSystem


10.4.2 Measurement at the MS SideA procedure is implemented in the MS to monitor periodically downlink received signallevel and quality from its serving cell.

To calculate the Pch value according to equation (1), the MS must derive the C value.Two different methods are used to estimate the C value, according to the MS state (i.e.,packet idle mode or packet transfer mode).

10.4.2.1 Packet Idle Mode: Measurements for Power ControlIn packet idle mode, the MS periodically measures the received signal level of thePCCCH or, if PCCCH is not configured, of the BCCH. The MS measures the receivedsignal level of each paging block monitored by the MS according to its current DRXmode and its paging group (see "9.8.3.2 Discontinuous Reception").

The normalized C value for each radio block is calculated as follows:

where:

Finally, the Cblock(n) values are filtered with a running average filter:

where a is the forgetting factor:

Cblock(n)= SSblock(n) + Pb (2)

SSblock(n): is the mean value of the received signal levels on the four normalbursts that compose the block;

Pb: is the BTS output power reduction (relative to the output power usedon BCCH) used on the channel on which the measurements areperformed; it corresponds to the PRPBCCH parameter. For PCCCH,Pb is broadcast on PBCCH. For BCCH, Pb = 0 (not broadcast).

C(n)= (1- a)* C(n- 1) + a * Cblock(n) C(0)=0

a = 1/MIN(n, MAX (5, TAVG_W/TDRX)

TDRX: is DRX period for the MS (see "9.8.3.2 Discontinuous Reception");TAVG_W: is the TAVGW parameter and indicates the signal strength filter period

for power control in packet idle mode. It is broadcast on PBCCH or, ifPBCCH does not exist, on BCCH.

n n is the iteration index. The filter will be restarted with n=1 for the firstsample every time a new cell is selected. Otherwise, when enteringpacket idle mode, the filter will continue from the n and C(n) valuesobtained during packet transfer mode. The filter will also continue fromits previous state if TDRX is changed.

264 A30808-X3247-L24-5-7618


The current C(n) value is used in formula (1) to calculate the output power when the MStransfers its first radio block.

10.4.2.2 Packet Transfer Mode: Measurements for Power ControlIn packet transfer mode, the MS uses the same received signal level measurements onthe BCCH carrier of the serving cell as made for cell reselection (see "10.4.2.2 PacketTransfer Mode: Measurements for Power Control"). The measurements are filtered witha running average filter:

where b is the forgetting factor:

If indicated by the PCMECH (PC_MEAS_CHAN) parameter, the MS will insteadmeasure the received signal level of each radio block on one of the PDCH monitored bythe MS for PACCH. For each downlink radio block a Cblock(n) value is derivedaccording to formula (2) (if PBCCH does not exist, Pb = 0).

Finally, the Cblock(n) values are filtered with a running average filter:

where c is the forgetting factor:

C(n)= (1- b)* C(n- 1) + b * SS(n)

b = 1/(6 * TAVG_T)

and:

SSn: is the received signal level of the measurement samples;TAVG_T: is the TAVGT parameter and indicates the signal strength filter period

for power control in packet transfer mode. It is broadcast on PBCCHor, if PBCCH does not exist, on BCCH.

n n is the iteration index; when entering packet transfer mode, the filterwill continue from the n and C(n) values obtained during packet idlemode.

C(n)= (1- c)* C(n- 1) + c * Cblock(n)

b = 1/(12 * TAVG_T)

and:

TAVG_T: is the TAVGT parameter and indicates the signal strength filter periodfor power control in packet transfer mode. It is broadcast on PBCCHor, if PBCCH does not exist, on BCCH.

n n is the iteration index; when entering packet transfer mode, the filterwill continue from the n and C(n) values obtained during packet idlemode.

A30808-X3247-L24-5-7618 265

InformationSystem


Once the current C(n) value has been obtained, this value is used to update formula (1).Each time a new C(n) value is obtained or whenever the MS applies new GAM orALPHA values, the Pch value is updated.

10.4.2.3 Derivation of Channel Quality ReportsThe channel quality is measured as the interference signal level during the idle framesof the multiframe, when the serving cell is not transmitting.

In packet transfer mode, the MS measures the interference signal strength of all eightchannels (slots) on the same carrier as the assigned PDCHs. The MS will make thesemeasurements 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 performat least NAVGI measurements before valid running average filter values can be deter-mined.

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 certainchannelsthat 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 forpacket transfer mode.

10.4.3 BTS Output PowerThe BTS uses constant power on those PDCH radio blocks that contain PBCCH orwhich may contain PCCCH. This power may be lower than the output power used onBCCH. The difference will be broadcast on PBCCH by means of the PRPBCCH param-eter.

10.5 Link AdaptationAs previously described (see 4.2), GPRS offers four different coding schemes, instead,for EGPRS nine different modulation and coding schemes are defined.

In both cases (GPRS and EGPRS) lowest coding schemes (e.g., CS1 and MCS1respectively) show good performances in poor radio conditions; on the other hand, onlythe highest coding schemes (e.g., CS4 and MCS9 respectively) can provide high datathroughput in good radio environments.

Therefore, an algorithm is needed to dynamically select the coding scheme thatbehaves better in a specific radio condition. The dynamic selection of the codingscheme, to suit radio link quality, is referred to as Link Adaptation.

Therefore, the basic idea is to dynamically select the coding scheme that allows thehighest throughput according to the present radio conditions. Then the problem is to findthe switching points that allow changing from one coding scheme to another.

Link Adaptation can be enabled, for both GPRS and EGPRS services, using theELKADPT parameter of the PTPPKF object. Link Adaptation is enabled in both uplinkand downlink directions at the same time.

The advantage to switching to a more robust coding scheme can be seen in Fig. 10.3,taking into account GPRS CS2 and CS1 coding schemes.

266 A30808-X3247-L24-5-7618


Fig. 10.3 CS1 and CS2 Throughput Depending on C/I (dB)

Assuming that the C/I ratio is better (i.e., higher direction towards '+') than the valuedenoted with '='. In this case the use of the higher coding scheme (i.e., CS2) results inan improved gross throughput compared to the use of CS1.

The situation changes, if the C/I becomes lower than '=' (direction towards '-'), accordingto the propagation conditions. In this case, the use of CS2 results in a lower grossthroughput than with CS1. This due to the necessity to re-send many blocks becausethey could not be received without errors the first time. In that situation, not only thegross throughput is lower than possible (i.e., if CS1 had been used) but also the delayincreases. In other words: if conditions get worse, then a switch to the more robustcoding scheme improves gross throughput and reduces delay. On the other hand, ifpropagation conditions improve, a switch to a higher coding scheme results in a bettergross throughput.

In general, C/I values are difficult to estimate in a real network, so another mechanismis followed.

The triggering of the switch does not use separate measurements of channel quality, butit is executed by analyzing the number of blocks to be repeated (not acknowledgedblocks) versus the number of transmitted blocks in total (i.e., the sum of the acknowl-edged blocks and the unacknowledged one). Therefore to fix the switching points, theNACK/(ACK+NACK) ratio (Block Erasure Ratio - BLER) is used; link adaptation is thenbased on BLER measurements (indirect measures of the radio quality). The switchingpoints between coding schemes, to be used in link adaptation, are then defined in termsof BLER thresholds (see 10.5.1 and 10.5.2.).

Since switching points depend on the actual RF scenario, it is impossible to calculatesuch optimal values for each particular scenario. Upgrade switching points and down-grade switching points are then stored in pre-calculated matrix tables, one for eachpossible RF environment (these matrix tables cannot be set by O&M). By O&M, it is thenpossible to select the suitable matrix table, containing all of the ideal switching points(downgrade/upgrade switching points from/to all coding schemes) for the particular RFscenario, by selecting the right radio environment.

The RAENV parameter allows the operator to specify the radio environment. As previ-ously described, according to the chosen radio environment certain matrix tables are

Gross

C/I [dB]

CS2

CS1

Throughput[kbit/s]

halam

Highlight

A30808-X3247-L24-5-7618 267

InformationSystem


selected (specific either for GPRS or for EGPRS) to define the BLER thresholds of theswitching points. The parameter can assume 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 (e.g., because MS have a speed less than 50 Km/h orbecause 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 parameters to manage 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 LinkAdaptation thresholds have been already optimized due to the improved RTT. Startingfrom this first improvement the Threshold Table has been optimized again. For Uplinkand Downlink directions the Throughput versus C/I curves for all the CS/MCS has beenmeasured again for low and high Diversity scenarios. In case of significant changes inthe Link Adaptation threshold Tables the new values have been applied. In this way abetter throughput per user and in general an overall data capacity increase of thenetwork is reached.

10.5.1 Link Adaptation for GPRSIn the following, link adaptation features for GPRS service are described.

With GPRS the receiver operates only in type I ARQ mode (see "9.9.1.1 GPRSAcknowledged Mode"); therefore link adaptation procedure is based only on this modeof operation.

10.5.1.1 GPRS: Switching PointsAs previously described, the exact values of the switching points depend on the realnetwork situation and are subjects of simulation and/or measurements.

For a first idea about the values to be expected, it is possible to interpret the followingsimulations based on TU3 with ideal frequency hopping (see Fig. 10.4).

268 A30808-X3247-L24-5-7618


Fig. 10.4 Gross Throughput Depending on CS and C/I (dB)

It is possible to estimate the 'ideal' switching points as follows:

However, switching points between coding schemes are defined in terms of BLERthresholds. The corresponding BLER values are shown in Fig. 10.5.

CS1 <---> CS2 C/I=6.2 dBCS2 <---> CS3 C/I=9.6 dBCS3 <---> CS4 C/I=16.5 dB

A30808-X3247-L24-5-7618 269

InformationSystem


Fig. 10.5 BLER as Function of C/I (dB) for all GPRS Coding Schemes

For GPRS, the following BLER thresholds, e.g., can be defined:

For example, if BLER goes below 17% while using CS1, then a change to CS2 will bedecided; if BLER goes over 43% while using CS2, then a change to CS1 will be decided.

A crosscheck e.g., for CS1<->CS2 provides approximately the same gross throughputs:

It is also possible to see – depending on the wished QoS – that the hysteresis shouldbe more towards the more stable CS: in the example above, both CS have nearly thesame gross throughput, but with CS2, 43% of all blocks mus bet repeated at least once,so the delay will be much higher than if one uses CS1. Therefore the '-' point should beas 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.4) are re-scaled, each one by aproper factor, and the 'ideal' switching points should be recalculated accordingly. Theseswitching points are reported in Tab. 10.3, and are the values that are contained in theGPRS internal switching matrix. It is important to underline that for GPRS, only oneswitching matrix exists, independently of the value given to the RAENV parameter.

BLER_CS1(CS1 ---> CS2) = 17% BLER_CS2(CS2 ---> CS1) = 43% C/I=6.2 dBBLER_CS2(CS2 ---> CS3) = 14% BLER_CS3(CS3 ---> CS2) = 26% C/I=9.6 dBBLER_CS3(CS3 ---> CS4) = 2% BLER_CS4(CS4 ---> CS3) = 17% C/I=16.5 dB

(1-0.17)*9.05 kbit/s=7.51 kbit/s (1-0.43)*13.4 kbit/s=7.64 kbit/s

CS1 CS2 CS3 CS4

CS1 <10%

Tab. 10.3 GPRS Thresholds with RAENV set to LOWDIV/HIGHDIV

270 A30808-X3247-L24-5-7618


In Tab. 10.3, coding schemes written in the vertical direction represent the startingcoding schemes, whereas those written in the horizontal direction represent the arrivalones. For example, watching at Tab. 10.3, to go from CS1 to CS2, the BLER value mustbe 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 andBLER(CSi<--CSi+1) the corresponding (downgrade) switching point andBLER(CSi=CSi+1) the BLER of the current coding scheme where both correspondingcoding schemes have with same C/I the same throughput.

Then the following must always be valid:

10.5.1.2 “Quality Traps” DisadvantageIt would be desirable to enforce in the downgrade situation, a re-sending of the NACKblocks 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 betransferred at all (conditions are too bad for transfer with current CS, but CS may not bechanged because blocks must be resent with the old CS).

Therefore, when radio conditions are bad and the link adaptation leads to switching toa lower coding scheme, in progress retransmission will be in any case performed usingthe ‘old’ coding scheme. As usual, when the number of retransmissions of a blockexceeds the N3101 value, the TBF is closed. If the TBF is re-opened within a timeconfigured by the STGTTLLIINF parameter, it will be re-opened with the lastcommanded/used coding scheme, overtaking quality traps disadvantages (see"10.5.3 Selection of the Candidate Initial Coding Scheme" to get more details about thisprocedure).

For example, for transmission in the downlink direction, if the current coding scheme isCS4 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

CS2 >50% <10%

CS3 >50% <1%

CS4 >30%

CS1 CS2 CS3 CS4

Tab. 10.3 GPRS Thresholds with RAENV set to LOWDIV/HIGHDIV

1) BLER(CSi-->CSi+1)<BLER(CSi=CSi+1) i=1..32) BLER(CSi=CSi+1)<=BLER(CSi<--CSi+1) i=1..3

iThe situation described above is very pessimistic. In more common cases, interferenceand fading conditions are variable enough, from block to block, to allow an RLC blockcorrect reception within a reasonable number of retransmissions. If p is the probabilityof retransmission, each RLC block will be correctly received after an average 1/(1-p)number of retransmissions.

A30808-X3247-L24-5-7618 271

InformationSystem


When the number of retransmissions of a block exceeds the N3101 value, the TBF isclosed. If the TBF is re-opened within the STGTTLLIINF time, CS3 coding scheme (lastused coding scheme) will be used.

For example, for transmission in the uplink direction, if the current coding scheme is CS4and 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 isclosed. If the MS again requires the TBF within the STGTTLLIINF time, CS3 codingscheme will be used (last commanded coding scheme).

10.5.1.3 GPRS: Link Adaptation AlgorithmSpeaking about GPRS service, link adaptation is based on the following features:

1. All of the signalling is done with CS1;2. Data transfer is started with the highest available coding scheme; the following

considerations can be drawn:– if the transmission to be started is a retry due to a previous “quality trap”

(see 10.5.1.2), the CS to be selected must be more stable than the one usedbefore. The PCU must store abnormal releases for a certain time, to recognize aretry and adapt the CS for that case.

– as described in 10.5.1.2, the PCU holds in memory the value of the last usedcoding scheme for a defined time; this coding scheme is the coding scheme to beused when a new TBF is opened. If the time is elapsed (or if a cell reselection isexecuted) the used coding scheme is those provided by the INICSCH parameter(see "10.5.3 Selection of the Candidate Initial Coding Scheme").

3. Basing on received blocks, the BSC can evaluate the BLER value;4. If conditions worsen, a downgrade to the lower CS is performed, but all of NACK

blocks must be successfully sent using the old coding scheme (i.e., after a changefrom coding scheme A to coding scheme B, all of the not acknowledged blocks mustbe resent using the coding scheme A); this may lead to the 'quality trap'. Thisproblem is solved only by expiration of a timer and reestablishing the transmissionwith a more appropriate CS.

5. If conditions improve, an upgrade to the higher CS is performed, but all of NACKblocks must successfully be sent using the old coding scheme. In uplink case, theBSC informs the MS to change the coding scheme; in downlink direction, the BSCstarts sending blocks with the new coding scheme. The upgrade procedure dependsnot only on the propagation conditions (i.e., C/I or BLER) but also on the availableresources. A switch (e.g., CS2 to CS3) is not allowed, if there is e.g., insufficienttransmission capacity on the Abis (e.g., a 32 kbit/s channel available for a CS3, see"6.3 PCU Frames and Dynamic Allocation on the Abis Interface").

10.5.2 Link Adaptation for EGPRSFor EGPRS, up to nine modulation and coding schemes are defined; each schemebelong to a certain family.

In general, according to the link quality, an initial Modulation and Coding Scheme (MCS)is selected for an RLC block. For retransmissions, the same or another MCS from thesame family of MCSs can be selected. For example, if MCS7 is selected for the first

272 A30808-X3247-L24-5-7618


transmission of an RLC block, any MCSs of the family B can be used for the retransmis-sion.

In the type I ARQ mode (see "9.9.1.2 EGPRS Acknowledged Mode"), decoding of anRLC Data Block is based solely on the prevailing transmission (i.e., erroneous blocksare not stored). In the type II ARQ case, erroneous blocks are stored by the receiver anda joint decoding with new transmissions is done. Link Adaptation procedure allows thereceiver to operate either in type I or type II hybrid ARQ mode.

10.5.2.1 EGPRS: Switching PointsWith EGPRS, different MCSs allow different performance (throughput) as a function ofthe C/I ratio (and the actual RF channel); Fig. 10.6 shows curves for TU3 with nofrequency hopping, for family A + MCS1 (without Incremental Redundancy).

Fig. 10.6 Simulation Results for Family A (+MCS1) without IR

It is possible to estimate the 'ideal' C/I switching points where the MCS should bechanged in order to maximize the net throughput. Referring to the previous case, andassuming only using MCSs belonging to family A (plus MCS1), the 'ideal' switchingpoints could be as follows:

MCS1 <---> MCS3 C/I=1.5 dBMCS3 <---> MCS6 C/I=7.5 dBMCS6 <---> MCS9 C/I=16 dB

A30808-X3247-L24-5-7618 273

InformationSystem


As described for GPRS, also with EGPRS the thresholds are given in terms of BLER,since C/I values are difficult to estimate; some examples of defined BLER thresholdscould be as follows:

The throughput is maximized changing the coding schemes according to thesethreshold values. For example, if BLER goes below 38%, while using MCS3, then achange to MCS6 will be decided; if BLER goes over 69%, while using MCS6, then achange to MCS3 will be decided.

In real networks, 'ideal' switching points will depend on the actual RF scenario and it isimpossible to calculate such optimal values for each particular scenario.

Upgrade switching points (BLER(MCSx--->MCSy), 1<=x<y<=9) and downgradeswitching 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 eachpossible 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 matrixtable, containing all of the ideal switching points (downgrade/upgrade switching pointsfrom/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 andBLER(MCSy_wIR--->MCSx_wIR), 1<=x<y<=9, as downgrade switching points. Thesevalues are stored in matrix tables, one for each possible RF scenario.

Among all possible EGPRS coding schemes, the operator must define which sets ofcoding schemes must be used in the cell, both in uplink and downlink direction (see"10.5.2.2 EGPRS: Link Adaptation Algorithm" to know how to enable EGPRS codingschemes in a cell). When configuring these sets, the following constraints are automat-ically considered by the system:

a) MCS1 is always included in the selection: this is needed for signalling and due to thefact 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 mustbe implemented. This is needed because retransmissions may have to beperformed with a (lower order) MCS of the same family.

c) If more than one family is configured, considering a given MCSx in use, the generalrule to decide the upgrading/downgrading MCS is the following: the “upgrading”MCS is the one characterized by the highest switching threshold (among the config-

BLER(MCS1 ---> MCS3) = 61% BLER(MCS3 ---> MCS1) = 77% C/I=1.5 dBBLER(MCS3 ---> MCS6) = 38% BLER(MCS6 ---> MCS3) = 69% C/I=7.5 dBBLER(MCS6 ---> MCS9) = 24% BLER(MCS9 ---> MCS6) = 62% C/I=16 dB

iLink Adaptation is not restricted within a family. Only retransmissions mustbe 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).

274 A30808-X3247-L24-5-7618


ured ones), while the “downgrading” MCS is the one characterized by the lowestswitching threshold (among the configured ones).

According to the chosen sets of coding schemes (in uplink or downlink direction),different thresholds must be considered, since different coding schemes are selected.Tab. 10.4 shows which thresholds are considered if, for instance, the user has enabledFamilyA plus MCS1. Instead Tab. 10.5 shows which thresholds are considered if, forinstance, the user has enabled FamilyB plus MCS1.

In the tables, coding schemes written in vertical direction represent the starting codingschemes, whereas those written in horizontal represent the arrival ones. Therefore, forexample, watching at Tab. 10.4, to go from MCS1 to MCS3 the BLER must be less thana XX% value; to go from MCS3 to MCS1 the BLER must be greater than another XX%value.

iIt may happen that the upgrading threshold is higher that the downgradingthreshold. 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 bestchoice is to immediately switch to a new one). In case both conditions aresatisfied, the best choice is to switch to the upgrading MCS.

iIf more than one family is enabled, the possible switching points are those given by thesum of tables related to the single families.

Fam C Fam B Fam A +Fam APadding


Fam B Fam APadding

Fam A

MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7 MCS8 MCS9

Fam C MCS1 <XX%

Fam B MCS2

Fam A +Fam APadding

MCS3 >XX% <XX%

Fam C MCS4

Fam B MCS5

Fam A +Fam APadding

MCS6 >XX% <XX%

Fam B MCS7

Fam APadding

MCS8

Fam A MCS9 >XX%

Tab. 10.4 Thresholds to be used if Family A plus MCS1 are chosen

A30808-X3247-L24-5-7618 275

InformationSystem


If all EGPRS coding schemes are enabled, according to radio environment (i.e., RAENVparameter setting) and IR, four different threshold settings are foreseen:

a) RAENV set to LOWDIV and IR is working (see Tab. 10.6)b) RAENV set to LOWDIV and IR is not working (see Tab. 10.7)c) RAENV set to HIGHDIV and IR is working (see Tab. 10.8)d) RAENV set to HIGHDIV and IR is not working (see Tab. 10.9)



Fam B Fam APadding

Fam A


Fam C MCS1 <XX%

Fam B MCS2 >XX% <XX%

Fam A +Fam APadding

MCS3

Fam C MCS4

Fam B MCS5 >XX% <XX%

Fam A +Fam APadding

MCS6

Fam B MCS7 >XX%

Fam APadding

MCS8

Fam A MCS9

Tab. 10.5 Thresholds to be used if Family B plus MCS1 are chosen

ToFrom


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.6 EDGE with Incremental Redundancy working and RAENV set to "LOWDIV"

276 A30808-X3247-L24-5-7618


ToFrom


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.7 EDGE with Incremental Redundancy not working and RAENV set to "LOWDIV"

ToFrom


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.8 EDGE with Incremental Redundancy working and RAENV set to "HIGHDIV"

ToFrom


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.9 EDGE with Incremental Redundancy not working and RAENV set to "HIGHDIV"

A30808-X3247-L24-5-7618 277

InformationSystem


To summarize, the basic ideas are as follows:• link Adaptation is based on BLER measurements• different BLER thresholds are needed to take into account type I ARQ and type II

Hybrid ARQ cases• only a subset of MCSs should be used; especially due to the fact that is quite difficult

to define consistent thresholds among all of the possible MCSs.

10.5.2.2 EGPRS: Link Adaptation AlgorithmRegarding the EGPRS link adaptation algorithm, some differences exist between uplinkand downlink directions; these differences arise from the following situations:

a) there are EGPRS mobile stations that are unable to use PSK modulation in uplinkdirection, but only the GMSK one (see "9.1 Mobile Stations for Packet SwitchedServices");

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 transmitcapable mobiles and the other one for GMSK-only transmit capable mobiles.

To enable sets of coding schemes, a parameter is given for each family. The parametersare as follows (remember that in uplink direction, the Incremental Redundancy is notimplemented):• EMFA1UNIR8PSK (enMcsFamAMcs1UplinkWoutIncrRed8Psk): enables MCS

belonging to FamilyA and MCS1 to be used, if MS support 8PSK modulation in theUplink;

• EMFAP1UNIR8PSK(enableMcsFamilyApMcs1UplinkWithoutIncrementalRedundancy8Psk): enablesMCS belonging to FamilyA padding and MCS1 to be used, if MS support 8PSKmodulation in the Uplink case;

• EMFB1UNIR8PSK (enMcsFamBMcs1UplinkWoutIncRed8Psk): enables MCSbelonging to Family B and MCS1 to be used, if MS support 8PSK modulation in theUplink EGPRS TBF;

• EMFCUNIR8PSK (enMcsFamCUplinkWoutIncRed8Psk): enables MCS belongingto Family C and MCS1 to be used, if MS support 8PSK modulation in the Uplinkcase;

• EMFGUNIR8PSK (enMcsFamGmskUplinkWoutIncRed8Psk): enables MCSbelonging to Family Gmsk to be used, if MS supports 8PSK modulation in the Uplinkcase;

• EMFCUNIRGMSK (enMcsFamCUplinkWoutIncrRedGmsk): enables MCSbelonging to Family C to be used, if MS does not support 8PSK modulation in theUplink case;

MCS8 >50% >25% <15%

MCS9 >55% >35% >50%

Tab. 10.9 EDGE with Incremental Redundancy not working and RAENV set to "HIGHDIV"

278 A30808-X3247-L24-5-7618


• EMFGUNIRGMSK (enMcsFamGmskUplinkWoutIncrRedGmsk): enables MCSbelonging to Family Gmsk to be used, if MS does not support 8PSK modulation inthe Uplink case.

The operator can also define the initial MCS to be used as default in uplink direction; ifno information is available about a MS in a cell, the defined MCSs will be used (see"10.5.3 Selection of the Candidate Initial Coding Scheme").

The IMCSULNIR8PSK attribute suggests the MCS to be used in uplink direction if theMS supports the 8 PSK modulation in this direction; the IMCSULNIRGMSK attributesuggests the MCS to be used in uplink direction if the MS supports only the GMSKmodulation in this direction.

The link adaptation algorithm in uplink direction works as follows:

1. The initial Modulation and Coding Scheme is decided. In the absence of Abiscongestion, the initial MCS will be IMCSULNIR8PSK (or IMCSULNIRGMSK forGMSK mobiles), unless some information is available about the last MCS used fora previous UL TBF characterized by the same TLLI. In this case, the initial MCS ofthe new TBF will be set equal to the last MCS of the previous one (see 10.5.3);

2. Once the connection is established, BLER is continuously updated at the PCU (each20 ms) by checking whether or not RLC blocks have been carefully received; thefiltering period can be defined, in number of radio blocks, by the BLERAVEULparameter;

3. Once the initial filtering period has elapsed (e.g., after 100 radio blocks if BLER-AVEUL is set to UNIT100), BLER is continuously monitored. Each time (i.e., for eachreceived block) BLER is checked and tested against the appropriate thresholds; ifMCSx is the actual MCS, MCSy the next available one and MCSz the previous avail-able one, the appropriate thresholds are:

4. If actual BLER falls below the upgrade threshold (Up_th), the algorithm switches tothe next (less protected) available MCS; if it exceeds the downgrade threshold(Dn_th), the algorithm switches to the previous (more protected) available MCS.

Downlink direction

In the downlink, direction incremental redundancy is assumed to always be enabled,since it is mandatory for EGPRS mobiles.

The operator can configure which sets of coding schemes can be used in the downlinkdirection. EGPRS mobiles will be able to receive 8PSK modulated signals, therefore atleast one family of available MCSs must be enabled (all of the MSs are 8PSK receivecapable).

iFamily GMSK is constituted by MSCs that can be used from a mobile station supporting,in uplink direction, the GMSK modulation only. The coding schemes belonging to FamilyGMSK are: MCS1, MCS2, MCS3, and MCS4; these coding schemes use the GMSKmodulation (see "3.1 GPRS and EGPRS Modulation Principles").

Up_th= BLER(MCSx--->MCSy) upgrade threshold

Dn_th= BLER(MCSx--->MCSz) downgrade threshold

iWhen upgrading to a less protected MCS, Abis availability should be checked, see"6.3 PCU Frames and Dynamic Allocation on the Abis Interface" and "5.3.4.2 Upgradeof Abis Resources".

A30808-X3247-L24-5-7618 279

InformationSystem


To enable sets of coding schemes, a parameter for each family is given. The followingare the parameters (remember that in downlink direction, the Incremental Redundancyis always supported by MSs):• 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 operator can also define, by the INIMCSDL attribute, the initial MCS to be used asthe default in the downlink direction; if no information about the MS in a cell is available,the suggested MCSs will be used (see "10.5.3 Selection of the Candidate Initial CodingScheme").

The link adaptation algorithm in the downlink direction works as follows:

1. The initial Modulation and Coding Scheme is decided. In the absence of Abiscongestion, the initial MCS will be INIMCSDL, unless some information is availableabout the last MCS used for a previous DL TBF characterized by the same TLLI. Inthis case, the initial MCS of the new TBF will be set equal to the last MCS of theprevious one (see 10.5.3);

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, reportedby the MS upon periodic request from the network (let k be the reporting instant); thefiltering period can be defined, in number of radio blocks, by the BLERAVEDLparameter;

3. When an EGPRS PACKET DOWNLINK ACK/NACK message is received (i.e., at theinstant k), the MS OUT OF MEMORY bit is checked to verify if no more memory forincremental redundancy procedure is available at the MS. From the MS OUT OFMEMORY bit, the IR_status_k variable is derived, providing information about theefficiency 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 DOWNLINKACK/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 theprevious available one, the appropriate thresholds are:– if IR was perfect (no memory size limitations, etc.), the appropriate thresholds

would be:

– if IR did not work at all, 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

280 A30808-X3247-L24-5-7618


– generally (IR efficiency given by IR_statusk) the appropriate thresholds would besomething between thresholds defined above:

5. If actual BLER falls below the upgrade threshold (Up_th_k), the algorithm switchesto 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.

10.5.3 Selection of the Candidate Initial Coding SchemeThe 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 anew 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 "9.1 Mobile Stations for

Packet Switched Services", not all the of EDGE mobile stations support the 8PSKmodulation, therefore:– the IMCSULNIR8PSK attribute suggests that the MCS to be used in uplink direc-

tion if the MS supports the 8 PSK modulation in this direction;– the IMCSULNIRGMSK attribute suggests that the MCS to be used in uplink direc-

tion if the MS supports only the GMSK modulation in this direction;• for EGPRS service, in downlink direction, all of the EDGE MS are obliged to support

the 8 PSK modulation, so the INIMCSDL attribute suggests the MCS to be used indownlink direction for all the EGPRS mobiles.

These values are used to choose the initial coding scheme, only when the PCU doesnot have valid information of the coding scheme to use when the TBF starts.

In fact, the PCU holds into memory, for each mobile station, the last coding scheme (CSor MCS) used in Uplink or Downlink direction for TBFs associated to the MS. Thesevalues are refreshed at the end of each TBF and cleared from memory if either a timerdefined by the STGTTLLIINF (storageTimeTLLIInfo) parameter expires or if a cell rese-lection is performed. These values of coding schemes are called “historical” codingschemes; configured by O&M coding schemes will be used only if no historical valuesare available at the PCU side.

Up_th_k= BLER(MCSx--->MCSy) upgrade threshold

Dn_th_k= BLER(MCSx--->MCSz) downgrade threshold

Up_th_k= (1-IR_status_k)*BLER(MCSx--->MCSy)+IR_status_k*BLER(MCSx_wIR--->MCSy_wIR)

upgradethreshold

Dn_th_k= (1-IR_status_k)*BLER(MCSx--->MCSz)+IR_status_k*BLER(MCSx_wIR--->MCSz_wIR)

downgradethreshold

iWhen upgrading to a less protected MCS, Abis availability should be checked, see"6.3 PCU Frames and Dynamic Allocation on the Abis Interface" and "5.3.4.2 Upgradeof Abis Resources".

iBesides the coding scheme, the PCU also holds in memory, for the same time, the“historical BLER”, i.e., the last measured BLER. This value is used to assign radioresources to the new TBF (see "5.3.3 Management of Incoming GPRS/EGPRSRequests").

A30808-X3247-L24-5-7618 281

InformationSystem


When a new TFB starts, the Candidate Initial Coding Scheme must be selected:

a) for GPRS capable mobiles, only the ‘candidate initial CS’ must be calculatedb) for EGPRS capable mobiles, both the ‘candidate initial MCS’ and the ‘candidate

initial CS’ must be calculated. In fact, only after the Resource Allocation procedure(see "5.3.3.1 PCU Algorithm" and "5.3.3.2 TDPC Algorithm") will be clear which TBFmode (GPRS or EGPRS) is to be used.

Therefore, the candidate initial coding scheme is selected in the order looking at thefollowing.

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.11)– 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.10)– configured initial CS, if historical CS/MCS are not available

Besides, for EGPRS service it is important to remember that the operator can configureseparately:– 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 directlyusable for the new TBF to be set up, because e.g., the user has changed the value ofO&M parameters. In this case, the rule to select the candidate initial MCS is: take thehighest configured MCS less or equal to the available historical MCS.

The following tables show the rules to decide the candidate initial coding scheme for thefollowing:– a GPRS TBF mode, when the last coding scheme was stored for an EGPRS TBF

mode (see Tab. 10.10).– a EGPRS TBF mode, when the last coding scheme was stored for a GPRS TBF

mode (see Tab. 10.11);

Historical MCS Candidate CS

MCS1 CS1

MCS2 CS2

MCS3 CS3

MCS4 or higher MCSs CS4

Tab. 10.10 Candidate Initial Coding Scheme for a GPRS TBF when the HistoricalCoding Scheme is related to an EGPRS TBF

282 A30808-X3247-L24-5-7618


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 8PSKcapable mobiles

UL TBF for GMSK capablemobiles

-Configured Initial MCS if it isupper than MCS4-MCS4 if FamilyC is configured-MCS3 if FamilyA is configured-MCS2 if FamilyB is configured-MCS1 otherwise

-MCS4 if FamilyC is configured-MCS3 if FamilyA is configured-MCS2 if FamilyB is configured-MCS1 otherwise

Tab. 10.11 Candidate Initial Coding Scheme for an EGPRS TBF when the HistoricalCoding Scheme is related to a GPRS TBF

A30808-X3247-L24-5-7618 283

InformationSystem


11 Database Parameters and ObjectsThe current chapter contains four tables:– In the first table the user finds, in the alphabetical order, all of the parameters, related

only to GPRS/EGPRS, that are discussed in the manual. For each parameter theuser finds one or more links to the chapters of the manual where the parameter isdescribed and also a link to the title of Feature Sheets (or Change Requests) thatintroduce or describe the parameter in Siemens technology;

– In the second one the user finds, in the alphabetical order, the unspecificGPRS/EGPRS parametersthat are discussed in the manual since they are alsorelated to GPRS/EGPRS . For each parameter, he/she finds one or more links to thechapters of the manual where the parameter is described; besides, starting fromparameters of BR5.5 release onwards, a link to the features that describe the param-eter is executed.

– In the third one the user finds, in the alphabetical order, all of the database objectsthat are related only to GPRS/EGPRS. For each object he/she finds the link toFeature Sheets (or Change Requests) that introduce the object in Siemens tech-nology;

– In the fourth one, the user finds, in the alphabetical order, all of the unspecificGPRS/EGPRS database objects that are also involved in GPRS/EGPRS. For eachobject he finds the link to the chapters of the manual that describe it; besides,starting from parameters of BR5.5 release onwards, a link to the features thatdescribe the parameter is executed.

Parameter Feature/CR Chapters

ABUTYP FSH 0720 "9.8.2.1 8 Bit or 11 Bit Uplink Access"

"9.8.2.4 TBF Establishment for EDGE MobileStations"

ACCEPTGDEGR FSH 0516 "5.3.4.1 Upgrade of Radio Resources"

ALPHA FSH 0720 "10.4.1 Power Control Algorithm"

"10.4.2.2 Packet Transfer Mode: Measure-ments for Power Control"

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.5.2.2 EGPRS: Link Adaptation Algorithm"

BLERAVEUL FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

BNDWIDTDD FSH 0418 "10.2.3 Handling of UMTS Neighboring Cells"

BPAGCHR FSH 0720 "4.5.2 PDCH Carrying both PBCCH andPCCCH"

"9.8.3.2 Discontinuous Reception"

"4.5.3 PDCH Carrying PCCCH"

Tab. 11.1 GPRS/EGPRS Parameters Summary Table

284 A30808-X3247-L24-5-7618


BPRACHR FSH 0720 "4.5.2 PDCH Carrying both PBCCH andPCCCH"

"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 andPCCCH"


BVCBHIPER FSH 0514 "7.3.3 SGSN-BSS Flow Control"

BVCBMAPER FSH 0514 "7.3.3 SGSN-BSS Flow Control"

BVCBLPER FSH 0514 "7.3.3 SGSN-BSS Flow Control"

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 0720CR - X617

"9.8.5 Polling Procedures"

CODE FSH 0720 "7.1 Physical Layer"

CRC FSH 0720 "7.1 Physical Layer"

CRESELTRHSOUT FSH 0418 "10.3.2 GPRS/EGPRS Traffic ControlStrategy"

CRESELTRSHINP FSH 0418 "10.3.2 GPRS/EGPRS Traffic ControlStrategy"

CSCH3CSCH4SUP FSH 0419 "4.2.1 GPRS Channel Coding"

DRXTMA FSH 0720CR - F190CR - X617


EBCCHTRX FSH 0420 "5.1.3 Aspects Related to Carrier Configura-tion"

"5.3.3 Management of IncomingGPRS/EGPRS Requests"

EEDGE FSH 0420CR - X0158

"5.1 Enabling Packet Switched Services in aCell"

EGPLGPONETS FSH 0420 "9.9.3.1 Uplink TBF Using the AcknowledgedMode"

"9.9.4.1 Acknowledged and UnacknowledgedModes on Downlink TBFs"



A30808-X3247-L24-5-7618 285

InformationSystem


EGPLGPTWOTS FSH 0420 "9.9.3.1 Uplink TBF Using the AcknowledgedMode"


EGPLGPTHREETS FSH 0420 "9.9.3.1 Uplink TBF Using the AcknowledgedMode"


EGPLGPFOURTS FSH 0420 "9.9.3.1 Uplink TBF Using the AcknowledgedMode"


EGPLGPFIVETS FSH 0420 "9.9.3.1 Uplink TBF Using the AcknowledgedMode"


EGPLGPSIXTS FSH 0420 "9.9.3.1 Uplink TBF Using the AcknowledgedMode"


EGPLGPSEVENTS FSH 0420 "9.9.3.1 Uplink TBF Using the AcknowledgedMode"


EGPLGPEIGHTTS FSH 0420 "9.9.3.1 Uplink TBF Using the AcknowledgedMode"


EGPRS FSH 0420CR - X0158

"5.1 Enabling Packet Switched Services in aCell"

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"

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.5.2.2 EGPRS: Link Adaptation Algorithm"



286 A30808-X3247-L24-5-7618


EMCSFAMA1DL FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

EMCSFAMAP1DL FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

EMCSFAMB1DL FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

EMCSFAMCDL FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

EMCSFAMGDL FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

EMFA1UNIR8PSK FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

EMFAP1UNIR8PSK FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

EMFB1UNIR8PSK FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

EMFCUNIR8PSK FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

EMFCUNIRGMSK FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

EMFGUNIR8PSK FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

EMFGUNIRGMSK FSH 0444 "10.5.2.2 EGPRS: Link Adaptation Algorithm"

ESUP FSH 0420 "5.1.2 Enabling EGPRS Service in the Cell"

FDDGQO CR - X482 "10.2.2 GSM-UMTS Re-selection Algorithm:Packet Switched Case"

FRSTD FSH 0720 "7.1 Physical Layer"

GAMMA ---- "10.4.1 Power Control Algorithm"

"10.4.2.2 Packet Transfer Mode: Measure-ments for Power Control"

GASTRABISTH FSH 0516 "5.3.2.4 Switching between VA and HAaccording to Abis Interface Conditions"

"5.3.2.5 Allocation of Resources"

"5.3.3.2 TDPC Algorithm"

"5.3.4.2 Upgrade of Abis Resources"

GASTRTH FSH 0503 "5.3.2.3 Switching between VA and HAAccording to Radio Conditions"

"5.3.2.5 Allocation of Resources"

"5.3.4.1 Upgrade of Radio Resources"

GDCH (ex GCCH) FSH 0720FSH 0457FSH 0503CR - X706

"5.2 Configuration of GPRS Channels in aCell"

"5.3.2.3 Switching between VA and HAAccording to Radio Conditions"


GCELLRESH FSH 0720 "10.1.3 Cell Re-selection Algorithm"

GFDDMURREP FSH 0418 "10.3.1.1 Measurement Reporting"

GFDDREPQTY FSH 0418 "10.3.1.1 Measurement Reporting"



A30808-X3247-L24-5-7618 287

InformationSystem


GHCSPC FSH 0720CR - F205

"10.1.2.2 C31 Criterion"


"10.1.4 Management of GPRS/EGPRSNeighboring Cells"

"10.1.4.3 Configuration of an Adjacent Cellwith GSUP= TRUE"

GHCSTH FSH 0720CR - F205




GLK FSH 0720 "7.1 Physical Layer"

"7.2.1.1 Examples of Addressing"

GMANMSAL FSH 0720 "4.3.3 Multiplexing MSs on the same PDCH:Configuration"

"4.4.3 Packet Data Traffic Channel (PDTCH)"


"5.3.2 Horizontal/Vertical Allocation Strate-gies"

"5.3.2.1 Vertical Allocation Strategy (VA)"

"5.3.3.1 PCU Algorithm"

"10.3.2.1 Network Controlled Cell ReselectionAlgorithm for Traffic Control Strategy"

GMANPAL FSH 0720CR - X232

REMOVED IN BR6.0

GMANPRES(restored in BR7.0)

CR - F187 "5.2 Configuration of GPRS Channels in aCell"




"7.3.3 SGSN-BSS Flow Control"

GMAPERTCHRES CR - X706 REMOVED IN BR7.0



288 A30808-X3247-L24-5-7618


GMSTXPMAC FSH 0720FSH 0418

"10.1.2.1 GPRS/EGPRS Path Loss Criterion(C1 Criterion)"



"10.3.1.2 Radio Link Network Controlled CellReselection Algorithm"


GNMULBAC FSH 0418 "10.1.1 Measurements for Cell Selection andRe-selection"

"10.3.1.1 Measurement Reporting"

GPATH FSH 0720 "9.8.2 TBF Establishment Initiated by the MSon CCCH/PCCCH"

GPDPDTCHA FSH 0503CR - X617





GPENTIME FSH 0720CR - F205





GRESOFF FSH 0720CR - F205CR - X617







A30808-X3247-L24-5-7618 289

InformationSystem


GRXLAMI FSH 0720FSH 0418

"10.1.2.1 GPRS/EGPRS Path Loss Criterion(C1 Criterion)"





GS FSH 0720 "9.8.2.6 Uplink Access on PRACH (AccessPersistence Control)"

GSUP (TRX object) FSH 0512 "5.1.1 Enabling GPRS Service in the Cell"

"5.1.2 Enabling EGPRS Service in the Cell"


GSUP (ADJC object) FSH 0720 "10.1.4 Management of GPRS/EGPRSNeighboring Cells"


"10.1.4.4 Configuration of an Adjacent Cellwith GSUP= FALSE"

GTDDMURREP FSH 0418 "10.3.1.1 Measurement Reporting"

GTEMPOFF FSH 0720CR - F205





GTS FSH 0720 "7.1 Physical Layer"


GTXINT FSH 0720 "9.8.2.6 Uplink Access on PRACH (AccessPersistence Control)"

GUMTSSRHPRI FSH 0418 "10.1.1 Measurements for Cell Selection andRe-selection"

"10.2 Cell Re-selection fromGSM/GPRS/EGPRS Network to UMTSNetwork"



290 A30808-X3247-L24-5-7618


IMCSULNIR8PSK FSH 0444 "4.2.2 EGPRS Channel Coding"

"10.5.2.2 EGPRS: Link Adaptation Algorithm"

"10.5.3 Selection of the Candidate InitialCoding Scheme"

IMCSULNIRGMSK FSH 0444 "4.2.2 EGPRS Channel Coding"



INIBLER FSH 0516 "5.3.3.1 PCU Algorithm"


INICSCH FSH 0720 "4.2.1 GPRS Channel Coding"

"10.5.1.3 GPRS: Link Adaptation Algorithm"


INIMCSDL FSH 0444 "4.2.2 EGPRS Channel Coding"



LOWBER FSH 0720 "7.1 Physical Layer"

MNTBMASK CR - X1869 "4.2.1 GPRS Channel Coding"

MSBHIPER FSH 0514 "7.3.3 SGSN-BSS Flow Control"

MSBMAPER FSH 0514 "7.3.3 SGSN-BSS Flow Control"

MSBLPER FSH 0514 "7.3.3 SGSN-BSS Flow Control"

MSBSPPER FSH 0514 "7.3.3 SGSN-BSS Flow Control"

N3101 FSH 0720CR - X617

"9.9.3.3 Anomalies During an Uplink TBF"

FSH 0444 "10.5.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 UnacknowledgedModes on Downlink TBFs"

N391 FSH 0720 "7.2.1.3 Procedures for PVCs"



NAVGI FSH 0720 "10.4.2.3 Derivation of Channel QualityReports"

NBVCBR FSH 0720 "7.3.1.1 BVC Procedures"



A30808-X3247-L24-5-7618 291

InformationSystem


NBVCUR FSH 0720 "7.3.1.1 BVC Procedures"

NBVCRR FSH 0720 "7.3.1.1 BVC Procedures"

NCC1TH FSH 0418 "10.3.1.2 Radio Link Network Controlled CellReselection Algorithm"

NCC1THADJC FSH 0418 "10.3.1.2 Radio Link Network Controlled CellReselection Algorithm"


NCGPENTIME FSH 0418 "10.3.1.2 Radio Link Network Controlled CellReselection Algorithm"


NCGRESOFF FSH 0418 "10.3.1.2 Radio Link Network Controlled CellReselection Algorithm"


NCGPENTIME FSH 0418 "10.3.1.2 Radio Link Network Controlled CellReselection Algorithm"


NCRARESH FSH 0418 "10.3.1.2 Radio Link Network Controlled CellReselection Algorithm"


NCRESELFLAG FSH 0418 "10.3.1 Network Controlled Cell Reselection"


"10.3.2 GPRS/EGPRS Traffic ControlStrategy"

NCSARA FSH 0418 "10.3.1.2 Radio Link Network Controlled CellReselection Algorithm"


NCTRFPSCTH FSH 0418 "10.3.2 GPRS/EGPRS Traffic ControlStrategy"

NMO FSH 0720 "9.8.3.1 Network Operation Modes forPaging"

NNSVCBLKR FSH 0720 "7.2.2.2 Control Procedures"

NNSVCRR FSH 0720 "7.2.2.2 Control Procedures"



292 A30808-X3247-L24-5-7618


NNSVCTSTR FSH 0720 "7.2.2.2 Control Procedures"


NNSVCUBLR FSH 0720 "7.2.2.2 Control Procedures"

NRLCMAX FSH 0720CR - X617

"9.9.3.1 Uplink TBF Using the AcknowledgedMode"


NSEI FSH 0720 "7.2.1 Sub-Network Service: Frame Relay onGb Interface"


"7.3.1 BSSGP Addressing: BSSGP VirtualConnections (BVCs)"

NSVCI FSH 0720 "7.2.1 Sub-Network Service: Frame Relay onGb Interface"


"7.2.2.2 Control Procedures"

NSVLI FSH 0720 "7.2.1 Sub-Network Service: Frame Relay onGb Interface"


NTWCNDRXP FSH 0418 "10.3.1 Network Controlled Cell Reselection"

NTWCOR FSH 0720 "10.3.1 Network Controlled Cell Reselection"

NTWCREPPIDL FSH 0418 "10.3.1 Network Controlled Cell Reselection"

NTWCREPPTR FSH 0418 "10.3.1 Network Controlled Cell Reselection"

"10.3.1.1 Measurement Reporting"

NUA FSH 0720 "7.1 Physical Layer"

PCMECH FSH 0720 "10.4.2.2 Packet Transfer Mode: Measure-ments for Power Control"

PCML FSH 0720 "7.1 Physical Layer"

PCUID (FLR object -In previous releases itwas called PCUN)

FSH 0720 "7.1 Physical Layer"


PCUN(PTPPKF object)

FSH 0720 REMOVED IN BR6.0

PERSTLVPRI1 FSH 0420 "9.8.2.6 Uplink Access on PRACH (AccessPersistence Control)"




A30808-X3247-L24-5-7618 293

InformationSystem




PKTMEASREPCNT FSH 0418 "10.3.1.2 Radio Link Network Controlled CellReselection Algorithm"

PKTNDEC FSH 0720 "9.9.3.1 Uplink TBF Using the AcknowledgedMode"

"9.9.3.2 Uplink TBF Using the Unacknowl-edged Mode"

PKTNINC FSH 0720 "9.9.3.1 Uplink TBF Using the AcknowledgedMode"


PKTNMA FSH 0720 "9.9.3.1 Uplink TBF Using the AcknowledgedMode"


PRPBCCH FSH 0720 "10.4.2.1 Packet Idle Mode: Measurementsfor Power Control"

"10.4.3 BTS Output Power"

QSRHPRI CR - X482 "10.2.2 GSM-UMTS Re-selection Algorithm:Packet Switched Case"

RAARET FSH 0720 "10.1.5 Abnormal Cell Re-selection"

RACODE FSH 0720 "9.2 Network Structure"


RACOL FSH 0720 "9.2 Network Structure"

"9.2 Network Structure"

RAENV FSH 0444 "10.5 Link Adaptation"

"10.5.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"






294 A30808-X3247-L24-5-7618






STGTTLLIINF FSH 0444 "10.5.1.2 “Quality Traps” Disadvantage"


T1 FSH 0720 "7.3.1.1 BVC Procedures"

T2 FSH 0720 "7.3.1.1 BVC Procedures"

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 (AccessPersistence Control)"

T3191 FSH 0720 "9.9.4.2 Release of a Downlink TBF"

T3192 FSH 0720CR - X617

"9.9.4.2 Release of a Downlink TBF"

T3193 FSH 0720CR - X617

"9.9.4.2 Release of a Downlink TBF"

T391 FSH 0720 "7.2.1.3 Procedures for PVCs"

TAVGT FSH 0720 "10.4.2.2 Packet Transfer Mode: Measure-ments for Power Control"

TAVGW FSH 0720 "10.4.2.1 Packet Idle Mode: Measurementsfor Power Control"

TCONG FSH 0720 "7.2.1.2 Frame Relay Structure"

TCONOFF FSH 0720 "7.2.1.2 Frame Relay Structure"

TDDARFCN FSH 0418 "10.2.3 Handling of UMTS Neighboring Cells"

TDDDIV FSH 0418 "10.2.3 Handling of UMTS Neighboring Cells"

TDDGQO FSH 0418 "10.2.2 GSM-UMTS Re-selection Algorithm:Packet Switched Case"

TEMPCH FSH 0720 "5.3.1 Generalities about Resource Assign-ments"



TEMPPDT FSH 0429 "5.3.1 Generalities about Resource Assign-ments"

TF1 FSH 0720 "7.3.3 SGSN-BSS Flow Control"



A30808-X3247-L24-5-7618 295

InformationSystem


THPROXT FSH 0720CR - F287CR - X617

This parameter was introduced for an olderSMG release, and it is no longer used startingfrom 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"

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"

TRFPS FSH 0418 "10.3.2 GPRS/EGPRS Traffic ControlStrategy"

TRFPSCTRL CR - X1850 "10.3.1.2 Radio Link Network Controlled CellReselection Algorithm"

TRFPSCTRLT FSH 0418 This parameter in BR7.0 release is not signifi-cant.

TRXMD FSH 0420 "5.1.1 Enabling GPRS Service in the Cell"

"5.1.2 Enabling EGPRS Service in the Cell"

"5.1.3 Aspects Related to Carrier Configura-tion"

"9.8.2.4 TBF Establishment for EDGE MobileStations"


TSULBAL CR - X1495 "9.9.5 Notes About Concurrent TBFs"

UPGRFREQ FSH 0516 "5.3.4.1 Upgrade of Radio Resources"

Parameter Object Feature/CR Chapters

ASSLAPD SUBTSLB FSH 0419 "6.3.3 Configuration of the Abis Interface"

BSCT17 BSC ---- "8.2 PCU Overload Management"

BSCT18 BSC ---- "8.2 PCU Overload Management"

CELLGLID TGTFDD CR - X260 "10.2.3 Handling of UMTS NeighboringCells"

Tab. 11.2 Unspecific GPRS/EGPRS Parameters Involved in PS Services



296 A30808-X3247-L24-5-7618


CELLRESH BTS ---- "10.1.3 Cell Re-selection Algorithm"

CPOLICY BSC FSH 0457CR - F092CR - X1150

"5.3.3 Management of IncomingGPRS/EGPRS Requests"



"5.3.6.1 Pre-emption of PDCH Channels"

ENFOIAHO BSC FSH 0457CR - F092

"5.3.6.3 Forced Intracell Handovers ofAlready Established CS Calls"

DGRSTRGY BSC FSH 0457CR - F092CR - X912CR - X1150

"5.3.6 Waiting Queue Management"

"5.3.6.1 Pre-emption of PDCH Channels"

FDDARFCN TGTFDD CR - X260 "10.2.3 Handling of UMTS NeighboringCells"

FDDDIV TGTFDD CR - X260 "10.2.3 Handling of UMTS NeighboringCells"

FDDQO BTS CR - X260 "10.2.1 GSM-UMTS Re-selection Algo-rithm: Circuit Switched Case"

FDDQMI BTS CR - X260CR - X482

"10.2.1 GSM-UMTS Re-selection Algo-rithm: Circuit Switched Case"

"10.2.2 GSM-UMTS Re-selection Algo-rithm: Packet Switched Case"

FDDSCRMC TGTFDD CR - X260 "10.2.3 Handling of UMTS NeighboringCells"

MSTXPMAXCH BTS ---- "10.1.2.1 GPRS/EGPRS Path Loss Crite-rion (C1 Criterion)"

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"

"5.1.2 Enabling EGPRS Service in theCell"

QSRHI BTS CR - X260 "10.2.1 GSM-UMTS Re-selection Algo-rithm: Circuit Switched Case"

RNCID TGTFDD CR - X260 "10.2.3 Handling of UMTS NeighboringCells"

RXLEVAMI BTS ---- "10.1.2.1 GPRS/EGPRS Path Loss Crite-rion (C1 Criterion)"



A30808-X3247-L24-5-7618 297

InformationSystem


SISGSNREL99 BSC FSH 0420FSH 0514


"3.2 Network Architecture"

TDDQO BTS FSH 0418 "10.2.1 GSM-UMTS Re-selection Algo-rithm: Circuit Switched Case"

TGTCELL ADJC FSH 1928CR - F119


"10.1.4.3 Configuration of an AdjacentCell with GSUP= TRUE"

TGTCELL ADJC3G CR - X260 "10.2.3 Handling of UMTS NeighboringCells"

Object Feature Chapters

FRL FSH 0720 "7 Gb Interface"

NSVC FSH 0720 "7 Gb Interface"

PCMG FSH 0720 "7 Gb Interface"

PCU FSH 0720 "6 Hardware and Software Architecture"

PTPPKF FSH 0720 "4 Radio Interface Description"

TGTPTPPKF FSH 1928CR - F119


Tab. 11.3 Object Related to the GPRS/EGPRS Services only

Object Feature/CR Chapters

ADJC ---- "10.1 Cell Selection and Re-selection"

ADJC3G CR - X260 "10.2.3 Handling of UMTS Neighboring Cells"

SUBTSLB FSH 0419 "6.3.3 Configuration of the Abis Interface"

TGTBTS FSH 1928CR - F119

"10.1.4 Management of GPRS/EGPRS NeighboringCells"

TGTFDD CR - X260 "10.2.3 Handling of UMTS Neighboring Cells"

TGTTDD FSH 0418 "10.2.3 Handling of UMTS Neighboring Cells"

Tab. 11.4 Unspecific GPRS/EGPRS Objects Involved in PS Services



298 A30808-X3247-L24-5-7618


12 AbbreviationsAGCH Access Grant Channel

BCCH Broadcast Control Channel

BECN Backward Explicit Congestion Notification

BSC Base Station Controller

BSN Block Sequence Number

BSS Base Station Subsystem

BSSGP Base Station System GPRS Protocol

BVC BSSGP Virtual Connection

BVCI BSSGP Virtual Connection Identifier

CCCH Common Control Channel

CCU Channel Control Unit

CS Circuit Switched

DCE Data Circuit-terminating Equipment

DE Discard Eligibility Indicator

DLCI Data Link Connection Identifier

DRX Discontinous Reception

DTE Data Terminal Equipment

EGPRS Enhanced General Packet Radio Service

FDD Frequency Division Duplex

FECN Forward Explicit Congestion Notification

FR Frame Relay

FRL Frame Relay Link

GGSN Gateway GPRS Support Node

GMSK Gaussian Minimum Shift Keying

GPRS General Packet Radio Service

HA Horizontal Allocation

HCS Hierarchical Cell Structures

HLR Home Location Register

HSCSD High Speed Circuit Switched Data

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

LLC Logical Link Control

LMT Local Maintenance Terminal

MA Mobile Allocation

MAC Medium Access Control

A30808-X3247-L24-5-7618 299

InformationSystem


MAIO Mobile Allocation Index Offset

MCC Mobile Country Code

MCS Modulation and Coding Scheme

MNC Mobile Network Code

MOI Managed Object Instance

MS Mobile Station

MSC Mobile Switching Centre

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

NUC Nailed Up Connection

O&M Operation and Maintenance

PAGCH Packet Acces Grant Channel

PBCCH Packet Broadcast Control Channel

PCCCH Packet Common Control Channel

PCH Paging Channel

PCU Packet Control Unit

PDCH Packet Data Channel

PDT Packet Data Terminal

PDTCH Packet Data Traffic Channel

PDU Packet Data Network

PDU Packet Data Unit

PLMN Public Land Mobile Network

PPCH Packet Paging Channel

PRACH Packet Random Acces Channel

PS Packet Switched

PSI Packet System Information

PSK Phase Shift Keying

PTCCH Packet Timing Advance Control Channel

PTM Point to Multipoint

P-TMSI Packet Temporary Mobile Subscriber Iden-tity

PTP Point to Point

PTPPKF Point To Point Packet Function

PVC Permanent Virtual Circuit

QoS Quality of Service

RA Routing Area

300 A30808-X3247-L24-5-7618


RAC Routing Area Code

RACH Random Access Channel

RAI Routing Area Identity

RAT Radio Access Technology

RC Radio Commander

RLC Radio Link Control

SGSN Serving GPRS Support Node

SMS Short Message Service

SNDCF SubNetwork Dependent ConvergenceProtocol

SS7 Signalling System number 7

TAI Timing Advance Index

TBF Temporary Block Flow

TCH Traffic Channel

TDD Time Division Duplex

TDMA Time Division Multiple Access

TFI Temporary Flow Identity

TLLI Temporary Logical Link Identity ,TSC Training Sequence Code

UE User Equipment

UMTS Universal Mobile TelecommunicationSystem

USF Uplink State Flag

VA Vertical Allocation

VLR Visitor Location Register

Documents

GPRS - Siemens