edge feature nokia(ned)

EDGE System Feature Description

DN03299216Issue 9-0 en20/03/2008

# Nokia Siemens Networks 1 (272)

BSC3153Nokia GSM/EDGE BSS, Rel. BSS13, BSC andTCSM, Rel. S13, Product Documentation, v.4

The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This documentation is intended for theuse of Nokia Siemens Networks customers only for the purposes of the agreement under whichthe document is submitted, and no part of it may be used, reproduced, modified or transmitted inany form or means without the prior written permission of Nokia Siemens Networks. Thedocumentation has been prepared to be used by professional and properly trained personnel,and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomescustomer comments as part of the process of continuous development and improvement of thedocumentation.

The information or statements given in this documentation concerning the suitability, capacity, orperformance of the mentioned hardware or software products are given “as is” and all liabilityarising in connection with such hardware or software products shall be defined conclusively andfinally in a separate agreement between Nokia Siemens Networks and the customer. However,Nokia Siemens Networks has made all reasonable efforts to ensure that the instructionscontained in the document are adequate and free of material errors and omissions. NokiaSiemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues whichmay not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NOEVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUTNOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESSOPPORTUNITY OR DATA, THAT MAYARISE FROM THE USE OF THIS DOCUMENT OR THEINFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights andother intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark ofNokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners,and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2008. All rights reserved.

2 (272) # Nokia Siemens Networks DN03299216Issue 9-0 en20/03/2008


Contents

Contents 3

Summary of changes 7

1 About this document 13

2 GPRS 152.1 GPRS data transfer protocols 212.2 Optimised GPRS Radio Resource Management 232.3 Frame Relay and Gb Interface 272.4 GPRS in Nokia Base Stations 29

3 EDGE 31

4 Software related to GPRS/EDGE 414.1 Extended Uplink TBF Mode 414.2 GPRS Coding Schemes 424.3 Link Adaptation for GPRS 464.4 Priority Class Based Quality of Service (QoS) 474.5 System Level Trace 49

5 Software related to EGPRS 555.1 EGPRS Modulation and Coding Schemes 555.2 EGPRS Packet Channel Request on CCCH 565.3 Incremental Redundancy 575.4 Link Adaptation for EGPRS 585.5 Nokia Smart Radio Concept for EDGE 605.6 8 Phase Shift Keying 67

6 System impact of GPRS/EDGE 696.1 System impact of GPRS 696.1.1 Requirements 696.1.2 Restrictions 716.1.3 Impact on transmission 726.1.4 Impact on BSS performance 726.1.5 User interface 736.1.5.1 BSC MMI 736.1.5.2 BTS MMI 746.1.5.3 BSC parameters 746.1.5.4 Alarms 806.1.5.5 Measurements and counters 826.1.6 Impact on Network Switching Subsystem (NSS) 886.1.7 Impact on NetAct products 886.1.8 Impact on mobile terminals 896.1.9 Impact on interfaces 896.1.10 Interworking with other features 906.2 System impact of EDGE 986.2.1 Requirements 98

DN03299216Issue 9-0 en20/03/2008


Contents

6.2.1.1 EDGE BTSs and hopping 1006.2.2 Restrictions 1036.2.3 Impact on transmission 1056.2.4 Impact on BSS performance 1056.2.5 User interface 1096.2.5.1 BSC MMI 1096.2.5.2 BTS MMI 1096.2.5.3 BSC parameters 1096.2.5.4 Alarms 1116.2.5.5 Measurements and counters 1126.2.6 Impact on Network Switching Subsystem (NSS) 1186.2.7 Impact on NetAct products 1206.2.8 Impact on mobile terminals 1216.2.9 Impact on interfaces 1226.2.10 Interworking with other features 123

7 System impact of GPRS/EDGE related software 1337.1 System impact of EGPRS Packet Channel Request on CCCH 1337.1.1 Requirements 1337.1.2 Impact on transmission 1347.1.3 Impact on BSS performance 1347.1.4 User interface 1357.1.5 Impact on Network Switching Subsystem (NSS) 1367.1.6 Impact on NetAct products 1367.1.7 Impact on mobile terminals 1367.1.8 Impact on interfaces 1367.2 System impact of Extended Uplink TBF Mode 1377.2.1 Requirements 1377.2.2 Impact on transmission 1387.2.3 Impact on BSS performance 1387.2.4 User interface 1397.2.5 Impact on Network Switching Subsystem (NSS) 1407.2.6 Impact on NetAct products 1407.2.7 Impact on mobile terminals 1417.2.8 Impact on interfaces 1417.2.9 Interworking with other features 1427.3 System impact of Nokia Smart Radio Concept for EDGE 1427.3.1 Requirements 1427.3.2 Impact on transmission 1437.3.3 Impact on BSS performance 1437.3.4 User interface 1447.3.5 Impact on Network Switching Subsystem (NSS) 1457.3.6 Impact on NetAct products 1457.3.7 Impact on mobile terminals 1467.3.8 Impact on interfaces 1467.4 System impact of Priority Class based Quality of Service 1477.4.1 Requirements 1487.4.2 Impact on transmission 1497.4.3 Impact on BSS performance 1497.4.4 User interface 1507.4.5 Impact on Network Switching Subsystem (NSS) 1537.4.6 Impact on NetAct products 153



7.4.7 Impact on mobile terminals 1547.4.8 Impact on interfaces 1547.4.9 Interworking with other features 1547.5 System impact of System Level Trace 1547.5.1 Requirements 1557.5.2 Impact on transmission 1567.5.3 Impact on BSS performance 1567.5.4 User interface 1577.5.5 Impact on Network Switching Subsystem (NSS) 1617.5.6 Impact on NetAct products 1617.5.7 Impact on mobile terminals 1627.5.8 Impact on interfaces 1627.5.9 Interworking with other features 163

8 Requirements for GPRS/EDGE 1658.1 Packet Control Unit (PCU) 1658.2 Gb interface functionality 1708.3 Additional GPRS hardware needed in BSCi and BSC2i 173

9 Radio network management for GPRS 1759.1 Routing Area 1759.2 PCU selection algorithm 177

10 Gb interface configuration and state management 17910.1 Protocol stack of the Gb interface 17910.2 Load sharing function 18210.3 NS-VC management function 18210.4 BVC management function 18710.5 Recovery in restart and switchover 189

11 Radio resource management 19311.1 Territory method 19411.2 Circuit switched traffic channel allocation in GPRS territory 20211.3 BTS selection for packet traffic 20311.4 Quality of Service 20411.5 Channel allocation and scheduling 20611.6 Quality Control 21511.7 MS Multislot Power Reduction (PCU2) 21611.8 Error situations in GPRS connections 218

12 GPRS/EDGE radio connection control 22112.1 Radio channel usage 22112.2 Data Transfer Protocols and Connections 22212.3 Paging 22312.4 Mobile terminated TBF (GPRS or EGPRS) 22612.5 Mobile originated TBF (GPRS or EGPRS) 22912.6 Suspend and resume GPRS 23512.7 Flush 23612.8 Cell selection and re-selection 23712.9 Traffic administration 23712.10 Coding scheme selection in GPRS 24012.11 Coding scheme selection in EGPRS 251

DN03299216Issue 9-0 en20/03/2008


Contents

12.12 Power control 25412.13 MS Radio Access Capability update 255

13 Implementing GPRS 25713.1 Implementing GPRS overview 257

14 Implementing EGPRS 25914.1 Implementing EGPRS overview 259

15 Configuring Intelligent Downlink Diversity 26515.1 Functional requirements and restrictions 26515.2 Supported configurations 26615.3 Configuring BTS to IDD mode with BTS Manager 26815.4 Configuring IDD in the BSC 27015.5 Alarm handling 27015.6 RX antenna supervision and IDD/4UD 27115.7 Object state management 27115.8 TRX reconfiguration 27215.9 TRX tests 272



Summary of changes

Changes between document issues are cumulative. Therefore, the latestdocument issue contains all changes made to previous issues.

Changes made between issues 9-0 and 8-1

The name of the document has been changed from (E)GPRS SystemFeature Description to GPRS/EDGE System Feature Description. Thecontents of (E)GPRS in BSC have been merged into this document.

Chapters Support for PBCCH/PCCCH and System impact of Support forPBCCH/PCCCH have been removed.

Chapters Dynamic Abis and System Impact of Dynamic Abis have beenmoved from this document to Dynamic Abis.

Chapter Software related to GPRS/EDGE has been modified to onlyinclude descriptions of such GPRS/EDGE-related features that do nothave their own separate description documents.

GPRS Coding Schemes

Support for 2nd generation BTS and PrimeSite BTS has been removed.

System Level Trace

Section System Level Trace in BSC has been moved here from (E)GPRSin BSC.

EGPRS Packet Channel Request on CCCH

A reference to PCCCH/PBCCH has been removed.

System impact of GPRS

DN03299216Issue 9-0 en20/03/2008


Summary of changes

Support for 2nd generation BTS and PrimeSite BTS has been removed.91 PBCCH Availability Measurement has been removed. Extended CellRange restriction has been removed.

Section Restrictions has been moved here from GPRS in BSC.

110 PCU Utilization Measurement has been added. New counters havebeen added to 72 Packet Control Unit Measurement.

Interworking with EGSM 900 - PGSM 900 BTS has been updated. Areference to GPRS/EDGE Support for PGSM-EGSM BTS was added.

The name of alarm 3273 (E)GPRS TERRITORY FAILURE has beenupdated to 3273 GPRS/EDGE TERRITORY FAILURE.

System impact of Nokia EDGE

Support for 2nd generation BTS and PrimeSite BTS has been removed.91 PBCCH Availability Measurement has been removed. Extended CellRange restriction has been removed.

Section Restrictions has been moved here from (E)GPRS in BSC.

110 PCU Utilization Measurement has been added. New counters havebeen added to 72 Packet Control Unit Measurement and 79 CodingScheme Measurement.

The name of alarm 3273 (E)GPRS TERRITORY FAILURE has beenupdated to 3273 GPRS/EDGE TERRITORY FAILURE.

System impact of EGPRS Packet Channel Request on CCCH

Support for 2nd generation BTS and PrimeSite BTS has been removed.Interworking with PCCCH/PBCCH has been removed.

System impact of Nokia Smart Radio Concept for EDGE


System impact of Priority Class based Quality of Service


System impact of System Level Trace




New counters have been added to 25 TBF Observation for GPRS Trace.

System impact of Extended Uplink TBF Mode

Support for 2nd generation BTS and PrimeSite BTS has been removed.New PRFILE parameters have been added.

Requirements for GPRS/EDGE

The chapter has been moved here from (E)GPRS in BSC. Information onPCCCH/PBCCH has been removed.

Radio network management for GPRS

The chapter has been moved here from (E)GPRS in BSC. A reference toPacket Control Unit (PCU2) Pooling has been added. Information onPCCCH/PBCCH has been removed.

Gb interface configuration and state management

The chapter has been moved here from (E)GPRS in BSC. A reference toMultipoint Gb Interface has been added.

Radio resource management

The chapter has been moved here from (E)GPRS in BSC. Information onPCCCH/PBCCH has been removed.

GPRS/EDGE radio connection control

The chapter has been moved here from (E)GPRS in BSC. SectionPACKET PSI STATUS procedure has been removed. Information onPCCCH/PBCCH has been removed.

The GPRS and EGPRS implementing instructions have been combinedinto single chapters.


Changes made between issues 8-1 and 8-0 lists the changes made to thedocument after the Nokia GSM/EDGE BSS, Rel. BSS12, SystemDocumentation pilot release. The following changes have been made:

DN03299216Issue 9-0 en20/03/2008


Summary of changes

. Nokia MetroSite BTS does not support Intelligent Downlink Diversity(IDD) or Interference Rejection Combining (IRC). Information onMetroSite support for IDD and IRC has been removed from chaptersConfiguring Intelligent Downlink Diversity, Nokia Smart RadioConcept for EDGE, and System impact of Nokia EDGE.

. The RDIV parameter value has been corrected in chapterConfiguring Intelligent Downlink Diversity.

. PCU2 support for PBCCH/PCCCH has been removed from chapterPacket Control Unit in BSC.


Information on the following new software and hardware products hasbeen added:

. Dual Transfer Mode

. Extended Dynamic Allocation

. High Multislot Classes

. Space Time Interference Rejection Combining

. Nokia Flexi EDGE BTS

The following system impact information has been added:

. System impact of Priority Based Quality of Service

. System impact of Dynamic Abis

. System impact of Support for PBCCH/PCCCH

. System impact of Nokia Smart Radio Concept for EDGE (NokiaSRC)

Chapter Support for PCU2 has been removed and the content moved toPacket Control Unit (PCU) in BSC. Information on BSC3i 1000 and BSC3i2000 has been added.

Chapter Coding Schemes CS-3 and CS-4 has been removed and thecontent moved to GPRS Coding Schemes.

Chapter Nokia Smart Radio Concept for EDGE (Nokia SRC) has beenupdated with information on ST-IRC.



The implementing instructions for GPRS and EGPRS have beenthoroughly revised to include the entire implementation procedure. Thechapter title Adding and removing TSLs to/from EDAP has been changedto Modifying EDAP timeslots. The following new chapters have beenadded:

. Activating GPRS

. Modifying GPRS

. Deactivating GPRS

. Configuring EDAP for BTS

. Testing the activation of EGPRS

. Deactivating EGPRS in BSC

DN03299216Issue 9-0 en20/03/2008


Summary of changes

1 About this document

This document includes information on both Nokia EDGE and NokiaGPRS. If you need information on GPRS alone, see GPRS SystemFeature Description.

This document is for S13/BSS13 level software.

In the context of this description, the term 'PCU' refers to both PCUvariants, PCU1 and PCU2. All mentioned issues apply to both variants,unless otherwise stated.

This text is applicable to both ANSI and ETSI environments.

The system impact chapters on GPRS/EDGE related features without theirown System Feature Descriptions are also included in this document.

DN03299216Issue 9-0 en20/03/2008


About this document

2 GPRS

General Packet Radio Service (GPRS) provides packet data radio accessfor GSM mobile phones. It upgrades GSM data services to allow aninterface with Local Area Networks (LANs), Wide Area Networks (WANs)and the Internet.

GPRS makes the radio interface usage more efficient:

. GPRS enables a fast method for reserving radio channels

. GPRS uses the same resources with circuit switched connection bysharing the overhead capacity

. GPRS provides immediate connectivity and high throughput.

On a general level, GPRS connections use the resources only for a shortperiod of time when sending or receiving data:

. in a circuit-switched system, the line is occupied even when no datais transferred

. in a packet-switched system, the resources are released so they canbe used by other subscribers.

GPRS is therefore well adapted to the bursty nature of data applications.GPRS has minimal effects on the handling of circuit switched calls, but theinteroperability of existing circuit switched functionalities needs to be takeninto account.

GPRS uses statistical multiplexing instead of static time divisionmultiplexing: when the user is ready to receive new data, the terminalsends a request, and resources are again reserved only for the duration oftransmitting the request and initiating a second data transfer. The data tobe transferred is encapsulated into short packets with a header containingthe originating and destination address. No pre-set time slots are used.Instead, network capacity is allocated when needed and released whennot needed.

DN03299216Issue 9-0 en20/03/2008


GPRS

GPRS offers a very flexible range of bitrates, from less than 100 bit/s toover 100 kbit/s. Applications that need less than one time slot benefit fromGPRS's ability to share one time slot among several users. Moreover, thehigh bitrates that GPRS provides by using multiple time slots give shortresponse times, even if a lot of data is transmitted.

The main functions of the BSC with GPRS are to:

. manage GPRS-specific radio network configuration

. control access to GPRS radio resources

. share radio resources between GPRS and circuit switched use

. handle signalling between the MS, BTS and Serving GPRS SupportNode (SGSN)

. transfer GPRS data.

BSC operational software includes support for GPRS coding schemes CS-1 and CS-2. Support for coding schemes CS-3 and CS-4 is an applicationsoftware product that requires PCU2 and Dynamic Abis.

GPRS is an application software product and requires a valid licence in theBSC. For more information, see Licensing in BSC.

Benefits of GPRS

GPRS offers the following additional benefits for the operators/end users:

. resources are used more efficiently, thus there is less idle time

. circuit switched traffic is prioritised, but quality is guaranteed byreserving time slots for GPRS traffic only

. new services, application, and businesses for the operators

. fast connection set-up for end users

. high bit rate in data bursts

. possibility of being charged only for transferred data

. generally, any service that can be run on top of IP protocols (theUDP or TCP transfer) is supported by the Nokia GPRS solution(taking into account data rate and delay requirements).



An investment in the GPRS infrastructure is an investment in futureservices. GPRS paves the way and is already part of the third generation(3G) network infrastructure. Migration to 3G comprises deployment of thenew WCDMA radio interface – served by the GSM and GPRS corenetworks. Many of the 3G services are based on IP, and the GPRS Corenetwork is the key step of introducing the IP service platform into thepresent GSM networks.

When migrating to 3G services, preserving the Core Network investmentsis a top priority. Introducing UMTS will complement the GSM network – notreplace it.

Required network changes

Nokia offers a total end-to-end General Packet Radio Service (GPRS)solution including the GPRS core, network management, and charginggateway with high capacity, scalability, and carrier class availability. As apart of the GPRS solution, the Nokia BSS offers GPRS support in the BSSwith powerful radio resource management algorithms, optimised BSSnetwork topology, and transmission solutions to ensure an optimalinvestment to operators and high capacity and quality service for endusers.

While the current GSM system was originally designed with an emphasison voice sessions, the main objective of the GPRS is to offer access tostandard data networks such as LAN using the TCP/IP protocol. Thesenetworks consider the GPRS to be a normal subnetwork, as seen in thefigure below. A gateway in the GPRS network acts as a router and hidesGPRS-specific features from the external data network. WAP (WirelessApplication Protocol) based services see the GPRS as one carrier (UDP).Wireless Markup Language (WML) based services in the GPRS can beaccessed using the standard WAP gateways. The WAP is essential increating applications that are 'useable' in the mobile environment (forexample, small screen display, low data rates).

DN03299216Issue 9-0 en20/03/2008


GPRS

Figure 1. GPRS network seen by another data network

GPRS is the first GSM Phase 2+ service that requires major changes inthe network infrastructure. In addition to the current GSM entities, GPRS isbased on a number of new network elements:

. Serving GPRS Support Nodes (SGSN)

. GPRS backbone

. Legal Interception Gateway (LIG).



Figure 2. GPRS architecture

Along with the new network elements, the following functions are needed:

. GPRS-specific mobility management

. Network management capable of handling the GPRS-specificelements

. A new radio interface for packet traffic

. New security features for the GPRS backbone and a new cipheringalgorithm

. New MAP and GPRS-specific signalling.

Related topics in GPRS System Feature Description

. Extended Uplink TBF Mode

. GPRS Coding Schemes

. Link Adaptation for GPRS

. Priority Class Based Quality of Service (QoS)

. System Level Trace

. System impact of GPRS

DN03299216Issue 9-0 en20/03/2008


GPRS

. System impact of Extended Uplink TBF Mode

. System impact of Priority Class based Quality of Service

. System impact of System Level Trace

. Requirements for GPRS

. Radio network management for GPRS

. Gb interface configuration and state management

. Radio resource management

. GPRS radio connection control

. Implementing GPRS overview

Other related topics

. Feature Descriptions. Data


. Dynamic Abis

. Extended Cell for GPRS/EDGE


. Gb over IP


. Inter-System Network-Controlled Cell Re-selection

. Multipoint Gb Interface

. Network-Assisted Cell Change

. Network-Controlled Cell Re-selection

. Packet Control Unit (PCU2) Pooling

. Test and activate. Data

. Activating and testing BSS9006: GPRS

. Reference. Commands

. MML Commands. EA - Adjacent Cell Handling. EE - Base Station Controller Parameter Handling

in BSC. EG - GSM Timer and BSC Parameter Handling. EQ - Base Transceiver Station Handling in BSC. ER - Transceiver Handling



. ES - Abis Interface Configuration

. EU - Power Control Parameter Handling

. FX - Gb Interface Handling. Service Terminal Commands

. PCU2 Service Terminal Commands. Counters/Performance Indicators

. Circuit-switched measurements. 106 CS DTM Measurement

. Packet-switched measurements

. Observations. 25 TBF Observation for GPRS Trace. 27 GPRS Cell Re-selection Report. 28 GPRS RX Level and Quality Report

. Parameters. BSS Radio Network Parameter Dictionary. PAFILE

. PAFILE timer and parameter lists. PRFILE and FIFILE

. PRFILE and FIFILE parameters

2.1 GPRS data transfer protocols

Figure 3. Transmission plane

DN03299216Issue 9-0 en20/03/2008


GPRS

The GSM RF is the normal GSM physical radio layer. The Radio LinkControl (RLC) function offers a reliable radio link to the upper layers. TheMedium Access Control (MAC) function handles the channel allocationand the multiplexing, that is, the use of physical layer functions. The RLCand the MAC together form the OSI Layer 2 protocol for the Um interface.The Logical Link Control (LLC) layer offers a secure and reliable logicallink between the MS and the SGSN to upper layers and is independent ofthe lower layers. The LLC layer has two transfer modes, the acknowledgedand unacknowledged. The LLC conveys signalling, SMS, and SNDCPpackets. The Subnetwork Dependent Convergence Protocol (SNDCP) is amapping and compression function between the network layer and lowerlayers. It also performs segmentation, re-assembly, and multiplexing.

The Base Station System GPRS Protocol (BSSGP) transfers controlinformation and data between a BSS and a SGSN. The Network Servicesrelays the BSSGP packets over the Gb interface and has load sharing andredundancy on top of Frame Relay. The L1bis is a vendor-dependent OSILayer 1 protocol. The Relay function relays LLC PDUs (Protocol DataUnits) between the LLC and BSSGP.

The Packet Control Unit is responsible for the following GPRS MAC andRLC layer functions as defined in 3GPP TS 43.064:

. LLC layer PDU segmentation into RLC blocks for downlinktransmission

. LLC layer PDU re-assembly from RLC blocks for uplink transmission

. PDCH scheduling functions for the uplink and downlink datatransfers

. PDCH uplink ARQ functions, including RLC block ack/nack

. PDCH downlink ARQ function, including buffering andretransmission of RLC blocks

. Channel access control functions, for example, access requests andgrants

. Radio channel management functions, for example, power control,congestion control, broadcast control information, etc.. The Channel Codec Unit (CCU) takes care of the channel

coding functions, including FEC and interleaving

. Radio channel measurement functions, including received qualitylevel, received signal level, and information related to timingadvance measurements.

For more information on the PCU, see Packet Control Unit (PCU).



The Network Protocol Data Units (N-PDU) are segmented into theSubnetwork Protocol Data Units (SN-PDU) by the Subnetwork DependentConvergence (SNDC) protocol, and SN-PDUs are encapsulated into oneor several LLC frames. LLC frames are of variable length. The maximumsize of the LLC frame is 1600 octets minus GP protocol controlinformation. See 3GPP TS 23.060 for information on SNDC and LLC. Thedetails on SNDC can be found in 3GPP TS 44.065 and the details on LLCin 3GPP TS 44.064. LLC frames are segmented into RLC Data Blocks. Inthe RLC/MAC layer, a selective ARQ protocol (including block numbering)between the MS and the network provides retransmission of erroneousRLC Data Blocks. When a complete LLC frame is successfully transferredacross the RLC layer, it is forwarded to the LLC layer.

Figure 4. Transmission and reception data flow

2.2 Optimised GPRS Radio Resource Management

The Nokia BSS offers dynamic algorithms and parameters to optimise theuse of radio resources. A dynamic and flexible GPRS radio resourcemanagement is important in effective usage of the Air interface capacity toensure maximum and secure data throughput. The limited radio resourcesmust be used effectively.

The figure below introduces the dedicated GPRS DCH channels:

DN03299216Issue 9-0 en20/03/2008


GPRS

Figure 5. GPRS DCH dedicated channels

GPRS packets are sent uni-directionally; uplink and downlink are separateresources. An MS can also have a bi-directional connection while usingGPRS, by having simultaneous uplink and downlink packet transfers. ATemporary Block Flow (TBF) is made for every new data flow. One or morepacket data traffic channels (PDTCHs) are allocated for the TBF. The TBFis used to send RLC/MAC blocks carrying one or more LLC PCUs. TheTBF reservations of PDTCHs are released when all the RLC/MAC blockshave been sent successfully.

Basically all TBFs have the same priority, that is, all users and allapplications get the same service level. The needs of different applicationsdiffer and mechanisms to have separate service levels are required. ETSIspecifications define QoS functionality which gives the possibility todifferentiate TBFs by delay, throughput and priority. Priority BasedScheduling is introduced as a first step towards QoS. With Priority BasedScheduling the operator can give users different priorities so that higherpriority users will get better service than lower priority users. There will beno extra blocking to any user, only the experienced service qualitychanges.

Packet Associated Control Channel (PACCH) conveys signallinginformation related to a given MS. The PACCH is a bi-directional channeland is located in the PDCH. It transmits signalling in both directionsalthough data is transmitted (PDTCH) only in the assigned direction.



Multiple MSs can share one PDTCH, but the PDTCH is dedicated to oneMS (TBF) at a time. This means that the PDTCH is reserved for multipleTBFs, but one TBF is receiving or sending at a time. All the GPRS TBFsallocated to a PDTCH are served equally. The number of TSLs allocatedfor a multislot MS is determined by the mobile's multislot capability andnetwork resources. Reallocations are done when the transfer mode ischanged between uni-directional (only uplink or downlink data transfer)and bi-directional (simultaneous uplink and downlink data transfer).

All the full rate or dual rate traffic channels are GPRS capable. With theNokia GPRS solution, the operator can define dynamically multipleparameters related to network configuration, such as:

. GPRS capacity cell by cell and TRX by TRX

. GPRS only traffic channels (Dedicated GPRS capacity)

. Default amount of GPRS capable traffic channels (Default GPRScapacity) and

. Whether BCCH TRX or non-BCCH TRX is preferred for GPRS.

The adjustable parameters help the network planners to control andoptimise GPRS radio resources.

Figure 6. Example of a GPRS capable cell

The BSS is upgraded with enhanced RLC/MAC protocols and TRAU forthe radio and Abis interfaces. Circuit Switched (CS) traffic has priority overPacket Switched (PS) traffic. In a CS congestion situation, the CS may usethe Default GPRS traffic channels, but Dedicated GPRS traffic channelsare reserved to carry PS traffic.

TRX 1

TRX 2

BCCH

DefaultGPRS Capacity

DedicatedGPRSCapacity

AdditionalGPRSCapacity

Territory border moves based onCircuit Switched and GPRS traffic load

GPRSTerritory

CircuitSwitchedTerritory

MaxGPRSCapacity

DN03299216Issue 9-0 en20/03/2008


GPRS

The default GPRS capacity determines the number of traffic channels(TCHs), which are always switched to the PCU when allowed by CS trafficload. With these TCHs, the operator can supply the need for fast GPRSchannel reservations for the first data packets. During peak GPRS trafficperiods, additional channels are switched to GPRS use, if the CS trafficload allows it.

Figure 7. Air interface traffic management

Dedicated, default, and additional GPRS TCHs form a GPRS poolconsisting of consecutive radio interface timeslots. When the GPRS poolis upgraded, intra-cell handovers of CS connections may be needed toallow for the selection of consecutive timeslots for GPRS use. New CSconnections may be allocated to a TCH in the GPRS pool only when all theTCHs not belonging to the GPRS pool are occupied.

IUO super reuse frequencies are not used for GPRS traffic, but the featureitself can be used to release resources for GPRS usage. In cells whereBase Band Frequency Hopping is in use, TSL 0 is not used for GPRStraffic.

When Extended Cell for GPRS/EDGE application sotware is used, theExtended Cell GPRS channels (EGTCH) in Extended TRX (E-TRX) arereserved only for fixed GPRS traffic and dynamic GPRS radio resourcemanagement is not used for them at all. For more information, seeExtended Cell for GPRS/EDGE.



2.3 Frame Relay and Gb Interface

Gb is the interface between a BSC and an SGSN. It is implemented usingeither Frame Relay or IP. For more information on Gb over IP, see Gb overIP. Frame Relay can be either point-to-point (PCU–SGSN), or there can bea Frame Relay network located between the BSC and SGSN. The protocolstack comprises BSSGB, NS, and L1. Frame Relay as stated in standardsis a part of the Network Service (NS) layer. On top of the physical layer inthe Gb-interface, the direct point-to-point Frame Relay connections orintermediate Frame Relay network can be used. The physical layer isimplemented as one or several PCM-E1 lines with G.703 interface. The FRnetwork will be comprised of third-party off-the-shelf products. Thefollowing figure displays examples of Gb interface transmission solutions:

Figure 8. BSC - SGSN interface

In the first solution (1) spare capacity of Ater and A interfaces is used forthe Gb. The Gb timeslots are transparently through connected in theTCSM and in the MSC. If free capacity exists, it is best to multiplex all Gbtraffic to the same physical link to achieve possible transmission savings.In many cases, the SGSN will be located in the MSC site, and thus themultiplexing has to take place there as well. Normal cross-connectequipment, for example, Nokia DN2 can be used for that purpose.

DN03299216Issue 9-0 en20/03/2008


GPRS

The second solution (2) represents any transmission network that providesa point-to-point connection between the BSC and the SGSN. In the thirdsolution (3) Frame Relay network is used. The Gb interface allows theexchange of signalling information and user data. The Gb interface allowsmany users to be multiplexed over the same physical resources.

At least one timeslot of 64 kbps is needed for each activated PCU bearer.One PCU1 can handle a maximum of 64 BTSs and 128 TRXs. One PCU2can handle a maximum of 128 BTSs and 256 TRXs. This capacity cannotbe shared with other cells connected to other PCUs in the BSC so there isno pooling. The PCU has to be installed into every BCSU for redundancyreasons, but the FR bearer has to be connected only to the active ones.Considering the transmission protection, it also needs to be decidedwhether two Frame Relay bearers are needed for each PCU usingdifferent ETs (external 2Ms) or if the transmission is protected with crossconnection equipment.

It is possible to multiplex more than one Gb interface directly to the SGSN,or multiplex them on the A interface towards the MSC and cross-connectthem to the SGSN from there. The 2M carrying the Gb timeslots can beone of the BSC's existing ETs, or an ET can be dedicated to the Gbinterface.

The Gb interface allows the exchange of signalling information and userdata. It also allows many users to be multiplexed over the same physicalresources. The logical structure of the point-to-point Gb interface ispresented in the following figure:

Figure 9. Gb logical structure



In the BSC, each PCU represents one Network Service Entity with ownIdentifier (NSEI). Each PCU can have one to four (ffs) FR bearer channels.The Access Rate of a FR Bearer Channel can be configured in 64kbitsteps. Each Bearer channel carries one to four Network Service VirtualConnections (NS-VC). Each BTS has a BSSGP Virtual Connection of itsown. The NSE takes care of the multiplexing of BSSGP VirtualConnections into the NS Virtual Connections and load sharing betweenthe different NS Virtual Connections (= Bearer Channels).

The following figure displays the Gb protocol layers:

Figure 10. Gb interface

2.4 GPRS in Nokia Base Stations

Radio resources are allocated by the BSC (PCU). The BCCH/CCCH isscheduled by the BTS; messages are routed via TRXSIG link between theBTS and BSC. GPRS data itself is transparent to the BTS; routed via TCHchannels in Abis.

The CCU (Channel Coding Unit) in the BTS DSP performs channel codingfor the following rates:

. CS-1 (Channel Coding Scheme 1) - 9.05 kbps




In Packet Transfer Mode, the MS will use the continuous timing advanceupdate procedure. The procedure is carried out on all PDCH timeslots.The mapping in time of these logical channels is defined by a multi-framestructure. It consists of 52 TDMA frames, divided into 12 blocks (of fourframes) and four idle frames.

DN03299216Issue 9-0 en20/03/2008


GPRS

3 EDGE

Enhanced Data rates for Global Evolution (EDGE), introduced to GSM/GPRS standard Release 99, boosts GSM/GPRS network capacity anddata rates to meet the demands of wireless multimedia applications andmass market deployment. The Nokia EDGE Solution includes EnhancedGPRS (EGPRS) for packet switched data.

EDGE uses 200 kHz radio channels, which are the same as the currentGSM channel widths. From a technical perspective, EDGE BSS allows theGSM and GPRS core network to offer a set of new radio access bearers.EDGE is designed to improve spectral efficiency through efficient linkutilisation with GMSK and 8-PSK modulation schemes, which can bealternated on the same radio timeslot according to radio channelconditions. With new modulation, EDGE increases the radio interface datathroughput in average three-fold compared to today's GSM and boostsboth circuit switched and packet switched services. The maximumstandardised data rate per timeslot will triple, and the peak throughput,with eight time slots in the radio interface, can be up to 473 kbit/s.

Since it is fully based on GSM, introducing EDGE to the existing networkrequires relatively small changes to the network hardware and software.EDGE does not entail any new network elements. The operators need notmake any changes to the network structure or invest in new regulatorylicenses. Oversea roaming of GSM/EDGE is better than that of any otherradio technology.

EDGE is an application software product and requires a valid licence in theBSC. For more information, see Licensing in BSC.

You do not need a separate GPRS licence to be able to use GPRS, a validEDGE licence is enough.

DN03299216Issue 9-0 en20/03/2008


EDGE

Benefits of Nokia EDGE solution

EDGE is compatible with GSM/GPRS equipment and services as well asall new emerging 3G services. The Nokia EDGE solution was created togive operators a competitive edge, to help them generate more revenues,and to strengthen their market share by offering a wide selection ofmodern 3G value-added services. Nokia's design target is to protectoperators’ existing investments and provide a smooth and cost-efficientevolution from GSM/GPRS to 3G by optimising the use of the radioresources with the existing infrastructure platform as a basis.

Backed by Nokia’s long, solid expertise in GSM and GPRS systems and acomprehensive knowledge of 3G systems, the Nokia EDGE solutionprovides standardised EDGE features from the very beginning. NokiaEDGE offers greater capacity and a higher Quality of Service (QoS) withexisting site densities and frequency plans.

The Nokia EDGE solution provides an unlimited EDGE growth path, notonly for macrocellular and microcellular solutions, but also for local areasolutions, such as indoor and picocellular. It improves operators’competitiveness in those segments with the most demanding subscribers.EDGE is especially attractive for GSM 800, GSM 900, GSM 1800, andGSM 1900 operators who wish to offer mobile multimedia applications atan early stage because EDGE offers means to provide 3G services for endusers in the existing GSM frequencies.

Compared to the data services currently available from GSM, EDGEprovides significantly higher capacity than GPRS. While GPRS offersimproved data services, EDGE provides more speed for GPRS. WithEDGE, operators realise their full revenue potential through incorporatinginternational roaming in a convenient and cost-effective manner.Operators with UMTS licenses can offer 3G capabilities to all end users ina cost-effective manner. Wideband Code Division Multiple Access(WCDMA) combines well with EDGE for data intensive applications thatrequire data user rates up to 473 kbp/s.

Benefits of EDGE include, for example, the following:

. migration path to wireless multimedia services: operators canincrease their data revenues by offering new, attractive services

. movement to third generation applications

. flexibility in pricing due to lower costs for data capacity in high-speeddata applications, potentially leading to lower price per bit



. fast network implementation by building full coverage using existingsites: EDGE requires no new network elements and the EDGEcapability can be introduced incrementally to the network

. optimised network investment

. flexible, demand-based deployment of data capacity

. improved service quality and end user satisfaction: increased datacapacity and higher data throughput decrease blocking andresponse times for all data services

. lower tariffs, resulting from more efficient networks

Required network changes

EDGE technology is introduced on the existing GSM network and does notcompromise network performance and quality.

Figure 11. Impacts of EDGE on the mobile network (ETSI release 99implementation)

EDGE capableterminal,GSM compatible

More capacity in interfacesto support higher datausage and higher user rates

GSM/EDGE coverage

BTS

BTS

Abis AGb

GnGGSN

SGSN

BSC MSC

EDGE functionalityin network elements

Nokia Flexi EDGE BTSNokia UltraSite EDGE BTSNokia MetroSite EDGE BTSGSM compatible

OSS

DN03299216Issue 9-0 en20/03/2008


EDGE

EDGE support requires minimum hardware changes for existing networks.Only GSM/EDGE TRX Radio Frequency (RF) and Baseband units need tobe installed — all other units stay the same. GSM/EDGE and GSM TRXscan co-exist, or operators can create a configuration using all-EDGEcomponents.

The EDGE capability is available with Nokia MetroSite EDGE BaseTransceiver Station (BTS), Nokia UltraSite EDGE BTS and Nokia FlexiEDGE BTS solutions as an easy unit upgrade. Nokia UltraSite EDGE BTSalso provides site evolution to WCDMA since it houses both EDGE andWCDMA carriers. The Nokia UltraSite EDGE and Nokia Flexi EDGEsolutions offer the traditional benefits of high capacity and coverage alongwith full data support.

GSM/EDGE-capable TRXs for Nokia MetroSite EDGE BTS and NokiaUltraSite EDGE BTS are compatible with GSM TRXs and fit into the sameslot in the BTS cabinets. In addition to providing EDGE services, GSM/EDGE TRXs are fully GSM compatible and support GSM voice, data,HSCSD, and GPRS plus EGPRS. They are also backward compatiblewith all legacy GSM terminals. All Nokia Flexi EDGE TRXs are EDGE andGSM capable.

These solutions provide an unlimited EDGE growth path and fullfunctionality for micro and macrocellular networks. The rest of the networkrequires supporting software releases and capacity expansions for higherdata rates. EDGE terminals will be available in line with the networkinfrastructure. EDGE terminals continue to support all GSM and GPRSservices.

Nokia EDGE features and functions

Nokia EDGE key features and functions

. 8-PSK modulation downlink and uplink

The benefits of 8-PSK modulation include three times the number ofbits per second through existing BTS EDGE hardware and GSMradio spectrum and smaller power consumption per delivered bit.Also, fewer new TRXs and BTS cabinets are required.

For more information, see 8 Phase Shift Keying.

. Nokia GSM/EDGE Radio Resource Management

With radio resource allocation using the Territory Method, theoperator can define the amount of GPRS/EDGE radio resourcesflexibly. The EDGE radio resources can also be extended to circuitswitched timeslots at times when there is no traffic.



For more information, see Optimised GPRS Radio ResourceManagement.

. Nokia Dynamic Abis

Dynamic Abis is a non-blocking and real time transmission solutionfor optimising EDGE and GPRS capacity in Abis.

For more information, see Dynamic Abis.

. Nokia BSS Radio Link Adaptation

Nokia Link Adaptation ensures that maximum throughput andminimum delay (RTT) is achieved in changing radio conditions byselecting the optimum Modulation and Coding Scheme (MCS).

For more information, see Link Adaptation for EGPRS.

. Nokia Incremental Redundancy downlink and uplink

Nokia Incremental Redundancy works in co-operation with NokiaLink Adaptation to improve throughput by automatically adapting thetotal amount of transmitted redundancy to the changing radiochannel conditions.

For more information, see Incremental Redundancy.

. Gb Flow Control

Gb Flow Control maximises the downlink data transmission fromSGSN to BSS. Gb Flow Control ensures that the BSS downlink databuffer is not overflown or run empty during data downlinktransmission. Gb Flow Control is 3GPP standardised and appliedonly to the downlink direction.

For more information, see BSC-SGSN Interface Specification BSSGPRS Protocol (BSSGP).

. Nokia EDGE BTS downlink radio re-transmissions

A transmitted radio block is stored in BTS memory. In re-transmissions, the stored block is re-transmitted and only a 16 kbit/sconnection is needed at Abis. For example, if MCS-9 radio block isre-transmitted, a 16 kbit/s Abis channel is enough compared to 5*16kbit/s required at the initial transmission. With EDGE BTS downlinkradio re-transmissions, the required re-transmission capacity in Abisis reduced by 80%.

. Proactive downlink re-transmissions

DN03299216Issue 9-0 en20/03/2008


EDGE

When the PCU has sent a downlink radio block to the MS, it puts itinto a ‘pending acknowledgement’ state until it receivesacknowledgement from the MS. When the PCU doesn’t have anynew radio blocks to send it will start to re-transmit the blocks whichare in the ‘pending acknowledgement’ state. This will improve therobustness of the sent data and allow faster radio block decoding inthe MS.

The benefits of Proactive downlink re-transmission includeimproving data transfer latency and robustness as well as theresponsiveness and quality for real time data services, such as VoIP,PoC and video services.

. Delayed uplink TBF release

An uplink TBF is not released immediately when the transmitteduplink data ends. If the PCU receives downlink data during the uplinkTBF release delay period, the downlink TBF can be established onan associated signalling channel instead of a common signallingchannel. The use of an associated signalling channel reduces thedownlink TBF establishment time significantly.

The benefits of Delayed uplink TBF release include smaller end-to-end latency (RTT) as well as improved responsiveness and qualityfor real time data services, such as VoIP, PoC and video services.

. EDGE counters and KPIs

EDGE counters and KPIs enable network level optimisation for bestend-user data service experience over EDGE. The KPIrecommendations are actively improved and updates are publishedaccordingly.

For more information, see System impact of Nokia EDGE and EDGEkey performance indicators (KPIs).

Nokia EDGE recommended supporting features and functions

. Delayed downlink TBF

When the BSS has sent all the downlink data from its buffer, it delaysthe release of the downlink TBF. During the release delay, if there isno existing uplink TBF for the MS, the BSS sends dummy blocks tothe MS. This is done in order to allow the MS to request an uplinkTBF. Also, if the BSS receives more downlink data during therelease delay, the PCU cancels the delayed release and begins tosend new downlink data blocks using the same TBF. With Delayeddownlink TBF, idle packet data latency is shortened and more userscan be served at the same time.



. Priority Class Based Quality of Service

With Priority Class based Quality of Service, end-user service qualitymay be differentiated. This allows flexible service categories andpricing.

For more information, see Priority Class Based Quality of Service.

. Uplink Power Control

Uplink Power Control decreases the uplink interference level in thenetwork and enables higher end-user uplink throughput.

For more information, see Power Control.

. Extended Uplink TBF

Extended Uplink TBF increases the application level (e.g. HTTP,WAP, FTP) performance remarkably by reducing system Round TripTime (RTT) and TCP slow start impact.

For more information, see Extended Uplink TBF Mode.

. One phase access for EDGE

One phase access for EDGE gives EDGE mobile stations fasteraccess to the network resources.

. GPRS Resume

When a GPRS attached MS receives a CS call, the GPRS Resumewill suspend data transfer. When the CS call is completed, GPRSservice is resumed with no need for a Routing Area update. GPRSResume decreases the number of Routing Area updates and thusdecreases the capacity used for signalling data.

. USF Granularity 4 (PCU2)

USF Granularity 4 with PCU2 enables higher use of 8-PSK indownlink, as well as during GPRS timeslot sharing in uplink. Itoptimises the multiplexed scheduling of GPRS and EDGE users andat its best, 2,8 folds the EDGE users’ throughput.

Related topics in GPRS/EDGE System Feature Description

. EGPRS Modulation and Coding Schemes

. EGPRS Packet Channel Request on CCCH

. Incremental Redundancy

. Link Adaptation for EGPRS

. Nokia Smart Radio Concept for EDGE

DN03299216Issue 9-0 en20/03/2008


EDGE

. 8 Phase Shift Keying

. System impact of Nokia EDGE

. System impact of EGPRS Packet Channel Request on CCCH

. System impact of Nokia Smart Radio Concept for EDGE

. Requirements for GPRS/EDGE in BSC

. Radio network management for GPRS in BSC



. GPRS/EDGE radio connection control

. Implementing EGPRS

. Configuring Intelligent Downlink Diversity

Other related topics

. Feature Descriptions. Data


. Dynamic Abis

. Extended Cell for GPRS/EDGE


. Gb over IP



. Multipoint Gb Interface



. Packet Control Unit (PCU2) Pooling

. Dimension. BTS EDGE Dimensioning. Abis EDGE Dimensioning. BSC EDGE Dimensioning. Gb EDGE Dimensioning

. Test and Activate. Data

. Activating and testing BSS10083: EGPRS

. Activating and testing BSS9006: GPRS



. Reference. Commands

. MML Commands. EA - Adjacent Cell Handling. EE - Base Station Controller Parameter Handling

in BSC. EG - GSM Timer and BSC Parameter Handling. EQ - Base Transceiver Station Handling in BSC. ER - Transceiver Handling. ES - Abis Interface Configuration. EU - Power Control Parameter Handling. FX - Gb Interface Handling

. Service terminal commands. PCU2 Service Terminal Commands

. Counters/Performance Indicators. Circuit-switched measurements

. 106 CS DTM Measurement. Packet-switched measurements. Observations

. 25 TBF Observation for GPRS Trace

. 27 GPRS Cell Re-selection Report

. 28 GPRS RX Level and Quality Report

. Parameters. BSS Radio Network Parameter Dictionary. PAFILE

. PAFILE timer and parameter lists. PRFILE and FIFILE

. PRFILE and FIFILE parameters

DN03299216Issue 9-0 en20/03/2008


EDGE

4 Software related to GPRS/EDGE

4.1 Extended Uplink TBF Mode

With Extended Uplink TBF Mode the uplink TBF may be maintained duringtemporary inactive periods, where the mobile station has no data to send.Without Extended Uplink TBF Mode a new uplink TBF has to beestablished after every inactive period.

When both the MS and the network support Extended Uplink TBF Mode,the release of the uplink TBF can be delayed even if the MS occasionallyhas nothing to transmit. Right after the MS has new data to send, the sameuplink TBF can be used and data transmission can be reactivated.

Extended Uplink TBF Mode requires 3GPP Rel. 4 GERAN featurepackage 1 mobile stations.

Benefits of the Nokia solution

. With Extended UL TBF Mode the UL TBF release can be delayed inorder to make it possible to establish the following downlink TBFusing Packet Associated Control Channel (PACCH). Using PACCHenables faster TBF establishment compared to using CCCH.

. Extended UL TBF Mode allows the mobile station to continue thedata transfer if it gets more data to send when the countdownprocedure has begun. Without Extended UL TBF Mode, the releaseof the current TBF is required and a new one is established, causingmore delay and signalling load.

DN03299216Issue 9-0 en20/03/2008


Software related to GPRS/EDGE

. Extended UL TBF Mode is effective in preventing the breaks in datatransfer. Occasional short breaks in data transmission do not delaythe activation of a new Uplink TBF, which increases the perceivedservice quality by the end user, for example, in speech delivery inPoC.

. Extended UL TBF Mode saves capacity, because it decreases thenumber of random access procedures during and after an activestream, when a TBF is needed for the other direction.

Related topics

. Activating and Testing BSS11151: Extended Uplink TBF Mode

4.2 GPRS Coding Schemes

GPRS provides four coding schemes, from CS-1 to CS-4, offering datarates from 9.05 to 21.4 kbit/s per channel. By using PCU1 and 16 kbit/sAbis links, it is possible to support CS-1 and CS-2.

Figure 12. GPRS Coding Schemes

Coding scheme CS-1 is always used in unacknowledged RLC mode,except with PCU2 where it is also possible to use other coding schemes inunacknowledged RLC mode.

In acknowledged mode, RLC data blocks are acknowledged, and both CS-1 and CS-2 are supported. Each TBF can use either a fixed codingscheme (CS-1 or CS-2), or Link Adaptation (LA). The link adaptationalgorithm is based on the RLC BLER (Block Error Rate). RetransmittedRLC data blocks must be sent with the same coding as was used initially.



Coding Schemes CS-3 and CS-4

Before the introduction of Dynamic Abis, only CS-1 and CS-2 GPRScoding schemes were supported because of Abis frame restrictions.Dynamic Abis makes it possible to use CS-3 and CS-4.

CS1 and CS2 offer data rates of 8.0 and 12.0 kbps per timeslot. With therates of 14.4 and 20.0 kbps, CS-3 and CS-4 provide a considerable gain indata rates for GPRS mobile stations not supporting EGPRS (themandatory RLC header octets are excluded from the data rate values).

CS-3 and CS-4 can boost GPRS throughput bit rates by a maximum of60% compared to CS-1 & CS-2. With average real network conditions(average C/I value distribution) a throughput increase of 0-30% can beachieved depending on the network’s C/I values.

Coding Schemes CS-3 and CS-4 can be used in both GPRS and EGPRSterritories. For hardware requirements, see section Requirements.

Requirements

The hardware and software requirements of Coding Schemes CS-3 andCS-4 are specified in the tables below.

Coding Schemes CS-3 and CS-4 are an application software product andrequire a valid licence in the BSC. All GPRS-capable mobile stationssupport CS-3 and CS-4.

Table 1. Required additional or alternative hardware or firmware

Network element Hardware/firmwarerequired

BSC PCU2

BTS The BaseBandhardware of the BTSmust support DynamicAbis. EDGE capableTRXs are required.

TCSM No requirements

SGSN No requirements

DN03299216Issue 9-0 en20/03/2008



Table 2. Required software by network elements

Network element Software releaserequired

BSC S13

Nokia Flexi EDGEBTSs

EP2

Nokia UltraSiteEDGE BTSs

CX6.0

Nokia MetroSiteEDGE BTSs

CXM6.0

Nokia Talk-familyBTSs

Not supported

Nokia InSite BTSs Not supported

MSC/HLR Not applicable

SGSN Not applicable

Nokia NetAct OSS4.2 CD Set 1

User interface

BTS MMI

Coding Schemes CS-3 and CS-4 cannot be managed with BTS MMI.

BSC MMI

The following MML commands are used to handle Coding Schemes CS-3and CS-4:

. Base Transceiver Station Handling in BSC: EQV, EQO

BSC radio network object parameters

The following parameters are introduced due to Coding Schemes CS-3and CS-4:

. coding schemes CS3 and CS4 enabled (CS34)

. DL coding scheme in acknowledged mode (DCSA)

. UL coding scheme in acknowledged mode (UCSA)

. DL coding scheme in unacknowledged mode (DCSU)



. UL coding scheme in unacknowledged mode (UCSU)

. adaptive LA algorithm (ALA)

Due to a new Link Adaptation algorithm the following existing parametersare no longer relevant when CS-3 and CS-4 is used:

. coding scheme no hop (COD)

. coding scheme hop (CODH)

For more information on radio network parameters, see BSS RadioNetwork Parameter Dictionary.

PRFILE parameters

The values of the following MS-specific flow control parameters must beincreased due to CS-3 and CS-4:

. FC_MS_B_MAX_DEF

. FC_MS_R_DEF

. FC_R_TSL.

For more information on PRFILE parameters, see PRFILE and FIFILEParameter List.

Alarms

The following new alarm is introduced due to Coding Schemes CS-3 andCS-4:

. 3273 GPRS/EDGE TERRITORY FAILURE

For more information, see Diagnosis Reports (3700-3999).

Measurements and counters

Two new object values are added to the 79 Coding Scheme Measurementdue to Coding Schemes CS-3 and CS-4. No new counters are needed.

Interworking with other features

CS-3 and CS-4 do not fit into one 16kbit/s Abis/PCU channel and requirethe use of Dynamic Abis and EDGE TRXs.

DN03299216Issue 9-0 en20/03/2008



Related topics

. Activating and testing BSS11088: Coding Schemes CS-3 and CS-4

. 79 Coding Scheme Measurement

4.3 Link Adaptation for GPRS

From BSS11.5 onwards, there are two GPRS Link Adaptation algorithms,the use of which depends on the PCU type (PCU1 or PCU2).

Although the Coding Schemes CS-3 and CS-4 are licence-based, the LAalgorithm is provided with PCU2.

Link Adaptation algorithm for PCU1

The GPRS Link Adaptation (LA) algorithm selects the optimum channelcoding scheme (CS-1 or CS-2) for a particular RLC connection and isbased on detecting the occurred RLC block errors and calculating theblock error rate (BLER).

The BSC level parameters coding scheme no hop (COD) and coding

scheme hop (CODH) define whether a fixed CS value (CS-1 or CS-2) isused or if the coding scheme changes dynamically according to the LAalgorithm. When the LA algorithm is deployed, the initial CS value at thebeginning of a TBF is CS-2.

Regardless of the parameter values, CS-1 is always used inunacknowledged RLC mode.

Link Adaptation algorithm for PCU2

A new Link Adaptation algorithm is introduced with PCU2, which replacesthe previous GPRS LA algorithm and covers the following codingschemes:

. CS-1 and CS-2 if CS-3 and CS-4 support is disabled in the territoryin question

. CS-1, CS-2, CS-3, and CS-4 if CS-3 and CS-4 support is enabled inthe territory in question

The following BTS-level parameters define, whether a fixed CS value (CS-1 - CS4) is used or if the coding scheme changes dynamically according tothe LA algorithm. The parameters can also be used to define the initial CSvalue at the beginning of a TBF:



. DL coding scheme in acknowledged mode (DCSA)

. UL coding scheme in acknowledged mode (UCSA)

. DL coding scheme in unacknowledged mode (DCSU)

. UL coding scheme in unacknowledged mode (UCSU)

. adaptive LA algorithm (ALA)


The LA algorithm measures the signal quality for each TBF in terms of thereceived signal quality (RXQUAL). RXQUAL is measured for eachreceived RLC block, which makes it a more accurate estimate than BLER.

The PCU determines the average BLER value separately for each BTS bycontinuously collecting statistics from all the connections in the territory inquestion. Based on the estimates, the LA algorithm determines whichcoding scheme will give the best performance.

The new LA algorithm can be used in both RLC acknowledged andunacknowledged modes in both uplink and downlink direction.

4.4 Priority Class Based Quality of Service (QoS)

With Priority Based Scheduling, an operator can give users differentpriorities. Higher priority users will get better service than lower priorityusers. There will be no extra blocking to any user, only the experiencedservice quality changes.

The concept of ‘Priority Class’ is based on a combination of the GPRSDelay class and GPRS Precedence class values. Packets will be evenlyscattered within the (E)GPRS territory between different time slots. Afterthat packets with a higher priority are sent before packets that have alower priority.

Mobile-specific flow control is part of the QoS solution in the PCU. It workstogether with the SGSN to provide a steady data flow to the mobile fromthe network. It is also an effective countermeasure against buffer overflowsin the PCU. Mobile-specific flow control is performed for every MS that hasa downlink TBF. There is no uplink flow control.

The PCU receives the QoS (Precedence class) information to be used inDL TBFs from the SGSN in a DL unitdata PDU.

DN03299216Issue 9-0 en20/03/2008



In case of UL TBF, the MS informs its radio priority in a PACKETCHANNEL REQUEST (PCR) or a PACKET RESOURCE REQUEST(PRR), and this is used for UL QoS. Exceptions to this rule are one phaseaccess and single block requests; in these cases the PCU always usesBest Effort priority.

Priority Class Based Quality of service is an operating software in the BSCand is always active in an active PCU. The subscriber priority must bedefined in the HLR once Priority Class Based QoS is taken into use.

Priority based scheduling algorithm

The description below covers the PCU1 implementation; PCU2implementation emulates this operation closely.

The priority based scheduling algorithm hands out radio resourcesaccording to the latest service time and scheduling step size of the TBFs.Each TBF allocated to a timeslot has a timeslot-specific latest service time,before which the TBF should get a chance to use the radio resource. Ineach scheduling round, the TBF with the lowest service time is selected.After the TBF has sent a radio block, its latest service time is incrementedby a predefined scheduling step size. The higher the scheduling step size,the less often the TBF is selected and given a transmission turn.

In BSS9 (Nokia GPRS Release 1) the scheduling steps of all TBFs are setto the same constant value. In the BSS10.5 release the step sizes dependon the priority class of the TBF: each priority class has its own schedulingstep size that can be adjusted by the operator. There are 4 QoS classes foruplink and 3 QoS classes for downlink. Each service class is given a fairamount of radio time. The best effort customers are an exception to therule and are only given a small share of the radio interface.

The allocation process is designed to ensure that better priority TBFs arenot gathered into the same radio timeslot. TBFs in the same time slot thathave the same QoS get an equal share of air time. However, equal air timedoes not provide equal data rates for the TBFs in the same time slot, it onlyguarantees that inside a QoS group the air time is divided equally and thata higher QoS class gets more air time.



Figure 13. Example of transmission turns

4.5 System Level Trace

System Level Trace is an operating software, which extends the currentGSM tracing to the GPRS service. GSM tracing is available in the networkelements of the GSM network to trace circuit switched calls.

System Level Trace enables customer administration and networkmanagement to trace activities of various entities (IMSIs and IMEIs), whichresult in events occurring in the PLMN. The trace facility is a usefulmaintenance aid and development tool, which can be used during systemtesting. In particular, it may be used in conjunction with test-MSs toascertain the digital cell 'footprint', the network integrity, and also thenetwork quality of service as perceived by the PLMN. The networkmanagement can use the facility, for example, in connection with acustomer complaint, a suspected equipment malfunction or if authoritiesrequest for a subscriber trace for example in an emergency situation.

The ETSI specifies the tracing facility for GSM, where it refers both tosubscriber tracing (activated using IMSI) and equipment tracing (activatedusing IMEI). The subscriber tracing can be defined for a certain subscriberin the HLR or in a specific SGSN. Equipment tracing can be defined in theSGSN.

DN03299216Issue 9-0 en20/03/2008



Figure 14. Trace activation/deactivation and report generation

The trace is already implemented in the GSM network, but introduction ofGPRS-service adds new network elements to the GSM network (GGSN,SGSN) and changes old principles. Therefore, new tracing facilities areneeded.

In order to get full advantage of System Level Trace, it must beimplemented in all main network elements of the GPRS network: theSGSN, GGSN, BSC, MSC/HLR, and OSS. The figure GPRS network andrelated network elements presents the overall picture of GPRS trace andshows all the network elements that can send trace reports to NetAct.GPRS trace is activated by OSS. The HLR, SGSN, GGSN, and BSS sendtrace records to OSS when an invoking event occurs.



Figure 15. Architecture of the GPRS network and related network elements

Trace from an operator's viewpoint

In the SGSN trace, three different scenarios can be identified from anoperator's point of view:

. HPLMN operator traces its own IMSI within the HPLMN

When an operator wishes to trace a GPRS subscriber in its own(home) network, the trace is first activated in the HLR. If a subscriberis not roaming outside the HPLMN and he/she is represented as aregister in the HLR, the HLR activates the trace in a specified SGSN.Otherwise, the HLR waits until the subscriber becomes active inHPLMN before it activates a trace in the SGSN.

. HPLMN operator tracing a foreign roaming subscriber (IMSI) withinits own HPLMN

When an operator wants to trace a foreign subscriber, the trace isactivated directly via MMI commands to all SGSNs in an operator'snetwork. The trace of a subscriber is in a state of active pending untilan invoking event occurs. The amount of active trace cases can belimited.

. HPLMN operator tracing equipment (IMEI).

DN03299216Issue 9-0 en20/03/2008



When an operator wants to trace equipment, the trace is activateddirectly via MMI commands to all SGSNs in operator's network. Thetrace of equipment is in a state of active pending until an invokingevent occurs. The amount of active trace cases can be limited.

The tracing of roaming IMSIs and the exchange of data is subject tobilateral agreements, and the request to trace a particular IMSI comesthrough administrative channels. The HPLMN operator can use the HLRparameters to define whether the trace settings are sent to the VPLMN.

System Level Trace in BSC

The SGSN invokes the trace by sending a BSSGP SGSN-INVOKE-TRACE (3GPP TS 48.018) message to the BSS when SGSN tracebecomes active or when SGSN receives a trace request. When the BSCreceives this message it starts tracing. The BSS does not send anacknowledgement of the BSSGP message to the SGSN. In case of ahandover between BSCs, the tracing is deactivated in the source BSCside and activated in the target BSC side by an SGSN-INVOKE-TRACEmessage from SGSN.

The System Level Trace for GPRS in the BSC is implemented as threedifferent observation types:

. TBF Observation for GPRS Trace

. GPRS Cell Re-Selection Report

. GPRS RX Level and Quality Report

These observations cannot, however, be started or stopped by MMLcommands or from the NMS. The trace as a whole is handled only by theSGSN-INVOKE-TRACE messages from the SGSN. If you attempt to startthese observations (without trace) from NetAct, the BSC replies with anerror status.

The BSC sends the generated trace reports to Nokia NetAct. Trace reportsare also stored in observation files on the BSC's disk.

TBF Observation for GPRS Trace

A TBF report is created when a subscriber performs actions causing anallocation of TBF in BSS during tracing. There is one report per eachallocated TBF, so simultaneous TBF allocations produce multiple reports.TBF release completes the report, which is then ready for post-processing.



During TBF allocation, TBF Observation for GPRS Trace records resourceconsumption by the user and call quality related transactions. In addition toTBF allocation and release, recorded events include TBF reallocations,MCS changes and MS Flow Control changes.

For further information, see 25 TBF Observation for GPRS Trace.

GPRS Cell Re-selection Report

GPRS Cell Re-selection is a trace report for GPRS trace. It containsinformation about NCCR triggering, NACC usage and possible failures.

The report is closed and sent further to NetAct when flush is received fromthe SGSN, the MS returns to source cell by Packet Cell Change failure, orNCCR context is released in the PCU.

For further information, see 27 GPRS Cell Re-selection Report.

GPRS RX Level and Quality Report

GPRS RX Level and Quality Report is a report type needed to periodicallyrecord serving and neighbour cell measurements and quality data. Thereport contains the following information:

. downlink RX level of serving cell and neighbour cells from packet(enhanced) measurement report

. downlink RX quality class or BEP values from (EGPRS) PACKETDOWNLINK ACKNOWLEDGEMENT message

. uplink RX level and quality from BTS measurements.

For further information, see 28 GPRS RX Level and Quality Report.

DN03299216Issue 9-0 en20/03/2008



5 Software related to EGPRS

5.1 EGPRS Modulation and Coding Schemes

EGPRS supports higher data rates compared to basic GPRS, usingseveral Modulation and Coding Schemes (MCSs) varying from 8.8 kbit/s to59.2 kbit/s in the radio interface.

Altogether nine MCSs are designed for EGPRS. When an RLC data blockis sent, the information is encoded using one of the MCSs to resist channeldegradation and modulated before transmission over the radio interface.

Since the resources are limited, the higher the level of protection forinformation, the less information is sent. The protection that best fits thechannel condition is chosen for a maximum throughput. The GMSKmodulation provides the robust mode for wide area coverage while 8PSKprovides higher data rates.

Table 3. Peak data rates for EGPRS Modulation and Coding Schemes

MCS Modulation Code Rate Family User Rate

MCS-1 GMSK .53 C 8.8 kbit/s

MCS-2 .66 B 11.2 kbit/s

MCS-3 .80 A 14.8 kbit/s

MCS-4 1 C 17.6 kbit/s

MCS-5 8PSK .37 B 22.4 kbit/s

MCS-6 .49 A 29.6 kbit/s

MCS-7 .76 B 44.8 kbit/s

MCS-8 .92 A 54.4 kbit/s

MCS-9 1 A 59.2 kbit/s

DN03299216Issue 9-0 en20/03/2008


Software related to EGPRS

In EGPRS, it is possible to switch between any of the MCSs, from one datablock to another, as in GPRS. In EGPRS, however, it is possible also tochange the retransmission MCS whereas with GPRS, the retransmissiontakes place with exactly the same level of protection as the initialtransmission. This is useful since the level of protection needed in aretransmission may differ due to varying channel conditions and theexisting protection from earlier Incremental Redundancy (IR)transmissions.

MCSs are organised in families to allow re-segmentation of data blocks incase of retransmissions, using Link Adaptation (LA). The retransmissioncan be accomplished with lower coding schemes, that is, if thetransmission failed with the original, higher coding scheme, the same datacan be retransmitted with a lower codec within the same family.

Note that GPRS is not a subset of EGPRS. The GPRS coding schemes,CS-1 to CS-4, are different than the EGPRS GMSK coding schemes,MCS-1 to MCS-4.

Related topics

. EDGE

. GPRS Coding Schemes

5.2 EGPRS Packet Channel Request on CCCH

When the MS wants to send data or upper layer signalling messages tothe network, it requires the establishment of an uplink TBF from the BSC.

With EGPRS terminals, this has typically been done as two phase accesson CCCH where the MS first requests an RLC block from the BSC andafter it has been assigned, the MS provides information about its EGPRScapabilities. Based on that information, a Packet Data Channel, ifavailable, is assigned for the TBF and the MS is instructed with attributesto be used in uplink transmission by BSC.

By using EGPRS Packet Channel Request on CCCH the uplink TBFestablishment can be speeded up substantially since one phase access isalso available for an EGPRS MS. The MS provides information about itsEGPRS capabilities already while requesting TBF establishment from theBSC. Based on this information the BSC can assign a Packet DataChannel for the TBF right away, if one is available.



Benefits of the Nokia solution

Fast uplink TBF establisment for EGPRS terminals on CCCH.

5.3 Incremental Redundancy

Incremental Redundancy (IR) is an efficient combination of twotechniques:

. Automatic Repeat reQuest (ARQ)

. Forward Error Correction (FEC).

The ARQ method means that if the receiver detects the presence of errorsin a received RLC block, it requests and receives a re-transmission of thesame RLC block from the transmitter. The process continues until anuncorrupted copy reaches the destination.

The FEC method adds redundant information to the re-transmittedinformation at the transmitter, and the receiver uses the information tocorrect errors caused by disturbances in the radio channel.

IR needs no information about link quality in order to protect thetransmitted data. Thus, the benefits of IR include increased throughputdue to automatic adaptation to varying channel conditions, and reducedsensitivity to link quality measurements.

Incremental Redundancy scheme

In the IR scheme (also known as Type II Hybrid ARQ scheme) isimplemented using the nine EGPRS MCSs. Only a small amount ofredundancy is sent first, which yields a high user throughput if thedecoding is successful. However, if the decoding fails, a re-transmissiontakes place according to the ARQ method and the transmitter transmits adifferent set of FEC information from the same RLC block. These sets arecalled protection schemes. There can be either two (P1 and P2) or three(P1, P2 and P3) protection schemes in each of the nine MCSs.

A data block is first protected with the P1 of a certain MCS. If the decodingfails, the received P1 is stored in the receiver's memory for future use anddata block is re-transmitted using the P2 of the same MCS. If after P3 thedata still cannot be recovered, P1 is sent again and combined with thestored P1, P2, and P3 schemes (reaching a protection level of about fourtimes P1), and so on, until the data is recovered.

DN03299216Issue 9-0 en20/03/2008



The IR scheme is illustrated in the figure Incremental Redundancyscheme. Since the combination includes more information than anyindividual transmission, the probability of correct reception is increased. IRco-operates with Link Adaptation (LA) that selects the amount ofredundant information transmitted in each transmission.

Figure 16. Incremental Redundancy scheme

5.4 Link Adaptation for EGPRS

The purpose of the Link Adaptation (LA) mechanism is to provide thehighest throughput and lowest delay available by adapting the protectionlevel of the transmitted information according to link quality. LA usesvarious measurements of the past link to predict the upcoming channelquality.

Data Block

One MCSP2 P3P1

P2

P2

P2

P1

P1

P1

P1

Stored

Stored

Receiver

Transmitter

No data

recovered

No data

recoveredCombination: Protection Level x 2

Protection Level 1

Combination: Protection Level x 3

Stored

P3

P3

1st transmission 1st re-transmissionupon reception failure

2nd re-transmissionupon reception failure



The link adaptation algorithm works in cooperation with IncrementalRedundancy (IR). While IR improves throughput by adapting the totalamount of transmitted redundancy automatically to the radio channelconditions, LA selects the amount of redundancy individually for eachtransmission. This helps to reduce the number of retransmissions, andthus keeps the transfer delay reasonably low.

Normally, LA adapts to path attenuation and slow fading but not fastfading. This corresponds to the "ideal LA" curves in link level simulations.

Link Adaptation can be enabled and disabled with the parameter EGPRSlink adaptation enabled (ELA). Other LA-related parameters include:

. initial MCS for acknowledged mode (MCA)

. initial MCS for unacknowledged mode (MCU)

. maximum BLER in acknowledged mode (BLA)

. maximum BLER in unacknowledged mode (BLU)

. mean BEP offset 8PSK (MBP)

. mean BEP offset GMSK (MBG)

. enable answer to paging call on FACCH (EPF)


Link quality measurements

Enabling Link Adaptation requires accurate link quality measurements anda set of modulation and coding schemes (MCSs) with different degrees ofprotection.

The efficient EGPRS measurements provide accurate predictions of theupcoming link quality in several propagation channels that have variousspeeds (for example, typical urban and rural areas and hilly terrain). Thelink adaptation algorithm is based on Bit Error Probability (BEP)measurements performed at the MS (downlink TBF) and the BTS (uplinkTBF). In acknowledged mode, the algorithm is designed to optimisechannel throughput in different radio conditions. In unacknowledged mode,the algorithm tries to keep below a specified Block Error Rate (BLER) limit.

For more information, see 28 GPRS RX Level and Quality Report.

DN03299216Issue 9-0 en20/03/2008



MCS selection

LA selects the optimal MCS for each radio condition. The LA procedure isbased on static MCS selection tables in the PCU. The MCS selection canbe divided into four classes:

1. initial MCS to be used when entering packet transfer mode

2. modulation selection

3. MCS selection for initial transmissions of each RLC block in ACKmode

4. MCS to be used for re-transmissions.

5.5 Nokia Smart Radio Concept for EDGE

The Nokia Smart Radio Concept (SRC) enhances the radio performanceof the BTS in both EDGE and GSMmodes and is an important software forgaining the maximum coverage for EDGE.

Nokia SRC consists of the following uplink and downlink performanceenhancement solutions:

. 4-way uplink diversity reception (4UD)

. Sensitivity-optimised High Gain Mast Head Amplifier (UltraSiteMHA)

. Interference Rejection Combining (IRC)

If the BSS12 licensed application software Space Time InterferenceRejection Combining (STIRC) is used, it replaces IRC.

. Intelligent Downlink Diversity Transmission (IDD)

The uplink (4UD, UltraSite MHA, IRC) and downlink (IDD) enhancementsolutions can also be used independently, except for 4UD, which is usedwith IDD.

The SRC concept, introduced in BSS10.5, is supported by the NokiaUltraSite BTS family. Nokia Flexi EDGE BTS supports Nokia SRC fromEP2.0 onwards.

Nokia SRC utilises auxiliary transceivers effectively for both UL and DL.



The figure Nokia Smart Radio Concept for EDGE, one carrier per cellshows one carrier/cell configuration of Nokia Smart Radio Concept forEDGE with IDD and by-pass combination configuration and MHAs.

Figure 17. Nokia Smart Radio Concept for EDGE, one carrier per cell

The figure Nokia Smart Radio Concept for EDGE, two carriers per cell withall SRC solutions shows an example of two carriers/cell configuration withIDD and 4-way Uplink Diversity in Nokia UltraSite EDGE BTS.

TRX RF units Receive Multicoupler Dual DuplexUnit

X-pol Antenna

TX

TX

RX

RX

main

main

div

div

Duplex

erDuplex

erDuplexer

LNA

LNAM2xA

RXRX1DRX1RX2DRX2 DRX

MHA MHA

DN03299216Issue 9-0 en20/03/2008



Figure 18. Nokia Smart Radio Concept for EDGE, two carriers per cell with allSRC solutions.

Interference Rejection Combining with 4-way Uplink Diversity andHigh Gain MHA

In Nokia SRC, the uplink performance (BTS reception) is enhanced withthe combination of Interference Rejection Combining (IRC) via 4-waydiversity reception of the BTS and sensitivity-optimised high-gain NokiaUltraSite Masthead Amplifiers (UltraSite MHA introduced already inBSS9). IRC can also be used together with 2-way diversity reception.

IRC is an operating software product which eliminates correlated noise(interference) received by both antennas. If there is no correlated noise,then IRC behaves like normal Maximum Ratio Combining (MRC). Thecombining gain depends on the dominant interference ratio and angularspread of interference.

TRX RF units Receive Multicouplers Dual DuplexUnits

Antennas

Duplex

erDuplex

erDuplex

erDuplex

erDuplex

erDuplex

er

LNA

LNA

LNA

LNA

M2xA

M2xA

RX

RX

RX1

RX1

DRX1

DRX1

RX2

RX2

DRX2

DRX2

DRX

DRX

MHA MHA MHA MHA

TX

TX

TX

TX

RX

RX

RX

RX

main

main

main

main

div

div

div

div



In 4-way diversity reception, post detection Maximum Ratio Combining isthen used for two IRC-combined signals. This method is ideal for a dual X-polarised antenna concept, providing up to 3dB gain. The gain of 4UDcomes from enhanced UL diversity performance as well as enhancedenergy collection surface of the antenna system, providing capacity andcoverage enhancements.

An example for two pairs of X-polarised antennas is presented in the figureTwo pairs of X-polarised antennas.

Figure 19. Two pairs of X-polarised antennas

The UltraSite High Gain MHA is especially designed to enhance theUltraSite BTS site performance by optimising a noise figure of the receiverchain including the antenna system and BTS receiver front end.

Space Time Interference Rejection Combining

Space Time Interference Rejection Combining (STIRC), introduced inBSS12, is an enhancement to Interference Rejection Combining (IRC).STIRC is an application software product, and requires a valid licence inthe BSC. When STIRC is activated, it replaces Interference RejectionCombining (IRC) in all TRXs in the sector.

IRC

IRC

MRC

Spacing: 0.5WL

DN03299216Issue 9-0 en20/03/2008



STIRC is an uplink receiver DSP software technology enhancement thatgives improved uplink interference rejection performance, both adjacentchannel and co-channel, to both traffic and signalling channels, whencompared to the current IRC technology. All antenna configurations aresupported. However, 4-way uplink diversity configurations provide the bestperformance.

For more information on STIRC, see Space Time Interference RejectionCombining.

Intelligent Downlink Diversity

Intelligent Downlink Diversity (IDD) transmission is a hybrid antennaconcept based on Delay Diversity. It increases the coverage area of cellsby enhancing downlink radio performance and antenna diversity gain ofthe BTS. The Delay diversity mode of operation is displayed in figureIntelligent Downlink Diversity (IDD) concept (Delay diversity).

For downlink IDD the required number of antennas is two, whereas a fullSRC downlink/uplink solution requires four antennas. Currently deployedmain and diversity antennas can be used.

Figure 20. Intelligent Downlink Diversity

BTSTX 1

TX 2

F-bus

Abis

TX1 main transmitter

TX2 auxiliary, delayed, transmitter

MS

filter

filter

TX 1

TX 2



Delay Diversity (DD)

The downlink DD improves the performance of a cellular system bytransmitting through two antennas. The cell coverage area is extended bysending the same radio time slots or bursts, with a slight delay,simultaneously through two transmitters and antennas, regardless of thelogical channel. One cell requires two antennas (or X-polarised antennas).To the BSC, the main and auxiliary TRXs appear as a single (logical) TRX,and the auxiliary TRX takes on all TRX configuration parameters andadministration state as set by the BSC for the main TRX.

Figure 21. Intelligent Downlink Diversity (IDD) concept (Delay diversity)

DD provides a good performance for all modulation schemes. Delay isoptimized in terms of a combination of the requested logical channel andused modulation. IDD boosts downlink performance by up to 5 dB (aminimum of 3 dB) in all radio time slots, compared to a single transmissionsystem. DD creates an artificial multi path propagation component, whichcan be resolved by all the legacy terminals, thus creating multi pathdiversity. The IDD method provides its best gain in low-correlated Rayleighchannels; therefore, phase hopping is used to change phasing betweenadjacent bursts, and, consequently, to decrease correlation between amain and auxiliary transmitter. Random or periodic phase hopping is used,according to modulation type and EGPRS coding rate used.

The figure Nokia EDGE downlink diversity solution, one carrier per cellshows an example of the IDD solution.

Delay &RandomPhase

Main TX

Delayed TX

MSReceivedSignal

BTS

DN03299216Issue 9-0 en20/03/2008



Figure 22. Nokia EDGE downlink diversity solution, one carrier per cell.

The typical configurations in one Nokia UltraSite EDGE BTS cabinet are:

. 1+1+1 with combiner by-pass.

. 2+2+2 with 4-way diversity.

. 6 TRXs per cell with Remote Tune Combiners for large coverageand high-capacity needs.

In each case, an additional TRX is needed for transmitting.

Related topics

. EDGE

. Double Power TRX for Flexi EDGE BTS

. Activating and Testing BSS20870: Double Power TRX for FlexiEDGE BTS

Basebandunits Downlink

signal

CombinedUplink signal

In IDD, the downlink signal is splitbetween transmitters of two TRXs.The delay is processed between thesignals and random phase hopping isadded.

MHA MHA

DVxx

EDGETRX

EDGETRX

RX + TX

RX DIV. + TX DIV.

MS



5.6 8 Phase Shift Keying

While GSM uses only Gaussian Minimum Shift Keying (GMSK), EDGEuses both 8 Phase Shift Keying (8-PSK) and GMSK. 8-PSK is a linear,higher-order modulation. Introducing 8-PSK in addition to GMSK allowsthe data transmission rates to be tripled. An 8-PSK signal carries three bitsper modulated symbol over the radio path, compared to a GMSK signal,which carries only one bit per symbol.

Table 4. 8-PSK and GMSK comparison

8-PSK GMSK

Modulation 8-PSK, 3 bit/sym GMSK, 1 bit/sym

Symbol rate 270.833 ksps 270.833 ksps

Payload/burst 346 bits 116 bits

Gross rate/time slot 69.6 kbit/s 23.2 kbit/s

Nokia uses standardized 3pi/8 offset rotation to reduce amplitudevariations with 8-PSK modulation, as shown in the figure 8-PSKmodulation scheme. The standard GSM carrier symbol rate (270.833ksps) is the same as with 8-PSK. The burst lengths are the same as theexisting GMSK Time Division Multiple Access (TDMA) structure, and thesame 200 kHz nominal frequency spacing between carriers is used.

Figure 23. 8-PSK modulation scheme

(0,1,0)

(0,1,1)

(1,1,1)

(1,1,0)

(1,0,0)

(1,0,1)

(0,0,1)

(0,0,0)

(d(3k),d(3k+1),d(3k+2))=

DN03299216Issue 9-0 en20/03/2008



6 System impact of GPRS/EDGE

6.1 System impact of GPRS

The system impact of BSS09006: GPRS is specified in the sections below.For an overview, see GPRS.

For implementation instructions, see Implementing GPRS overview.

GPRS is an application software product and requires a valid licence in theBSC.

6.1.1 Requirements

The following network elements and functions are required to implementGPRS:

. Serving GPRS Support Nodes (SGSN)

. Gateway GPRS Support Nodes (GGSN)

. GPRS backbone

. Point-to-multipoint Service Centre (PTM SC)

. Lawful Interception Gateway (LIG)

. Charging Gateway (CG)

. Gb interface between the BSC and SGSN

. Packet Control Unit (PCU)

. GPRS-specific mobility management, where the location of the MSis handled separately by the SGSN and by the MSC/VLR even ifsome cooperation exists

DN03299216Issue 9-0 en20/03/2008


System impact of GPRS/EDGE

. the network management must be capable of handling the GPRS-specific elements

. new security features for the GPRS backbone

. a new ciphering algorithm

. a new radio interface (Um) for packet data traffic

. new MAP and GPRS-specific signalling.

. Additionally, coding schemes CS-3 & CS-4 require EDGE-capableTRXs (EDGE hardware and attached to EDAP)

For the full use of GPRS all these need to be taken into consideration. Theradio interface and GPRS signalling are relevant to the functioning of theBSC.

Software requirements

Table 5. Required software


BSC S13


EP2.0


CX6.0


CXM6.0


No requirements


MSC/HLR M14

SGSN SG7


Frequency band support

The BSC supports GPRS on the following frequency bands:

. GSM 800

. PGSM 900



. EGSM 900

. GSM 1800

. GSM 1900

6.1.2 Restrictions

. If Baseband hopping is employed in a BTS, radio timeslot 0 of anyTRX in the BTS will not be used for GPRS.

. BTS testing cannot be executed on the packet control channel.

. Network operation mode III is not supported.

. In PCU1 Coding Scheme CS-1 is always used in unacknowledgedRLC mode. In acknowledged RLC mode, the Link Adaptationalgorithm uses both CS-1 and CS-2.

In PCU2, because of CS-3 & CS-4 implementation, there is a newLink Adaptation algorithm that uses all the Coding Schemes in bothunacknowledged and in acknowledged RLC mode.

. Paging reorganisation is not supported.

. The master and slave channels must be cross-connected in thesame way; the EDAP and the TRXs tied to it shall use a single PCMline. If they use different PCM lines, transmission delay between thelines may differ. This may cause a timing difference with the resultthat synchronisation between the master and slave channels is notsuccessful.

. GPRS territory can be defined to each BTS object separately. GPRSand EGPRS territories cannot both be defined to a BTS object at thesame time.

. TRXs inside a BTS object must have common capabilities. Anexception to this is that EDGE-capable and non-EDGE-capableTRXs can be configured to the same BTS object, if EGPRS or CS-3& CS-4 is enabled in the BTS.

In this case, GPRS must be disabled in the non-EDGE/non-CS–3 &CS–4-capable TRXs, and these TRXs cannot be attached to EDAP.An EDGE/CS–3 & CS–4-capable TRX has EDGE hardware and isadded to EDAP. A non-EDGE/non-CS–3 & CS–4-capable TRX hasno EDGE hardware or it is not added to EDAP.

DN03299216Issue 9-0 en20/03/2008



. To get BCCH recovery to work correctly, it is recommendedthat the operator takes the following conditions into account,when unlocked EDGE and non-EDGE-capable TRXs orunlocked CS–3 & CS–4 and non-CS–3 & CS–4-capable TRXsexist in the same EGPRS or CS-3 & CS-4 enabled BTS:. If a BCCH TRX is EDGE hardware-capable, added to

EDAP, and it has the GTRX parameter set to Y, then allunlocked TRXs, which are added to EDAP, are EDGEhardware-capable, and have GTRX set to Y, should bemarked Preferred BCCHs.

. If a BCCH TRX is non EDGE/non-CS–3 & CS–4-capable, and has the parameter GTRX set to N, then allnon-EDGE/non-CS–3 & CS–4-capable unlocked TRXs,which have GTRX set to N, should be marked PreferredBCCHs.

For information on restrictions when baseband hopping is used, seeEDGE BTSs and hopping in System impact of EDGE in EDGESystem Feature Description.

. The BSS does not restrict the use of 8PSK modulation on TSL7 ofthe BCCH TRX, using the highest output power. The maximumoutput power is 2dB lower than with GMSK. This is fully compliantwith 3GPP Rel 5.

. PCU1 does not support CS–3 & CS–4, Extended DynamicAllocation (EDA), High Multislot Classes (HMC) or Dual TransferMode (DTM).

. For restrictions related to Dynamic Abis, see Dynamic Abis.

6.1.3 Impact on transmission

No impact.

6.1.4 Impact on BSS performance

OMU signalling

No impact.

TRX signalling

No impact.



Impact on BSC units

Table 6. Impact of GPRS on BSC units

BSC unit Impact

OMU No impact

MCMU No impact

BCSU No impact

PCU The PCU controls the GPRS radio resources and acts asthe key unit in the following procedures:. GPRS radio resource allocation and management. GPRS radio connection establishment and management. data transfer. coding scheme selection. PCU statistics.

TCSM No impact

Impact on BTS units

No impact.

6.1.5 User interface

6.1.5.1 BSC MMI

The following command groups and MML commands are used to handleGPRS:

. Base Station Controller Parameter Handling in BSC: EE

. GSM Timer and BSC Parameter Handling: EG

. Base Transceiver Station Handling in BSC: EQ

. Transceiver Handling: ER

. Power Control Parameter Handling: EU

. Gb Interface Handling: FX

. Licence and Feature Handling: W7

. Parameter Handling: WO

DN03299216Issue 9-0 en20/03/2008



For more information on the command groups and commands, see MMLCommands under Reference/Commands in the PDF view.

6.1.5.2 BTS MMI

GPRS cannot be managed with BTS MMl.

6.1.5.3 BSC parameters

Base Transceiver Station parameters

. GPRS non BCCH layer rxlev upper limit (GPU)

. GPRS non BCCH layer rxlev lower limit (GPL)

. direct GPRS access BTS (DIRE)

. max GPRS capacity (CMAX)

. GPRS rxlev access min (GRXP)

. GPRS MS txpwr max CCH (GTXP1)

. GPRS MS txpwr max CCH 1x00 (GTXP2)

. priority class (PRC)

. HCS threshold (HCS)

. RA reselect hysteresis (RRH)

. routing area code (RAC)

. GPRS enabled (GENA)

. network service entity identifier (NSEI)

. default GPRS capacity (CDEF)

. dedicated GPRS capacity (CDED)

. prefer BCCH frequency GPRS (BFG)

. transport type (TRAT)


. BTS downlink throughput factor for CS1-CS4 (TFD) (PCU2)

. BTS uplink throughput factor for CS1-CS4 (TFU) (PCU2)

. quality control GPRS DL RLC ack throughput threshold(QGDRT)



. quality control GPRS UL RLC ack throughput threshold(QGURT)

. DL adaption probability threshold (DLA)

. UL adaption probability threshold (ULA)

. DL BLER crosspoint for CS selection no hop (DLB)

. UL BLER crosspoint for CS selection no hop (ULB)

. DL BLER crosspoint for CS selection hop (DLBH)

. UL BLER crosspoint for CS selection hop (ULBH)

. coding scheme no hop (COD) (PCU1)

. coding scheme hop (CODH) (PCU1)

. DL coding scheme in acknowledged mode (DCSA) (PCU2)

. UL coding scheme in acknowledged mode (UCSA) (PCU2)

. DL coding scheme in unacknowledged mode (DCSU) (PCU2)

. UL coding scheme in unacknowledged mode (UCSU) (PCU2)

. adaptive LA algorithm (ALA) (PCU2)

. EGPRS inactivity alarm weekdays (EAW)

. EGPRS inactivity alarm start time (EAS)

. EGPRS inactivity alarm end time (EAE)

Adjacent Cell parameters

. adjacent GPRS enabled (AGENA)

. HCS signal level threshold (HCS)

. GPRS temporary offset (GTEO)

. GPRS penalty time (GPET)

Gb Interface Handling parameters

. data link connection identifier (DLCI)

. committed information rate (CIR)

. network service virtual connection identifier (NSVCI)

. network service virtual connection name (NAME)


DN03299216Issue 9-0 en20/03/2008



. bearer channel identifier (BCI)

. bearer channel name (BCN)

Gb Interface Handling parameters (IP)

. network service virtual connection identifier (NSVCI)

. network service virtual connection name (NAME)


. BCSU logical index (BCSU)

. PCU logical index (PCU)

. local UDP port number (LPNBR)

. remote IP address (RIP)

. remote host name (RHOST)

. remote UDP port number (RPNBR)

. preconfigured SGSN IP endpoint (PRE)

. remote data weight (RDW)

. remote signalling weight (RSW)

. packet service entity identifier (PSEI)

Power Control Handling parameters

. binary representation ALPHA (ALPHA)

. binary representation TAU (GAMMA)

. idle mode signal strength filter period (IFP)

. transfer mode signal strength filter period (TFP)

TRX Handling parameters

. GPRS enabled TRX (GTRX)

. dynamic abis pool ID (DAP)

Base Station Controller parameters

. GPRS territory update guard time (GTUGT)

. maximum number of DL TBF (MNDL)



. maximum number of UL TBF (MNUL)

. CS TCH allocate RTSL0 (CTR)

. CS TCH allocation calculation (CTC)

. PFC unack BLER limit for SDU error ratio 1 (UBL1) (PCU2)

. PFC ack BLER limit for transfer delay 1 (ABL1) (PCU2)

. QC NCCR action trigger threshold (QCATN) (applicable if NCCRis activated)

. QC reallocation action trigger threshold (QCATR)

. free TSL for CS downgrade (CSD)

. free TSL for CS upgrade (CSU)

. EGPRS inactivity criteria (EGIC)

. events per hour for EGPRS inactivity alarm (IEPH)

. supervision period length for EGPRS inactivity alarm (SPL)

. mean BEP limit MS multislot pwr prof 0 with 2 UL TSL (BL02)








. RX quality limit MS multislot pwr prof 0 with 2 UL TSL (RL02)








DN03299216Issue 9-0 en20/03/2008




PAFILE parameters

These parameters have no Q3 interface and are stored in PAFILE, notBSDATA:

. DRX TIMER MAX

. MSC RELEASE

. SGSN RELEASE

For more information on PAFILE parameters, see PAFILE Timer andParameter List.

PRFILE parameters

The following parameters are related to Gb interface configuration andstate management, the PCU, and the MAC and RLC protocols (Abisinterface):

. TNS_BLOCK

. TSNS_PROV

. TNS_RESET

. TNS_TEST

. TNS_ALIVE

. SNS_ADD_RETRIES

. SNS_CONFIG_RETRIES

. SNS_CHANGEWEIGHTS_RETRIES

. SNS_DELETE_RETRIES

. SNS_SIZE_RETRIES

. NS_BLOCK_RETRIES

. NS_UNBLOCK_RETRIES

. NS_ALIVE_RETRIES

. NS_RESET_RETRIES

. TGB_BLOCK



. TGB_RESET

. TGB_SUSPEND

. BVC_BLOCK_RETRIES

. BVC_UNBLOCK_RETRIES

. BVC_RESET_RETRIES

. SUSPEND_RETRIES

. TGB_RESUME

. RESUME_RETRIES

. RAC_UPDATE_RETRIES

. TGB_RAC_UPDATE

. RAC_UPDATE_RETRIES

. FC_B_MAX_TSL

. FC_B_MAX_TSL_EGPRS

. FC_MS_B_MAX_DEF

. FC_MS_R_DEF

. FC_MS_R_MIN

. FC_R_DIF_TRG_LIMIT

. FC_R_TSL

. GPRS_DOWNLINK_PENALTY

. GPRS_DOWNLINK_THRESHOLD

. GPRS_UPLINK_PENALTY

. GPRS_UPLINK_THRESHOLD

. MEMORY_OUT_FLAG_SUM

. PRE_EMPTIVE_TRANSMISSIO

. TBF_LOAD_GUARD_THRSHLD

. TBF_SIGNAL_GRD_THRSHLD

. TERRIT_BALANCE_THRSHLD

. TERRIT_UPD_GTIME_GPRS

. UPLNK_RX_LEV_FRG_FACTOR

DN03299216Issue 9-0 en20/03/2008



. DL_TBF_RELEASE_DELAY

. UL_TBF_RELEASE_DELAY

. UL_TBF_REL_DELAY_EXT

. UL_TBF_SCHED_RATE_EXT (PCU1)

. POLLING_INTERVAL (PCU2, replaces UL_TBF_SCHED_RATE_EXT)

. CHA_CONC_UL_FAVOR_DIR

. CHA_CONC_DL_FAVOR_DIR

. GPRS_UL_MUX_DEC_FACTOR (PCU2)

. BACKGROUND_ARP_1

. BACKGROUND_ARP_2

. BACKGROUND_ARP_3

The following parameters are related to alarm 0125 PCU PROCESSORLOAD HIGH.

. PCU_LOAD_NOTIF_LIMIT

. SUSPEND_PCU_LOAD_NOTIF


6.1.5.4 Alarms

This section lists the main GPRS-related alarms. Keep in mind that severalother alarms may also be generated with the use of GPRS.

. 0125 PCU PROCESSOR LOAD HIGH

. 0136 PCU CONNECTIVITY EXCEEDED

. 2114 FR VIRTUAL CONNECTION FAILED

. 2115 FR USER LINK INTEGRITY VERIFICATION FAILED

. 2117 FR TRUNK FAILED

. 2188 FR ACCESS DATA UPDATING FAILED

. 2189 COMMUNICATION FAILURE BETWEEN FR TERMINAL ANDFRCMAN

. 3019 NETWORK SERVICE ENTITY UNAVAILABLE



. 3020 NETWORK SERVICE VIRTUAL CONNECTIONUNAVAILABLE

. 3021 NETWORK SERVICE VIRTUAL CONNECTION UNBLOCKPROCEDURE FAILED

. 3022 NETWORK SERVICE VIRTUAL CONNECTION BLOCKPROCEDURE FAILED

. 3023 NETWORK SERVICE VIRTUAL CONNECTION RESETPROCEDURE FAILED

. 3024 NETWORK SERVICE ENTITY CONFIGURATIONMISMATCH

. 3025 NETWORK SERVICE VIRTUAL CONNECTION TESTPROCEDURE FAILED

. 3026 NETWORK SERVICE VIRTUAL CONNECTION PROTOCOLERROR

. 3027 UPLINK CONGESTION ON THE NETWORK SERVICEVIRTUAL CONNECTION

. 3028 NETWORK SERVICE VIRTUAL CONNECTION IDENTIFIERUNKNOWN

. 3029 BSSGP VIRTUAL CONNECTION UNBLOCK PROCEDUREFAILED

. 3030 BSSGP VIRTUAL CONNECTION BLOCK PROCEDUREFAILED

. 3031 BSSGP VIRTUAL CONNECTION RESET PROCEDUREFAILED

. 3032 BSSGP VIRTUAL CONNECTION PROTOCOL ERROR

. 3033 UNKNOWN ROUTING AREA OR LOCATION AREA DURINGPAGING

. 3068 EGPRS DYNAMIC ABIS POOL FAILURE

. 3073 FAULTY PCUPCM TIMESLOTS IN PCU

. 3164 PCU PROCESSOR OVERLOAD ALARM

. 3209 SUB NETWORK SERVICE SIZE PROCEDURE FAILED

. 3210 SUB NETWORK SERVICE CONFIGURATION PROCEDUREFAILED

. 3211 LAST REMOTE IP DATA ENDPOINT DELETED

DN03299216Issue 9-0 en20/03/2008



. 3261 FAILURE IN UPDATING BSC SPECIFIC PARAMETERS TOPCU


. 3324 FAILURE IN UPDATING CONFIGURATION DATA TO PCU

. 7724 CONFLICT BETWEEN BSS RADIO NETWORK DATABASEAND CALL CONTROL

. 7725 TRAFFIC CHANNEL ACTIVATION FAILURE

. 7730 CONFIGURATION OF BCF FAILED

. 7738 BTS WITH NO TRANSACTIONS

. 7769 FAILURE IN UPDATING CELL SPECIFIC PARAMETERS TOPCU

. 7789 NO (E)GPRS TRANSACTIONS IN BTS

For more information on alarms, see Notices (0-999), Failure Printouts(2000-3999) and Base Station Alarms (7000-7999).

6.1.5.5 Measurements and counters

The following measurements are related to GPRS:

. 72 Packet Control Unit Measurement

. 73 RLC Blocks per TRX Measurement

. 74 Frame Relay Measurement

. 76 Dynamic Abis Measurement. For counters of 76 Dynamic Abis Measurement, see System

impact of Dynamic Abis.


. 90 Quality of Service Measurement

. 95 GPRS Cell Re-selection Measurement. For counters of 95 GPRS Cell Re-selection Measurement, see

System impact of Network Controlled Re-selection.

. 96 GPRS RX Level and Quality Measurement

. 98 Gb Over IP Measurement. For counters of 98 Gb over IP Measurement, see System

impact of Gb over IP.

. 105 PS DTM Measurement



. For counters of 105 PS DTM Measurement, see Systemimpact of Dual Transfer Mode.

. 106 CS DTM Measurement. For counters of 106 CS DTM Measurement, see System

impact of Dual Transfer Mode.

. 110 PCU Utilization Measurement

72 Packet Control Unit Measurement

Table 7. Counters of Packet Control Unit Measurement related to GPRS

Name Number

RLC DATA BLOCKS UL CS1 072062

RLC DATA BLOCKS DL CS1 072063

RLC DATA BLOCKS UL CS2 072064

RLC DATA BLOCKS DL CS2 072065

RETRA RLC DATA BLOCKS DL CS1 072068

RETRA RLC DATA BLOCKS DL CS2 072069

BAD FRAME IND UL CS1 072070

BAD FRAME IND UL CS2 072071

RETRA DATA BLOCKS UL CS1 072173

RETRA DATA BLOCKS UL CS2 072174

WEIGHTED DL TSL ALLOC GPRS NUMERATOR 072195

WEIGHTED DL TSL ALLOC GPRS DENOMINATOR 072196

RLC RETRANSMITTED DL CS1 DUE OTHER THAN NACK 072222

RLC RETRANSMITTED DL CS2 DUE OTHER THAN NACK 072223

DL CS1 DATA FOR DUMMY LLC 072224

IGNORED RLC DATA BLOCKS UL DUE TO BSN CS1 072225

IGNORED RLC DATA BLOCKS UL DUE TO BSN CS2 072226

1-PHASE UL GPRS TBF ESTABLISHMENT REQUESTS 072227

1-PHASE UL GPRS TBF SUCCESSFULESTABLISHMENTS

072229

For more information, see 72 Packet Control Unit Measurement.

DN03299216Issue 9-0 en20/03/2008



73 RLC Blocks per TRX Measurement

Table 8. Counters of RLC Blocks per TRX Measurement

Name Number

UR DL RLC MAC BLOCKS 073000

RETRANS DL RLC MAC BLOCKS 073001

SCHED UNUSED RADIO BLOCKS 073002

DL RLC MAC BLOCKS 073003

For more information, see 73 RLC Blocks per TRX Measurement.

74 Frame Relay Measurement

Table 9. Counters of Frame Relay Measurement

Name Number

FRMS WRONG CHECK SEQ ERR 074000

FRMS WRONG DLCI 074001

OTHER FRAME ERROR 074002

T391 TIMEOUT 074003

STAT MSG WRONG SEND SEQ NBR 074004

STAT MSG WRONG REC SEQ NBR 074005

BEAR CHANGED UNOPER 074006

BEAR RET OPER 074007

STAT MSG UNKNOWN PVC 074008

STAT MSG SENT TOO OFTEN 074009

TIME BEAR UNOPERATIONAL 074010

DLCI 1 ID 074011

DLCI 1 SENT FRMS 074012

DLCI 1 KBYTES SENT 074013

DLCI 1 REC FRMS 074014

DLCI 1 KBYTES REC FRMS 074015

DLCI 1 DISC SENT FRMS 074016

DLCI 1 BYTES DISC SENT FRMS 074017

DLCI 1 DISC REC FRMS 074018



Table 9. Counters of Frame Relay Measurement (cont.)

Name Number

DLCI 1 BYTES DISC REC FRMS 074019

DLCI 1 STAT ACT TO INACT 074020

DLCI 1 INACTIVITY TIME 074021

DLCI 1 DISC UL NS UDATA 074022

DLCI 5 ID 074059












For more information, see 74 Frame Relay Measurement.

79 Coding Scheme Measurement

Table 10. Counters of Coding Scheme Measurement

Name Number

NUMBER OF DL RLC BLOCKS IN ACKNOWLEDGEDMODE

079000

NUMBER OF DL RLC BLOCKS IN UNACKNOWLEDGEDMODE

079001

NUMBER OF UL RLC BLOCKS IN ACKNOWLEDGEDMODE

079002

NUMBER OF UL RLC BLOCKS IN UNACKNOWLEDGEDMODE

079003

NUMBER OF BAD RLC DATA BLOCKS WITH VALIDHEADER UL UNACK MODE

079004

DN03299216Issue 9-0 en20/03/2008



Table 10. Counters of Coding Scheme Measurement (cont.)

Name Number

NUMBER OF BAD RLC DATA BLOCKS WITH BADHEADER UL UNACK MODE

079005

NUMBER OF BAD RLC DATA BLOCKS WITH VALIDHEADER UL ACK MODE

079006

NUMBER OF BAD RLC DATA BLOCKS WITH BADHEADER UL ACK MODE

079007

RETRANSMITTED RLC DATA BLOCKS UL 079008

RETRANSMITTED RLC DATA BLOCKS DL 079009

For more information, see 79 Coding Scheme Measurement.

90 Quality of Service Measurement

Table 11. Counters of Quality of Service Measurement related to GPRS

Name Number

NUMBER OF TBF ALLOCATIONS 090000

TOTAL NBR OF RLC BLOCKS 090001

TOTAL DURATION OF TBFS 090002

DROPPED DL LLC PDUS DUE TO OVERFLOW 090003

DROPPED DL LLC PDUS DUE TO LIFETIME EXPIRY 090004

AVERAGE MS SPECIFIC BSSGP FLOW RATE 090005

AVERAGE MS SPECIFIC BSSGP FLOW RATE DEN 090006

VWTHR NUMERATOR GPRS 090007

VWTHR DENOMINATOR GPRS 090008

For more information, see 90 Quality of Service Measurement.

96 GPRS RX Level and Quality Measurement

Table 12. Counters of GPRS RX Level and Quality Measurement

RXL UP BOUND CLASS 0 096000





Table 12. Counters of GPRS RX Level and Quality Measurement (cont.)



UL SAMPLES WITH RXL 0 RXQ 0 096005












DL SAMPLES WITH RXL 0 RXQ 0 096053












For more information, see 96 GPRS RX Level and Quality Measurement.

110 PCU Utilization Measurement

Table 13. Counters of PCU Utilization Measurement

PEAK RESERVED PCUPCM CHANNELS 110000

DN03299216Issue 9-0 en20/03/2008



Table 13. Counters of PCU Utilization Measurement (cont.)

PEAK OCCUPIED PDTCH UL 110001

PEAK OCCUPIED PDTCH DL 110002

For more information, see 110 PCU Utilization Measurement.

6.1.6 Impact on Network Switching Subsystem (NSS)

No impact.

6.1.7 Impact on NetAct products

NetAct Reporter

NetAct reporter can be used to view reports from measurements related toGPRS. For a list of the measurements, see Measurements and counters.

NetAct Monitor

NetAct Monitor can be used to monitor all alarms related to GPRS. For alist of the alarms, see Alarms.

NetAct Tracing

Nokia NetAct Tracing supports GPRS-capable Nokia network elements inOSS3.1 ED2. Data Tracing must be supported by the BSS and the PacketCore Network.

NetAct Administrator

Standard Nokia NetAct Administration applications, such as NetworkEditor, Time Management, User Group Profiles, Authority Manager, andService Access Control are used to administer GPRS.

NetAct Optimizer

No impact.

NetAct Planner

GPRS has no direct impact on NetAct Planner. However, GPRS can betaken into consideration when network traffic is planned and simulatedwith NetAct Planner.



NetAct Radio Access Configurator (RAC)

NetAct Radio Access Configurator (RAC) can be used to configure theradio network parameters related to GPRS. For more information, seeBSS RNW Parameters and Implementing Parameter Plans in NokiaNetAct Product Documentation. For a list of the radio network parameters,see BSC parameters.

6.1.8 Impact on mobile terminals

GPRS-capable mobile terminals are required.

GPRS defines three classes of mobile terminals:

. Class A terminals support simultaneous circuit-switched (CS) andpacket-switched (PS) traffic.

. Class B terminals attach to the network as both CS and PS clientsbut only support traffic from one service at a time.

. Class C terminals may support both CS and PS services.

With Class C terminals, users must manually select either CS or PS mode,or the terminals can be set up to accept data only. Class C terminalscannot accept paging from both CS and PS at the same time. However,Class B terminals can accept paging of any type when in idle mode.

6.1.9 Impact on interfaces

Impact on radio interface

No impact.

Impact on Abis interface

. Dynamic Abis

Dynamic Abis pools need to be configured for GPRS if CS-3 & CS-4is in use.

. GPRS messages

The Abis interface supports GPRS messages.

Impact on A interface

No impact.

DN03299216Issue 9-0 en20/03/2008



Impact on Gb interface

Nokia BSC supports the Gb interface (BSC-SGSN) as specified in GSMRecommendations (3GPP):

. 3GPP TS 48.018, General Packet Radio Service (GPRS); BaseStation System (BSS) - Serving GPRS Support Node (SGSN); BSSGPRS Protocol (BSSGP)

. 3GPP TS 48.016, General Packet Radio Service (GPRS); BaseStation System (BSS) - Serving GPRS Support Node (SGSN)interface; Network Service

Impact on Gs interface

Nokia SGSN and MSC support the Gs interface (SGSN-MSC/VLR)although it is specified as optional by 3GPP.

The advantages of Gs interface include:

. support for TIA/EIA-136 networks by offering a connection for thetunneling of non-GSM signalling messages via the GPRS network toa non-GSM MSC/VLR.

. more effective radio resource usage with combined GPRS/IMSIattach/detach and combined RA/LA updates, that is, reducedsignalling over the radio interface.

. the possibility to page GPRS terminals for circuit-switched services(for example circuit-switched calls) via GPRS.

6.1.10 Interworking with other features

The implementation of GPRS causes changes to the following existingfunctions of the BSC:

. the PCU plug-in unit is introduced in Hardware ConfigurationManagement

. GPRS-related radio network parameters are introduced in RadioNetwork Configuration Management

. co-operation between circuit-switched traffic and GPRS traffic isdefined in Radio Channel Allocation

. GPRS traffic is monitored with GPRS-specific measurements andcounters

. the serving PCU must be the same for all TRXs under one segment.



For more information on the implementation procedure, see:

. Implementing GPRS overview

. Radio network management for GPRS in BSC



. GPRS radio connection control

The GPRS related measurements are introduced in sectionMeasurements and counters.

Circuit-switched traffic

In the BSC the introduction of GPRS means dividing the radio resources(circuit-switched and GPRS traffic) into two territories. This has an effecton the radio channel allocation features in which the BSC makes decisionsbased on the load of traffic. For some features only the resources of thecircuit-switched territory are included in the decisions. However, for mostfeatures also the traffic channels in the GPRS territory need to be takeninto consideration when the BSC defines the traffic load, because radiotimeslots (RTSL) in the GPRS territory may be allocated for circuit-switched traffic if necessary. Only if there are radio timeslots that arepermanently reserved for GPRS use (dedicated GPRS resources), thesecannot be used for circuit-switched calls and the BSC excludes these in itsdecisions on traffic load.

Frequency Hopping

In Baseband hopping, radio timeslot 0 belongs to a different hopping groupthan the other radio timeslots of a TRX. This makes radio timeslot 0unusable for multislot connections. If Baseband hopping is employed in aBTS, radio timeslot 0 of any TRX in the BTS is not used for GPRS.

Optimisation of MS Power Level

The BSC attempts to allocate traffic channels within the circuit-switchedterritory according to the interference level recommendation the BSC hascalculated, to allow the performing of optimisation of the MS power level.When the BSC has to allocate a traffic channel for a circuit-switchedrequest in the GPRS territory, the interference level recommendation is nolonger the guiding factor. Now, the first GPRS radio timeslot next to theterritory border is taken regardless of whether its interference level isamong the recommended ones or not. For more information on thedivision of territories, see section Radio resource management.

DN03299216Issue 9-0 en20/03/2008



Intelligent Underlay-Overlay, Enhanced Coverage by FrequencyHopping, Handover Support for Coverage Enhancements

Super-reuse TRX frequencies are not supported for GPRS.

Dynamic SDCCH allocation

The BSC selects a traffic channel timeslot to be reconfigured as a dynamicSDCCH timeslot always within the circuit-switched territory.

TRX prioritisation in TCH allocation

The operator can set the BCCH TRX or the non-BCCH TRXs as preferredTRX for the GPRS territory with the parameter prefer BCCH frequency

GPRS (BFG). If no preference is indicated, no prioritisation is used betweenthe different TRX types when the GPRS territory is formed.

Trunk Reservation

In trunk reservation, the BSC defines the number of idle traffic channels.The BSC adds together the number of idle traffic channels in the circuit-switched territory and the number of traffic channels in the radio timeslotsof the GPRS territory. The traffic channels in the radio timeslots that theBSC has allocated permanently for GPRS, are excluded.

TRX fault

When a TRX carrying traffic channels becomes faulty, the radio timeslotson the TRX are blocked from use. The BSC releases the ongoing calls andthe call control resources. The BSC downgrades the traffic channelsbelonging to the GPRS territory in the faulty TRX from GPRS use. Toreplace the lost GPRS capacity, the BSC determines the possibility of aGPRS territory upgrade in another TRX. For more information on GPRSterritory upgrades and downgrades, see section Radio resourcemanagement.

If the faulty TRX functionality is reconfigured to another TRX in the cell, thevalue of the GPRS enabled TRX (GTRX) parameter is also transferred tothe new TRX.

If the faulty TRX is EDGE-capable, and GPRS in enabled in the TRX andCS-3 & CS-4 or EGPRS is enabled in the BTS, the system tries toreconfigure its functionality to another EDGE-capable TRX in the BTS.



Resource indication to MSC

In general, the BSC’s indication on the resources concerns traffic channelsof a BTS excluding those allocated permanently to GPRS (dedicatedGPRS channels). GPRS territory resources other than the dedicated onesare regarded as working and idle resources.

Half Rate

Permanent type half rate timeslots are not used for GPRS traffic.Therefore, it is recommended not to configure permanent half ratetimeslots in TRXs that are planned to be used for GPRS.

When the BSC can select the channel rate (full rate or half rate) to be usedfor a circuit-switched call based on the traffic load of the target BTS, theload limits used in the procedure are calculated using the operator definedBSC and BTS parameters lower limit for HR TCH resources (HRL),upper limit for HR TCH resources (HRU), lower limit for FR TCH

resources (FRL), and upper limit for FR TCH resources (FRU). TheBSC parameter CS TCH allocation calculation (CTC) defines how theGPRS territory is seen when the load limits are calculated. Depending onthe value of CTC either only CS territory or both CS and GPRS territories(excluding the dedicated GPRS timeslots) are used to calculate the loadlimits. Additionally, with the CTC parameter the user can define whether theresources in GPRS territory are seen as idle resources or as occupiedresources.

High Speed circuit-switched Data (HSCSD)

If GPRS has been enabled in a BTS, the HSCSD-related load limits arecalculated based on the existing HSCSD parameters and the followingrules:

. the number of working resources includes all the working full ratetraffic channel (TCH/F) resources of a BTS, excluding the ones thathave been allocated permanently to GPRS

. the number of occupied TCH/F resources includes all the occupiedTCH/Fs of the circuit-switched territory, as well as the default GPRSterritory TCH/Fs, excluding the GPRS radio timeslots defined asdedicated

. HSCSD parameter HSCSD cell load upper limit (HCU) is replacedwith the radio network GPRS parameter free TSL for CS downgrade(CSD) if the latter is more restricting; thus the one that limits HSCSDtraffic earlier is used.

DN03299216Issue 9-0 en20/03/2008



The parameter free TSL for CS downgrade (CSD) defines a margin ofradio timeslots that the BSC tries to keep idle for circuit-switched traffic bydowngrading the GPRS territory when necessary.

If HSCSD multislot allocation is denied based on the appropriateparameters, the BSC rejects the transparent HSCSD requests and servesthe non-transparent HSCSD requests with one timeslot.

If the timeslot share in HSCSD allocation is not restricted, the transparentrequests are served preferably in the circuit-switched territory, and only ifnecessary in the GPRS territory. If a transparent HSCSD call ends up inthe GPRS territory, the BSC does not try to move it elsewhere with an intracell handover. Instead, it tries to replace the lost GPRS capacity byextending the GPRS territory on the circuit-switched side of the territoryborder.

When the transparent HSCSD call inside the GPRS territory is laterreleased, the BSC returns the released radio timeslots back to GPRS useto keep the GPRS territory continuous and undivided. For moreinformation on how the resources form the territories, see section Radioresource management.

The non-transparent HSCSD requests are always served in the circuit-switched territory as long as there is at least one TCH/F available. Anormal HSCSD upgrade procedure is applied later to fulfill the need of thenon-transparent request, if the call starts with less channels than neededand allowed. In order for the non-transparent call to get the needednumber of timeslots, the BSC starts an intra cell handover for suitablesingle slot calls beside the non-transparent HSCSD call. At the start of thehandover, the BSC checks that a single slot call can be moved to anotherradio timeslot and that an HSCSD upgrade is generally allowed.

A non-transparent HSCSD call enters the GPRS territory only if there iscongestion in the circuit-switched territory. If multislot allocation wasoriginally defined as allowed, it is also applied within the GPRS territory toserve the non-transparent request. If the BTS load later decreases,enabling a GPRS territory upgrade, the non-transparent HSCSD call ishanded over to another location in the BTS so that the GPRS territory canbe extended.

When deciding whether to downgrade an HSCSD call or the GPRSterritory, the BSC checks first if the margin of idle resources defined by theparameter free TSL for CS downgrade (CSD) exists. If a sufficient marginexists, the BSC acts as without GPRS, that is, using the state information



that the HSCSD parameters define for the BTS, the BSC performs anHSCSD downgrade if necessary. If the number of idle resources is belowthe parameter free TSL for CS downgrade (CSD), the actions proceed asfollows:

. if there are GPRS radio timeslots that are above and beyond theoperator defined default GPRS territory then these additional GPRSradio timeslots are the first target for the GPRS territory downgrade

. if there are no additional GPRS radio timeslots, the BSC examines ifthere are more HSCSD traffic channels than the parameter HSCSDTCH capacity minimum (HTM) requires and if so, executes anHSCSD downgrade

. if the minimum HSCSD capacity is not in use, a GPRS territorydowngrade is made to maintain the margin defined by the parameterfree TSL for CS downgrade (CSD).

As a TCH/F becomes free through a channel release, the BSC firstexamines the need and possibility for an HSCSD upgrade. If the BSCstarts no HSCSD upgrade, it further checks the need and possibility for aGPRS upgrade. The GPRS territory can be upgraded although theparameter HSCSD TCH capacity minimum (HTM) is not in use and there arepending HSCSD connections in the cell. The parameter free TSL for CS

upgrade (CSU) and the margin it defines is the limiting factor for a GPRSterritory upgrade.

Parameter free TSL for CS upgrade (CSU) defines the number of radiotimeslots that have to remain idle in the circuit-switched territory after theplanned GPRS territory upgrade has been performed.

For more information on GPRS territories, see section Radio resourcemanagement, and for more information on HSCSD, see HSCSD and 14.4kbit/s Data Services in BSC.

Radio Network Supervision

Actions of the radio network supervision do not apply for timeslots thathave been included in the GPRS territory. The only reasonable thing tomonitor is the uplink interference on timeslots in GPRS use.

Radio Network Supervision does not apply to the packet control channel.

BTS testing

BTS testing cannot be executed on the packet control channel.

DN03299216Issue 9-0 en20/03/2008



Multi BCF Control, Common BCCH Control

Multi BCF introduces a radio network object called the segment. SeveralBTS objects can belong to one segment. Only one BTS object of thesegment can have a BCCH. The segment can have BTS objects, whichdiffer in:

. frequency band (GSM800, PGSM900, EGSM900, GSM1800, andGSM1900)

. power levels (Talk-family and UltraSite base stations)

. regular and super-reuse frequencies

. EDGE capability.

TRXs inside a BTS object must have common capabilities. An exception tothis is that EDGE-capable and non-EDGE-capable TRXs can beconfigured to the same BTS object. When EGPRS or CS-3 & CS-4 isenabled in the BTS, there exist some restrictions related to TRXconfiguration. For more information, see section Resrictions. PS territorycan be defined to each BTS object separately. GPRS and EGPRSterritories cannot both be defined to a BTS object at the same time. Super-reuse frequencies are not supported in GPRS.

For information on restrictions when baseband hopping is used, seeEDGE BTSs and hopping in System impact of EDGE in EDGE SystemFeature Description.

There is only one BCCH /CCCH in one segment.

You must define GPRS territory to the BCCH frequency band in aCommon BCCH cell in which more than one frequency band is in use.Otherwise GPRS does not work properly in the cell. The reason for thisrequirement is that in cases when the MS RAC of the GPRS mobile is notknown by the BSC, the temporary block flow (TBF) must be allocated onthe BCCH frequency band first. During the first TBF allocation, the GPRSmobile indicates its frequency capability to the BSC. After that, otherfrequency bands of the cell can be used for the GPRS mobile accordingly.

GPRS territory must be configured into the BCCH BTS of a segment withtwo or more BTSs on the BCCH band if BTS(s) containing GPRS channelsare hopping.



This is because hopping frequency parameters are encoded to theIMMEDIATE ASSIGNMENT message on CCCH with indirect encoding.When the allocated BTS is hopping, indirect encoding can only refer to theSYSTEM INFORMATION TYPE 13 message, which in the Nokia BSScontains GPRS Mobile Allocation only for the BCCH BTS.

The limitation to use only indirect encoding with hopping frequencyparameters in IMMEDIATE ASSIGNMENT comes from the fact thatIMMEDIATE ASSIGNMENT message segmentation is not supported in theNokia BSS. The other two possible hopping frequency encodings, direct 1and 2, might use a large number of octets for the frequency hopping. Largesized frequency parameters cause control message segmentation. Thusas IMMEDIATE ASSIGNMENT segmentation is not supported, direct 1 and 2encoding cannot be used.

Therefore, in a segment where BCCH band GPRS channels are onhopping BTS(s), the TBFs must initially be allocated to the BCCH BTS.Later, the TBFs may be reallocated to other BTSs as well.

See Common BCCH Control in BSC and Multi BCF Control in BSC formore information on Multi BCF and Common BCCH.

Dual Transfer Mode

GPRS must be available and active in the network for Dual Transfer Mode(DTM) to work. The BSC supports DTM data transfer in both GPRS andEGPRS modes. If GPRS is deactivated when DTM is in use, the MSs thathave an active DTM connection keep their CS connection but lose theirTBFs. A DTM TBF is established in EGPRS mode if the MS is EGPRScapable and if the DTM call is allocated from an EGPRS-capable PSterritory. If not, the DTM TBF is established in GPRS mode.

For more information on DTM, see Dual Transfer Mode.

EGSM 900 - PGSM 900 BTS

When the BCCH is on PGSM 900 frequency band in the PGSM-EGSMBTS and RF hopping is used, GPRS has to be disabled in the RF hoppingTRXs. Set the GPRS enabled TRX (GTRX) parameter of the RF hoppingTRXs to value 'N'.

The following restrictions apply when there are EGSM 900 and PGSM 900frequencies in the BTS and GPRS/EDGE Support for PGSM-EGSM BTSis not used:

DN03299216Issue 9-0 en20/03/2008



. When BCCH is on EGSM 900 frequency band and there is a TRX onPGSM 900 frequency band in the BTS, GPRS/EDGE cannot beused in the PGSM 900 TRXs in the BTS. Set the GPRS enabled TRX

(GTRX) parameter of the PGSM 900 TRXs to value 'N'.

. When BCCH is on PGSM 900 frequency band and there is a TRX onEGSM 900 frequency band in the BTS, GPRS/EDGE cannot beused in the EGSM 900 TRXs in the BTS. Set the GPRS enabled TRX

(GTRX) parameter of the EGSM 900 TRXs to value 'N'.

Extended Cell Range

GPRS/EDGE cannot be used in Extended TRXs (E-TRX) withoutextended cell GPRS/EDGE channels (EGTCH).

Extended Cell for GPRS/EDGE

With GPRS/EDGE and Extended Cell for GPRS/EDGE applicationsoftware products GPRS/EDGE traffic can be used in EGTCH channels ofExtended TRXs (E-TRX). EGTCHs constitutes of fixed PS channels andthey cannot be used for CS traffic.

6.2 System impact of EDGE

The system impact of BSS10091: EDGE is specified in the sections below.For an overview, see EDGE.

For implementation instructions, see Implementing EGPRS overview.

EDGE is an application software product and requires a valid licence in theBSC.

6.2.1 Requirements

Hardware requirements

The following network elements are required to implement EDGE:

. Nokia MetroSite EDGE BTS, Nokia UltraSite EDGE BTS or NokiaFlexi EDGE BTS.

Nokia Talk-family BTS site can be upgraded to support Nokia EDGEwith the installation of a Nokia UltraSite EDGE BTS (housing NokiaEDGE-capable TRXs) on site as an extension cabinet. Sitecompatibility is achieved with the synchronisation of Nokia Talk-



family BTS and Nokia UltraSite EDGE BTS and by using existingantenna and feeding structures. The synchronised BTSs share asingle BCCH (per sector) and function in the network as a single cell.The site is then seen as one object by NetAct and the BSC (MultiBCF control). In this configuration, the Nokia Talk-family TRXssupport voice, circuit-switched data, HSCSD, and GPRS.

. EDGE-capable TRXs

. Packet Control Unit (PCU1/PCU2). EGPRS can be implemented in the BSC with S9 level GPRS

PCUs.. The maximum amount of PCUs differ between the BSC

generations.

For more information on PCU, see Packet Control Unit (PCU).

. Additional or optional hardware for GPRS/EDGE needed by BSCiand BSC2i. optional fourth SW64B plug-in unit and SWBUS4 connector to

the bit group switch (GSWB)

The PCU requires the GSWB extension (2 per BSC) formultiplexing the 256 Abis sub-timeslots into it. The secondPCU card for the BSC unit requires an extension of the GSWBwith a fourth SW64B plug-in unit.

. ET5C cartridge (optional)

Additional ET5C cartridges are optional as they are notneeded for GPRS. However, they are needed to increase thePCMs from 80 to 112. In the S8 optional upgrade to HighCapacity BSC they have been added.

. AS7-X, adapter for CCS7 signalling (replaces AS7-V and AS7-VA in new deliveries)




BSC S13


EP2


CX6.0


CXM6.0

DN03299216Issue 9-0 en20/03/2008



Table 14. Required software (cont.)



Not supported


MSC/HLR M14

SGSN SG7



The BSC supports Nokia EDGE on the following frequency bands:

. GSM 800

. GSM 900

. GSM 1800

. GSM 1900

6.2.1.1 EDGE BTSs and hopping

It is possible to have non-EDGE and EDGE TRXs under the same BTSobject if RF Hopping or No Hopping is used. BTS object is an object in theBSC that corresponds to a set of TRXs in a single BTS cabinet, whichcover the same geographical area, use the same frequency band, and(normally) have the same output power. A BTS object may contain one to12 TRXs and one segment may contain one or more BTS objects.

For non-EDGE and EDGE TRXs within a BB Hopping BTS object, seeTables Compatible TRXs, 'GMSK TRX' hopping and Compatible TRXs,'EDGE TRX' hopping.

Nokia EDGE-capable TRXs for Nokia MetroSite EDGE BTS and NokiaUltraSite EDGE BTS are compatible with GSM TRXs. In addition toproviding Nokia EDGE services, Nokia EDGE TRXs are fully GSMcompatible and support GSM voice, data, HSCSD, GPRS, and EGPRS.They are also backward compatible with all legacy GSM mobiles. All NokiaFlexi EDGE TRXs are EDGE and GSM capable.



BTS hopping modes

The different TRX hopping modes are:

. No hopping. TRX RF units Tx/Rx on fixed frequency. radio channel to MS is fixed frequency

. BB hopping. TRX RF units Tx/Rx on fixed frequency. radio channel to MS Tx/Rx is via different TRX RF units

. RF hopping. TRX RF unit Tx/Rx is on different frequencies. radio channel to MS is from the same (hopping) RF unit

. Antenna hopping. TRX RF unit Tx/Rx is on different frequencies. radio channel to MS Tx/Rx is via different TRX RF units. [to give antenna diversity on the link from BTS to MS]. note that Antenna hopping requires an EDGE TRX

UltraSite TRX units

. UltraSite GMSK RF units are: 'TSxA'

. UltraSite EDGE RF units are: 'TSxB'

Where x is the letter (T, G, D, P) which identifies the frequency band (800,900, 1800, 1900 MHz).

. UltraSite GMSK BB unit is: BB2A

. UltraSite EDGE BB units are: BB2E, BB2F

The TSxB EDGE RF unit always requires an EDGE-capable basebandunit, BB2E or BB2F, even if it works in GSM mode only.

The EDGE-capable baseband unit, BB2E or BB2F, is backwardcompatible and also supports the GSM RF unit, TSxA. Table UltraSite TRXunits shows the compatibility matrix for all the different BB2x and TSxxcombinations.

EGPRS support requires both EDGE-capable baseband unit, BB2E orBB2F and EDGE-capable RF unit, TSxB.

DN03299216Issue 9-0 en20/03/2008



Table 15. UltraSite TRX units

Units Compatible Modes of operation

BB2A + TSxA OK GMSK

BB2A + TSxB NOK -

BB2E + TSxA OK GMSK

BB2E + TSxB OK GMSK, EDGE

BB2F + TSxA OK GMSK

BB2F + TSxB OK GMSK, EDGE

GMSK and EDGE TRX hopping group compatibility

Because of the different data rates with GMSK and EDGE, there arerestrictions on mixing GMSK-only TRXs and EDGE-capable TRXs within abaseband hopping group. Note that it is possible to set up GMSK-onlyTRXs in one BTS object, and EDGE-capable TRXs in a second BTSobject, within the same segment by using Common BCCH.

With RF hopping, any combination of TRXs within a hopping group ispossible.

Allowed TRX combinations for baseband hopping are listed in thefollowing tables:

Table 16. Compatible TRXs, 'GMSK TRX' hopping

Units 'GMSK TRX' hoppingcompatible

TRX mode ofoperation

BB2A + TSxA OK GMSK

BB2E + TSxA OK GMSK

BB2F + TSxA OK GMSK

BB2F + TSxB OK GMSK

Note that BB2E + TSxB is not ‘GMSK TRX’ hopping compatible.



Table 17. Compatible TRXs, 'EDGE TRX' hopping

Units 'EDGE TRX' hoppingcompatible

Modes of operation

BB2E + TSxB OK EDGE or GMSK

BB2F + TSxB OK EDGE or GMSK

MetroSite TRX units

. MetroSite EDGE TRX units are: 'WTxA' or 'CTxA'

. MetroSite GMSK-only TRX units are: 'VTxA' or 'HVxA'

Where x is the letter (T, G, D, P) which identifies the frequency band (800,900, 1800, 1900 MHz).

MetroSite TRXs use RF hopping, so EDGE and GMSK-only TRXs may beused in the same hopping group.

6.2.2 Restrictions

. If Baseband hopping is employed in a BTS, radio timeslot 0 of anyTRX in the BTS will not be used for GPRS.

. BTS testing cannot be executed on the packet control channel.

. Network operation mode III is not supported.

. In PCU1 Coding Scheme CS-1 is always used in unacknowledgedRLC mode. In acknowledged RLC mode, the Link Adaptationalgorithm uses both CS-1 and CS-2.

In PCU2, because of CS-3 & CS-4 implementation, there is a newLink Adaptation algorithm that uses all the Coding Schemes in bothunacknowledged and in acknowledged RLC mode.

. Paging reorganisation is not supported.

. Only EDGE-capable TRXs are capable of using shared EGPRSDynamic Abis Pool (EDAP) resources.

. There can be 16 EGPRS Dynamic Abis Pools per Packet ControlUnit.

. One EDAP resource should not be shared between several BCFcabinets. It may damage the TRX or DTRU hardware if the operatortries to share EDAP between several cabinets.

DN03299216Issue 9-0 en20/03/2008



. The master and slave channels must be cross-connected in thesame way; the EDAP and the TRXs tied to it shall use a single PCMline. If they use different PCM lines, transmission delay between thelines may differ. This may cause a timing difference with the resultthat synchronisation between the master and slave channels is notsuccessful.

. GPRS territory can be defined to each BTS object separately. GPRSand EGPRS territories cannot both be defined to a BTS object at thesame time.

. TRXs inside a BTS object must have common capabilities. Anexception to this is that EDGE-capable and non-EDGE-capableTRXs can be configured to the same BTS object, if EGPRS or CS-3& CS-4 is enabled in the BTS.

In this case, GPRS must be disabled in the non-EDGE-capableTRXs. An EDGE-capable TRX has EDGE hardware and is added toEDAP. A non-EDGE-capable TRX has no EDGE hardware or it isnot added to EDAP.. To get BCCH recovery to work correctly, it is recommended

that the operator takes the following conditions into account,when unlocked EDGE and non-EDGE-capable TRXs exist inthe same EGPRS or CS-3 & CS-4 enabled BTS:. If a BCCH TRX is EDGE hardware-capable, added to

EDAP, and it has the GTRX parameter set to Y, then allunlocked TRXs, which are added to EDAP, are EDGEhardware-capable, and have GTRX set to Y, should bemarked Preferred BCCHs.

. If a BCCH TRX is non-EDGE-capable, and has theparameter GTRX set to N, then all non-EDGE-capableunlocked TRXs, which have GTRX set to N, should bemarked Preferred BCCHs.

For information on restrictions when baseband hopping is used, seeEDGE BTSs and hopping in System impact of EDGE in EDGESystem Feature Description.

. The BSS does not restrict the use of 8PSK modulation on TSL7 ofthe BCCH TRX, using the highest output power. The maximumoutput power is 2dB lower than with GMSK. This is fully compliantwith 3GPP Rel 5.


. For restrictions related to Dynamic Abis, see Dynamic Abis.




EDGE sets new demands on Abis interface transmission. The Abisinterface transmission data rate varies depending on the call type. Insteadof allocating fixed transmission capacity according to the highest possibledata rate for every traffic channel from the Abis interface, it isrecommended to share common transmission resources between severaltraffic channels.

Dynamic Abis makes it possible to define common transmission resourcesfor EDGE-capable TRXs situated in the same Abis ETPCM. This commonresource is called the Dynamic Abis Pool. There are fixed transmissionresources for Abis signalling links and traffic channels in Abis ETPCM asbefore but extra transmission resources needed for EGPRS calls arereserved from the Dynamic Abis Pool.


EGPRS impact on TCP performance

Data link bandwidth of EGPRS

The dynamic sharing of resources and variable radio conditions introducevariation to available link level bandwidth. In addition, the signallingprocedures on the MAC layer generate interruptions in the data transferand increase the round-trip delay on the upper layers. Severalmechanisms, such as delayed TBF release, have been implemented toreduce the latency introduced by the MAC layer.

The asymmetry ratio between uplink and downlink is quite low for typicalMS multislot classes, with 8-PSK uplink capability.

EGPRS protocol overhead consists of the following fields:

SNDCP header 4 bytes per IP packet

LLC headers 6 bytes per LLC block

LLC length indicator in RLC 2 bytes per LLC block

The BSC uses MCS-1 or CS-1 synchronisation frame for every 18th block,which reduces the maximum TCP throughput by 4% for MCS-9. The tablebelow summarises the maximum link bandwidth limited TCP throughput[kB/s] for MTU=1500.

DN03299216Issue 9-0 en20/03/2008



Table 18. Maximum TCP throughput per MCS for single slot

Modulation andCoding Scheme

Max. TCPthroughput forUL

(1 slot)

Max. TCPthroughput forDL

(2 slots)

MCS-1 (8.8 kbit/s) 1.0 kB/s 2.0 kB/s

MCS-2 (11.2 kbit/s) 1.3 kB/s 2.6 kB/s

MCS-3 (14.8 kbit/s) 1.7 kB/s 3.4 kB/s

MCS-4 (17.6 kbit/s) 2.0 kB/s 4.0 kB/s

MCS-5 (22.4 kbit/s) 2.5 kB/s 5.1 kB/s

MCS-6 (29.6 kbit/s) 3.3 kB/s 6.7 kB/s

MCS-7 (44.8 kbit/s) 5.0 kB/s 10.0 kB/s

MCS-8 (54.4 kbit/s) 6.1 kB/s 12.0 kB/s

MCS-9 (59.2 kbit/s) 6.7 kB/s 13.0 kB/s

GPRS and EGPRS TBF multiplexing

If GPRS UL TBF and EGPRS DL TBF have been allocated on the sametimeslot, the uplink state flag (USF) signalling to the GPRS TBF requiresGMSK modulation on DL which may reduce the DL throughput for theEGPRS TBF. However, the BSC allocates the EGPRS and GPRS TBFs todifferent territories whenever possible so this constraint is not valid if thereare separate territories for the GPRS and EGPRS TBFs.

On the single territory case, the BSC allocates the maximum number ofslots as per MS capability and tries to allocate GPRS and EGPRS TBFs todifferent timeslots whenever possible. So the larger the territory size theless significant is the impact on performance. When size of territory equalsthe sum of typical slot capabilities of GPRS and EGPRS MSs, the impactis neglected.

Cell re-selection

The impact of cell change depends on the type of cell change:

. RA+LAC update

. RA update

. Inter PCU Cell re-selection

. Intra PCU Cell re-selection



Round-trip Delay

TCP data transfer is very sensitive to round-trip delay of the end-to-endlink. Therefore, one of the main targets in the end-to-end optimisation is tominimise the overall delay. This concerns not only the RLC/MAC layer,which is probably the main delay source in EGPRS data transfer, but alsothe terminal equipment on the mobile side as well as the core network andthe application server.

The data transmission time is only one part of the round-trip delay. Othercontributors include:

. MAC layer signalling delays

. processing delays at the PCU and MS.

The round trip time (RTT) of EGPRS on TCP layer varies considerablybecause of variation of link layer bandwidth. The obtainable RTT over theEGPRS bearer is approximately 1 second for a segment size of 1500 B.

Cell change may cause a peak delay of several seconds, especially ifNACC is not used.

Bandwidth delay product

The bandwidth-delay product of the EGPRS link is rather high, around tenkilobytes. EGPRS increases the data transmission capability, that is,bandwidth of the radio link, but the round-trip delay of the link is still ratherlong. Large bandwidth-delay product requires large window sizes on theTCP layer, which in turn sets high buffering requirements at the SGSN,PCU, and MS.

Packet (SDU) Loss

TCP protocol slows down the transmission rate each time a packet loss isdetected by the TCP transmitter. Therefore, it is crucial to avoid bit errors inthe radio transmission as well as packet discarding in the networkelements. This requires RLC ACK mode and adequate buffering capabilityat the SGSN, PCU and MS.

The PDP context related Rel99 QoS attributes can be used to selectdifferent operation modes for RLC and LLC protocol layers.

The 12bit CRC error detection scheme for RLC may pass some errors toLLC layer at low C/I or Es/No ratios. In unACK mode the LLC can detectthe errors with 24bit CRS but not correct them.

DN03299216Issue 9-0 en20/03/2008



The resulting TCP/IP packet loss in EGPRS non ACK LLC mode istypically of the order 10-3 … 10-5.

Figure 24. Simulated SDU error probability because of bit errors passed byRLC (TU3iFH)

Mobile station synchronisation requirements

GSM specification 45.008 requires that for synchronisation purposes, thenetwork shall ensure that each MS with an active TBF in uplink or downlinkreceives at least one block transmitted with a coding scheme and amodulation that can be decoded by that MS every 360 milliseconds (78TDMA frames).

There is no special implementation for this GSM specification requirementin GPRS territories (EGENA = N). In EGPRS territories (EGENA =Y), thisGSM specification requirement is implemented as follows:

The PCU registers when each MS was expected to successfully decode adownlink block. Then, in the scheduling phase, each MS is checked. If anMS has not been decoding anything for a 17 block period, the PCU setsthe limit of the MCS/CS for GPRS in the next downlink block so low thatthe MS can be expected to decode it. The block may be addressed toother MSs too but the MCS/CS is limited according to the rules below.

0 5 10 15 20 25 30

1.E-02

1.E-03

1.E-04

1.E-05

1.E-06

C/I [dB]

MCS-9MCS-1

SDUError

Probability



. An EGPRS MS is expected to decode blocks that are using an MCS/CS lower or equal to the one selected by link adaptation for the MS’sdownlink TBF. If an EGPRS MS only has an uplink TBF, (M)CS-1 or(M)CS-2 in the downlink is considered robust enough to be decodedcorrectly.

. A GPRS MS is expected to decode blocks that are using CS-1 orCS-2.

. If a GPRS MS has not been decoding anything for a 17 block period,the PCU sends a CS-1 or CS-2 coded block. If possible, the turn isgiven to a GPRS downlink TBF. If only an EGPRS TBF exists on thedownlink connection, the PCU sends a CS-1 (dummy) control block.


6.2.5.1 BSC MMI

The following command groups and MML commands are used to handleNokia EDGE.

. Base Transceiver Station Handling in BSC: EQ

. Power Control Parameter Handling: EU

. Transceiver Handling: ER

. Base Station Controller Parameter Handling in BSC: EE

. Licence and Feature Handling: W7

. Parameter Handling: WO

. GSM Timer and BSC Parameter Handling: EG

. Gb Interface Handling: FX


6.2.5.2 BTS MMI

Nokia EDGE cannot be managed with BTS MMI.

6.2.5.3 BSC parameters

BSC radio network object parameters

Base Tranceiver Station parameters

DN03299216Issue 9-0 en20/03/2008



. BTS uplink throughput factor for MCS1-MCS4 (TFUM1) (PCU2only)

. BTS downlink throughput factor for MCS1-MCS9 (TFDM) (PCU2only)

. BTS uplink throughput factor for MCS1-MCS9 (TFUM) (PCU2only)

. quality control EGPRS DL RLC ack throughput threshold(QEDRT)

. quality control EGPRS UL RLC ack throughput threshold(QEURT)

. EGPRS enabled (ENA)

. EGPRS Link Adaptation enabled (ELA)

. initial MCS for acknowledged mode (MCA)

. initial MCS for unacknowledged mode (MCU)

. maximum BLER in acknowledged mode (BLA)

. maximum BLER in unacknowledged mode (BLU)

. mean BEP offset 8PSK (MBP)

. mean BEP offset GMSK (MBG)


Power Control parameters

. bit error probability filter averaging period (BEP)

For parameters related to GPRS, see section BSC parameters in Systemimpact of GPRS.


PRFILE parameters

. MEMORY_OUT_FLAG_SUM

. EGPRS_UPLINK_PENALTY

. EGPRS_UPLINK_THRESHOLD

. EGPRS_DOWNLINK_PENALTY



. EGPRS_DWNLINK_THRESHOLD

. UPLNK_RX_LEV_FRG_FACTOR

. GPRS_TBF_REALLC_THRSHLD

. TERRIT_BALANCE_THRSHLD

. TERRIT_UPD_GTIME_GPRS

. TBF_LOAD_GUARD_THRSHLD

. EGPRS_RE_SEGMENTATION

. PRE_EMPTIVE_TRANSMISSIO

. BCCH_BAND_TBF_THRSHLD

. FC_MS_R_DEF_EGPRS

. FC_MS_B_MAX_DEF_EGPRS

. FC_R_TSL_EGPRS

. FC_B_MAX_TSL_EGPRS

. EGPRS_GPRS_MUX_PENALTY (PCU2 only)

. EGPRS_DL_MUX_DEC_FACTOR (PCU2 only)


PAFILE parameters

. BS_CV_MAX

For more information on PAFILE parameters, see PAFILE Timer andParameter List.

6.2.5.4 Alarms

The following alarms can be generated in connection with Nokia EDGE:

. 3068 EGPRS DYNAMIC ABIS POOL FAILURE

. 3261 FAILURE IN UPDATING BSC SPECIFIC PARAMETERS TOPCU


. 3324 FAILURE IN UPDATING CONFIGURATION DATA TO PCU

. 7738 BTS WITH NO TRANSACTIONS

DN03299216Issue 9-0 en20/03/2008



. 7769 FAILURE IN UPDATING CELL SPECIFIC PARAMETERS TOPCU

. 7789 NO (E)GPRS TRANSACTIONS IN BTS

For more information on alarms, see Failure Printouts (2000-3999) andBase Station Alarms (7000-7999).

6.2.5.5 Measurements and counters

The following measurements are related to Nokia EDGE:

. 72 Packet Control Unit Measurement

. 73 RLC Blocks per TRX Measurement

. 74 Frame Relay Measurement

. 76 Dynamic Abis Measurement. For counters of 76 Dynamic Abis Measurement, see System

impact of Dynamic Abis.


. 90 Quality of Service Measurement

. 95 GPRS Cell Re-selection Measurement. For counters of 95 GPRS Cell Re-selection Measurement, see

System impact of Network Controlled Re-selection.

. 96 GPRS RX Level and Quality Measurement

. 98 Gb Over IP Measurement. For counters of 98 Gb over IP Measurement, see System

impact of Gb over IP.

. 105 PS DTM Measurement. For counters of 105 PS DTM Measurement, see System


. 106 CS DTM Measurement. For counters of 106 CS DTM Measurement, see System


. 110 PCU Utilization Measurement




Table 19. Counters of 72 Packet Control Unit Measurement related to EGPRS

Name Numbers

NUMBER OF EGPRS TBFS UL 072088

NUMBER OF EGPRS TBFS DL 072089

NUMBER OF ESTABLISHED UPLINK EGPRS TBFS INUNACK MODE

072090

NUMBER OF ESTABLISHED DOWNLINK EGPRS TBFSIN UNACK MODE

072091

UL EGPRS TBF RELEASE DUE NO RESPONSE FROMMS

072094

DL EGPRS TBF RELEASE DUE NO RESPONSE FROMMS

072095

VOLUME WEIGHTED LLC THROUGHPUT EDGE 4 DLNUMERATOR

072109

VOLUME WEIGHTED LLC THROUGHPUT EDGE 4 DLDENOMINATOR

072110

AVER EGPRS TBFS PER TSL UL 072111

AVER EGPRS TBFS PER TSL UL DEN 072112

AVER EGPRS TBFS PER TSL DL 072113

AVER EGPRS TBFS PER TSL DL DEN 072114

UL GPRS TBF IN EGPRS TERR 072117

DL GPRS TBF IN EGPRS TERR 072118

DL GPRS TBF FOR EGPRS REQ 072120

REQ 1 TSL UL FOR EGPRS MS 072141








REQ 1 TSL DL FOR EGPRS MS 072149




DN03299216Issue 9-0 en20/03/2008



Table 19. Counters of 72 Packet Control Unit Measurement related to EGPRS(cont.)

Name Numbers





EGPRS UL CTRL BLOCKS 072165

EGPRS DL CTRL BLOCKS 072166

DL 8PSK TO GMSK DUE UL GPRS 072167

DL EGPRS TBF INIT REALL FAIL 072190

WEIGHTED DL TSL ALLOC EDGE 4 TSL NUMERATOR 072191

WEIGHTED DL TSL ALLOC EDGE 4 TSL DENOMINATOR 072192

WEIGHTED DL TSL ALLOC EDGE NUMERATOR 072193

WEIGHTED DL TSL ALLOC EDGE DENOMINATOR 072194

WEIGHTED UL TSL ALLOC EDGE NUMERATOR 072197

WEIGHTED UL TSL ALLOC EDGE DENOMINATOR 072198

WEIGHTED UL TSL ALLOC EDGE 4 TSL NUMERATOR 072199

WEIGHTED UL TSL ALLOC EDGE 4 TSL DENOMINATOR 072200

1-PHASE UL EGPRS TBF ESTABLISHMENT REQUESTS 072228

1-PHASE UL EGPRS TBF SUCCESSFULESTABLISHMENTS

072230


73 RLC Blocks per TRX Measurement

Table 20. Counters of RLC Blocks per TRX Measurement

Name Number

UR DL RLC MAC BLOCKS 073000

RETRANS DL RLC MAC BLOCKS 073001

SCHED UNUSED RADIO BLOCKS 073002

DL RLC MAC BLOCKS 073003

For more information, see 73 RLC Blocks per TRX Measurement.



74 Frame Relay Measurement

Table 21. Counters of Frame Relay Measurement

Name Number

FRMS WRONG CHECK SEQ ERR 074000

FRMS WRONG DLCI 074001

OTHER FRAME ERROR 074002

T391 TIMEOUT 074003

STAT MSG WRONG SEND SEQ NBR 074004

STAT MSG WRONG REC SEQ NBR 074005

BEAR CHANGED UNOPER 074006

BEAR RET OPER 074007

STAT MSG UNKNOWN PVC 074008

STAT MSG SENT TOO OFTEN 074009

TIME BEAR UNOPERATIONAL 074010

DLCI 1 ID 074011












DLCI 5 ID 074059







DN03299216Issue 9-0 en20/03/2008



Table 21. Counters of Frame Relay Measurement (cont.)

Name Number






For more information, see 74 Frame Relay Measurement.

79 Coding Scheme Measurement

Table 22. Counters of Coding Scheme Measurement

Name Number

NUMBER OF DL RLC BLOCKS INACKNOWLEDGED MODE

079000

NUMBER OF DL RLC BLOCKS INUNACKNOWLEDGED MODE

079001

NUMBER OF UL RLC BLOCKS INACKNOWLEDGED MODE

079002

NUMBER OF UL RLC BLOCKS INUNACKNOWLEDGED MODE

079003

NUMBER OF BAD RLC DATA BLOCKS WITHVALID HEADER UL UNACK MODE

079004

NUMBER OF BAD RLC DATA BLOCKS WITH BADHEADER UL UNACK MODE

079005

NUMBER OF BAD RLC DATA BLOCKS WITHVALID HEADER UL ACK MODE

079006

NUMBER OF BAD RLC DATA BLOCKS WITH BADHEADER UL ACK MODE

079007

RETRANSMITTED RLC DATA BLOCKS UL 079008

RETRANSMITTED RLC DATA BLOCKS DL 079009

DL RLC DATA FOR DUMMY LLC 079012

RLC RETRANSMITTED DL DUE TO OTHERREASON THAN NACK

079013

IGNORED RLC DATA BLOCKS UL DUE TO BSN 079014

For more information, see 79 Coding Scheme Measurement.




Table 23. Counters of 90 Quality of Service Measurement related to EGPRS

Name Number

VWTHR NUMERATOR EDGE OTHER 4 090009

VWTHR DENOMINATOR EDGE OTHER4

090010

VWTHR NUMERATOR EDGE 4 090011

VWTHR DENOMINATOR EDGE 4 090012


96 GPRS RX Level and Quality Measurement

Table 24. Counters of GPRS RX Level and Quality Measurement





















DN03299216Issue 9-0 en20/03/2008



Table 24. Counters of GPRS RX Level and Quality Measurement (cont.)










For more information, see 96 GPRS RX Level and Quality Measurement.

110 PCU Utilization Measurement

Table 25. Counters of PCU Utilization Measurement

PEAK RESERVED PCUPCM CHANNELS 110000

PEAK OCCUPIED PDTCH UL 110001

PEAK OCCUPIED PDTCH DL 110002

For more information, see 110 PCU Utilization Measurement.


The GPRS packet core comprising the Serving GPRS Support Node(SGSN), Gateway GPRS Support Node (GGSN), Charging Gateway (CG)and IP backbone continue to be used when EDGE is introduced in theGSM network. Support for EDGE is available starting from GPRS corerelease 2, which involves upgrades to the SGSN, GGSN and CG.

Nokia’s MSC/HLR supports enhanced data rates for EGPRS. M11 isrequired to support EGPRS service subscription and QoS parameters.



Figure 25. Support for Nokia GPRS Core

GPRS architecture provides IP connectivity from a mobile station to anexternal fixed IP network. A quality of service (QoS) is defined for eachradio access bearer that serves a connection. The parameters includepriority, reliability, delay, and maximum and mean bit rates. A specifiedcombination of these parameters defines a bearer, and different bearersare selected to suit the needs of different applications. Nokia EDGErequires an updated parameter space for the QoS parameters. Higherlayer protocols, such as those used by the GGSN and the SGSN, remainthe same. With these methods, Nokia EDGE delivers enhanced data ratesup to a theoretical maximum of 473 kbps using the same infrastructure asGPRS.

EDGE impact on CS charging

DNS

GGSN

Gi

PACKETCORE

GN

BG

SGSN

CG

Internet

GPRSbackbonenetwork(IP based)

BSC

BTSUm

Support for EDGE functionshas been available startingfrom GPRS core release 2

EDGETRXs

GB

DN03299216Issue 9-0 en20/03/2008



EDGE-specific values are introduced in the channel coding fields. No newCharging Data Recods (CDRs) or fields have been added.

The following values are added to the following CDRs:

. Mobile Originated Call CDR

. Mobile Terminated Call CDR

. Unsuccessfull Call Attempt CDR.



Standard Nokia NetAct Administration applications, such as NetworkEditor, Time Management, User Group Profiles, Authority Manager andService Access Control are used to administer EDGE.

NetAct Monitor

Standard Nokia NetAct monitoring applications, such as Top-Level UI,Alarm History, Alarm Manual (modifiable), Alarm Monitor, Alarm Viewer areused to monitor the network.


NetAct Radio Access Configurator (RAC) can be used to configure theradio network parameters related to EGPRS. For more information, seeBSS RNW Parameters and Implementing Parameter Plans in NokiaNetAct Product Documentation. For a list of the radio network parameters,see BSC parameters.

The features of RAC applications include the following:

. basic EDGE usage enabling

. GUI access to configure the Dynamic Abis pool (DAP) parameters

. CM Provisioner automatically re-creates the TRX with the plannedDAP id: use CM Provisioner for EDGE roll-out

. EDGE-specific rules in CM analyser (consistency check)

See Building and Extending EDGE Coverage in NetAct documentation fordetails.



NetAct Reporter and Network Doctor

NetAct Reporter can be used to view reports from measurements relatedto EGPRS. For a list of the measurements, see Measurements andcounters.

NetAct Doctor Reports 226, 275 and 280 include KPIs that are relevant forEDGE. For more information, see EDGE key performance indicators(KPIs).

NetAct Tracing

NetAct Tracing supports EDGE capable Nokia network elements. DataTracing must be supported by the BSS and the Packet Core Network.

EDGE specific tracing content (from the BSC) includes information aboutthe following:

. Used Modulation and Coding Schemes (MCS)

. The amount of data transferred with each MCS

. Number of MCS changes caused by Dynamic Abis bus blockage

TraceViewer offers efficient means to trace mobile equipment orsubscribers in EDGE networks.


EDGE-capable mobile terminals are required.

All new Nokia GPRS terminals are also EDGE-capable.

There are two GSM EDGE terminal classes, 1 and 2:

. Class 1 terminals can use 8-PSK in downlink and must use GMSK inuplink (also called asymmetric EDGE)

. Class 2 terminals can use 8-PSK in both directions.

EDGE terminal classes combine up to six types of terminals, as shown infigure EDGE terminal classes. EDGE will provide different uplink anddownlink capabilities for terminals. After the roll-out of EDGE terminals,WCDMA operation must be added to appropriate products as required bythe market.

DN03299216Issue 9-0 en20/03/2008



Figure 26. EDGE terminal classes



. Dynamic Abis

Dynamic Abis pools need to be configured.

. Support for EGPRS messages. The BTS sends EGPRS Packet Channel Request information

to the PCU (BSC).. A new information field EGPRS PCR is added to the message

P-CHANNEL REQUIRED.


No impact.


Nokia BSC supports Gb interface (BSC-SGSN) as specified in GSMRecommendations (3GPP):

Simultaneous Voice and Data

EDGE

1 2GPRS

Non-Simultaneous Voice and Data

Asymmetric(8PSK in

Downlink only)

Symmetric(8PSK in Uplinkand Downlink)

Manually selected Voice (CS) orData (PS) or exclusively Data (PS)

CLASSA

CLASSB

CLASSC PCMCIA data-only



. 3GPP TS 48.018, General Packet Radio Service (GPRS); BaseStation System (BSS) - Serving GPRS Support Node (SGSN); BSSGPRS Protocol (BSSGP)

. 3GPP TS 48.016, General Packet Radio Service (GPRS); BaseStation System (BSS) - Serving GPRS Support Node (SGSN)interface; Network Service

BSSGP flow control for BVC and MS:

BVC and MS specific bucket sizes and leak rates are enhanced due tohigher EGPRS throughput. When an EGPRS mobile uses EGPRS TBF indownlink data transfer, EGPRS-specific parameters are used in flowcontrol calculations. If an EGPRS mobile uses normal GPRS TBF, flowcontrol uses GPRS-specific parameters for calculating BVC and MSbucket sizes and leak rates.

There are four EGPRS-specific PRFILE parameters for the Gb interface.For a list of the parameters, see PRFILE parameters.

Impact on Gs interface

Nokia SGSN and MSC support the Gs interface (SGSN-MSC/VLR)although it is specified as optional by 3GPP.

The advantages of Gs interface include:

. support for TIA/EIA-136 networks by offering a connection for thetunneling of non-GSM signalling messages via the GPRS network toa non-GSM MSC/VLR.

. more effective radio resource usage with combined GPRS/IMSIattach/detach and combined RA/LA updates, that is, reducedsignalling over the radio interface.

. the possibility to page GPRS terminals for circuit-switched services(for example circuit-switched calls) via GPRS.


GPRS and EGPRS

GPRS and EGPRS can be multiplexed dynamically on the same timeslot.See EGPRS impact on TCP performance section GPRS and EGPRS TBFmultiplexing for details.

DN03299216Issue 9-0 en20/03/2008



Frequency Hopping

In Baseband hopping, radio timeslot 0 belongs to a different hopping groupthan the other radio timeslots of a TRX. This makes radio timeslot 0unusable for multislot connections. If Baseband hopping is employed in aBTS, radio timeslot 0 of any TRX in the BTS is not used for GPRS.

Both RF and Baseband hopping are supported in EGPRS.

TRX loop test is not possible with Baseband or Antenna hopping.

Optimisation of the MS Power Level

The BSC attempts to allocate traffic channels within the circuit-switchedterritory according to the interference level recommendation the BSC hascalculated, to allow the performing of optimisation of the MS power level.When the BSC has to allocate a traffic channel for a circuit-switchedrequest in the GPRS territory, the interference level recommendation is nolonger the guiding factor. Now, the first GPRS radio timeslot next to theterritory border is taken regardless of whether its interference level isamong the recommended ones or not. For more information on thedivision of territories, see section Radio resource management.

Intelligent Underlay-Overlay, Enhanced Coverage by FrequencyHopping, Handover Support for Coverage Enhancements

Super-reuse frequencies are not supported for GPRS.

Dynamic SDCCH allocation

The BSC selects a traffic channel time slot to be reconfigured as adynamic SDCCH time slot always within the circuit switched territory.

TRX prioritisation in TCH allocation

The operator can set the BCCH TRX or the non-BCCH TRXs as preferredTRX for the GPRS territory with the parameter prefer BCCH frequency

GPRS (BFG). If no preference is indicated, no prioritisation is used betweenthe different TRX types when the GPRS territory is formed.

Trunk reservation

In trunk reservation, the BSC defines the number of idle traffic channels.The BSC adds together the number of idle traffic channels in the circuitswitched territory and the number of traffic channels in the radio timeslotsof the GPRS territory, excluding the ones that are in the radio timeslots thatthe BSC has allocated permanently for GPRS.



TRX fault

When a TRX carrying traffic channels becomes faulty, the radio timeslotson the TRX are blocked from use. The BSC releases the ongoing calls andthe call control resources. The BSC downgrades the traffic channelsbelonging to the GPRS territory in the faulty TRX from GPRS use. Toreplace the lost GPRS capacity, the BSC determines the possibility of aGPRS territory upgrade in another TRX. For more information on GPRSterritory upgrades and downgrades, see section Radio resourcemanagement.

If the faulty TRX functionality is reconfigured to another TRX in the cell, thevalue of the GPRS enabled TRX (GTRX) parameter is also transferred tothe new TRX.

If the faulty TRX is EDGE-capable, and GPRS in enabled in the TRX andCS-3 & CS-4 or EGPRS is enabled in the BTS, the system tries toreconfigure its functionality to another EDGE-capable TRX in the BTS.

Note that a TRX is an EDGE-capable TRX if the TRX HW is EDGEcapable and it is added to EDAP. ATRX is a non-EDGE-capable TRX if theTRX has no EDGE HW or it is not added to EDAP.

Resource indication to MSC

In general the BSC’s indication on the resources concerns traffic channelsof a BTS excluding those allocated permanently to GPRS (dedicatedGPRS channels). GPRS territory resources other than the dedicated onesare regarded as working and idle resources.

Half Rate

Permanent type half rate timeslots are not used for GPRS traffic.Therefore, it is recommended not to configure permanent half ratetimeslots in TRXs that are planned to be capable of GPRS.

When the BSC can select the channel rate (full rate or half rate) to be usedfor a circuit switched call based on the traffic load of the target BTS, theload limits used in the procedure are calculated using the operator definedBSC and BTS parameters lower limit for HR TCH resources (HRL),upper limit for HR TCH resources (HRU), lower limit for FR TCH

resources (FRL), and upper limit for FR TCH resources (FRU). TheBSC parameter CS TCH allocation calculation (CTC) defines how theGPRS territory is seen when the load limits are calculated. Depending onthe value of CTC either only CS territory or both CS and GPRS territories

DN03299216Issue 9-0 en20/03/2008



(excluding the dedicated GPRS timeslots) are used to calculate the loadlimits. Additionally, with the CTC parameter the user can define whetherthe resources in GPRS territory are seen as idle resources or as occupiedresources.

High Speed Circuit Switched Data (HSCSD)

If GPRS has been enabled in a BTS, the HSCSD-related load limits arecalculated based on the existing HSCSD parameters and the followingrules:

. the number of working resources includes all the working full ratetraffic channel (TCH/F) resources of a BTS, excluding the ones thathave been allocated permanently to GPRS

. the number of occupied TCH/F resources includes all the occupiedTCH/Fs of the circuit-switched territory, as well as the default GPRSterritory TCH/Fs, excluding the GPRS radio timeslots defined asdedicated

. HSCSD parameter HSCSD cell load upper limit (HCU) is replacedwith the radio network GPRS parameter free TSL for CS downgrade(CSD) if the latter is more restricting; thus the one that limits HSCSDtraffic earlier is used.

The parameter free TSL for CS downgrade (CSD) defines a margin ofradio timeslots that the BSC tries to keep idle for circuit-switched traffic bydowngrading the GPRS territory when necessary.

If HSCSD multislot allocation is denied based on the appropriateparameters, the BSC rejects the transparent HSCSD requests and servesthe non-transparent HSCSD requests with one timeslot.

If the timeslot share in HSCSD allocation is not restricted, the transparentrequests are served preferably in the circuit-switched territory, and only ifnecessary in the GPRS territory. If a transparent HSCSD call ends up inthe GPRS territory, the BSC does not try to move it elsewhere with an intracell handover. Instead, it tries to replace the lost GPRS capacity byextending the GPRS territory on the circuit-switched side of the territoryborder.

When the transparent HSCSD call inside the GPRS territory is laterreleased, the BSC returns the released radio timeslots back to GPRS useto keep the GPRS territory continuous and undivided. For moreinformation on how the resources form the territories, see section Radioresource management.



The non-transparent HSCSD requests are always served in the circuit-switched territory as long as there is at least one TCH/F available. Anormal HSCSD upgrade procedure is applied later to fulfill the need of thenon-transparent request, if the call starts with less channels than neededand allowed. In order for the non-transparent call to get the needednumber of timeslots, the BSC starts an intra cell handover for suitablesingle slot calls beside the non-transparent HSCSD call. At the start of thehandover, the BSC checks that a single slot call can be moved to anotherradio timeslot and that an HSCSD upgrade is generally allowed.

A non-transparent HSCSD call enters the GPRS territory only if there iscongestion in the circuit-switched territory. If multislot allocation wasoriginally defined as allowed, it is also applied within the GPRS territory toserve the non-transparent request. If the BTS load later decreases,enabling a GPRS territory upgrade, the non-transparent HSCSD call ishanded over to another location in the BTS so that the GPRS territory canbe extended.

When deciding whether to downgrade an HSCSD call or the GPRSterritory, the BSC checks first if the margin of idle resources defined by theparameter free TSL for CS downgrade (CSD) exists. If a sufficient marginexists, the BSC acts as without GPRS, that is, using the state informationthat the HSCSD parameters define for the BTS, the BSC performs anHSCSD downgrade if necessary. If the number of idle resources is belowthe parameter free TSL for CS downgrade (CSD), the actions proceed asfollows:

. if there are GPRS radio timeslots that are above and beyond theoperator defined default GPRS territory then these additional GPRSradio timeslots are the first target for the GPRS territory downgrade

. if there are no additional GPRS radio timeslots, the BSC examines ifthere are more HSCSD traffic channels than the parameter HSCSDTCH capacity minimum (HTM) requires and if so, executes anHSCSD downgrade

. if the minimum HSCSD capacity is not in use, a GPRS territorydowngrade is made to maintain the margin defined by the parameterfree TSL for CS downgrade (CSD).

As a TCH/F becomes free through a channel release, the BSC firstexamines the need and possibility for an HSCSD upgrade. If the BSCstarts no HSCSD upgrade, it further checks the need and possibility for aGPRS upgrade. The GPRS territory can be upgraded although theparameter HSCSD TCH capacity minimum (HTM) is not in use and there arepending HSCSD connections in the cell. The parameter free TSL for CS

upgrade (CSU) and the margin it defines is the limiting factor for a GPRSterritory upgrade.

DN03299216Issue 9-0 en20/03/2008



Parameter free TSL for CS upgrade (CSU) defines the number of radiotimeslots that have to remain idle in the circuit-switched territory after theplanned GPRS territory upgrade has been performed.

For more information on GPRS territories, see section Radio resourcemanagement, and for more information on HSCSD, see HSCSD and 14.4kbit/s Data Services in BSC.

Radio Network Supervision

Actions of the radio network supervision do not apply for time slots thathave been included in the GPRS territory. You may want to monitor theuplink interference on time slots in GPRS use.

Radio Network Supervision does not apply to the packet control channel.

BTS testing

The BTS testing cannot be executed on the packet control channel.

Multi BCF Control, Common BCCH Control

Multi BCF introduces a radio network object called the segment. SeveralBTS objects can belong to one segment. Only one BTS object of thesegment can have a BCCH. The segment can have BTS objects, whichdiffer in:

. frequency band (GSM800, PGSM900, EGSM900, GSM1800, andGSM1900)

. power levels (Talk-family and UltraSite base stations)

. regular and super-reuse frequencies

. EDGE capability.

TRXs inside a BTS object must have common capabilities. An exception tothis is that EDGE-capable and non-EDGE-capable TRXs can beconfigured to the same BTS object. When EGPRS or CS-3 & CS-4 isenabled in the BTS, there exist some restrictions related to TRXconfiguration. For more information, see section Restrictions. PS territorycan be defined to each BTS object separately. GPRS and EGPRSterritories cannot both be defined to a BTS object at the same time. Super-reuse frequencies are not supported in GPRS.

There is only one BCCH/CCCH in one segment.



You must define GPRS territory to the BCCH frequency band in aCommon BCCH cell in which more than one frequency band is in use.Otherwise GPRS does not work properly in the cell. The reason for thisrequirement is that in cases when the MS RAC of the GPRS mobile is notknown by the BSC, the temporary block flow (TBF) must be allocated onthe BCCH frequency band first. During the first TBF allocation, the GPRSmobile indicates its frequency capability to the BSC. After that, otherfrequency bands of the cell can be used for the GPRS mobile accordingly.

GPRS territory must be configured into the BCCH BTS of a segment withtwo or more BTSs on the BCCH band and BTS(s) containing GPRSchannels are hopping.

This is because hopping frequency parameters are encoded to theIMMEDIATE ASSIGNMENT message on CCCH with indirect encoding.When the allocated BTS is hopping, indirect encoding can only refer to theSYSTEM INFORMATION TYPE 13 message, which in the Nokia BSScontains GPRS Mobile Allocation only for the BCCH BTS.

The limitation to use only indirect encoding with hopping frequencyparameters in IMMEDIATE ASSIGNMENT comes from the fact thatIMMEDIATE ASSIGNMENT message segmentation is not supported in theNokia BSS. The other two possible hopping frequency encodings, direct 1and 2, might use a large number of octets for the frequency hopping. Largesized frequency parameters cause control message segmentation. Thusas IMMEDIATE ASSIGNMENT segmentation is not supported, direct 1 and 2encoding cannot be used.

Therefore, in a segment where BCCH band GPRS channels are onhopping BTS(s), the TBFs must initially be allocated to the BCCH BTS.Later, the TBFs may be reallocated to other BTSs as well.

See Common BCCH Control in BSC and Multi BCF Control in BSC formore information on Multi BCF and Common BCCH.

IDD and hopping compatibility

The hopping mode setup (No hopping, BB hopping, RF hopping, Antennahopping) applies to all TRXs within a Sector/BTS object. It is not possibleto mix BB, RF or Antenna hopping within a Sector/BTS object with NokiaUltraSite BTSs. Mixing different hopping modes within different sectors ispossible with Nokia Flexi EDGE BTSs. Nokia Flexi EDGE BTS supportsIDD from EP2.0 onwards.

Note that with BB, RF and Antenna hopping it is possible to set up thehopping parameters so that a TRX, or timeslot(s) within a TRX, do not hop.

DN03299216Issue 9-0 en20/03/2008



RF hopping and Antenna hopping cannot be used in a sector which usesthe Remote Tune Combiner (RTC).

IDD is set up per TRX, with 2 TRX units making 1 (logical) IDD TRX; theBSC sees the IDD TRX pair as a single (logical) TRX.

BB hopping, Antenna hopping and IDD all use the BB hopping HW, but inslightly different ways. This restricts some of the combinations within thecabinet.

. It is possible to mix BB hopping, RF hopping, and Antenna hoppingsectors within an UltraSite cabinet.

. Within a cabinet it is not possible to have a single sector that is BBhopping and uses IDD; Sector with IDD and BB hopping will beintroduced in future releases.

. It is not possible to have an IDD sector and a BB hopping sectorwithin a cabinet.

. It is not possible to have an IDD sector and an Antenna Hoppingsector within a cabinet.

Table 26. IDD and hopping compatibility

First SectorType

Second Sector Type Third Sector Type Mixed Sectors WithinCabinet

BB hopping RF hopping - Possible

BB hopping Antenna hopping - Possible

BB hopping IDD - Not possible

BB hopping RF hopping Antenna hopping Possible

BB hopping RF hopping IDD Not possible

BB hopping Antenna hopping IDD Not possible

RF hopping Antenna hopping - Possible

RF hopping IDD - Possible

RF hopping Antenna hopping IDD Not possible

Antenna hopping IDD - Not possible



Rx Antenna Supervision

Rx Antenna Supervision by comparing RSSI value is possible with RF,Baseband and Antenna hopping, but with some combinations of RFcabling configuration and hopping type, the results need care ininterpretation.

The RSSI values for a sector are summarised as follows:

. Each TRX calculates an average of the RSSI difference betweenMain and Div Antennas.

. The O&M then takes the average of the RSSI difference figures fromall TRXs in the sector, and reports the single sector-wide averagefigure.

Dual Transfer Mode

GPRS must be available and active in the network for Dual Transfer Mode(DTM) to work.

The BSC supports DTM data transfer in both GPRS and EGPRS modes. IfGPRS is deactivated when DTM is in use, the MSs that have an activeDTM connection keep their CS connection but lose their temporary blockflows (TBFs). A DTM TBF is established in EGPRS mode if the MS isEGPRS capable and if the DTM call is allocated from an EGPRS-capablePS territory. If not, the DTM TBF is established in GPRS mode.

For more information on DTM, see Dual Transfer Mode.

EGSM 900 - PGSM 900 BTS

The following restrictions apply when there are EGSM 900 and PGSM 900frequencies in the BTS and GPRS/EDGE Support for PGSM-EGSM BTSis not used:

. When BCCH is on EGSM 900 frequency band and there is a TRX onPGSM 900 frequency band in the BTS, GPRS/EDGE cannot beused in the PGSM 900 TRXs in the BTS. Set the GPRS enabled TRX

(GTRX) parameter of the PGSM 900 TRXs to value 'N'.

. When BCCH is on PGSM 900 frequency band and there is a TRX onEGSM 900 frequency band in the BTS, GPRS/EDGE cannot beused in the EGSM 900 TRXs in the BTS. Set the GPRS enabled TRX

(GTRX) parameter of the EGSM 900 TRXs to value 'N'.

DN03299216Issue 9-0 en20/03/2008



7 System impact of GPRS/EDGE relatedsoftware

7.1 System impact of EGPRS Packet Channel Requeston CCCH

The system impact of BSS11156: EGPRS Packet Channel Request onCCCH is specified in the sections below. For an overview, see EGPRSPacket Channel Request on CCCH.

EGPRS Packet Channel Request on CCCH is an operating softwareproduct in the BSS, but it requires Nokia EDGE as a prerequisite.

7.1.1 Requirements


Table 27. Required additional or alternative hardware or firmware.


BSC No requirements

BTS EDGE TRXs are required



DN03299216Issue 9-0 en20/03/2008


System impact of GPRS/EDGE related software




BSC S13


EP2


CX6.0


CXM6.0


No requirements

Nokia InSite BTSs No requirements

MSC/HLR No requirements


Nokia NetAct No requirements


The BSC supports EGPRS Packet Channel Request on CCCH on thefollowing frequency bands:

. GSM 800

. GSM 900

. GSM 1800

. GSM 1900


No impact.


OMU signalling

No impact.



TRX signalling

No impact.

Impact on BSC units

Table 29. Impact on BSC units

BSC unit Impact

OMU No impact.

MCMU No impact.

BCSU No impact.

PCU Faster EGPRS Uplink TBF establishment oncells without PCCCH.

Impact on BTS units

No impact.


BSC MMI

No impact.

BTS MMI

EGPRS Packet Channel Request on CCCH cannot be managed with BTSMMI.

BSC parameters

No impact.

Alarms

No alarms are specifically related to EGPRS Packet Channel Request onCCCH.


No impact.

DN03299216Issue 9-0 en20/03/2008




No impact.



No impact.

NetAct Monitor

No impact.

NetAct Optimizer

No impact.

NetAct Planner

No impact.


No impact.

NetAct Reporter

No impact.

NetAct Tracing

No impact.


EDGE-capable mobile terminals are required.



No impact.




EGPRS Packet Channel Request information is sent to the PCU (BSC).

New information field EGPRS PCR is added to message P-CHANNELREQUIRED.


No impact.


No impact.

7.2 System impact of Extended Uplink TBF Mode

The system impact of BSS11151: Extended Uplink TBF Mode is specifiedin the sections below. For an overview, see Extended Uplink TBF Mode.

For implementation instructions, see Activating and Testing BSS11151:Extended Uplink TBF Mode.

Extended Uplink TBF Mode does not require a licence, but it requires theNokia GPRS functionality as a prerequisite.

7.2.1 Requirements


Table 30. Required additional or alternative hardware or firmware.


BSC No requirements

BTS No requirements



DN03299216Issue 9-0 en20/03/2008






BSC S13


No requirements

Nokia UltraSiteBTSs

No requirements

Nokia MetroSiteBTSs

No requirements


No requirements


MSC/HLR No requirements




The BSC supports Extended Uplink TBF Mode on the following frequencybands:

. GSM 800

. GSM 900

. GSM 1800

. GSM 1900


No impact.


OMU signalling

No impact.



TRX signalling

No impact.

Impact on BSC units

Table 32. Impact of Extended Uplink TBF Mode on BSC units

BSC unit Impact

OMU No impact.

MCMU No impact.

BCSU No impact.

PCU Faster uplink data flow continuing aftershort breaks.

Impact on BTS units

No impact.


BSC MMI

The following command groups and MML commands are used to handleExtended Uplink TBF Mode:

. Parameter Handling: WOA, WOI, WOC

. Base Transceiver Station Handling in BSC: EQV


BTS MMI

Extended Uplink TBF Mode cannot be managed with BTS MMI.

BSC parameters

PRFILE parameters

. UL_TBF_REL_DELAY_EXT

. UL_TBF_SCHED_RATE_EXT

DN03299216Issue 9-0 en20/03/2008



. POLLING_INTERVAL_STRM

. POLLING_INTERVAL_IA

. POLLING_INTERVAL_BG

. POLLING_INTERVAL_STR_LOW

. POLLING_INTERVAL_IA_LOW

. POLLING_INTERVAL_BG_LOW


Alarms

No alarms are specifically related to Extended Uplink TBF Mode.


The following measurements and counters are related to Extended UplinkTBF Mode.


Table 33. Counters of 72 Packet Control Unit Measurement

Name Number

UL DATA CONT AFTER COUNTDOWN 072115

EXTENDED UL TBFS 072116

The counters are collected on BTS level.



No impact.



No impact.



NetAct Monitor

No impact.

NetAct Optimizer

No impact.

NetAct Planner

No impact.


No impact.

NetAct Reporter

NetAct reporter can be used to create reports from measurements relatedto Extended Uplink TBF Mode. For a list of the measurements, seeMeasurements and counters.

NetAct Tracing

No impact.


3GPP Rel.4 GERAN feature package 1 MS required.



No impact.


Support for Extended UL TBF Mode related signalling with the MS.


No impact.

DN03299216Issue 9-0 en20/03/2008




No impact.


No impact.

7.3 System impact of Nokia Smart Radio Concept forEDGE

The system impact of BSS10104: Nokia Smart Radio Concept for EDGE(Nokia SRC) is specified in the sections below. For an overview, see NokiaSmart Radio Concept for EDGE.

Nokia Smart Radio Concept for EDGE does not require a licence.

7.3.1 Requirements




BSC No requirements

BTS EDGE TRXs

EDGE baseband units(BB2E/BB2F)








BSC S13


EP2


CX6.0


Not supported


Not supported


MSC/HLR Not applicable

SGSN Not applicable

Nokia NetAct Not applicable


The BSC supports Nokia SRC on the following frequency bands:

. GSM 800

. GSM 900

. GSM 1800

. GSM 1900


No impact.


OMU signalling

No impact.

DN03299216Issue 9-0 en20/03/2008



TRX signalling

No impact.

Impact on BSC units

Table 36. Impact of Nokia SRC on BSC units

BSC unit Impact

OMU No impact

MCMU No impact

BCSU No impact

PCU No impact

Impact on BTS units

When Nokia SRC is used, BB hopping must be disabled.

The downlink gain of IDD in terms of signal level is 4 dB on average overone way transmission. This is mainly achieved due to 3 dB power gainusing 2 TRXs transmission at the same time, and the provided diversitygain of delay diversity and phase hopping. The diversity gain is dependenton the propagation environment, frequency hopping and mobile speed.

The uplink gain of 4UD is from 2 to 2,5 dB on average over 2-way diversityreception.


BSC MMI

Nokia SRC cannot be managed with BSC MMI.

BTS MMI

Nokia SRC is managed with BTS MMI. Nokia SRC is set up during BTScommissioning. The TRXs are displayed in the Supervision window –Equipment view in BTS Manager.

BSC parameters

There are no BSC parameters related to Nokia SRC.



Alarms

. IDD changes to the alarm handling function primarily address theneed to “hide” the IDD auxiliary TRXs from the BSC.

. If an alarm is generated for an IDD main TRX, the alarm will bereported normally to the BSC and MMI.

. In case of a faulty alarm, alarm 7606 will be sent to the BSC andMMI. Only the main TRX will be blocked out of use but in effect theauxiliary TRX will be blocked as well.

. Alarms for IDD auxiliary TRXs are treated differently. If an alarm isgenerated for an IDD auxiliary TRX, the alarm will be reported toMMI and the BSC in the same way as its partner, the IDD main TRXalarm.

. In case of a faulty alarm, all signalling and traffic to the auxiliary TRXwill stop, and the alarm is reported to the BSC and MMI as degradedservice of the partner IDD main TRX. However, in order to let theBSC tell which unit the alarm comes from, new plug-in types will bedefined for the alarm messages to the BSC.


There are no measurements related to Nokia SRC.


No impact.



No impact.

NetAct Monitor

NetAct Monitor can be used to monitor all alarms related to Nokia SRC.For a list of the alarms, see Alarms.

NetAct Optimizer

No impact.

DN03299216Issue 9-0 en20/03/2008



NetAct Planner

No impact.


No impact.

NetAct Reporter

No impact.

NetAct Tracing

No impact.


There are no requirements for mobile terminals.



Nokia Smart Radio Concept is a performance enhancement solution.Nokia SRC is a combination of increased Tx/Rx signal power and diversitysolution in both uplink and downlink directions. It consists of two TRXs,where the main and auxiliary TRXs are combined together with softwarefor one operable logical TRX in the BSC.

Nokia SRC consists of the following downlink and uplink performanceenhancement solutions:

. Intelligent Downlink Diversity Transmission (IDD)

. Interference Rejection Combining (IRC)

. Sensitivity-optimised High Gain Mast Head Amplifier (UltraSiteMHA)

. 4-way Uplink Diversity reception (4UD)

In downlink direction, Intelligent Downlink Diversity (IDD) is a method,where a combination of delay diversity and phase hopping is used. DelayDiversity is a function of auxiliary TRX in IDD, and it creates an artificialmultipath, which can be resolved by any mobile receiver. This reduces theimpact of fast fading, in other words, the fading dips are not so deep.



Phase Hopping is also a function of auxiliary TRX in IDD, and it artificiallyincreases the channel fading rate, which would be comparable tofrequency hopping and increased mobile speed. This reduces the timecorrelation of the channel, thus improving the performance.

Uplink Diversity means that the same signal is received by multipleantennas at the same time. In uplink, Interference Rejection Combining(IRC) is an extension to the Maximum Ratio Combining (MRC) method.IRC can reject the interference and constructively combine multiple inputsignals from different antenna sources into one signal, while MRC onlytakes into account the noise difference between the received signals. IRCdecorrelates input signal branches (IRC step) and performs signalcombining (MRC step) for decorrelated branches. If there is nointerference, IRC behaves like normal Maximum Ratio Combining withoutloss in terms of sensitivity performance.

In case of 4-way Uplink Diversity, both main and auxiliary TRXs defined inIDD are used to process the received signal in uplink. The 4-way receptionis done by 2-way IRC combining independently in both TRXs, followed by2-way MRC post-detection combining stage in the main TRX.


No impact.


No impact.


No impact.

7.4 System impact of Priority Class based Quality ofService

The system impact of BSS10084: Priority Class based Quality of Serviceis specified in the sections below. For an overview, see Priority Classbased Quality of Service.

Priority Class based Quality of Service does not require a licence.

DN03299216Issue 9-0 en20/03/2008



7.4.1 Requirements



Network element Required hardwareor firmware

BSC PCU1/PCU2

BTS No requirements






BSC S13


No requirements


No requirements


No requirements


No requirements


MSC/HLR M14

GGSN GGSN2

CG2/3

SGSN SG7





The BSC supports Priority Class based Quality of Service on the followingfrequency bands:

. GSM 800

. GSM 900

. GSM 1800

. GSM 1900


No impact.


OMU signalling

No impact.

TRX signalling

No impact.

Impact on BSC units

Table 39. Impact of Priority Class based Quality of Service on BSC units

BSC unit Impact

OMU No impact

MCMU No impact

BCSU No impact

PCU Both PCU1 and PCU2 support PriorityClass based Quality of Service.

Impact on BTS units

No impact.

DN03299216Issue 9-0 en20/03/2008




BSC MMI

The following command group and MML commands are used to handlePriority Class based Quality of Service:

. Base Station Controller Parameter Handling in BSC: EEV, EEO

BTS MMI

Priority Class based Quality of Service cannot be managed with BTS MMI.

BSC parameters

BSC radio network parameters

There are different radio network parameters for priority based schedulingin PCU1 and PCU2. Table Radio network parameters for Priority BasedScheduling describes the correspondence of these parameters betweenPCU1 and PCU2.

The following parameters apply to PCU1:

. DL high priority SSS (DHP)

. DL normal priority SSS (DNP)

. DL low priority SSS (DLP)

. UL priority 1 SSS (UP1)




The following parameters apply to PCU2:

. background traffic class scheduling weight for ARP 1(BGSW1)





. interactive 1 traffic class scheduling weight for ARP 1(ISW11)





. interactive 2 traffic class scheduling weight for ARP 3(ISW23




. streaming traffic class scheduling weight for ARP 1 (SSW1)



Table 40. Radio network parameters for Priority Based Scheduling

Scheduling stepsize (PCU1)

Schedulingweight (PCU2)

1 60

2 30

3 20

4 15

5 12

6 10

7 9

8 8

9 7

10 6

DN03299216Issue 9-0 en20/03/2008



Table 40. Radio network parameters for Priority Based Scheduling (cont.)

Scheduling stepsize (PCU1)

Schedulingweight (PCU2)

11 5

12 5


Alarms

No impact.


The following measurement and counters are related to Priority Classbased Quality of Service:


Table 41. Counters of Quality of Service Measurement

Name Number

NUMBER OF TBF ALLOCATIONS 090000

TOTAL NBR OF RLC BLOCKS 090001

TOTAL DURATION OF TBFS 090002

DROPPED DL LLC PDUS DUE TOOVERFLOW

090003

DROPPED DL LLC PDUS DUE TOLIFETIME EXPIRY

090004

AVERAGE MS SPECIFIC BSSGP FLOWRATE

090005

AVERAGE MS SPECIFIC BSSGP FLOWRATE DEN

090006

VWTHR NUMERATOR GPRS 090007

VWTHR DENOMINATOR GPRS 090008

VWTHR NUMERATOR EDGE OTHER 4 090009

VWTHR DENOMINATOR EDGE OTHER4

090010

VWTHR NUMERATOR EDGE 4 090011



Table 41. Counters of Quality of Service Measurement (cont.)

Name Number

VWTHR DENOMINATOR EDGE 4 090012



The subscriber priority must be defined in the home location register (HLR)once Priority Class based Quality of Service is introduced in the network.



No impact.

NetAct Monitor

No impact.

NetAct Optimizer

TRECs are supported in Service Optimizer (OSS3.1).

NetAct Planner

Priority Class based Quality of Service is supported in NetAct Planner. Theprecedence class and traffic class can be set for packet switched services.


NetAct Radio Access Configurator (RAC) can be used to configure theradio network parameters related to Priority Class based Quality ofService. For more information, see BSS RNW Parameters andImplementing Parameter Plans in Nokia NetAct Product Documentation.For a list of the radio network parameters, see BSC parameters.

NetAct Reporter

NetAct Reporter can be used to view and create reports based onmeasurements related to Priority Class based Quality of Service. For a listof the measurements, see Measurements and counters.

DN03299216Issue 9-0 en20/03/2008



NetAct Tracing

The Quality of Service type is shown in the GPRS trace report in NetActTracing.


GPRS/EDGE-capable mobile terminals are required.



See Priority Class based Quality of Service for details.


No impact.


No impact.


No impact.


PCU and Priority Class based Quality of Service

Priority Class based Quality of Service works with both PCU1 and PCU2.There is an efficient Quality of Service differentiation mechanism in PriorityClass based Quality of Service with PCU1. The differentiation isimplemented by tuning the scheduling step size parameters (SSS). Theseparameters correspond to the scheduling weight parameters with PCU2.The SSS parameters cannot be used with PCU2.

7.5 System impact of System Level Trace

The system impact of BSS10089: System Level Trace is specified in thesections below. For an overview, see System Level Trace.



System Level Trace does not require a licence.

7.5.1 Requirements




BSC No requirements

BTS No requirements






BSC S13


No requirements


No requirements


No requirements


No requirements


MSC/HLR M14

GGSN GGSN2

SGSN SG7


DN03299216Issue 9-0 en20/03/2008




The BSC supports System Level Trace on the following frequency bands:

. GSM 800

. GSM 900

. GSM 1800

. GSM 1900


No impact.


OMU signalling

No impact.

TRX signalling

No impact.

Impact on BSC

Table 44. Impact of System Level Trace on BSC units

BSC unit Impact

OMU No impact

MCMU No impact

BCSU No impact

PCU Faster uplink data flow continuing aftershort breaks.

Impact on BTS units

No impact.




BSC MMI

No impact.

BTS MMI

System Level Trace cannot be managed with BTS MMI.

BSC parameters

No impact.

Alarms

No impact.


The following observations and counters are related to System LevelTrace.

25 TBF Observation for GPRS Trace

Table 45. Counters of TBF Observation for GPRS Trace

Name Number

SEGMENT ID 025000

BTS ID 025001

TRX ID 025002

IMSI 025003

TBF ALLOCATION TIME 025004

TBF ALLOCATION CALENDAR TIME 025005

TBF RELEASE TIME 025006

TBF DIRECTION 025007

QOS PRIORITY CLASS 025008

NBR OF FLOW CNTRL CHANGES 025009

FLOW CTRL CHANGE TIME 0 025010

BUCKET SIZE 0 025011

QOS LEAK RATE 0 025012

DN03299216Issue 9-0 en20/03/2008



Table 45. Counters of TBF Observation for GPRS Trace (cont.)

Name Number

... ...

FLOW CTRL CHANGE TIME 19 025067

BUCKET SIZE 19 025068

QOS LEAK RATE 19 025069

NBR OF TCHS IN BEG 025070

NBR OF REALLOC 025071

REALLOC TIME 0 025072

REALLOC CAUSE 0 025073

BTS ID 0 025074

TRX ID 0 025075

NEW NBR OF TCHS 0 025076

... ...

REALLOC TIME 19 025167

REALLOC CAUSE 19 025168

BTS ID 19 025169

TRX ID 19 025170

NEW NBR OF TCHS 19 025171

AMOUNT OF LLC DATA 025172

NBR OF RLC BLOCKS LAST MCS 025173

INITIAL CODING SCHEME 025174

NBR OF DYNABIS MCS CHANGES 025175

MCS CHANGES 025176

MCS CHANGE TIME 0 025177

CAUSE MCS CHANGE 0 025178

NEW MCS 0 025179

NBR OF RLC BLOCKS PREV MCS 0 025180

AMOUNT OF LLC DATA PREV MCS 0 025181

... ...

MCS CHANGE TIME 19 025272

CAUSE MCS CHANGE 19 025273

NEW MCS 19 025274

NBR OF RLC BLOCKS PREV MCS 19 025275



Table 45. Counters of TBF Observation for GPRS Trace (cont.)

Name Number

AMOUNT OF LLC DATA PREV MCS 19 025276

CAUSE TBF RELEASE 025277

TRACE STATUS 025278

TBF DTM FLAG 025312

MULTISLOT CLASS 025313

DTM MULTISLOT CLASS 025314

For more information, see 25 TBF Observation for GPRS Trace.

27 GPRS Cell Re-Selection Report

Table 46. Counters of GPRS Cell Re-Selection Report

Name Number

LAC CI 027000

RAC 027001

SEGMENT ID 027002

BTS ID 027003

TRX ID 027004

IMSI 027005

NC MODE 027006

CELL RESEL START TIME 027007

CELL RESEL START CALTIME

027008

NCCR TRIGGERING CAUSE 027009

TARGET CELL ID 027010

TARGET RNC ID 027011

NACC START TIME 027012

CELL CHANGE TIME 027013

CELL RESEL END CAUSE 027014

CELL RESEL END TIME 027015

For more information, see 27 GPRS Cell Re-Selection Report.

DN03299216Issue 9-0 en20/03/2008



28 GPRS RX Level and Quality Report

Table 47. Counters of GPRS RX Level and Quality Report

Name Number

LAC CI 028000

RAC 028001

BTS ID 028002

TRX ID 028003

IMSI 028004

REP PERIOD IDLE 028005

REP PERIOD TRANSF 028006

BEP USED 028007

RECORD START TIME 028008

RECORD END TIME 028009

NR OF MEASUREMENTS 028010

UL MEAS RESULTS 1 028011

... ...

UL MEAS RESULTS 16 028026

IS PACKET TRANSF MODE 1 028027

REPORT TIME SEC AND 100THSEC 1

028028

DL RX LEV AND QUAL 1 028029

NCELL MEAS RESULTS 1 028030

... ...

IS PACKET TRANSF MODE 16 028087

REPORT TIME SEC AND 100THSEC 16

028088

DL RX LEV AND QUAL 16 028089

NCELL MEAS RESULTS 16 028090

NCELL INDEX 1 028091

NCELL RADIO TYPE 1 028092

NCELL ID 1 028093

... ...

NCELL INDEX 40 028208

NCELL RADIO TYPE 40 028209



Table 47. Counters of GPRS RX Level and Quality Report (cont.)

Name Number

NCELL ID 40 028210

For more information, see 28 GPRS RX Level and Quality Report.

Table 48. CS and MCS codecs in the initial coding scheme and new MCSfields

Countervalue

Codec (Modulation and user data rate)

0 GPRS CS1 (GMSK 8 kbps)


2 GPRS CS3 (GMSK 14.4 kbps)


4 dummy value, bad header in ack mode

5 EGPRS MCS1 (GMSK 8.4 kbps)




9 EGPRS MCS5 (8-PSK 22.5 kbps)






No impact.



No impact.

DN03299216Issue 9-0 en20/03/2008



NetAct Monitor

No impact.

NetAct Optimizer

No impact.

NetAct Planner

No impact.


No impact.

NetAct Reporter

NetAct reporter can be used to create reports from measurements relatedto System Level Trace. For a list of the measurements, see Measurementsand counters.

NetAct Tracing

No impact.


GPRS-capable terminals are required.



No impact.


Support for Extended Uplink TBF Mode related signalling with the mobilestation is required.


No impact.




The SGSN invokes the trace by sending a BSSGB SGSN-INVOKE-TRACE(3GPP TS 48.018) message to the BSS when the SGSN trace becomesactive or when the SGSN receives a trace request.


No impact.

DN03299216Issue 9-0 en20/03/2008



8 Requirements for GPRS/EDGE

8.1 Packet Control Unit (PCU)

For GPRS the BSC needs the Packet Control Unit, which implements boththe Gb interface and RLC/MAC protocols in the BSS.

PCU functions

The PCU controls the GPRS radio resources and acts as the key unit inthe following procedures:

. GPRS radio resource allocation and management

. GPRS radio connection establishment and management

. Data transfer

. Coding scheme selection

. PCU statistics

PCU and BSC product variants

The PCU hardware is positioned at the BSC site as a plug-in unit in eachBCSU. Table Nokia GSM/EDGE PCU product family lists the availablePCU variants and table PCUs in BSC product variants shows the amountof PCUs for each BSC product variant.

Table 49. Nokia GSM/EDGE PCU product family

PCUPacket Control Unit, a general term for all NokiaGSM/EDGE PCU variants

General nameName of PCUproduct variant Explanation

DN03299216Issue 9-0 en20/03/2008



Table 49. Nokia GSM/EDGE PCU product family (cont.)

PCUPacket Control Unit, a general term for all NokiaGSM/EDGE PCU variants

General nameName of PCUproduct variant Explanation

Nokia First Generation PacketControl Unit - PCU1

PCU

PCU-S

PCU-T

First generation PCU for BSCiand BSC2i

PCU-B First generation PCU for BSC3i660, includes two logical PCUs

Nokia Second GenerationPacket Control Unit - PCU2

PCU2-U Second generation PCU for BSCiand BSC2i

PCU2-D Second generation PCU forBSC3i 660, BSC3i 1000 andBSC3i 2000, includes two logicalPCUs

Table 50. PCUs in BSC product variants

BSC product variant Amount of PCUs

BSCi One PCU plug-in unit (PIU) in each BCSU, a total of8 (+1 spare) logical PCUs.

BSC2i Two PCU PIUs in each BCSU, a total of 16 (+2spares) logical PCUs.

BSC3i 660 Two PCU PIUs in each BCSU, a total of 24 (+4spares) logical PCUs.

BSC3i 1000 Five PCU PIUs in each BCSU, a total of 50 (+10spares) logical PCUs.

Note that only two of the PCU PIUs can be of thetype PCU-B.

BSC3i 2000 Five PCU PIUs in each BCSU, a total of 100 (+10spares) logical PCUs.

Note that only two of the PCU PIUs can be of thetype PCU-B.

When installing the PCUs to BSCi and BSC2i, the operator has to makesure that the GSWB has enough capacity. Installing the first PCU plug-inunit into the BCSUs requires three SW64B plug-in units in the GSWB(GSWB size 192 PCMs), installing the second PCU plug-in unit requiresfour SW64B plug-in units in the GSWB (GSWB size 256 PCMs).



If Gb over Frame Relay is used, then the operator also has to consider theneed for E1/T1 (ET) extensions.

PCU capacity and connections

Table 51. PCU maximum connectivity per logical PCU

PCU1 PCU2

BTS IDs 64 128

Cells/Segments 64 64

TRXs 128 256

Connectivity (traffic channels,16 kbit/s, Abis)

256

PCU1 variants PCU andPCU-S: 128

256

EDAPs 16 16

Figure 27. PCU connections to BTS and SGSN when Frame Relay is used

Refer to Enabling GPRS in BSC for instructions on how to equip andconnect the PCU, and PCU-B and PCU2-D for more information on theplug-in unit hardware.

SGSN

ETs

ETs

ET

DMC bus

PCU

GSWB

Packets in FR

AbisGb

FR: bearer channel + optionalload sharing redundant bearer (2 Mbit/s)

Packets inTRAU frames

4 Mbit/s internal PCM256 channels

DN03299216Issue 9-0 en20/03/2008



Support for PCU2

PCU2 is a high capacity embedded plug-in unit that provides additionalprocessing power and extended functionality from BSS11.5 onwards.Second Generation PCUs have an enhanced design architecture thatenable the network to meet the real time traffic requirements of newservices and provide means to new enhanced functionality (GERAN)beyond GPRS and EGPRS.

There are two PCU2 plug-in unit variants: PCU2-U for BSCi and BSC2iand PCU2-D for BSC3i 660, BSC3i 1000 and BSC3i 2000.

Main hardware improvements when compared to the other PCU plug-inunits used in BSC include:

. more processing capacity:. PQII: from 300MHz to 450 MHz. DSP: from 100MHz to 200MHz

. 16MB External memory for each DSP

. new serial interface between PQII and DSPs

. PCM interface through one serial interface

Internal PCU1 restrictions

. In one logical PCU1 there are 16 digital signal processor (DSP)cores. In a PCU1, one DSP core can handle only one EGPRSdynamic Abis pool (EDAP), but one EDAP can be shared by severalDSP cores.

. In the PCU1s, one DSP core can handle 0 to 20 channels (16 kbit/s),including active EDAP channels, EGPRS channels, and GPRSchannels. The maximum number of 16 kbit/s channels per PCU1 is256.

. All EGPRS channels of one EDGE TRX must be handled in the DSPcore which handles the related EDAP. If an EDAP is handled inseveral DSP cores, the EGPRS channels of one EDGE TRX can bedivided among several DSP cores in a PCU1.

. In PCU1 there is one synchronisation master channel (SMCH) forevery EDAP. Due to DSP restrictions the SMCH must be allocatedon PCUPCM0. To ensure that each EDAP has SMCH candidates onPCUPCM0, the PCU1 reserves a number of subTSLs fromPCUPCM0 exclusively for each EDAP, that is for the EGPRS



channels on the TRXs attached to the EDAP. The PCU1 allocatesthe SMCHs from the beginning of PCUPCM0 and they are usuallyallocated to a different PCUPCM TSL than other EGPRS channels inthe same TRX.

. PCU1 and PCU1-S can handle 128 radio timeslots; the supportedmaximum number of GPRS channels and EGPRS master channelsis 128. The full 256 channel EGPRS connectivity can be reachedwith EGPRS slave channels, in other words, the limitation does notconcern EDAP channels. This issue should be taken into account inPCU dimensioning.


Internal PCU2 restrictions

. In one logical PCU2 there are 8 digital signal processor (DSP) cores.In a PCU2, one DSP core can connect two EGPRS dynamic Abispools (EDAP), but one EDAP can be shared by several DSP cores.

. The nominal capacity of one DSP core of the PCU2 is 40 channels, itcan connect 0 to 40 channels (16 kbit/s), including active EDAPchannels, EGPRS channels and GPRS channels. However, themaximum summary of EGPRS channels and GPRS channels is 32per DSP core, so in order to reach 40 channels there has to be atleast 8 EDAP channels. The maximum number of 16 kbit/s channelsper PCU2 is 256.

. All EGPRS channels of one EDGE TRX must be handled in the DSPcore which handles the related EDAP. In addition, all the channels ofa TRX must be on the same DSP core.

. In PCU2 there is one synchronisation master channel (SMCH) forevery DSP. The PCU2 can allocate the SMCHs to both PCUPCMs 0and 1.

. PCU2 does not support GPRS with Nokia InSite BTS.

DN03299216Issue 9-0 en20/03/2008



Common restrictions for both PCU1 and PCU2

. EDAP resource usage in a PCU dynamically reserves the DSPresources in the PCU. When EGPRS and GPRS calls (TBFs) inEGPRS territory use EDAP resources, allocation of the new packetswitched radio timeslots to the PCU may fail due to the currentEDAP and DSP resource load.

. When new packet switched radio timeslots are added/upgraded tothe PCU, the PCU DSP resource capacity used for the EDAPsdecreases. This may lead to a situation where the desired CS/MCScannot be assigned to the TBFs. In DL direction, the TBFs canadjust the DL data according to limited Dynamic Abis capacity. In ULdirection, the PCU DSP resource load situation may cause asituation in which the UL transmission turns cannot be assigned forthe MSs, for example if adequate UL Dynamic Abis resourcescannot be allocated.

. The EDAP size itself also limits the CS/MCS usage for both DL andUL TBFs.

8.2 Gb interface functionality

The Gb interface is an open interface between the BSC and the SGSN.The interface consists of the Physical Layer, Network Service layer (NS),and the Base Station Subsystem GPRS Protocol (BSSGP).

The Network Service layer further divides into Sub-network Service andNetwork Service Control. The Sub-network Service uses either FrameRelay or UDP/IP based protocol. The layers are briefly described here, buttheir functions are discussed in more detail in Gb interface configurationand state management. For more information on Gb over IP, see Gb overIP in BSC.



Figure 28. Protocol stack of the Gb interface

The BSSGP protocol functions are BSSGP protocol encoding anddecoding, BSSGP virtual connection (BVC) management, BSSGP datatransfer, paging support, and flow control support.

The Network Service Control is responsible for the following tasks:

. NS protocol encoding and decoding

. NS data transfer

. NS Service Data Unit (NS SDU) transmission

. uplink congestion control on Network Service Virtual Connection(NS-VC)

. load sharing between NS-VCs

. NS-VC state management

. GPRS-specific addressing, which maps cells to virtual connections

. Network Service Virtual Link (NS-VL) management

Network Service Control /Network Service Control protocol

Sub-Network Service Control /Sub-Network Service Control protocol

NS

BSS SGSNGb

LLC

BSSGP

NS

L1

RLC

MAC

RELAY

BSSGP

L1

NS

DN03299216Issue 9-0 en20/03/2008



The Frame Relay protocols provide a link layer access between the peerentities. Frame Relay offers permanent virtual circuits (PVC) to transferGPRS signalling and data between the BSC and SGSN.

The Gb interface may consist of direct point-to-point connections betweenthe BSS and the SGSN, or an intermediate Frame Relay network may beplaced between both ends of the Gb interface. In the case of anintermediate Frame Relay network, both BSS and SGSN are treated asthe user side of the user-to-network interface.

In Frame Relay, the physical link is provided by the Frame Relay Bearerchannels. In the BSC this physical connection is a maximum of one 2 Mbit/s PCM for each active PCU. For load sharing and transmission securityreasons, one PCU can have up to four Frame Relay Bearer channels thatare routed to the SGSN through different transmission paths. This meansthat the GPRS traffic from one PCU can be shared with a maximum of fourphysical PCM connections. The PCUs cannot be multiplexed to use acommon bearer.

The maximum combined Bearer Channel Access Rate is 2048 kbit/swithin a PCU. This can be achieved by combining the different PCMs sothat 32 subtimeslots are available for traffic. The step size is 64 kbit/s. TheCommitted Information Rate of Network Service Virtual Connections canbe configured from 16 kbit/s up to the Access Rate of the Bearer channelin 16 kbit/s steps.

In the Nokia implementation each PCU represents only one NetworkService Entity (NSE), unless Multipoint Gb and Packet Control Unit(PCU2) Pooling are used.



Figure 29. Gb interface between the BSC and SGSN when Frame Relay (FR) isused

For more information on the NS and BSSGP protocols, refer to BSC-SGSN Interface Specification, Network Service Protocol (NS) and BSC-SGSN Interface Specification, BSS GPRS Protocol (BSSGP).

For more information on configuring and handling the Gb interface, seeEnabling GPRS in BSC, Frame Relay Bearer Channel Handling, (FU) andFrame Relay Parameter Handling (FN).

8.3 Additional GPRS hardware needed in BSCi andBSC2i

GSWB extension (optional)

The PCU requires the GSWB extension (2 per BSC) for multiplexing the256 Abis sub-timeslots. The second PCU plug-in unit for the BSC requiresan extension of the GSWB with a third SW64B plug-in unit.

BCSU 0

GSWB

FR

PCU

ET

PCM-TSL

bearer channelID=1name=BSC1time slots:1-31access rate:1984 kbit/s

SGSN

BSC

DN03299216Issue 9-0 en20/03/2008



ET5C cartridge (optional)

Additional ET5C cartridges are optional. They are needed to increase theamount of external PCMs, in BSCi from 56 to 88 and in BSC2i from 80 to144. The additional PCMs may be used for Gb over Frame Relay.



9 Radio network management for GPRS

For Radio Network Configuration Management the preconditions are thatthe PCU and Gb interface have been created and configured. In the caseof Frame Relay, the user builds the Gb interface in two phases: first theFrame Relay bearer channels are created, then the NS layer. Beforeenabling GPRS on a cell level, you need to create the Routing Area. SeeActivating and testing BSS9006: GPRS for detailed instructions.

9.1 Routing Area

Mobility management in the GPRS network is handled in a similar way tothe existing GSM system. One or more cells form a Routing Area (RA),which is a subset of one Location Area (LA). The Routing Area is uniquewithin a Location Area. As Routing Areas are served by SGSNs, it isimportant to keep in mind the network configuration plan and what hasbeen defined in the SGSN, before configuring the BSC side. One RoutingArea is served by one SGSN.

When creating a Routing Area the user identifies the obligatoryparameters mobile country code (MCC), mobile network code(MNC), location area code (LAC), and routing area code (RAC).Routing Areas are created in the BSS Radio Network ConfigurationDatabase (BSDATA).

The MCC, MNC, LAC and RAC parameters constitute the routing areaidentification (RAI):

RAI = MCC+MNC+LAC+RAC

The Routing Area and the BTS are linked logically together by the RAI.Routing Areas are used in the PCU selection algorithm which selects aserving PCU for the cell when the operator enables the GPRS traffic in thecell.

DN03299216Issue 9-0 en20/03/2008



Figure 30. Relationship of Routing Areas and PCUs

Optimal Routing Area size

Paging signalling to mobiles is sent, for example, over the whole LocationArea/Routing Area. An optimal Routing Area (RA) is balanced betweenpaging channel load and Routing Area updates. Refer to GPRS radioconnection control for more information on paging.

If the Routing Area size is too large, paging channels and capacity will besaturated due to limited LAPD, Abis or radio interface CCCH pagingcapacity. On the other hand, with a small Routing Area there will be alarger number of Routing Area updates. Paging channel capacity is sharedbetween the paging of the existing GSM users to the Location Areas (LA)and the GPRS users to the Routing Area. Based on the traffic behaviour ofsubscribers and the performance of the network (in terms of pagingsuccess), it is possible to derive guidelines regarding the maximumnumber of subscribers per LA/RA.

The Routing Area dimensioning is similar to the dimensioning of theLocation Area of the existing GSM service. Routing Area dimensioningbalances paging traffic from subscribers and the paging capacity offeredby a given paging channel configuration. The number of pages that aresent by the BTS within an LA/RA indicates the number of mobileterminating calls that are being sent to subscribers in the LA/RA. Thepaging demand thus depends on three factors:

BTS

RA 2

RA n

BTS

BTS

BTS

BTS

BTS

BTS

RA 1

SGSN

BSCLA

PCU 1

PCU 0

PCU 2



. the number of mobile terminating calls

. the number of subscribers in the LA/RA

. paging parameters defined by the operator in the SGSN.

The higher the number of mobile terminating sessions for subscribers inthe Routing Area, the higher the number of pages that have to be sent bythe BTS in the Routing Area. The success of paging, that is the number oftimes that a paging message has to be resent before it is answered, alsohas a profound effect on paging traffic. Paging traffic can thus be observedby means of:

. the number of pages per second per user

. the number of subscribers

. the paging success ratio.

The Nokia infrastructure allows a combined Routing Area and LocationArea paging by implementing the Gs interface between the SGSN andMSC/HLR. An attached GPRS mobile must send a Routing Area Updateto the SGSN each time it changes Routing Area. The SGSN then forwardsthe relevant location area update information to the MSC reducing theRACH and AGCH load. The conclusion is that the signalling load is highlydependent on the parameters. In the same LA/RA, the paging load shouldbe monitored.

Tip

The smallest cell in the LA/RA will set the paging channel limit wherecombined channel structure is in use. Combined channel structure ispossible if the cell is GPRS enabled (Routing Area exists).

9.2 PCU selection algorithm

The PCU selection algorithm in the BSC distributes GPRS traffic capacitybetween PCUs. Traffic is distributed on a cell level when the user enablesGPRS in the cell. The algorithm then selects which PCU takes care of thetraffic of a certain cell.

DN03299216Issue 9-0 en20/03/2008



When GPRS is enabled, each cell is situated in a Routing Area. In theRadio Network, each Routing Area has its own object, to which the userdefines the Network Service Entity Identifiers (NSEI) serving the RoutingArea. The NSEIs are further discussed in Gb interface configuration andstate management. The Nokia implementation is such that one PCUcorresponds to one NSEI (unless Multipoint Gb and Packet Control Unit(PCU2) Pooling are used), and thus it can be said that the function of thePCU selection algorithm is to distribute GPRS traffic capacity betweenthese NSEIs.

The algorithm locates the cells (BVCIs) in the same BCF to the sameNSEI. The algorithm also tries to locate the cells which have adjacenciesbetween each other to the same NSEI. If there are no NSEIs with the sameBCF or with adjacencies then the algorithm selects the NSEI to which thesmallest number of GPRS capable traffic channels, defined with theparameter max GPRS capacity (CMAX), is attached. Traffic channels arecounted on TRXs which are GPRS enabled but not extended or super-reuse TRXs. Only unlocked NSEIs are selected. The NSEI is unlockedwhen it has at least one of its NS-VCs unlocked.

If a Dynamic Abis Pool is defined for a TRX in a cell and when GPRS isenabled for the cell, the same NSEI (PCU) is selected for the cell as for theDynamic Abis Pool. In this case the PCU selection algorithm is not used.

The operator can choose whether the selected NSEI uses IP or FRtransport with the parameter transport type (TRAT). The parametercannot be used with manual NSEI selection. If no transport type isspecified the default is that neither IP nor FR is preferred in the PCUselection algorithm.

The NSEIs can also be selected manually. If manual selection is used thePCU selection algorithm is not used. For more information on manualselection, see Activating and Testing BSS9006: GPRS and BaseTransceiver Station Handling in BSC (EQ).

For information on the PCU selection algorithm when Packet Control Unit(PCU2) Pooling is used, see chapter Functionality of Packet Control Unit(PCU2) Pooling in Packet Control Unit (PCU2) Pooling under Featuredescriptions/Data in the PDF view.



10 Gb interface configuration and statemanagement

The BSC has the following functions in connection with the Gb interface:

. load sharing

. NS-VC management

. NS-VL management (IP)

. BVC management

. recovery.

Only Gb over Frame Relay is covered in these guidelines. For informationon Gb over IP, see Gb over IP in BSC.

For information on Multipoint Gb Interface, see Multipoint Gb Interfaceunder Feature descriptions/Data in the PDF view.

10.1 Protocol stack of the Gb interface

The Gb interface has a protocol stack consisting of three layers: PhysicalLayer, Network Service Layer (NS) and the Base Station System GPRSProtocol (BSSGP). The Network Service Layer further divides into Sub-network Service and Network Service Control. The Sub-network Serviceuses either Frame Relay or UDP/IP protocol.

DN03299216Issue 9-0 en20/03/2008



Figure 31. The protocol stack on the Gb interface

Network Service Virtual Connection (NS-VC)

NS-VCs are end-to-end virtual connections between the BSS and SGSN.The physical link in the Gb interface is the Frame Relay Bearer channel orUDP/IP connection.

In the case of Frame Relay, a NS-VC is the permanent virtual connection(PVC) and corresponds to the Frame Relay DLCI (Data Link ConnectionIdentifier) together with the Bearer channel identifier. Each NS-VC isidentified by means of a Network Service Virtual Connection Identifier (NS-VCI).

Network Service Entity (NSE)

NSE identifies a group of NS-VCs in the BSC. The NSEI is used to identifythe Network Service Entity that provides service to a BSSGP Virtualconnection (BVC). One NSE is configured between two peer NSs. At eachside of the Gb interface, there is a one-to-one correspondence between agroup of NS-VCs and an NSEI. The NSEI has an end-to-end significanceacross the Gb interface at NS level, but only local significance at theBSSGP level. One NSE per PCU is supported and within one NSE amaximum of four NS-VCs are supported.

Network Service Control /Network Service Control protocol

Sub-Network Service Control /Sub-Network Service Control protocol

NS

BSS SGSNGb

LLC

BSSGP

NS

L1

RLC

MAC

RELAY

BSSGP

L1

NS



Network Service Virtual Connection Group

According to the 3GPP standard (TS48.016), the Network Service VirtualConnection Group groups together all NS-VCs providing communicationbetween the same peer NS entities. One NS-VC group is configuredbetween two peer NS entities. This grouping is performed byadministrative means. At each side of the Gb interface, there is a one-to-one correspondence between a group of NS-VCs and an NSEI. The NSEIhas an end-to-end significance across the Gb interface.

BSSGP Virtual Connection (BVC)

BVCs are communication paths between peer NS user entities on theBSSGP level. Each BVC is supported by one NSE and it is used totransport Network Service Service Data Units (NS SDUs) between peerNS users.

Each BVC is identified by means of a BVCI which has end-to-endsignificance across the Gb interface. Each BVC is unique between twopeer NSs.

Within BSS the user identifies a cell uniquely by a BVCI. The BVCI value0000H is used for signalling and the value 0001H is reserved for point-to-multipoint (PTM). PTM is not supported. All other values can be used forcell identifiers.

Link Selector Parameter (LSP)

All BSSGP UNITDATA PDUs related to an MS are passed to NS with thesame LSP. This preserves the order of BSSGP UNITDATA PDUs, sincethe LSP is always mapped to a certain NS-VC. LSP has only localsignificance at each end of the Gb interface.

Frame Relay Permanent Virtual Connection (PVC)

See 10.1.1 Network Service Virtual Connection (NS-VC).

DN03299216Issue 9-0 en20/03/2008



10.2 Load sharing function

The BSC's load sharing function distributes all uplink Network ServiceService Data Units (NS SDUs) among the unblocked NS-VCs within theNSE on the Gb interface. The use of load sharing also provides the upperlayer with seamless service upon failure or user intervention byreorganising the SDU traffic between the unblocked NS-VCs. Whencreating the NS-VC the operator gives a CIR value (bit/s).

The reorganisation may disturb the order of transmitted SDUs. All NSSDUs to be transmitted over the Gb interface towards the SGSN arepassed from BSSGP to NS along with the Link Selector Parameter (LSP).All the NS SDUs of an MS have the same LSP. However, several MSs mayuse the same LSP. NS SDUs with the same LSP are sent on the same NS-VC.

The load sharing functions of the BSC and SGSN are independent.Therefore, uplink and downlink NS SDUs may be transferred over differentNS-VCs. SGSN distributes downlink NS SDUs.

10.3 NS-VC management function

The Network Service Virtual Connection (NS-VC) management function isresponsible for the blocking, unblocking, resetting, and testing of NS-VCs.NS-VC management procedures can be triggered by both the BSC andthe SGSN.

Only one substate (BL-US, BL-SY or BL-RC) is valid at a time when anNS-VC is blocked. The BL-US state overrides both the BL-SY and BL-RCstates. The BL-SY state overrides the BL-RC state. The BL-RC state doesnot override any other blocking state, so it is only possible when the NS-VC is unblocked. An exception is when the NS-VC is in the BL-SY stateand SGSN initiates an NS-RESET. The NS may be reset only when usingFrame Relay. Refer to 10.3.1 NS-VC reset for more information.

Table 52. NS-VC operational states

State Possible substates

Unblocked (WO-EXAvailable)

–



Table 52. NS-VC operational states (cont.)

State Possible substates

Blocked BL-US (unavailable by user)

BL-SY (unavailable by system)

BL-RC (unavailable by remote user)

NS-VC blocking

When an NS-VC is unavailable for BSSGP traffic, the NS-VC is marked asblocked by the BSC and the peer NS is informed by means of the blockingprocedure.

The BSC blocks an NS-VC when:

. the user locks the NS-VC, thus making it unavailable for BSSGPtraffic; the cause sent to SGSN is 'O & M intervention'; operationalstate is BL-US.

. an NS-VC test fails; the cause sent to SGSN is 'Transit networkfailure'; operational state is BL-SY

. Frame Relay detects unavailability of a bearer or PVC; the causesent to SGSN is 'Transit network failure'; operational state is BL-SY

During user block the BSC marks the NS-VC as user blocked, informspeer NSs, and reorganises BSSGP traffic to use other unblocked NS-VCsof the NSE. User-triggered blocking is started only when the PVC or thebearer is available, otherwise the NS-VC is marked as user blocked andthe block procedure is skipped. The BSC cancels any pending NS-VCmanagement procedure and related alarm.

After NS-VC test failure the NS-VC is marked as system blocked, the BSCraises the alarm NETWORK SERVICE VIRTUAL CONNECTION TESTPROCEDURE FAILED (3025) and blocks the NS-VC towards the SGSNthrough any 'live' NS-VC within the NSE, blocked or unblocked. The BSCalso initiates the NS-VC reset procedure. BSSGP traffic is reorganised touse other unblocked NS-VCs of the NSE. If the NS-VC is user blockedwhile reset is attempted, the reset is stopped, the user block is acceptedand the state of the NS-VC is user blocked. The BSC cancels theNETWORK SERVICE VIRTUAL CONNECTION TEST PROCEDUREFAILED (3025) alarm after the next successful test procedure on the NS-VC. If the NS-VC is already user blocked, the BSC does not change the

DN03299216Issue 9-0 en20/03/2008



NS-VC state, it sets no alarms, and sends no block to the SGSN, butinstead initiates the NS-VC reset procedure. After a successful reset, thetest procedure is continued. If the NS-VC reset procedure fails after all theretries, no alarm is set.

After the BSC detects the unavailability of a PVC or a bearer, the relatedNS-VC(s) is marked as system blocked and the BSC blocks it towards theSGSN through any 'live' NS-VC within the NSE, blocked or unblocked. TheBSC sets the NETWORK SERVICE VIRTUAL CONNECTIONUNAVAILABLE (3020) alarm for the blocked NS-VC(s) and reorganisesBSSGP traffic to use other unblocked NS-VCs of the NSE. If the NS-VC(s)is already user blocked, when the unavailability of a PVC or bearer isdetected, the BSC does not change the state of the NS-VC(s), does notset an alarm, and does not send a block to the SGSN, but instead stopsthe NS-VC(s) test. If the NS-VC(s) is already system blocked, the BSCactions are the same but it also stops a possible ongoing reset procedure.

During an SGSN-initiated block, if the NS-VC is not user, system or remoteblocked, the BSC marks the NS-VC as remote blocked, reorganisesBSSGP traffic to use other unblocked NS-VCs of the NSE and sets thealarm NETWORK SERVICE VIRTUAL CONNECTION UNAVAILABLE(3020). If the NS-VC is user, system or remote blocked, then the BSC doesnot change the NS-VC state and acknowledges the received block back tothe SGSN.

In all the above cases, if the blocked NS-VC is the last one in the NSE, itmeans that all BSSGP traffic to/from PCU-managed cells stops on the Gbinterface, and the BSC sends System Information messages to relevantcells indicating that GPRS is disabled. The BSC sets the NETWORKSERVICE ENTITY UNAVAILABLE (3019) alarm when PVC/bearers areunavailable, the SGSN initiates the block, or related BVCs are implicitlyblocked.

NS-VC unblocking

When the NS-VC becomes available again for BSSGP traffic, the peer NSis informed by means of the unblocking procedure, after which the NS-VCis marked as unblocked by the BSC.

The BSC unblocks an NS-VC after:

. user unlocks the NS-VC thus making it available for BSSGP traffic.

. the system initiates a NS-VC reset, for example after a test failedNS-VC is reset or after a reset of a NS-VC whose bearer is resumedas available for NS level.



During user unblock the BSC informs the peer NS and marks the NS-VCas unblocked after receiving an acknowledgement from the peer NS. NewBSSGP traffic now uses this new NS link (refer to 10.2 Load sharingfunction). User triggered unblocking starts only when the PVC or thebearer is available, otherwise the BSC marks the NS-VC as systemblocked and skips the unblock procedure. The BSC sets the NETWORKSERVICE VIRTUAL CONNECTION UNBLOCK PROCEDURE FAILED(3021) alarm and marks the NS-VC unblock as pending until NS-VCunblock can be performed and the alarm is cancelled by the BSC.

During system unblock the BSC cancels the NETWORK SERVICEVIRTUAL CONNECTION UNAVAILABLE (3020) alarm. The BSC does notstart system initiated unblock if the NS-VC is user blocked.

During SGSN initiated unblock, the BSC marks the NS-VC as unblockedand cancels the NETWORK SERVICE VIRTUAL CONNECTIONUNAVAILABLE (3020) alarm if the NS-VC is not user or system blocked. Ifthe NS-VC is user blocked, then the BSC is not able to unblock the NS-VC. The NS-VC remains user blocked and the BSC initiates the NS-VCblocking procedure by returning an NS-BLOCK PDU to the SGSN with thecause "O & M intervention". This NS-BLOCK PDU is sent on the NS-VCwhere the NS-UNBLOCK PDU was received. If the NS-VC is systemblocked with no BSC initiated unblock procedure on, then the BSC is notable to unblock the NS-VC. The NS-VC remains system blocked and theBSC initiates the NS-VC reset procedure by returning an NS-RESET PDUto the SGSN with the cause "PDU not compatible with the protocol state".If the NS-VC is system blocked with a BSC initiated unblock procedure on,then the BSC acknowledges the received PDU back to the SGSN and it isinterpreted as an acknowledgement for the sent NS-UNBLOCK PDU.

In all of the above cases, if the unblocked NS-VC is the first one in theNSE, it means that BSSGP traffic to/from PCU-managed cells can startagain on the Gb interface, and the BSC sends System Informationmessages to relevant cells indicating that GPRS is enabled. The BSCtriggers the BVC reset procedure for signalling BVC and cell-specificBVCs, and cancels the NETWORK SERVICE ENTITY UNAVAILABLE(3019) alarm in cases of system unblock and SGSN initiated unblock.

For more information, see BSC-SGSN Interface Specification, NetworkService Protocol (NS).

NS-VC reset

The NS-VC reset procedure is used to reset an NS-VC to a determinedstate between peer NSs.

DN03299216Issue 9-0 en20/03/2008



Table 53. NS-VC reset cases

Case where the BSC resets an NS-VC Cause sent to the SGSN

The user sets up, modifies or unlocks anNS-VC

O & M intervention

System or BCSU restarts Equipment failure (see 10.5.1 BCSUrestart)

Periodic NS-VC test fails Transit network failure

Frame Relay detects an unavailability of abearer

Transit network failure

During a reset triggered by user unblock, the BSC marks the NS-VC assystem blocked, informs the peer NS, and reorganises BSSGP traffic touse other unblocked NS-VCs of the NSE. After a completed resetprocedure, the BSC starts a test procedure (periodic testing) and aftersuccessful testing unblocks the NS-VC. The BSC starts a reset triggeredby user unblock only when the PVC or the bearer is available, otherwise itmarks the NS-VC as system blocked, skips the reset procedure, and setsthe NETWORK SERVICE VIRTUAL CONNECTION RESETPROCEDURE FAILED (3023) alarm. The BSC sets the NS-VC reset aspending until the NS-VC reset can be performed and then cancels thealarm.

During an SGSN-initiated reset, the BSC marks the NS-VC as remoteblocked and sets the NETWORK SERVICE VIRTUAL CONNECTIONUNAVAILABLE (3020) alarm if the NS-VC is not user or remote blocked. Ifthe NS-VC is user or remote blocked, then the BSC does not change thestate, but acknowledges the received reset back to SGSN and initiates thetest procedure. If the NS-VC is system blocked, then the action dependson whether the NS-VC reset is ongoing or not. If the NS-VC reset isongoing, then the received NS-RESET is interpreted as anacknowledgement and the BSC acknowledges it back to the SGSN andinitiates the test procedure. If the NS-VC reset is stopped, then the BSCchanges the NS-VC state to remote blocked (to get the NS-VC up duringSGSN initiated NS-VC unblock), acknowledges the received reset back tothe SGSN, and initiates the test procedure.

In all the above cases, if the blocked NS-VC is the last one in the NSE, itmeans that all BSSGP traffic to/from PCU managed cells stops on the Gbinterface, and the BSC sends System Information messages to relevantcells indicating that GPRS is disabled. The BSC sets the NETWORKSERVICE ENTITY UNAVAILABLE (3019) alarm in a SGSN initiated resetand blocks the related BVCs implicitly.




NS-VC test

The NS-VC test procedure is used when the BSC checks that end-to-endcommunication exists between peer NSs on a given NS-VC. The user candefine the test procedure with the PRFILE parameter TNS_TEST. Whenend-to-end communication exists, the NS-VC is said to be 'live', otherwiseit is 'dead'. A 'dead' NS-VC cannot be in the unblocked state, instead it isalways marked as blocked and a reset procedure is initiated.

Both sides of the Gb interface may initiate the NS-VC test independentlyfrom each other. This procedure is initiated after successful completion ofthe reset procedure, and is then periodically repeated. The test procedureruns on unblocked NS-VCs and also on user blocked and remote blockedNS-VCs, but not on system blocked NS-VCs, except after NS-VC reset.The test procedure is stopped when the underlying bearer or PVC isunavailable.


10.4 BVC management function

The BVC management function is responsible for the blocking, unblockingand reset of BVCs. The BVC reset procedure can be triggered by both theBSC and the SGSN, but BVC blocking and unblocking procedures canonly be triggered by the BSC.

The user can output the BVC operational state with the command EQO.The possible states are shown in the table below.

Table 54. BVC operational states

Operational state Explanation

WO-EX The BVC is operational.

BL-SY Unavailable by system.

The NSE is not functional, or a radio network object(a TRX, BTS or BCF) is blocked so that the celldoes not have GPRS capability.

DN03299216Issue 9-0 en20/03/2008



Table 54. BVC operational states (cont.)

Operational state Explanation

unblocked Either GPRS has been enabled in the cell and theBVC has been created in the SGSN, but the BVC'sflow control is not yet operational, or the cell has noGPRS TSLs.

BVC conf lost The BVC has not been configured for the PCU, orthe configuration has been lost from the PCU.

This situation can be resolved by disabling, and there-enabling GPRS in the cell, or by executingBCSU switchover.

unknown The enquired BVCI is outside the allowed valuerange, or the PCU does not report the state of theBVC within the time limit because of some faultsituation. In the latter case the user should checkthe status of the PCU.

BVC blocking and unblocking

BVC blocking is initiated by the BSC to remove a BVC from GPRS datause.

Table 55. BVC blocking cases

Case where the BSC blocks a BVC Cause sent to the SGSN

A user disables GPRS in a cell, disables the lastGPRS-supporting TRX in a cell, blocks the BCCHTRX in a cell or deletes a BVC by disabling GPRS ina cell.

O & M intervention

A user or system block of the last NS-VC of the NSEserving the BVC; related BVCs are locally blocked bythe BSC.

No indication is sent to the SGSN.

SGSN initiates a BVC-RESET procedure (ifnecessary).

BVCI-blocked

A cell level fault, for example at the beginning of sitereset, BTS reset or TRX reset.

Equipment failure

BVC unblocking is used only in an exceptional condition when the BSCreceives an unexpected BVC-BLOCK-ACK PDU relating to a BVC that islocally unblocked. The BSC then unblocks the BVC with the BVC-UNBLOCK PDU.



For more information, see BSC-SGSN Interface Specification, BSS GPRSProtocol (BSSGP).

BVC reset

A BVC reset is initiated by the BSC to bring GPRS data into use in a BVC.BVC reset is used instead of BVC unblock because of the dynamicconfiguration of BVCs in the SGSN.

Table 56. BVC reset cases

Case where BSC resets a BVC Cause sent to the SGSN

A user enables GPRS in a cell, enables the firstGPRS-supporting TRX in a cell, deblocks the BCCHTRX in a cell, or creates a BVC by enabling GPRS ina cell.

O & M intervention

A user or system unblock of the first NS-VC of theNSE serving the BVC (signalling BVC is reset first,then the rest).

Network service transmission capacitymodified from zero kbit/s to greater thanzero kbit/s

A cell restart, for example after site, BTS or TRXreset, when the restarted object is working

Equipment failure

With the BVC reset the underlying network service must be available foruse, otherwise the BSC marks the BVC as unblocked in order to get theBVC up and running when the NS-level becomes available again, skipsthe BVC reset procedure, and sets the BSSGP VIRTUAL CONNECTIONRESET PROCEDURE FAILED (3031) alarm. The BSC cancels the alarmafter the next successful BVC block, unblock or reset.


10.5 Recovery in restart and switchover

In a recovery situation the BCSU and PCU are always handled together asa pair. The diagnostics of the PCU is included in the diagnostics of theBCSU. Diagnostics is run automatically, but the operator may also start thediagnostics routine if needed.

DN03299216Issue 9-0 en20/03/2008



BCSU restart

If the Gb interface uses Frame Relay, after user or system initiated BCSUrestart, the BSC recreates the Gb interface on the restarted PCU right afterFrame Relay level set-up. The PCU starts Frame Relay level periodicpolling towards the SGSN. Spontaneous indications come from the SGSNto the BSC's PCU on Frame Relay level about bearer channel availabilityfor NS-VCs.

First all NS-VCs are created, then all BVCs are created after cell-specificblock indications. The PCU maintains only user blocked information of NS-VCs. The NS-VCs which have received DLCIs from the network are resetwhen the bearer channel is available. The PCU sets others as pendingand raises the NETWORK SERVICE VIRTUAL CONNECTION RESETPROCEDURE FAILED (3023) alarm for each NS-VC.

The reset procedure is completed when the PCU receives a suitable DLCIfrom the network, and cancels the alarm. The PCU then initiates the testprocedure on the successfully reset NS-VCs, and after successful testsunblocks all tested NS-VCs, and resets the signalling BVC. Aftersuccessful BVC reset the uplink BSSGP data delivery is possible on thatBVC. After an initial flow control procedure for the BVCs, also downlinkBSSGP data delivery is possible on that BVC. Flow control is discussed inmore detail in GPRS radio connection control.

BCSU switchover

If the Gb interface uses Frame Relay, after BCSU switchover (either useror system initiated), the BSC recreates the Gb interface on the target PCUright after Frame Relay level set-up. The Gb interface configuration is fromthe source PCU and the setting up of the Gb interface is similar to whatwas described in section 10.5.1 BCSU restart.

The BSC does not send NS level blocks from the source PCU in order notto interrupt the BVC configurations of the SGSN.

Forced BCSU switchover

The operation in a forced BCSU switchover is very similar to the operationin a BCSU restart. The PCU releases all PCU PCM connections related tothe restarted PCU. All GPRS data connections will drop after the PCUPCM connections are released.

After the switchover — whether user or system initiated — the BSCunblocks TRXs and delivers new territory to the PCU.



Controlled BCSU switchover

A controlled BCSU switchover is either a user or a system initiated action.The user defines between which BCSUs the switchover is made. Thesystem cancels the switchover command if the execution would lead to asituation where some of the circuit switched calls would drop. If theswitchover is cancelled, the original working BCSU is restored back to theworking state. If a PCU gets faulty the system may initiate the BCSUswitchover.

Tip

Only GPRS data connections that are connected to the PCU arereleased.

In a successful switchover, the BSC moves the control of the workingBCSU/PCU pair to the spare BCSU/PCU pair as in the forced switchover,but data is copied only from the working BCSU to the spare BCSU.Because GPRS data is not copied to the PCU, the PCU sees the data aslost and thus releases all its PCU PCM connections and unblocks itsBTSs. The BSC resets the new spare PCU to the working state, anddefines its new GPRS territory.

If the switchover is cancelled for some reason, the original working PCU isrestored back to the working state, and the BSC resumes GPRS territoryupdatings. The BSC allows new GPRS connection setups in the oldworking PCU again. After an unsuccessful switchover the PCU uses thesame GPRS territory as it had before the switchover. At the end of theswitchover the spare PCU is restarted regardless of the switchover beingsuccessful or not.

DN03299216Issue 9-0 en20/03/2008



11 Radio resource management

GPRS radio resource management in BSC involves two processes:division of radio timeslots between circuit switched and packet switchedtimeslot territories on the one hand, and channel allocation for individualMSs within the PS territory on the other hand.

Division of radio timeslots into territories means that BSC selects the radiotimeslots that shall be used primarily for packet data traffic and which shalltherefore be avoided in traffic channel allocation for circuit switchedservices. During channel allocation for individual MSs PCU assigns PSterritory timeslots for GPRS TBFs.

The radio resource management function which is responsible for the CS/PS territory management also takes care of traffic channel allocation forcircuit switched calls. PCU has its own radio channel allocation that takescare of allocating channels for GPRS TBFs.

Up to seven uplink GPRS TBFs can share the resources of a single radiotimeslot. Uplink and downlink scheduling processes are independent ofeach other, and for downlink up to nine GPRS TBFs can share theresources of a single radio timeslot.

To enable GPRS traffic in a cell, and to initiate the creation of thenecessary PS territory, the operator has to first activate GPRS in the BSCwith the cell-specific parameter GPRS enabled (GENA) and define whichTRXs are capable of GPRS with the parameter GPRS enabled TRX(GTRX). To activate EGPRS, the operator uses the BTS-specificparameter EGPRS enabled (EGENA).

Only after the BSC has an update on the BTS parameters and otherparameters indicating GPRS usage, does it count the number of defaultand dedicated GPRS timeslots in the BTS and select a TRX where it startsto establish the GPRS territory.

DN03299216Issue 9-0 en20/03/2008



The BSC can upgrade or downgrade the number of radio resourcesallocated for GPRS use according to the varying needs of the circuitswitched and GPRS traffic. These procedures are explained in detail in thefollowing sections.

11.1 Territory method

The territory method is the same for GPRS and EGPRS.

The BSC divides radio resources semipermanently between circuitswitched services and GPRS, thus forming two territories. The PCU usesthe GPRS territory resources. The initial territories are formed on a BTS-to-BTS basis according to the operator-defined parameters. The BSC canlater broaden the GPRS territory based on the actual need and accordingto the requests of the PCU.

The circuit switched services have priority over GPRS in channelallocation within common resources. In principle, GPRS releases itsresources as soon as they are needed for circuit switched traffic.

Only Full Rate and Dual Rate traffic channels are GPRS compatible, andwithin a cell only such channels may be configured into the PS territory.GPRS capacity can be divided into three types:

. default GPRS capacity

. dedicated GPRS capacity

. additional GPRS capacity.

GPRS has a predefined set of resources which it can utilise when thecircuit switched load allows. This is referred to as the default GPRScapacity. Part of these default traffic channels can be reserved solely forGPRS and this means they are blocked altogether from circuit switcheduse. This is referred to as dedicated GPRS capacity. The user can modifythese two capacities by using the respective parameters default GPRScapacity (CDEF) and dedicated GPRS capacity (CDED).

Additional GPRS capacity is referred to with radio timeslots that are aboveand beyond the default GPRS capacity and that the BSC has allocated forGPRS use according to the requests of the PCU. GPRS territory size canbe restricted by the user-modifiable parameter max GPRS capacity(CMAX). There is a GPRS territory update guard time defining how oftenthe PCU can request new radio timeslots for GPRS use.



Figure 32. Territory method in BSC

The BSC calculates these defined resources from percentages to concretenumbers of radio timeslots based on the number of traffic channel radiotimeslots (both blocked and working) capable of Full Rate traffic in theTRXs with GPRS enabled (set with the parameter GPRS enabled TRX(GTRX)). The super reuse TRXs (Intelligent Underlay Overlay) and theextended area TRXs (Extended Cell Range) are never included asavailable resources in the GPRS territory calculation. The calculation is asfollows:

. the product of default GPRS capacity (CDEF) parameter andthe number of radio timeslots is rounded down to a whole number.

. if default GPRS capacity (CDEF) parameter value is > 0 but therounded product equals 0, then the territory size 1 is used.

. default GPRS capacity (CDEF) parameter minimum value is 1.

. max GPRS capacity (CMAX) parameter minimum value is 1 (range1–100%).

The BSC starts to create the GPRS territory by first selecting the mostsuitable TRXs in the BTS according to its GPRS capability, TRX type, TRXconfiguration, and the actual traffic situation in the TRX.

The prefer BCCH frequency GPRS (BFG) parameter indicates if theBCCH-TRX is the first or the last choice for the GPRS territory or if it ishandled equally with non-BCCH-TRXs.

TRX 1

TRX 2

BCCH

DefaultGPRS Capacity

DedicatedGPRSCapacity

AdditionalGPRSCapacity

Territory border moves based onCircuit Switched and GPRS traffic load

GPRSTerritory

CircuitSwitchedTerritory

MaxGPRSCapacity

DN03299216Issue 9-0 en20/03/2008



The best candidate for GPRS territory according to the traffic load is theTCH TRX that holds the most idle successive Full Rate-capable (TCH/F orTCH/D) timeslots counted from the end of the TRX (timeslot 7). The GPRStimeslots are always allocated from TSL7 towards TSL0 per TRX. If thereare two or more TRXs that have the same number of idle successive FullRate-capable timeslots, then the TRX containing permanent TCH/Ftimeslots is preferred to one with Dual Rate timeslots to avoid wasting HalfRate capability in the GPRS territory. TRXs with permanent TCH/Htimeslots or multislot HSCSD calls are also avoided, if possible.

Having defined the GPRS capacity share and having selected the bestTRX for GPRS, the BSC next begins a GPRS territory upgrade procedurewhere it allocates the selected radio timeslots of the TRX for GPRS useand informs the PCU.

GPRS territory upgrade

The BSC uses a GPRS territory upgrade procedure to allocate part of theresources for GPRS use. The BSC starts the GPRS territory upgradeprocedure when the user enables GPRS in a BTS.

The number of timeslots given for GPRS use is defined by the operatorwith the parameters dedicated GPRS capacity (CDED), defaultGPRS capacity (CDEF) and max GPRS capacity. All the definedtimeslots cannot necessarily be delivered immediately due to the circuitswitched traffic load of the BTS. However, the BSC fulfils the definedGPRS capacity as soon as possible. After the default capacity (whichincludes also the dedicated part) has been delivered, the PCU can requestmore resources for a GPRS territory upgrade based on the actual needcaused by GPRS use.

Each GPRS territory upgrade concerns timeslots of one TRX; thus anupgrade is a TRX-specific procedure. The BSC performs upgrades ofcontinuous sets of successive timeslots. Starting from the end of the firstTRX in the GPRS territory, the BSC includes in a GPRS territory upgradethe timeslots according to need and availability.

If the GPRS territory cannot be extended to its full size due to a timeslotbeing occupied by circuit switched traffic, an intra cell handover is started.The aim of the handover is to move the circuit switched call to anothertimeslot and clear the timeslot for GPRS use (refer to the figure below).The BSC then continues with the upgrading of the GPRS territory after therelease of the source channel of the handover. If the GPRS territory of aBTS needs more timeslots than one TRX can offer, the BSC selects a newTRX and starts to define the territory.



When the user enables GPRS in a cell, the BSC starts a handover to beable to allocate dedicated GPRS channels, even if the defined margin ofidle timeslots is not met but there is at least one timeslot available.

The BSC starts a handover to move a non-transparent multislot HSCSDcall, but not for a transparent multislot HSCSD call. For a transparentHSCSD call, the HSCSD timeslots are left inside the GPRS territory,although not as actual GPRS channels. The BSC extends the GPRSterritory on the other side of the timeslots reserved for the transparentHSCSD call.

Figure 33. GPRS territory upgrade when a timeslot is cleared for GPRS usewith an intra cell handover

Situations leading to the starting of a GPRS territory upgrade are related toconfiguration and traffic channel resource changes. When the user addsGPRS capable TRXs in a BTS, it results in an increase in the timeslotshare that should be provided for GPRS traffic. The BSC starts the GPRSterritory upgrade procedure when:

. the user enables GPRS in a cell

. the user or BSC unblocks a GPRS enabled TRX thus enabling apending GPRS territory upgrade

. the user or BSC unblocks a radio timeslot inside the GPRS territoryenabling it to be included in the GPRS territory

. the BSC releases a circuit switched TCH/F causing the number ofidle resources in the BTS to increase above a margin that is requiredbefore GPRS territory upgrade can be started

= Circuit Switched territory

= GPRS territory

B S C C C C C

C

C

C C

C

C d d D D D

C C C C

C C C

C

GPRS territory upgrade

B = BCCH TSLS = SDCCH TSLC = Circuit Switched call

Default GPRS capacity (d)= 20%Dedicated GPRS capacity (D) = 10%

DN03299216Issue 9-0 en20/03/2008



. the BSC releases a circuit switched TCH/F beside the GPRSterritory border (as a consequence of handover) so that the pendingGPRS territory upgrade can be performed

. the PCU requests a GPRS territory upgrade.

Other general conditions for a GPRS territory upgrade are:

. previous GPRS territory change in the BTS has been completed

. sufficient margin of idle TCH/Fs in the BTS

. idle GPRS capable resources available in the BTS

. available capacity in the PCU controlling the BTS.

The margin of idle TCH/Fs that is required as a condition for starting aGPRS territory upgrade is defined by the BSC parameter free TSL forCS upgrade (CSU). In fact, the parameter defines how many trafficchannel radio timeslots have to be left free after the GPRS territoryupgrade. When defining the margin, a two-dimensional table is used. Inthe two-dimensional table the columns are for different amounts ofavailable resources (TRXs) in the BTS. The rows indicate a selected timeperiod (seconds) during which probability for an expected downgrade is nomore than 5%. The operator can modify the period with the BSCparameter CSU. The default value for the period length is 4 seconds.

Table 57. Defining the margin of idle TCH/Fs

TRXs 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Timeperiod:0 s

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

1 s 0 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3

2 s 1 1 2 2 2 3 3 3 3 4 4 4 4 5 5 5

3 s 1 1 2 3 3 3 4 4 4 5 5 6 6 6 6 6

4 s 1 2 2 3 4 4 4 5 5 6 6 6 7 7 7 7

5 s 1 2 3 3 4 5 5 5 6 6 7 7 7 8 8 8

6 s 1 2 3 4 4 5 5 6 6 7 7 8 8 8 9 9

7 s 1 2 3 4 5 5 6 7 7 7 8 8 9 9 9 9

8 s 1 3 4 4 5 6 6 7 7 7 8 9 9 9 9 9

9 s 1 3 4 5 5 6 7 7 8 8 9 9 9 9 9 9

10 s 2 3 4 5 6 7 7 8 8 8 9 9 9 9 9 9



The user can define and modify with the parameter GPRS territoryupdate guard time (GTUGT) the guard time, which the PCU has to waitbetween successive requests for GPRS territory configuration updates.The BSC obeys this guard time also when it performs GPRS territoryupgrades to fulfil the operator-defined default GPRS territory.

If the conditions required for a GPRS territory upgrade are not met at thetime the PCU requests a GPRS territory upgrade, the BSC simply doesnothing but updates related statistics. There are three reasons for a GPRSterritory upgrade request being rejected: lack of GPRS radio resources,circuit switched traffic load, and the capacity limit of the PCU unit. In casethe PCU asks for several timeslots in one request and only a part of therequested resources are available, a statistics counter is updated.

In the GPRS territory upgrade, the PCU selects a free circuit from thePCUPCM and the BSC connects it to an Abis circuit. If an error occurswhen connecting the PCUPCM circuit to the Abis circuit, the BSC cancelsthe upgrade and saves information on the detected fault. The BSC initiatesa new GPRS territory upgrade after a guard period.

If two successive connection failures of a PCUDSP circuit with differentAbis circuits occur, the BSC marks the PCUDSP channel as faulty andsets the alarm FAULTY PCUPCM TIMESLOTS IN PCU (3073).

Alarm GPRS/EDGE TERRITORY FAILURE (3273) is set if the territorysize in the BTS is below the limit specified by the BTS specific radionetwork parameter default GPRS capacity (CDEF). The BSC has notbeen able to add more radio channels to the territory within the informingdelay of the alarm.

Additional GPRS territory upgrade

The need for additional GPRS channels is checked when a new TBF isestablished or an existing TBF is terminated. The PCU requests additionalchannels, if a GPRS territory contains less channels than could beallocated to a mobile according to its multislot class, or if the averagenumber of TBFs per TSL is more than 1.5 after the allocation of the newTBF (average TBF/TSL>1.5). These additional channels are requestedonly if all GPRS default channels are already in the GPRS territory.

The number of additional channels the PCU requests is the greater of thefollowing two numbers:

DN03299216Issue 9-0 en20/03/2008



. the number of additional channels needed in the allocationaccording to the MS's multislot class (this criterion is used only whenthe GPRS territory contains fewer channels than the MS is capableof using), and

. the number of additional channels needed for the average number ofallocated TBFs per TSL to be 1 (average TBF/TSL=1).

Example

The GPRS territory consists of one (default) channel and resources shouldbe allocated for a downlink TBF of a multislot class 4 mobile. The PCU firstallocates one channel for the TBF and it requests for (at least) 2 morechannels, as the mobile is capable of using 3 downlink channels. Whenthe PCU receives this additional capacity, the TBF is reallocated to utiliseall channels.

Example

The GPRS territory consists of three channels (one default and twoadditional) and a mobile of multislot class 4 has a downlink TBF of threetimeslots (performing ftp for example). One of the additional channels istaken into CS use, the territory is decreased to two channels, and thedownlink TBF is reallocated to these channels. When the previouslyreserved channel is freed from the CS side, a territory upgrade would bepossible, but nothing happens (no upgrade of the territory), because thesystem only checks for need for upgrade when a new TBF is established.However, if the existing TBF is terminated and a new one is established orif the concurrent uplink TBF is terminated the need and possibility of theterritory upgrade is re-evaluated.

GPRS territory downgrade

The BSC uses a GPRS territory downgrade procedure when it needs toreduce the share of timeslots in the GPRS territory, for example whenthere is an increase in the circuit switched traffic load.

The BSC starts a GPRS territory downgrade procedure when

. the user disables GPRS in a cell

. the user or BSC blocks the TRX that is carrying GPRS traffic

. the user or BSC blocks the timeslot that is carrying GPRS traffic

. the user or BSC blocks circuit switched resources causing thenumber of idle resources in the BTS to decrease below the requiredmargin



. the BSC allocates a traffic channel for circuit switched use causingthe number of idle resources in the BTS to decrease below therequired margin

. the PCU requests for a GPRS territory downgrade

The PCU initiates a GPRS territory downgrade procedure for additionaltype GPRS radio timeslots. This means that the PCU has requested thesetimeslots for GPRS traffic in addition to the default capacity, but the needfor additional timeslots has ceased. If the BSC cannot start a GPRSterritory downgrade at the time the PCU requests it, the PCU has torequest a downgrade again after the territory update guard time hasexpired, if the need for the downgrade still exists.

The operator defines the margin of idle TCHs that the BSC tries tomaintain free in a BTS for the incoming circuit switched resource requestsusing the parameter free TSL for CS downgrade (CSD). If the numberof idle TCH resources in the circuit switched territory of the BTS decreasesbelow the defined margin, a GPRS territory downgrade is started ifpossible. The definition of the margin involves a two-dimensional table.One index of the table is the number of TRXs in the BTS. Another index ofthe table is the needed number of idle TCHs. Actual table items arepercentage values indicating probability for TCH availability during a one-second downgrade operation with the selected resource criterion. Defaultprobability 95% can be changed through the free TSL for CSdowngrade (CSD) parameter.

Table 58. Defining the margin of idle TCHs, %

TRXs 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

TCH0

94 84 76 69 63 58 54 50 48 45 43 41 40 38 37 35

1 99 98 96 93 91 87 85 82 79 77 74 72 70 68 66 64

2 100 99 99 99 98 97 96 94 93 92 90 89 87 86 84 83

3 100 99 99 99 98 98 97 97 96 95 94 94 93

4 100 99 99 99 99 99 98 98 98 97

5 100 100 99 99 99 99

6 100 100 100

7 100 100

8 100%

100%

100%

100%

9 100 100

DN03299216Issue 9-0 en20/03/2008



Additional GPRS territory downgrade

Additional channels are taken into CS use whenever more channels areneeded on the CS side. The need for additional GPRS channels is alwayschecked when an existing TBF is terminated. The PCU requests theremoval of additional channels, if the average TBFs per TSL is less than0.5 (average TBF/TSL<0.5).

11.2 Circuit switched traffic channel allocation in GPRSterritory

The BSC maintains a safety margin of idle traffic channels for circuitswitched traffic by starting a GPRS territory downgrade when the numberof free traffic channels in the circuit switched territory of a BTS decreasesbelow the limit defined by the parameter free TSL for CS downgrade(CSD). Depending on the size of the margin and on the amount of trafficon the BTS, new circuit switched traffic channel requests may come beforethe GPRS territory downgrade procedure has been completed. During asudden burst of traffic channel requests, the BSC may not be able tomaintain the margin with the GPRS territory downgrade procedure and thecircuit switched territory may run out of idle traffic channels.

If the circuit switched territory becomes congested, the BSC can allocate atraffic channel for circuit switched use in the GPRS territory — if there isone not dedicated for GPRS. The BSC first releases the channel in GPRSuse from the PCU and then activates it in the BTS for circuit switched use.

The BSC cannot allocate a traffic channel in the GPRS territory for circuitswitched use, if the radio timeslot in question is involved in a GPRSterritory upgrade procedure that has not been completed yet. In this casethe circuit switched traffic channel request is put in queue to wait for theGPRS territory upgrade to finish. This kind of queuing can be performed ifthe MSC allows it for the request. Traffic channel queuing during GPRSterritory upgrade does not require the normal queuing to be in use in thetarget BTS. The use of the parameter free TSL for CS upgrade (CSU)aims at avoiding collisions between a GPRS territory upgrade and circuitswitched requests.



Multislot traffic channel allocation for an HSCSD call within the GPRSterritory follows the same principles as for single slot requests. A non-transparent HSCSD call is placed inside the GPRS territory only in thecase of total congestion of the CS territory. In that case the HSCSD callcan have one or more TSLs depending on the HSCSD parameters of theBTS in question. A transparent HSCSD call can be allocated partly overthe GPRS territory so that traffic channels for the call are allocated fromboth territories or the whole HSCSD call can be allocated over the GPRSterritory.

Baseband Hopping BTS

The BSC parameter CS TCH allocate RTSL0 (CTR) defines the order ofpreference between the RTSL-0 hopping group and the default GPRSterritory in CS TCH allocation. Value 0 of the parameter means that thedefault GPRS territory timeslots are preferred in CS traffic channelallocation. If no free resources are available in the default GPRS territory,the RTSL-0 hopping group is searched. Value 1 of the parameter meansthat the RTSL-0 hopping group is preferred in CS traffic channel allocation.If no free resources are available in the RTSL-0 hopping group, the defaultGPRS territory is searched.

Load limit calculation

The BSC parameter CS TCH allocation calculation (CTC) defineshow the GPRS territory is seen when the load limits for CS TCH allocationare calculated. Additionally, it defines whether the resources in the GPRSterritory are seen as idle resources or as occupied resources. Value 0 ofthe parameter means that only the resources in the CS territory are takeninto account in load calculations. Value 1 of the parameter means that boththe CS territory resources and the GPRS territory resources (excluding thededicated GPRS timeslots) are taken into account, and the GPRS territoryresources are seen as occupied resources. Value 2 of the parametermeans that both the CS territory resources and the GPRS territoryresources (excluding the dedicated GPRS timeslots) are taken intoaccount, and the GPRS territory resources are seen as idle resources.

11.3 BTS selection for packet traffic

Channel allocation goes through all the following steps, in the orderpresented, in every allocation and reallocation instance. After every step,the list of valid BTSs is relayed to the next step and the BTSs that did notmeet the requirements are discarded.

DN03299216Issue 9-0 en20/03/2008



BTS selection in a segment with more than one BTS

1. Mobile Radio Access Capability (bands)

2. Check maximum TBF/TSL in BTS

3. Signal Level. In case of initial allocation (DL signal level not known), DIRE is

used for ruling out some BTSs. BTS with NBL value greaterthan DIRE is ruled out.

. Reallocation based on signal level is triggered by: (RX_level(BCCH)-NBL<GPL)

. In reallocation between different valid BTSs, NBL is used forcomparing levels and ruling out BTSs. (RX_level(BCCH)-NBL>GPU)

. In reallocation case, if no BTS fullfilling (RX_level(BCCH)-NBL>GPU) is found, the old BTS is selected.

4. Capability and throughput. PCU1 only: Mobile capability (GPRS/EGPRS) vs BTS

capability (GPRS/EGPRS).. PCU2 only: Throughput (Penalty, Qos, BTS throughput factor).

BTS throughput factor takes MS and BTS GPRS/EGPRScapability into account and the BTS providing highest relativethroughput is selected.

5. PCU1 only: Load (Penalty, QoS).

In UL reallocation, the uplink RX level of the TBF in the serving BTS iscompared to GPL to check if the reallocation was triggered by a bad uplinkRX level (uplink RX level < GPL).

If the reallocation was due to bad uplink RX level, or triggered by QualityControl due to service quality degradation (see section 11.6 QualityControl), then the old serving BTS is discarded in the very beginning.

11.4 Quality of Service

The concept of 'Priority Class' is introduced at system level. This is basedon combinations of GPRS Delay class and GPRS Precedence classvalues. Packets having higher 'Priority' are sent before packets havinglower 'Priority'.



ETSI specifications define QoS functionality which gives the possibility todifferentiate TBFs by delay, throughput and priority. Priority BasedScheduling is introduced as a first step towards QoS. With Priority BasedScheduling the operator can give users different priorities. Higher priorityusers will get better service than lower priority users. There will be no extrablocking to any user, only the experienced service quality changes.

The PCU receives the QoS information to be used in DL TBFs from theSGSN in a DL unitdata PDU. In case of UL TBF, the MS informs its radiopriority in an (EGPRS) PACKET CHANNEL REQUEST ((E)PCR) or aPACKET RESOURCE REQUEST (PRR), or an (EGPRS) PACKETDOWNLINK ACK/NACK ((E)PDAN) and this is used for UL QoS.

In the UL direction, the PCU uses the radio priority received from the MS.Exceptions to this rule are GPRS one phase access on CCCH; in this casethe PCU always uses the lowest priority, and EGPRS UL TBFestablishment on CCCH with access cause 'Signalling'; in this case thePCU always uses the highest priority.

The PCU receives the QoS profile information element in the DL unitdata.This IE includes Precedence class information which indicates the priorityof the PDU.

In PCU1 each TBF allocated to a timeslot has a so-called latest (timeslot-specific) service time. In each scheduling round (performed every 20 ms),the TBF with the lowest service time is selected and given a turn to send aradio block (provided that no control blocks have to be sent). Also, thelatest service time of the selected TBF is incremented by the schedulingstep size of the TBF in PCU1. The PCU2 scheduling uses the BucketRound Robin (BRR) algorithm, and there similar behaviour is obtainedusing scheduling weight. See parameter conversion in section BSCparameters of System Impact of Priority Class based Quality of Service.

The sizes of the scheduling steps/weight determine the handing out ofradio resources. If several TBFs have been allocated to a timeslot, thenthe higher the scheduling step size or respectively, the lower thescheduling weight of the TBF, the less often it is selected and given a turn.

Scheduling step sizes/weights depend on the priority class of the TBF. InPCU1, each priority class has its own scheduling step size which isoperator adjustable. The same applies also to PCU2 scheduling weightwhich is operator adjustable.

Priorities are also taken into account in allocations of TBFs. The allocationprocess tries to ensure that better priority TBFs do not gather into thesame radio timeslot.

DN03299216Issue 9-0 en20/03/2008



Priority Based Scheduling in BSC is an operating software product and isalways active in an active PCU.

To get more detailed information about QoS in Gb, see BSC-SGSNinterface description; BSS GPRS protocol (BSSGP).

11.5 Channel allocation and scheduling

GPRS channels are allocated according to the following rules:

. downlink and uplink are separate resources

. multiple mobiles can share one traffic channel, but the traffic channelis dedicated to one MS at a time — this is referred to as temporaryGPRS connection block flow or Temporary Block Flow (TBF) —meaning that one MS is transmitting or receiving at a time; sevenuplink and nine downlink TBFs can share the resources of a singletimeslot; the uplink and downlink scheduling are independent

. channels allocated to a TBF must be allocated from the same TRX

. The traffic channels which would provide the maximum possible(priority based) capacity, within the restrictions of the multislot classof the mobile, are allocated for a TBF. Exceptions are TBFs for whichonly one channel is allocated. In PCU2, channel allocation alsoinvolves other criteria in case EDA is active. For more information onEDA, see Overview of Extended Dynamic Allocation.

. the Medium Access (MAC) mode capability of a mobile affects its ULtransmission capability (within the Multislot Class restrictions).Dynamic Allocation MAC mode allows an MS to use a maximum oftwo UL timeslots; Exended Dynamic Allocation (PCU2) allows anMS to use a maximum of four UL timeslots. MAC mode does notaffect the DL capability of an MS. For more information, see 11.5.1Packet scheduling.

Temporary Block Flow (TBF) is explained in GPRS radio connectioncontrol.

The PCU determines the number of traffic channels that are needed andcounts the best throughput for that number of traffic channels. In PCU1 thetraffic channel combinations are first compared by QoS load, then bycapacity type (additional < default < dedicated) and then by the PacketAssociated Control Channel (PACCH) load. The QoS load of a channel is



defined as a weighted sum of the TBFs in the channel. The weights usedcorrespond with the scheduling rate of the QoS class of TBFs in thechannel. In PCU1 the PACCH load is the number of TBFs using a certainTCH as PACCH. PACCH is defined in more detail in GPRS radioconnection control. In PCU2 the PACCH load is monitored by thescheduler and that is used together with the scheduling weights when therelative throughput of the channel combination is estimated. The trafficchannel combinations are first compared by relative throughput and thenby capacity type (additional < default < dedicated). Furthermore in PCU2,a comparison of estimated throughputs is carried out between DA (max.two slots) and EDA (max. four slots) connections in uplink. For moreinformation, see Functionality of Extended Dynamic Allocation in ExtendedDynamic Allocation in BSC.

Higher priority TBFs will get more turns, therefore they will cause moreload on the channel.

TBF allocation

After the BTS has been selected, QoS and TBF type are comparedsimultaneously. Different QoS classes result in different penalties for loadcomparing. Multiplexed and non-multiplexed TSLs are also prioritised by apenalty value. Among multiplexed TSLs, QoS is the selection criteria. Inaddition, the PCU monitors PACCH load (in other words signalling load) inTSLs and takes that into account in allocation.

If there are both GPRS and EGPRS TBFs allocated in the same BTS, thePCU1 tries to avoid allocating the GPRS and EGPRS TBFs into the sametimeslots because it would dramatically worsen the throughput of EGPRSTBFs. In PCU2 implementation multiplexing is taken into account whencomparing different allocations and residual capacity provided by them. InPCU2, channel allocation does not involve special procedures for pickingout resources which would not lead to multiplexing. Instead, channelallocation penalties are applied to allocations which would result inmultiplexing, and then the allocation which is estimated to provide the bestthroughput is chosen without further selection between multiplexed andnon-multiplexed connections.

If we would like to allocate a new EGPRS TBF into a TRX, the channelallocator would see the TRX as follows: the timeslots where there alreadyare some GPRS TBFs allocated would not look very attractive for thisallocation, because the EGPRS TBF throughput would be reduced inthose timeslots due to multiplexing.

DN03299216Issue 9-0 en20/03/2008



When optimum resources for a mobile are searched for, both UL and DLresources are evaluated and the decision for the allocation is madedepending on the amount of effective resources received in bothdirections. If a mobile is using only one direction (UL or DL), only theresources of the direction used are evaluated. If the mobile beingevaluated already has an existing TBF in one direction and it requiresresources from the other direction, the evaluation of concurrent resourcesreceived is first done for the adjoining allocation beside existing allocationand then for different concurrent reallocations, where existing TBF isreallocated from its current allocation. In PCU2, however, no preference isgiven to adjoining allocations when concurrent TBF is being created.

Channel combination in concurrent allocation is determined from operatormodifiable parameters CHA_CONC_UL_FAVOR_DIR andCHA_CONC_DL_FAVOR_DIR. If DL TBF exists and UL TBF is allocated asconcurrent, CHA_CONC_UL_FAVOR_DIR defines the direction that shouldbe preferred in allocation. Respectively, when allocating DL TBF asconcurrent, CHA_CONC_DL_FAVOR_DIR defines the preferred direction.These parameters have three values - favour UL, favour DL and shareresources - which result in different emphasis in resource division betweenUL and DL.

During concurrent TBFs the PCU monitors the traffic, and PCU usesreallocations to modify the timeslot configuration to give preference to thedirection with more traffic. The preferred direction affects the configurationwhen the MS multislot class allows different UL/DL timeslot combinations.If effective resources received in the adjoining allocation are the same aswith concurrent reallocation, the adjoining allocation is preferred. In theevaluation of the resources, dedicated and default territory areas arepreferred, so if similar resources are found from the additional and defaultterritory, resources from the default area will be allocated.

Example

The GPRS territory consists of three channels, and an MS of multislotclass 4 has a downlink TBF of three timeslots (performing FTP forexample) and also uses an uplink TBF of one timeslot to acknowledge thereceived data (Note that the UL TBF is not always present as it is notalways needed). A second mobile of multislot class 4 requests ULresources. These will be allocated to it and the optimum resources areevaluated for the UL direction only. As a result, the second MS gets its ULresource from a channel that is not used by the first mobile.

TSL 0 1 2 3 4 5 6 7

DEF DEF DEF

UL MS1 MS2



DL MS1 MS1 MS1

Example

Continuing from the previous example, downlink resources are needed forthe second mobile. Available resources are evaluated for both directionsand the allocation is made in such a way that optimum resources are usedin both directions. Now the allocation depends on the resource usage ofMS1 in both UL and DL directions.

1. A concurrent allocation for the DL TBF is made for MS2 if MS1 hasan UL TBF in use when the DL TBF of MS2 is allocated. Theadjoining allocation is made, because the reallocation does notprovide any better resources for MS2 in this phase.

TSL 0 1 2 3 4 5 6 7

DEF DEF DEF

UL MS1 MS2

DL MS1 MS1

MS2

MS1

MS2

As a result, MS1 has the resources of 3 effective timeslots (the totalsum of UL and DL resources) and MS2 has the resources of 2effective timeslots. If MS2 had been allocated in the same way asMS1 (with re-allocation), it would have resulted in both MSs havingonly 2 effective timeslots (the total sum of UL and DL resources).MS2 does not receive the maximum number of timeslots in the DLdirection in this phase, but it will receive them later, when the territoryupgrade has been completed.

In case of PCU2, the allocation is made according to multislot classcapabilities. In other words, adjoining allocation with fewer channelsthat multislot class allows is not made. If the favoured direction is setto favor DL, 3+1 allocation is reserved for MS2. As a result, MS2 isallocated similarly to MS1.

TSL 0 1 2 3 4 5 6 7

DEF DEF DEF

UL MS1

MS2

DN03299216Issue 9-0 en20/03/2008



DL MS1

MS2

MS1

MS2

MS1

MS2

In case of PCU, if the favoured direction is UL, 2+2 allocation ismade.

TSL 0 1 2 3 4 5 6 7

DEF DEF DEF

UL MS1

MS2

MS2

DL MS1 MS1

MS2

MS1

MS2

2. DL resources for MS2 are given with reallocation if MS1 does nothave a UL TBF in use when the DL TBF of MS2 is allocated. Thereallocation is made, because better resources are achieved with it.

TSL 0 1 2 3 4 5 6 7

DEF DEF DEF

UL MS2

DL MS1

MS2

MS1

MS2

MS1

MS2

In this allocation, MS1 has the resources of 1.5 effective timeslots(the total sum of UL and DL resources) and MS2 has the resourcesof 2.5 effective timeslots.

Then the PCU would request a territory upgrade according to therules explained in the section 11.1.1 additional GPRS territoryupgrade (in case a, two channels will be requested and in case b,three channels will be requested).

Example

Continuing from the previous example, the PCU has received theadditional capacity it has requested and the reallocation of the TBF(s) willbe made. As a result, the following allocations will be made:



1. Both mobiles will get 2.5 timeslots in the DL direction and 1 timeslotin the UL direction.

TSL 0 1 2 3 4 5 6 7

ADD ADD DEF DEF DEF

UL MS2 MS1

DL MS2 MS2 MS1

MS2

MS1 MS1

2. Both mobiles will get 3 timeslots in the DL direction and 1 timeslot inthe UL direction.

TSL 0 1 2 3 4 5 6 7

ADD ADD ADD DEF DEF DEF

UL MS2 MS1

DL MS2 MS2 MS2 MS1 MS1 MS1

After the TBF is created in a BTS

When a GPRS TBF is in a multiplexed TSL, PCU1 will constantly check:

1. if the channel is multiplexed

2. if it is the only GPRS TBF in the TSL thus causing multiplexing

3. if there are multiplexed channels where it is allowed to reallocate

In PCU2, allocation is done to achieve the highest possible relativethroughput. Consequently, the above mentioned checks do not apply sincethere is no attempt to remove multiplexing and USF Granularity 4 is used.

In addition, PCU constantly checks if reallocation should take place toachieve better relative capacity. Reallocation check interval is determinedby operator modifiable parameter TBF_LOAD_GUARD_THRSHLD. Theparameter defines reallocation check interval for a TBF in block periods.

The PCU requests for more additional channels, if a GPRS territorycontains less channels than what could be allocated to a mobile accordingto its multislot class. These additional channels are requested only if allGPRS default channels are already in the GPRS territory. The maximumnumber of GPRS channels is limited by CMAX.

DN03299216Issue 9-0 en20/03/2008



When ensuring the best quality and speed for end-users, planning may notrely on additional channels in the dimensioning of the GPRS territory. Theuse of additional channels is less efficient compared to the defaultchannels. The reason for this is that the additional channels (territoryupgrade) are always requested from circuit-switched (CS) territory andthere is always some delay before the channel is moved to the GPRSterritory. For example, there can be a CS call in the timeslot, which is to bemoved to the GPRS territory, and intracell handover is needed before theterritory upgrade can be completed.

Additional channels are taken into CS use whenever more channels areneeded on the CS side. The need for additional GPRS channels is alwayschecked when an existing TBF is terminated. The PCU requests theremoval of additional channels, if the average TBF/TSL is less than 0.5(average TBF/TSL<0.5). The target in the downgrade is to achieve anaverage TBF/TSL equal of 1.

When there is an EGPRS downlink TBF and a GPRS uplink TBF in theTSL, the MCS is limited to 1-4 (GMSK) whenever there is USF signalling tothe GPRS TBF. In PCU2, USF Granularity 4 is used in such cases,meaning that one block carrying USF signalling to GPRS TBF assigns atransmission turn to GPRS TBF for four consecutive UL radio blocks.There will also be a CS-coded downlink block every 360 ms forsynchronisation purposes for GPRS MSs.

Packet scheduling

Uplink and downlink scheduling are independent of each other. The PCUcan assign multiple MSs to the same uplink traffic channels. ETSIspecifications allow the scheduling of uplink transmission turns to be doneby two different Medium Access Control (MAC) modes: DynamicAllocation (DA) and Extended Dynamic Allocation (EDA). The BSCreleases from S9 onwards support Dynamic Allocation, and releases fromS12 onwards also support Extended Dynamic Allocation (PCU2 only).

In DA and EDA, the BSC gives the MS a USF value for each assignedtraffic channel in the assignment message. The MS monitors the downlinkRadio Link Control (RLC) blocks on the traffic channels it has beenassigned. Whenever the MS finds the USF value in the downlink RLCblock, it may send an uplink RLC block in the corresponding uplink frame.The scheduling of the RLC data block in each timeslot is independent ofother timeslots. DA allows an MS to use a maximum of two timeslots in UL.Radio Link Control is defined in more detail in GPRS radio connectioncontrol.



Figure 34. Dynamic Allocation MAC mode

EDA allows an MS to use more than two uplink timeslot by removing theneed of detecting USFs separately for each assigned traffic channel: areceived USF gives the MS a permission to send, during the nexttransmission turn, on the corresponding UL channel and on all thefollowing channels of the UL TBF.

Figure 35. Extended Dynamic Allocation MAC mode

Scheduling in PCU1 is based on a kind of weighted round robin (WRR)method, which means that a higher priority (QoS) Temporary Block Flow(TBF) gets a bigger share of the PDTCHs allocated for it than a lowerpriority TBF.

Scheduling in PCU2 is based on a Bucket Round Robin (BRR) algorithm.In addition, PCU2 uses USF granularity 4 for GPRS TBFs in EGPRS BTSto reduce the negative impact of EGPRS/GPRS multiplexing. USFgranularity 4 is only used with DA, not EDA. The main difference to PCU1WRR algorithm implementation is that BRR distributes transmission turnsper MS and not per TCH as WRR in PCU1 implementation. Both WRR andBRR distribute capacity according to connection specific schedulingweights.

See 11.4 Quality of service for more information on adjusting weight inpriority based QoS.

0 1 2 3 4 5 6 7

0 1 2 3 4 5 6 7

T T

USF USF

0 1 2 3 4 5 6 7

USF

0 1 2 3 4 5 6 7

T T T

DN03299216Issue 9-0 en20/03/2008



Extended Uplink TBF mode

Extended UL TBF mode is an optional functionality.

If the MS supports Extended UL TBF Mode (indicated in MS RAC), thenormal uplink release is delayed. The delay time is operator adjustablewith parameter UL_TBF_REL_DELAY_EXT. During delay time MS is inextended mode. In extended mode network schedules USFs to MS withlower scheduling rate. If MS in extended mode has data to send data itreturns to normal mode. For more information, see Data transfer.

Scheduling in extended mode for an uplink TBF is based on operatormodifiable parameters UL_TBF_SCHED_RATE_EXT in PCU1 andPOLLING_INTERVAL in PCU2. In PCU1, UL_TBF_SCHED_RATE_EXTdefines the next block period when a TBF in extended mode is given atransmission turn. However, a TBF in extended mode cannot have betterresidual capacity than it would in normal mode. In PCU2,POLLING_INTERVAL defines the time in block periods that TBF inextended state cannot have transmission time. After POLLING_INTERVALis elapsed, TBF is returned to scheduling and once it is scheduled it isrestricted again unless it is returned to normal mode.

Dynamic Scheduling for Extended UL TBF Mode

In PCU2, Dynamic Scheduling for Extended UL TBF Mode optimises thescheduling algorithm applied to mobile stations in extended uplink TBFmode (EUTM). When any of the uplink TSLs which can be used for pollingan MS in EUTM accommodates more than one UL TBF, thePOLLING_INTERVAL parameter defines the frequency of UL transmissionturns scheduled for the MS in EUTM. When none of the uplink TSLs whichcan be used for polling an MS in EUTM accommodates more than one ULTBF, the POLLING_INTERVAL_BG_LOW parameter defines the frequencyof UL transmission turns scheduled for the MS in EUTM. This methodhelps to improve the RTT performance for MSs in EUTM under light ormoderate traffic density without affecting adversely the radio throughput ofother users.



11.6 Quality Control

The purpose of Quality Control is to monitor and detect degradationperiods in service quality, and to perform corrective actions to remove theservice degradation. The possible actions include TBF reallocation andNetwork-Controlled Cell Re-selection. Monitoring of degradation in servicequality includes BLER and bitrate per radioblock monitoring.

The PCU monitors bitrate per radio block for each TBF in RLC ACK mode,for UL and DL separately. When the PCU sends or receives a radio block,it updates the number of bits transmitted/received in the radio block. ThePCU ignores LLC dummy blocks in this calculation. For theretransmissions, the PCU shall calculate the number of bits transmitted aszero.

The PCU calculates the bitrate per radio block value and checks it againstthe corresponding threshold value. The threshold values are operatorparameters and there is a separate value for UL and DL, as well as forGPRS and EGPRS, respectively: QC GPRS DL RLC ack throughputthreshold (QGDRT), QC GPRS UL RLC ack throughput threshold(QGURT), QC EGPRS DL RLC ack throughput threshold (QEDRT)and QC EGPRS UL RLC ack throughput threshold (QEURT). If thecalculated value is below threshold, degradation duration time isincreased. The PCU monitors the bitrate per radio block degradationduration counter. If the counter is larger than predefined triggering levels,the corresponding corrective action is performed.

The PCU monitors also RLC Block Error Ratio (BLER) for each TBF. TheBLER value shall be checked against the required maximum BLER. InPCU1, maximum BLER is defined by operator parameter maximum BLERin acknowledged mode (BLA) or maximum BLER inunacknowledged mode (BLU), depending on the RLC mode of theTBF. In PCU2, maximum BLER is defined by operator parameters PFCACK BLER limit (ABL1) and PFC UNACK BLER limit (UBL1). If BLERis above maximum, degradation duration time is increased and if thecounter is larger than predefined triggering levels, the correspondingcorrective action is performed.

When any of the degradation duration counters monitored by the PCU getslarger than a predefined action trigger threshold, the PCU shall perform acorresponding corrective action. Each action shall be triggered only oncefor a TBF in PCU. For example, if reallocation is already done, the nextaction to be performed is Network-Controlled Cell Re-selection (NCCR),triggered when a degradation duration counter exceeds the NCCR triggerthreshold. The flags of already performed actions are cleared when thedegradation ends, that is when all the degradation duration counters arecleared.

DN03299216Issue 9-0 en20/03/2008



The action trigger thresholds are expressed in block periods and thevalues can be set by operator (see parameter QC Action TriggerThreshold). It is possible to change the order of different actions bymodifying the action trigger threshold values. If two or more actions are setto the same threshold value, the order of actions is first reallocation andthen NCCR. Although possible, it is not recommended to set the valuesvery close to each other, for example reallocation 100, NCCR 101.Otherwise, there is no time to execute the triggered action before the nextis already triggered. The default action trigger threshold values are shownbelow.

Action Block periods

Reallocation 25

NCCR (*) 100

(*) Applicable if NCCR is activated.

11.7 MS Multislot Power Reduction (PCU2)

When multiple timeslots have been assigned to an uplink TBF, the mobilestation may reduce its transmission power as a function of the number ofthese timeslots: the more UL timeslots assigned, the larger thetransmission power reduction applicable. This power reduction helps theMS to meet radiation regulations and to avoid heating problems.

Every mobile station (Rel 5 or later) conforms to one of four standardisedMultislot Power Profiles (0-3), which determine the maximum output powersupported by an MS for different ULTBF configurations. An MS of MultislotPower Profile 3 does not apply power reduction to connections of four ULtimeslots and less, while the amount of applicable reduction increases witheach lower Power Profile.

The effect of Multislot Power Reduction needs to be observed in radioresource allocation because the output power of an MS contributes toradio path quality, and consequently affects both the choice of the channelcoding scheme to be used (CS1-CS4; MCS1-MCS9) and the achievablethroughput per timeslot within the chosen scheme. In other words, largepower reduction leads to poorer radio path quality, which in turn decreasesthroughput per timeslot both by necessitating robust channel coding andby increasing the number of transmission errors and retransmissions.



In resource allocation, the effect of power reduction is observed by usingUL signal quality measurements by the BTS to determine the maximumnumber of UL timeslots that can be assigned to the MS and still keep thesignal quality at an acceptable level in spite of the entailing transmissionpower reduction.

Multislot power reduction is applicable to all multislot UL connections. IfEDA is enabled, up to four timeslots may be assigned to an ULTBF. If EDAis not enabled, up to two timeslots may be assigned in UL.

UL signal quality and the maximum number of timeslots

If the MS UL signal quality (GMSK Mean BEP or RX Quality measured bythe BTS) is known during radio resource allocation, which is normally thecase during two-phase access, the PCU uses this information to determinethe maximum number of UL timeslots that may be allocated for the MS.The PCU uses the signal quality measurement that is available, buttypically Mean BEP is used with EGPRS connections or if Dynamic Abis issupported, and RX Quality is used in other cases.

The operator can define the signal quality limits for different UL timeslotconfigurations by modifying the Mean BEP Limit and RX Quality Limitparameters. In determining these limits, the appropriate signal quality - astypically required by applications used in the network - must be consideredtogether with the power reduction characteristics of different mobilestations. The limits should be set so that the signal quality remainsacceptable even when the MS applies maximum power reduction. Thefollowing tables define the default values for the two signal quality limits(for Rel 5 mobiles and later).

Table 59. GMSK Mean BEP Limit for UL

MAX Numberof UL TSLs

MS MultislotPowerProfile 0

MS MultislotPower Profile1



1 — — — —

2 21 20 — —

3 26 25 24 —

4 30 30 29 —

For instance, three UL timeslots may be assigned to a Multislot PowerProfile 1 MS if the measured GMSK Mean BEP value is 25 or higher.

DN03299216Issue 9-0 en20/03/2008



Table 60. RX Quality Limit for UL

MAX Numberof UL TSLs

MS MultislotPower Profile0




1 — — — —

2 5 5 — —

3 3 3 3 —

4 1 1 2 —

For instance, three UL timeslots may be assigned to a Multislot PowerProfile 1 MS if the measured RX Quality is three or lower.

If no Multislot Power Profile has been defined for an MS (Rel 4 or earlier) orthe Profile is not known by the PCU for some other reason, the PCUhandles the MS according to Power Profile 0.

When an UL TBF is reallocated to another BTS, where the mobile stationspecific GMSK Mean BEP and RX Quality measurements are notavailable for the MS, the maximum number of timeslots that can beassigned to the reallocated connection is determined on the basis of thegeneral RX level in the new BTS. This is done by checking what number oftimeslots - considering the Multislot Power Profile of the MS - would allowat least the same average RX level to be achieved under the new BTS asunder the old one.

11.8 Error situations in GPRS connections

Synchronisation errors

When the PCU detects a synchronisation error between itself and theBTS, the BSC downgrades the related channels from GPRS use. TheBSC upgrades the radio timeslots back to GPRS use after a guard period.

Traffic channel activation failures

The BSC sets the alarm TRAFFIC CHANNEL ACTIVATION FAILURE7725 if the Abis synchronisation for an GPRS traffic channel repeatedlyfails. The alarm is automatically cancelled when the synchronisationsucceeds and the channel is taken back into GPRS use.



(E)GPRS Inactivity (Sleeping BTSs)

The BSC sets the alarm NO (E)GPRS TRANSACTIONS IN BTS 7789 ifthere have been no normal TBF releases within the supervision period in aBTS where this alarm is enabled, although there have been allocation TBFattempts.

To enable this alarm functionality in the BSC, you define the triggeringcriteria, length of the supervision period and traffic threshold. Therecommended triggering criteria is the lack of normal TBF releases both inUL and DL, but you may choose to monitor only one of the directions. Thelength of the supervision period shall be defined according to estimatedtraffic density, recommended values ranging from 15 minutes (default) to60 minutes. Traffic threshold means the required number of TBF allocationattempts per hour, to ensure that the alarm is not raised due to low trafficvolume. Default value for traffic threshold is 10 TBF allocation attempts perhour.

The BSC level configuration of this alarm is done by modifying thefollowing parameters with the MML command EEJ:

EGIC=<EGPRS Inactivity Alarm criteria>

0x00: Alarm disabled on BSC Level (default)

0x01: No normal UL TBF releases

0x02: No normal DL TBF releases

0x03: No normal UL TBF releases and no normal DL TBF releases (recommended)

IEPH=<Required number of TBF allocation attempts per hour>

Default: 10

Range: 0 ... 255

SPL=<Supervision period in minutes>

Default: 15 minutes

Range: 0 ... 1440 minutes

The alarm also needs to be enabled on the BTSs, which will be monitored.This is done by configuring the related BTS level parameters. Although thesupervision period length is common for all BTSs within a BSC, thesupervision periods (weekdays and hours) can be defined separately foreach BTS.

The BTS level configuration of this alarm is done by modifying thefollowing parameters with the MML command EQV:

DN03299216Issue 9-0 en20/03/2008



EAW = <(E)GPRS Inactivity Alarm weekdays (bitmask)>

Default: 00000000b (alarm disabled in BTS)

Examples: 01000000 (Monday)

00100000 (Tuesday)

01111100 (Monday thru Friday)

01111111 (Every day)

EAS = <(E)GPRS Inactivity Alarm start time (hours-minutes)>

Default: 08-00

Range: 00-00 ... 23-45

EAE = <(E)GPRS Inactivity Alarm end time (hours-minutes)>

Default: 18-00

Range: 00-00 ... 23-45

The alarm is set if the criteria is met at the end of the supervision period.The criteria is that no normal TBF releases have been detected within a 15minute (default) period during the hours when the alarm is active on thegiven weekdays, and there have been at least the required number of TBFallocation attempts.

The alarm is cancelled if a normal TBF release is detected within thesubsequent supervision periods. Note that the cancellation is notdependent on the setting criteria, but a normal TBF release in eitherdirection cancels the alarm.



12 GPRS/EDGE radio connection control

Radio channel usage when GPRS is in use is discussed in this section.The GPRS radio connection establishment (TBF establishment) and datatransfer are described from the point of view of a mobile terminating (MT)and mobile originating (MO) GPRS TBF. Paging is described in a sectionof its own. This section describes the BSC's functions in relation tosuspend and resume, flush, coding scheme selection, as well as trafficadministration and power control in GPRS. Cell selection and re-selectionare also defined.

12.1 Radio channel usage

ETSI specifications (05.02) define the possibility to use dedicatedbroadcast and common control channels for GPRS.

System information messages on BCCH

The support of GPRS is indicated in a SYSTEM_INFORMATION_TYPE_3message. GPRS-specific cell parameters are sent to the MS in aSYSTEM_INFORMATION_TYPE_13 message.

For more information refer to GSM Specification (04.18).

Common Control Channel (CCCH) signalling

The Common Control Channel (CCCH) signalling is used for paging anduplink and downlink temporary block flow (TBF) setup.

GPRS paging is made on the Paging Channel (PCH). The MS initiatesuplink TBF establishment on the Random Access Channel (RACH). Thenetwork responds to the MS on the Access Grant Channel (AGCH).Network-initiated TBF establishment is done on the AGCH.

DN03299216Issue 9-0 en20/03/2008



Packet Data Traffic Channel (PDTCHs)

The Packet Data Traffic Channel (PDTCH) is a channel allocated for datatransfer. It is temporarily dedicated to one MS. In multislot operation, oneMS may use multiple PDTCHs in parallel for individual packet transfer. AllPDTCHs are uni-directional, either uplink (PDTCH/U) for a mobileoriginated packet transfer or downlink (PDTCH/D) for a mobile terminatedpacket transfer. PDTCH/U and PDTCH/D can be assigned to an MSsimultaneously. In the Nokia implementation, traffic channels belonging toa GPRS territory are PDTCHs and traffic channels belonging to circuitswitched territory are TCHs. The PCU uses each radio timeslot which theBSC has allocated for the GPRS territory, as one PDTCH. GPRSterritories are described in Radio resource management.

Packet Associated Control Channel (PACCH)

The Packet Associated Control Channel (PACCH) conveys signallinginformation related to a given MS. The signalling information includes, forexample, acknowledgements and resource assignment and reassignmentmessages. One PACCH is associated to one or several traffic channelsthat are assigned to one MS. PACCH is a bi-directional channel. It can beallocated on both uplink and downlink regardless of whether thecorresponding traffic channel assignment is for uplink or downlink.Assigned traffic channels are used for PACCH in the direction the data issent. In the opposite direction the MS multislot capability has to be takeninto account when allocating the PACCH.

12.2 Data Transfer Protocols and Connections

Temporary Block Flow (TBF)

Temporary Block Flow (TBF) is a physical connection used by two radioresource entities to support the unidirectional transfer of Logical LinkControl (LLC) PDUs on packet data physical channels. The TBF isallocated radio resources on one or more PDTCHs and comprises anumber of RLC/MAC blocks carrying one or more LLC PDUs. A TBF isidentified by a Temporary Flow Identity (TFI) and maintained only for theduration of the data transfer.



Logical Link Control (LLC) and Radio Link Control (RLC)

The Logical Link Control (LLC) layer provides a highly reliable cipheredlogical link. LLC is independent of the underlying radio interface protocolsin order to allow introduction of alternative GPRS radio solutions withminimum changes to the NSS. LLC PDUs are sent between the MS andthe SGSN.

The Radio Link Control (RLC) function provides a radio-solution-dependent reliable link. RLC blocks are sent between the MS and the BSC(PCU). There are two RLC modes: acknowledged and unacknowledgedmode. The latter does not have retransmission.

In downlink data transmission, the PCU receives LLC PDUs from theSGSN, segments them to the RLC blocks and sends the RLC blocks to theMS. The LLC PDU is buffered in the PCU until it has been sent to the MSor discarded.

In uplink data transmission, the PCU receives the RLC data blocks fromthe MS and reassembles them into LLC PDUs. When the LLC PDU isready, the PCU sends it to the SGSN and releases it from the PCU buffer.The LLC PDUs have to be sent to the SGSN in the order they weretransmitted by the MS.

12.3 Paging

The network may provide co-ordination of paging for circuit switchedservices and GPRS depending on the network operation modessupported.

Network operation modes

The BSC supports network operation modes I and II. Mode I requires Gsinterface between the SGSN and MSC/HLR.

In mode II circuit switched paging messages are transferred through the Ainterface from the MSC to the BSC. In mode I circuit switched pagingmessages are routed through the Gb interface for GPRS-attachedmobiles. GPRS pages always come from the SGSN through the Gbinterface.

DN03299216Issue 9-0 en20/03/2008



The network operation mode is indicated as system information tomobiles, and it must be the same in each cell of a Routing Area. Based onthe provided mode, an MS can choose (according to its capabilities)whether it attaches to GPRS services or to non-GPRS services, or to both.

Table 61. Supported Network Operation Modes

Mode Circuit PagingChannel

GPRS PagingChannel

Gb interface Paging co-ordination

I CCCH CCCH Yes Yes

I Packet DataChannel

N/A Yes Yes

II CCCH CCCH No No

GPRS paging

The SGSN initiates the GPRS paging process. It sends one or morePAGING_PS_PDUs messages to the BSC (PCU). These PDUs containthe information elements necessary for the BSS to initiate paging for anMS within a group of cells at an appropriate time. The BSC translates theincoming GPRS and circuit switched paging messages into onecorresponding Abis paging message per cell. A GPRS paging message issent only to cells that support GPRS services.

The paging area indicates the cells within which the BSC pages the MSand they can be:

. all cells within the BSC

. all cells of the BSC within one Location Area

. all cells of the BSC within one Routing Area

. one cell (identified with a BSSGP virtual connection identifier(BVCI)).

A Routing Area, a Location Area, or a BSC area is associated with one ormore NSEIs (PCUs). If the cells in which to page the MS are served byseveral NSEIs, then the SGSN sends one paging message to each ofthese NSEIs.

The SGSN indicates the MS's IMSI and DRX parameters, which enablesthe BSS to derive the paging group. If the SGSN provides a P-TMSI, thenthe BSC uses it to address the MS. Otherwise IMSI is used to address theMS.



In GPRS paging the BSS forwards the PACKET_PAGING_REQUESTmessage from the SGSN to the MS on the CCCH(s). The MS's pagingresponse to the SGSN is handled in the PCU as any other uplink TBF.


Tip

RA0 is a routing area for cells that do not support GPRS.

Tip

Gs interface is obligatory in order to support CS paging.

Circuit switched paging via GPRS in network operation mode I

In order to initiate circuit-switched transmission between the MSC and theMS, the SGSN sends one or more PAGING CS PDUs to the BSC. ThesePDUs contain the information elements necessary for the BSS to initiatepaging for an MS within a group of cells. The paging area is the same as inGPRS paging.

The SGSN indicates the MS's IMSI and DRX parameters, which enablethe BSS to derive the paging group. If the SGSN provides the TMSI, thenthe BSC does not use the IMSI to address the MS. If a radio contextidentified by the TLLI exists within the BSS, then the paging message isdirectly sent to the MS on PACCH. If no radio context identified by the TLLIexists within the BSS, then the TMSI is used to address the MS. OtherwiseIMSI is used to address the MS.

After the paging procedure, the circuit switched connection is set up asusual as described in Basic Call.

If within the SGSN area there are cells that do not support GPRS services,the cells are grouped under a 'null RA' (RA0). RA0 covers all the cells inthe indicated paging area that do not support GPRS services. Forexample, if the SGSN indicates to the BSC to initiate paging for an MSwithin a Routing Area the BSC sends one circuit switched paging messageto all cells in the Routing Area and one message to all the cells in RA0.The RA0 in this case is all the cells that do not support GPRS services in aLocation Area derived from the Routing Area.

DN03299216Issue 9-0 en20/03/2008



For more details about the paging message contents, refer to BSC-SGSNInterface Specification, BSS GPRS Protocol (BSSGP).

12.4 Mobile terminated TBF (GPRS or EGPRS)

When the SGSN knows the location of the MS, it can send LLC PDUs tothe correct PCU. Each LLC PDU is encapsulated in one DL-UNITDATAPDU. The SGSN indicates the cell identification in every DL-UNITDATAPDU. For more details about the downlink data message contents, refer toBSC-SGSN Interface Specification, BSS GPRS Protocol (BSSGP).

The PCU allocates one or more PDTCHs for the TBF, and indicates it andthe TFI to the MS in the assignment message. The TBF establishment isdone in one of the following ways:

. on PACCH; used when a concurrent ULTBF exists or when the timerT3192 is running in the MS

. on CCCH; used when there is no concurrent UL TBF, and T3192 isnot running

These alternatives are described in the following subsections. Theprocedures are the same for GPRS and EGPRS TBFs. The EGPRS-specific issues are discussed in section 12.4.1 Finding an EGPRS-capable MS.

Downlink TBF establishment on CCCH

The PCU allocates one PDTCH for the TBF, and sends anIMMEDIATE_ASSIGNMENT message to the MS. The possible multislotallocation is done later and indicated to the MS by a reallocation message.

When the MS is ready to receive on PACCH, the PCU sends aPACKET_POLLING_REQUEST message to the MS and requests anacknowledgement. This is done in order to determine the initial TimingAdvance for the MS. If the channel configuration to be allocated for thedownlink TBF consists of only one channel already assigned to the MS,the PCU sends the PACKET_POWER_CONTROL/TIMING_ADVANCEmessage to the MS to indicate the Timing Advance value.



When multiple PDTCHs are allocated to the MS, the MS GPRS multislotclass must be taken into account. The MS GPRS multislot class is part ofthe MS Radio Access Capability IE, which is included in the DL-UNITDATA_PDU message. The PCU sends thePACKET_DOWNLINK_ASSIGNMENT message, and gives the wholeconfiguration together with the Timing Advance value to the MS.

In case there are no radio resources for the new TBF, the LLC PDU isdiscarded and the BSC sends a LLC-DISCARD message to the SGSN.The assignment procedure is guarded with two timers, one for resendingthe IMMEDIATE_ASSIGNMENT message and one for aborting theestablishment.

Downlink TBF establishment when an uplink TBF exists

Downlink TBF establishment when an uplink TBF exists follows the sameprinciples as uplink TBF establishment when a downlink TBF exists. Thisis discussed more at the end of 12.5 Mobile originated TBF.

The establishment is done with a PACKET_DOWNLINK_ASSIGNMENTor PACKET_TIMESLOT_RECONFIGURE message. The TBF mode(GPRS/EGPRS) is always the same as the mode of the existing UL TBF.

Downlink TBF establishment when timer T3192 is running and no ULTBF exists

When the DL TBF is released, the MS starts the timer T3192 andcontinues monitoring the PACCH of the released TBF until T3192 expires.During the timer T3192 the PCU makes the establishment of a new DLTBF by sending a PACKET_DOWNLINK_ASSIGNMENT on the PACCHof the 'old' DL TBF.

Finding an EGPRS-capable MS (EGPRS downlink TBF establishment)

The DL-UNITDATA message from the SGSN to the PCU includes the MSRadio Access Capability IE (RAC). If this optional field is missing only theBCCH band can be used for TBF establishment and only one PDTCH canbe allocated for a GPRS-mode TBF. Multislot capability struct has theoptional field EGPRS Multislot Class. If this field is not present the MS isnot EGPRS capable, and a standard GPRS TBF is established with GPRSmultislot capabilities. If the field is present, it defines the multislotcapabilities of the MS when an EGPRS mode TBF is used. The GPRSmultislot class is used, however, if the PCU allocates a TBF for the MS inGPRS mode.

Downlink EGPRS-mode TBF establishment is done by including EGPRS-specific fields, for example EGPRS window size, to the assignmentmessage. The existence of these fields defines the TBF mode.

DN03299216Issue 9-0 en20/03/2008



An EGPRS-mode TBF is primarily allocated for an EGPRS capable MS (toan EDGE capable BTS). A GPRS-mode TBF can be allocated for anEGPRS capable MS to a non-EDGE capable BTS if:

. there are no EDGE capable BTSs in the segment, or

. the average TBF / TSL is more than or equal to the parameterindicating the threshold amount of TBFs in one TSL, defined in everyEDGE capable BTS.

MS-specific flow control

Mobile specific flow control is part of the QoS solution in the PCU. It workstogether with the SGSN to provide a steady data flow to the mobile fromthe network. Mobile specific flow control also ensures that if an MS hasbetter QoS, and therefore better transmission rate in radio interface (moreair time), it will also get more data from the SGSN. It is also an effectivecountermeasure against buffer overflows in the PCU. Mobile-specific flowcontrol is done for every MS that has a downlink TBF. There is no uplinkflow control.

Data transfer

During the actual data transfer, the MS recognises the transmitted RadioLink Control (RLC) blocks based on the TFI, which is included in everyRLC block header. Each TBF has a transmit window, which is themaximum number of unacknowledged RLC blocks at a time. The windowsize is 64 blocks in GPRS mode. In EGPRS mode the window size islarger than in GPRS and depends on the number of allocated timeslots.

The PCU can request the MS to send an (EGPRS)_PACKET_DOWNLINK_ACK/NACK message by setting a polling flag tothe RLC data block header. The PCU can send further RLC data blocksalong with the acknowledgement procedure. If the PCU does not receivethe (EGPRS)_PACKET_DOWNLINK_ACK/NACK message when polled,it increments a counter. After the counter reaches its maximum value of 8,the BSC considers the MS as lost, releases the downlink TBF anddiscards the LLC PDU from the PCU buffer. The BSC signals this to theSGSN by setting the Radio Cause information element (IE) value to 'radiocontact lost with MS'. This indicates to the SGSN that attempts tocommunicate between the MS and the SGSN via the cell should besuspended or abandoned. The BSC thus recommends the SGSN to stopsending LLC PDUs for the MS to the cell.

The counter is reset after each correctly received (EGPRS)_PACKET_DOWNLINK_ACK/NACK.



The PCU can change the downlink PDTCH configuration wheneverneeded by sending the MS_PACKET_DOWNLINK_ASSIGNMENT orPACKET_TIMESLOT_RECONFIGURE message. The reasons for thisreallocation may be a GPRS territory downgrade, uplink TBFestablishment, or a change of requirements of the SGSN.

If reallocation is impossible in the case of GPRS territory downgrade, thePCU may release channels with a PDCH_RELEASE message.

The normal downlink TBF release is initiated by the PCU by setting a FinalBlock Indicator (FBI) bit in the last RLC block header. There may still besome retransmission after this, but the PCU releases the TBF andremoves the LLC PDU from the PCU buffer when the MS sends the(EGPRS)_PACKET_DOWNLINK_ACK/NACK message with the Final AckIndicator bit on.

When the PCU has sent the last buffered LLC PDU to the MS, the PCUdelays the release of the TBF (by 1 s by default). If there is no concurrentUL TBF, during the delay time DUMMY LLC PDUs are sent to the MS (withpolling), in order to allow the MS to request for a UL TBF. If the PCUreceives more data during the delay time, the PCU cancels the delayedrelease and begins to send RLC data blocks to the MS, in other words thesame downlink TBF continues normally.

12.5 Mobile originated TBF (GPRS or EGPRS)

When the MS wants to send data or upper layer signalling messages tothe network, it requests the establishment of an uplink TBF from the BSC.There are the following main alternatives for the TBF establishment:

. on PACCH; used when a concurrent DL TBF exists

. on CCCH; used when there is no concurrent DL TBF

Additionally, on CCCH there are different options for TBF establishment,for example one phase access or two phase access, depending on theneeds for the data transfer. The PCU may force the MS to make a twophase access, even if the MS requested some other access type, forinstance if there is no room for the TBF in the BCCH band.

These alternatives are described in the following subsections. Theprocedures are mainly the same for GPRS and EGPRS TBFs. TheEGPRS-specific issues are discussed in separate sections.

DN03299216Issue 9-0 en20/03/2008



Random access on CCCH

The MS can send a CHANNEL_REQUEST message or anEGPRS_PACKET_CHANNEL_REQUEST (EPCR) message on CCCH(RACH). The EGPRS_PACKET_CHANNEL_REQUEST is supported onRACH, if the BTS supports it. In cells where EPCR is not supported, theMS cannot tell its EGPRS capability in the CHANNEL_REQUESTmessage, and the MS must use two phase access when it wants to initiatean EGPRS TBF on CCCH. The BSC tells the MS in the SI13 GPRS CellOptions IE about the EPCR support.

One phase access on CCCH, GPRS

In a one phase access the MS sends a CHANNEL_REQUEST messagewith the establishment cause 'one phase access'. The PCU allocates aPDTCH for the request, and informs the MS in theIMMEDIATE_ASSIGNMENT message along with TFI and USF values.The MS sends its TLLI in the first data blocks and the one phase access isfinalised when the PCU sends the PACKET_UPLINK_ACK/NACKmessage to the MS containing the TLLI (contention resolution).

If the PCU has no PDTCHs to allocate to the MS, it sends anIMMEDIATE_ASSIGNMENT_REJECT message to the MS. One phaseaccess is guarded by a timer in the PCU.

Two phase access on CCCH, GPRS

In a two phase access the MS sends a CHANNEL_REQUEST messagewith the establishment cause 'single block access'. The PCU allocates oneuplink block for the request, schedules a certain radio interface TDMAframe number for the block, and informs it to the MS in theIMMEDIATE_ASSIGNMENT message.

The MS then uses the allocated block to send a more accurate request tothe PCU with the PACKET_RESOURCE_REQUEST message. The PCUallocates the actual configuration for the uplink TBF according to theinformation received in this message. When multiple PDTCHs areallocated to an MS, the MS GPRS multislot class must be taken intoaccount. The MS GPRS multislot class is a part of the MS Radio AccessCapability IE, which is included in the PACKET_RESOURCE_REQUESTmessage. The PCU indicates the PDTCH configuration, USF value foreach PDTCH, and the TFI to the MS in thePACKET_UPLINK_ASSIGNMENT message sent in the same timeslot inwhich the single block was allocated, but the assigned PDTCH(s) may beelsewhere. The channel allocation in this second phase is independent ofthe first phase, and if the PCU has no PDTCHs to allocate to the MS, itsends a PACKET_ACCESS_REJECT message to the MS. The secondpart of the two phase access is guarded with a timer in the PCU.



The two phase access is finalised when the PCU receives the first blockon the assigned PDTCH . The MS sends its TLLI in thePACKET_RESOURCE_REQUEST message, and the PCU includes it inthe PACKET_UPLINK_ASSIGNMENT message to the MS (contentionresolution).

Two phase access on CCCH, EGPRS (EPCR not supported)

The PCU assigns one RLC block for an MS with theIMMEDIATE_ASSIGNMENT message. The frame number of the assignedblock is told in the message. The MS sends aPACKET_RESOURCE_REQUEST message in the assigned block. Therethe PCU receives information about the MS's EGPRS capabilities(EGPRS multislot capability and uplink 8PSK capability). When uplink TBFestablishment is done with a CHANNEL_REQUEST message, the MSmight only be able to tell the RAC information from the band where theCCCH is located. If the PACKET_RESOURCE_REQUEST message doesnot include the EGPRS BTS band MS Radio Access Capabilityinformation, the PCU requests the full Radio Access Capability informationfor MS from SGSN, after which the TBF establishment continues.

The multislot capability struct has the optional field EGPRS multislot class.If this field is not present, the MS is not EGPRS-capable, and a standardGPRS TBF is established with GPRS multislot capabilities. If the field ispresent it defines the multislot capabilities of the MS when an EGPRSmode TBF is used. The GPRS multislot class is used, however, if the PCUallocates a TBF for the MS in GPRS mode. The PCU allocates thePDTCHs for the TBF and sends a PACKET_UPLINK_ASSIGNMENT(PUA) message to the MS. The PUA includes the following new fields:

. EGPRS Channel Coding Command IE, where the BSC tells the MSwhat MCS it must use in uplink RLC blocks.

. Resegment IE, which determines whether the MS must use thesame MCS in RLC data block retransmission as was used initially, orresegment the retransmitted RLC data block according to thecommanded MCS.

. EGPRS Window Size IE, where the BSC tells what RLC windowsize the MS must use

One phase access on CCCH, EGPRS

In one phase access using the EPCR message, the MS's multislot class isincluded. In addition, the training sequence indicates whether the MSsupports 8PSK modulation in uplink direction. If the mobile does not have8PSK capability in uplink, only EGPRS GMSK MCSs can be used in ULdata transfer. The PCU allocates the PDTCH for the TBF (only one

DN03299216Issue 9-0 en20/03/2008



PDTCH can be assigned) and selects the initial MCS and the EGPRSwindow size to be used in the uplink TBF. The assignment information issent to the MS with an IMMEDIATE_ASSIGNMENT message. When theBSC sends the message it can poll RAC information, which includes theMS's multislot capabilities and information about the supported frequencybands. When the cell supports several frequency bands, the RAC isrequested for them all. The MS sends aPACKET_RESOURCE_REQUEST (PRR) message where it has includedthe requested RAC information from at least the first requested band. If allthe requested RAC information does not fit in the PRR, the MS also sendsan ADDITIONAL_MS_RADIO_ACCESS_CAPABILITIES (ARAC)message where it tells the RAC of the other frequencies. Transmissionturns to that MS can be scheduled regardless of the PRR and ARACpolling. The MS uses the two radio blocks assigned first for thesesignalling messages.

Reallocation need is checked, when the establishment is completed.

Two phase access on CCCH, EGPRS

IThe BSC can request RAC information from several frequency bands.When the cell supports several frequency bands the RAC is requestedfrom them all. The multi block assignment information is sent to the MSwith an IMMEDIATE_ASSIGNMENT message. It contains a multi blockallocation, assigning a single block or two consecutive blocks for the MS,depending on the requested RAC information. The MS sends aPACKET_RESOURCE_REQUEST (PRR) message where it has includedthe requested RAC information at least from the first requested band. If allthe requested RAC information does not fit in the PRR, the MS also sendsan ADDITIONAL_MS_RADIO_ACCESS_CAPABILITIES (ARAC)message where it tells the RAC of the other frequencies.

Short access on CCCH, EGPRS

The MS may request EGPRS Short Access with or without uplink 8PSKcapability if the amount of sent data is less than or equal to 8 MCS-1 codedRLC blocks. The amount of blocks is told in theEGPRS_PACKET_CHANNEL_REQUEST message. Only one PDTCH isallocated for such a request and no RAC information is polled. Theassignment information is sent to the MS with anIMMEDIATE_ASSIGNMENT message. The short access is completed asthe 'One phase access on CCCH, EGPRS'.



Signalling access on CCCH, EGPRS

The MS may request EGPRS Signalling Access with or without uplink8PSK Capability. Only one PDTCH is allocated for the request and noRAC information is polled. The highest priority is applied to the TBFscheduling. The assigned PDTCH and MCS are told to the MS in theIMMEDIATE_ASSIGNMENT message. The signalling access iscompleted as the 'One phase access on CCCH, EGPRS'.

Data transfer

In uplink data transfer, the RLC data blocks are collected to the PCUbuffer. The TBF has a transmit window, which is the maximum number ofunacknowledged RLC blocks. The window size is 64 blocks in GPRSmode. In EGPRS mode the window size is larger than in GPRS anddepends on the number of allocated timeslots.

The PCU can schedule the MS to send further the RLC data blocks alongwith the acknowledgement procedure. The PCU can at any time send thePACKET_UPLINK_ACK/NACK message to the MS. ThePACKET_UPLINK_ACK/NACK message includes a bitmap which tells thecorrectly received blocks. The PCU can use the PACKET_UPLINK_ACK/NACK message for other purposes too, for example to change the codingscheme, which also affects the frequency of the acknowledgements.

The PCU has a counter to control the MS's ability to send RLC blocks inthe frames it has been assigned by the USF values. The counter is alwaysreset when the MS uses the frame it has been assigned to. If the counterreaches its maximum value of 15, the MS is considered lost and thereforethe PCU releases the uplink TBF.

The PCU delivers the LLC PDU with a UL-UNITDATA PDU to the SGSN.There is only one LLC PDU per UL-UNITDATA PDU. The underlyingnetwork service has to be available for the BSSGP level in order to deliverdata to the SGSN. Otherwise the data is discarded and a counter isupdated.

The PCU can change the uplink PDTCH configuration whenever neededby sending the MS a PACKET_UPLINK_ASSIGNMENT orPACKET_TIMESLOT_RECONFIGURE message. Reasons forreallocation may be a GPRS territory downgrade, downlink TBFestablishment, or a change of an MS's requirements.

If reallocation during a downgrade is impossible, the PCU releaseschannels with a PDCH_RELEASE message to the MS. A normal uplinkTBF release is made by countdown, where the MS counts down the lastRLC data blocks (15 or less) with the last block numbered 0. There may

DN03299216Issue 9-0 en20/03/2008



still be some retransmission, but when the PCU has received all the RLCdata blocks correctly, it sends the LLC PDU to the SGSN, and aPACKET_UPLINK_ACK/NACK message with final ack indicator to theMS. The MS responds with a PACKET_CONTROL_ACK message andthe PCU releases the TBF.

If the MS supports Extended UL TBF Mode (indicated in MS RAC), thenormal uplink release is delayed. Instead of sending aPACKET_UPLINK_ACK/NACK (final ack) immediately, the networkschedules USF turns to the MS in extended mode, but with a lower rate asnormally. For more information on Extended UL TBF Mode, see sectionChannel allocation and scheduling. The MS sends a PACKET UPLINKDUMMY CONTROL BLOCK in the scheduled block if it has no data tosend. If the MS has got new data, it sends an RLC data block, and afterthat the PCU cancels the delayed TBF release, and the TBF continueswith the normal scheduling rate.

Even if the MS does not support Extended UL TBF Mode, the PCU maydelay the UL TBF release (by 0.5s by default). This is done when there isno concurrent DL TBF for the same MS. The purpose of the delay is tospeed up the possibly following DL TBF establishment. No USF turns arescheduled during this delay.

For more details about the uplink data message contents, refer to BSC-SGSN Interface Specification, BSS GPRS Protocol (BSSGP).

Uplink TBF establishment when downlink TBF exists

During a downlink TBF the MS can request resources for an uplink TBF byincluding a Channel Request Description IE in the (EGPRS)_PACKET_DOWNLINK_ACK/NACK message. The TBF mode (GPRS/EGPRS) of the new UL TBF is always the same as the mode of theexisting DL TBF.

If there is no need to change the downlink PDTCH configuration, aPACKET_UPLINK_ASSIGNMENT message from the PCU to the MScontains the uplink PDTCH configuration, USF values for each PDTCH,and TFI.

If the downlink PDTCH configuration is changed, for instance due to MSmultislot capability restrictions, thePACKET_TIMESLOT_RECONFIGURE message from the PCU informsthe MS of both the uplink and downlink PDTCH configurations, USFvalues for the uplink PDTCHs, and the uplink and downlink TFIs.



The establishment is ready when the PCU receives the first block on theassigned uplink PDTCHs. This establishment is also guarded by a timer inthe PCU.

If the PACKET_UPLINK_ASSIGNMENT message fails, the uplink TBF isreleased. If the PACKET_TIMESLOT_RECONFIGURE message fails,both downlink and uplink TBFs are released.

12.6 Suspend and resume GPRS

The GPRS suspension procedure enables the network to discontinueGPRS packet flow in the downlink direction. Suspend is referred to as thesituation, which occurs when a circuit switched call interrupts a GPRSpacket flow and the GPRS connection is thus discontinued or suspended.

When a mobile station which is IMSI attached for GPRS services entersdedicated mode, and when the MS or network limitations make it unable tohandle both dedicated mode and either packet idle mode or packettransfer mode simultaneously (in other words DTM cannot be used), theMS performs the GPRS suspension procedure. TheGPRS_SUSPENSION_REQUEST message is an indication to the SGSNnot to send downlink data.

The MS initiates the GPRS suspension procedure by sending a messageto the BSC. The BSC sends the SUSPEND_PDU message to the SGSN.The message contains the TLLIand the Routing Area of the MS. TheSGSN acknowledges with a SUSPEND-ACK PDU message, whichcontains the TLLI, the Routing Area of the MS, and the SuspendReference Number. The SGSN typically stops paging for a suspendedmobile.

If the SGSN is not able to suspend GPRS services, it sends a negativeresponse to the BSC with the SUSPEND-NACK PDU message. Themessage contains the TLLI, the Routing Area of the MS and the cause ofthe negative acknowledgement.

When a GPRS attached MS in an GPRS/EDGE-capable but non-DTM-capable cell leaves dedicated mode, disconnecting the MS from the MSC,or a DTM-capable MS is handed over from a non-DTM cell to a cell thatsupports DTM, the reason for the suspension disappears. In this case, theBSC either instructs the MS to initiate the Routing Area Update procedureor signals to the SGSN that the MS's GPRS service shall be resumed.

DN03299216Issue 9-0 en20/03/2008



If a DTM-capable MS is handed over from a non-DTM cell to a cell thatsupports DTM during a dedicated connection, the MS shall perform theRouting Area Update procedure to resume GPRS services in the new cell.The MS starts the Routing Area Update procedure after detecting the DTMservice in the cell.

If the suspension procedure has been successfully completed and thereason for the suspension is still valid, for instance a DTM-capable MS hasnot been handed over from a non-DTM cell to a DTM-capable cell, theBSC resumes the GPRS services before the circuit switched call isreleased by sending a RESUME PDU message to the SGSN. Themessage contains the TLLI, the Routing Area of the MS and the SuspendReference Number. The SGSN acknowledges the procedure with aRESUME-ACK PDU message, which contains the TLLI and the RoutingArea of the MS.

When the circuit switched call is released, the BSC sends a CHANNELRELEASE message to the MS indicating that the resume procedure hasbeen successfully completed. If the BSC has not been able to resumeGPRS services or in case of a DTM-capable MS, the services are stillsuspended, the MS resumes the services by sending the Routing AreaUpdate Request to the SGSN after the circuit switched connection hasbeen released.

12.7 Flush

The flush procedure is used, for example, when the MS has stopped datasending in a given cell and has moved to another cell. The SGSN sends aFLUSH-LL PDU to the BSC to ensure that LLC PDUs queued fortransmission in a cell for an MS are either deleted or transferred to the newcell.

The MS's TLLI indicates which mobile's data is in question and the BVCI(old) indicates the cell. The BSC deletes all buffered LLC PDUs in the celland all contexts for the MS. If an optional new cell, BVCI (new), is given,the BSC transfers all buffered LLC PDUs to the new cell on the conditionthat both the BVCI (old) and the BVCI (new) are served by the same PCUand the same Routing Area.

For more details on flush, refer to BSC-SGSN Interface Specification, BSSGPRS Protocol (BSSGP).



12.8 Cell selection and re-selection

Cell selection and re-selection is performed autonomously by the MS or bythe network, depending on the network control mode.

The following cell re-selection criteria are used for GPRS:

. The path loss criterion parameter C1 is used as a minimum signallevel criterion for cell re-selection for GPRS in the same way as forGSM Idle mode.

. The signal level threshold criterion parameter C31 for hierarchicalcell structures (HCS) is used to determine whether prioritisedhierarchical GPRS and LSA cell re-selection shall apply.

. The cell ranking criterion parameter (C32) is used to select cellsamong those with the same priority.

For information on network-controlled cell re-selection, see:



For information on network-assisted cell change, see:


12.9 Traffic administration

The BSC has many overload mechanisms to protect existing traffic flowand thus ensure good quality for end-users.

The cause of an overload may be, for example, in the planning of thenetwork and capacity being too small in a particular area. In the case ofoverload, neither circuit switched nor GPRS connections can be set up.The BCSU continuously tries, however, to set up the GPRS connection,and the unit can in the worst case thus easily run itself into a state ofmalfunction. The BCSU cuts down the load by rejecting particularmessages when the processor load or the link load exceeds the definedload limit. Circuit switched calls are marked in the same way as GPRSconnections.

DN03299216Issue 9-0 en20/03/2008



The load the BCSU can handle has been tested, but the user candetermine GPRS usage and thus prevent the overload situations fromhappening. Refer to section BSS overload protection and flow control inBSS (BSC) Traffic Handling Capacity, Network Planning and OverloadProtection for more information on the BSC's overload control in general.

BCSU overload control

The BCSU has an overload control to protect itself against the processoroverloading and the TRXSIG link overloading.

BCSU protection against excessive number of paging messages onthe Gb interface

The BCSU cuts down the load by rejecting particular messages when theprocessor load or the link load exceeds the defined load limit. The BCSUrejects messages which are sent in the downlink direction to the TRXSIG ifneeded. Each message sent to TRXSIG has a certain message groupvalue. In case the message buffers of an AS7 plug-in unit begin to fill up,the BCSU rejects messages based on the message group value.

The BCSU cuts down the load caused by GPRS and circuit switchedpaging messages sent by the SGSN. The load control is based on thenumber of unhandled messages in the BCSU's message queue. TheBCSU checks the count of unhandled messages in the message queueevery time a new paging message is received. If the load limit is exceeded,the message is deleted.

BCSU protection against high GPRS RACH load

In the uplink direction the BCSU cuts down the load caused by GPRSrandom accesses. The BCSU rejects P-CHANNEL_REQUIREDmessages received from the TRXSIG if the processor load exceeds thedefined load limit. The load control is based on the number of unhandledmessages in the BCSU's message queue. The count of unhandledmessages in the message queue is checked every time a new P-CHANNEL_REQUIRED message is received. If the load limit is exceeded,the BCSU deletes the message.

BSSGP flow control

Flow control is part of the BSSGP protocol. It is used to adjust the flow ofBSSGP DL-UNITDATA PDUs from SGSN to the PCU. PCU controls theflow by indicating its buffer size and maximum allowed throughput to theSGSN. SGSN is not allowed to transmit more data than indicated by thePCU. Flow control is performed for downlink data in BVC (cell) and MSlevel. Any uplink flow control is not performed.



PCU holds a buffer for storing downlink data. The amount of the data to bestored in the PCU is optimised for efficient use of the available radioresources. The BVC and MS buffer sizes indicated to the SGSN arecontrolled by the PRFILE parameters FC_B_MAX_TSL andFC_MS_B_MAX_DEF.

PCU monitors the lifetime values of the buffered DL UNITDATA PDUs. Ifthe lifetime of a PDU expires before the PDU is sent across the radiointerface, PCU deletes the PDU locally. Local deletion is signalled to theSGSN by a LLC-DISCARDED PDU.

The 3GPP Rel-5 specifications introduce a third layer for BSSGP flowcontrol: a Packet Flow Context (PFC) flow control. The PFC flow control isan optional functionality.

Flow control mode of operation

The PCU sends an initial FLOW-CONTROL-BVC PDU to the SGSN aftera BVC is reset in order to allow SGSN to start the downlink BSSGP datatransfer. This message contains BVC specific buffer size and leak rate, aswell as default values for MS buffer size and leak rate. The PRFILEparameters FC_B_MAX_TSL and FC_R_TSL define the BVC specific buffersize and leak rate together with the number of actual GPRS timeslots inthe cell. The parameters FC_MS_B_MAX_DEF and FC_MS_R_DEF definethe MS specific default values. SGSN uses the MS default values forcontrolling the flow of an individual MS until it receives a FLOW-CONTROL-MS PDU regarding that MS.

Upon reception of a FLOW-CONTROL PDU, SGSN modifies its downlinktransmission as instructed and ensures that it never transmits more datathan can be accommodated within the BSC buffer for a BVC or an MS.

After the initial BVC FLOW-CONTROL PDU, PCU starts to performperiodic flow control in BVC and MS level. The frequency of FLOW-CONTROL PDUs is limited so that the PCU may send a new PDU once inevery C seconds for each flow. The value C in the PCU is fixed to 1 s.

PCU checks the flow control status for each BVC and MS once a secondand sends as a periodic FLOW CONTROL PDU to SGSN for the flowswhich needs to be adjusted. For this purpose the PCU keeps record of thereceived DL data per BVC and per MS. It knows the buffer utilisation ratioand leak rate of each flow, and compares the actual leak rate value to thevalue reported earlier to the SGSN. If the leak rate difference for a flowexceeds the PRFILE parameter FC_R_DIF_TRG_LIMIT, the flow controlparameters in SGSN needs to be updated. For a BVC flow, the FLOW-CONTROL-BVC PDU and for a MS flow, the FLOW-CONTROL-MS PDUis sent to SGSN.

DN03299216Issue 9-0 en20/03/2008



If the PCU does not receive confirmation to a FLOW-CONTROL PDU, nofurther action is taken. If the condition which requires flow control remainseffective, a new FLOW-CONTROL PDU is sent to the SGSN after onesecond.

For more information on BVC and MS flow control, refer to BSC-SGSNInterface Specification, BSS GPRS Protocol (BSSGP).

Uplink congestion control on NS-VC

The BSC/PCU uses a local congestion control procedure to adapt uplinkNS-UNITDATA traffic to the NS-VCs according to their throughput. ThePCU sends an NS-UNITDATA, which passes the procedure, to the SGSNas long as the CIR of the NS-VC is not exceeded.

The PCU deletes any NS-UNITDATA that does not pass the procedure.This updates a counter, and the BSC sets the alarm 3027 UPLINKCONGESTION ON THE NETWORK SERVICE VIRTUAL CONNECTIONin the BSC. The alarm is cancelled automatically, when NS-UNITDATAagain passes the procedure.

12.10 Coding scheme selection in GPRS

Stealing bits in the channel coding (for more information, see ETSIspecification on Channel Coding) are used to indicate the actual codingscheme (CS) which is used for each block sent between the BSC's PCUand the MS.

In downlink packet transfer the PCU selects the CS, and the code word forthe selected CS is included in each RLC data block sent to the MS. If thePCU changes the CS during one TBF reservation, it includes the new CScode word in the blocks.

In uplink data transfer, the PCU informs the MS the initial CS to be used ineither the IMMEDIATE_ASSIGNMENT orPACKET_UPLINK_ASSIGNMENT message. The PCU can command theMS to change the CS by sending the PACKET_UPLINK_ACK/NACKmessage, which includes the Channel Coding Command field. Inretransmission the same CS has to be used as in the initial blocktransmission.



In PCU1 the coding schemes CS-1 and CS-2 are supported. In PCU2 thecoding schemes CS-3 and CS-4 are introduced. Although the CS-3 andCS-4 coding schemea are licence based, the Link Adaptation algorithm isstill provided with PCU2. However, in case the operator has both PCU1and PCU2 in use in the same track, coding schemes CS-1 and CS-2 canonly be used and the Link Adaptation algorithm with coding scheme nohop (COD) and coding scheme hop (CODH) parameters is deployed.

PCU1

The BSC level parameters coding scheme no hop (COD) and codingscheme hop (CODH) define whether the fixed CS value (CS-1/CS-2) isused or if the coding scheme is changed dynamically according to the LinkAdaptation algorithm. In unacknowledged RLC mode CS-1 is always usedregardless of the parameter values. When the Link Adaptation algorithm isdeployed, then the initial value for the CS at the beginning of a TBF is CS-2.

Link Adaptation algorithm

The Link Adaptation (LA) algorithm is used to select the optimum channelcoding scheme (CS-1 or CS-2) for a particular RLC connection and it isbased on detecting the occurred RLC block errors.

Essential for the LA algorithm is the crosspoint, where the two codingschemes give the same bit rate. In terms of block error rate (BLER) thefollowing equation holds at the crosspoint:

8.0 kbps * (1 - BLER_CP_CS1) = 12 kbps * (1 - BLER_CP_CS2), where:

. 8.0 kbps is the theoretical maximum bit rate for CS-1

. 12.0 kbps is the theoretical maximum bit rate for CS-2

. BLER_CP_CS1 is the block error rate at the crosspoint when CS-1is used

. BLER_CP_CS2 is the block error rate at the crosspoint when CS-2is used

If CS-1 is used and if BLER is less than BLER_CP_CS1, then it would beadvantageous to change to CS-2. If CS-2 is used and if BLER is largerthan BLER_CP_CS2, then it would be advantageous to change to CS-1.Since CS-1 is more robust than CS-2, BLER_CP_CS2 is larger thanBLER_CP_CS1.

DN03299216Issue 9-0 en20/03/2008



The crosspoint can be determined separately for UL and DL directions aswell as for frequency hopping (FH) and non-FH cases. For this purposethe following BSC-level parameters are used by the LA algorithm:

. UL BLER crosspoint for CS selection hop (ULBH)

. DL BLER crosspoint for CS selection hop (DLBH)

. UL BLER crosspoint for CS selection no hop (ULB)

. DL BLER crosspoint for CS selection no hop (DLB)

The given parameters correspond to the BLER_CP_CS1 (see equationabove).

During transmission, two counters are updated: N_Number gives the totalnumber of RLC data blocks and K_Number gives the number of corruptedRLC data blocks that have been transmitted after the last link adaptationdecision.

At certain intervals (in uplink transfer after approximately 10 transmittedRLC blocks, and in downlink after every PACKET_DL_ACK/NACKmessage reception) the LA algorithm is run by performing two of thefollowing (either 1 and 2 or 3 and 4) statistical tests:

1. Current coding scheme is CS-1; change to CS-2?

Hypothesis: BLER > BLER_CP_CS1.

Reference case: N_Number of blocks have been transmitted with aconstant BLER value of BLER_CP_CS1. In this reference case thenumber of erroneous blocks follow binomial distribution and the P-valuegives the probability to get at most K_Number of block errors out ofN_Number of transmissions.

P-value =

If the P-value is less than a certain risk level (RL), the hypothesis can berejected with (1-RL) confidence. If the hypothesis is rejected, it means thatthe reference case would hardly give the observed measures with thegiven condition of BLER > BLER_CP_CS1. If this is the case, then it canbe concluded that BLER < BLER_CP_CS1.



Action in case the hypothesis is rejected: Change to CS-2. Reset countersN_Number and K_Number.

Action in case the hypothesis is accepted: No actions.

2. Current coding scheme is CS-1; confirm CS-1?

Hypothesis: BLER < BLER_CP_CS1.

Reference case: N_Number of blocks have been transmitted with aconstant BLER value of BLER_CP_CS1. In this reference case thenumber of erroneous blocks follow binomial distribution and the P-valuegives the probability to get at least K_Number of block errors out ofN_Number of transmissions.

P-value =

If the P-value is less than a certain risk level, the hypothesis can berejected with (1-RL) confidence. This means that the reference case wouldhardly give the observed measures with the condition of BLER <BLER_CP_CS1. If this is the case, then it can be concluded that BLER >BLER_CP_CS1.

Action in case the hypothesis is rejected: Reset counters N_Number andK_Number (CS-1 is confirmed).


3. Current coding scheme is CS-2; change to CS-1?

Hypothesis: BLER < BLER_CP_CS2.

Reference case: N_Number of blocks have been transmitted with aconstant BLER value of BLER_CP_CS2. In this reference case thenumber of erroneous blocks follow binomial distribution and the P-valuegives the probability to get at least K_Number of block errors out ofN_Number of transmissions.

P-value =

DN03299216Issue 9-0 en20/03/2008



If P-value is less than a certain risk level, the hypothesis can be rejectedwith (1-RL) confidence. This means that the reference case would hardlygive the observed measures with the condition of BLER <BLER_CP_CS2. If this is the case, then it can be concluded that BLER >BLER_CP_CS2.

Action in case the hypothesis is rejected: Change to CS-1. Reset countersN_Number and K_Number.


4. Current coding scheme is CS-2; confirm CS-2?

Hypothesis: BLER > BLER_CP_CS2.

Reference case: N_Number of blocks have been transmitted with aconstant BLER value of BLER_CP_CS2. In this reference case thenumber of erroneous blocks follow binomial distribution and the P-valuegives the probability to get at most K_Number of block errors out ofN_Number of transmissions.

P-value =

If P-value is less than a certain risk level, the hypothesis can be rejectedwith (1-RL) confidence. This means that the reference case would hardlygive the observed measures with the condition of BLER >BLER_CP_CS2. If this is the case, then it can be concluded that BLER <BLER_CP_CS2.

Action in case the hypothesis is rejected: Reset counters N_Number andK_Number (CS-2 is confirmed).




In practice the threshold K_Number values have been computedbeforehand to look-up tables indexed with respect to the N_Number andthe link adaptation decisions can be performed by simply comparing theobserved K_Number with the theshold K_Number values.

The Risk Level parameters (UL adaption probability threshold(ULA) and DL adaption probability threshold (DLA)) describethe probability with which the LA algorithm may make a wrong conclusionto reject a given hypothesis. In other words, they determine the sensitivityof the LA algorithm. The larger the risk level, the more quickly the LAalgorithm is able react to changes in BLER by switching the codingscheme but on the other hand the reliability of the switching decision islowered as the risk level is increased.

The PCU chooses a lower CS than what the Link Adaptation algorithmallows, if there is no room in the dynamic Abis pool for the higher CSallowed by the LA.

PCU2

The Link Adaptation algorithm

In PCU2 the coding schemes CS-1 - CS-4 are supported. The BTS levelparameters DL coding scheme in acknowledged mode (DCSA), ULcoding scheme in acknowledged mode (UCSA), DL coding schemein unacknowledged mode (DCSU) and UL coding scheme inunacknowledged mode (UCSU) define whether the fixed CS value (CS-1 - CS-4) is used or if the coding scheme is changed dynamicallyaccording to the Link Adaptation algorithm. The parameter DL codingscheme in acknowledged mode (DCSA) defines it in RLCacknowledged mode in downlink direction, UL coding scheme inacknowledged mode (UCSA) defines it in RLC acknowledged mode inuplink direction and so on. The BTS level parameter adaptive LAalgorithm (ALA) defines whether the Link Adaptation algorithm isadaptive or not.

The new Link Adaptation algorithm can be used both in RLCacknowledged and in unacknowledged modes both in uplink and downlinkdirection. When the Link Adaptation algorithm is deployed, the initialvalues for the CS at the beginning of a TBF can also be defined with theparameters DL coding scheme in acknowledged mode (DCSA), ULcoding scheme in acknowledged mode (UCSA), DL coding schemein unacknowledged mode (DCSU) and UL coding scheme inunacknowledged mode (UCSU).

DN03299216Issue 9-0 en20/03/2008



Note, however, that when a GPRS MS already has a TBF and a new TBFis established for the MS to the opposite direction, then the initial value ofthe CS of the new TBF is set to be the same that is currently used by theongoing TBF.

The new Link Adaptation algorithm replaces the current LA algorithm inGPRS and covers the coding schemes:

. CS-1 and CS-2 if the CS-3 and CS-4 support is not enabled in theterritory

. CS-1, CS-2, CS-3 and CS-4, if the CS3 and CS-4 support is enabledin the territory

The new LA algorithm is based on the following principles:

. The signal quality is measured for each TBF in terms of RXQUAL,which describes the channel quality with the accuracy of eight levels(RXQUAL is expressed with three bits). Note that RXQUAL ismeasured for each received RLC radio block. On a block basisRXQUAL is thus more accurate estimate than the BLER, which hasonly two levels: 0 and 1.

. The PCU determines internally the average BLER separately foreach coding scheme and reported RXQUAL value. This is doneseparately in each cell by collecting statistics continuously from allthe connections in the corresponding cell.

. Based on the statistics (common for all the TBFs in the cell) and thereceived RXQUAL estimate (specific to the given TBF), the PCU isable to estimate what the BLER would be if CS1, CS2, CS3 or CS4were deployed for this TBF. Moreover, based on these BLERestimates the PCU can compute which coding scheme would givethe best performance, that is the highest throughput in RLCacknowledged mode.

. The new LA algorithm adapts to the radio characteristics of the cellbecause the BLER is dynamically measured as a function ofRXQUAL and coding scheme. Therefore, there is no need for pre-determined threshold values that are traditionally used in linkadaptation.

Operation in downlink direction



The PCU uses two 2-dimensional tables (ACKS and NACKS) for the LAoperation (another set of ACKS and NACKS tables are needed for ULdirection). In these tables, the first index refers to the coding scheme andthe second index refers to the RXQUAL value. Initially the ACKS andNACKS tables are initialised with values obtained from the simulations.Therefore, the operation of the LA algorithm is initially based on thesimulation results.

The PCU has separate ACKS and NACKS tables as well as separateinitialisation for hopping and non-hopping BTSs.

During the DL data transfer the mobile station measures the signal quality(RXQUAL) from the RLC radio blocks that are successfully decoded andaddressed to the mobile station. The RXQUAL is averaged over thereceived RLC blocks and the averaged RXQUAL estimate is sent to thenetwork in the Packet DL Ack/Nack messages. There can be eightdifferent values for the RXQUAL. When the PCU receives a valid PacketDL Ack/Nack message for the DL TBF that operates in an RLCacknowledged mode, the received bitmap is analysed and thecorresponding RLC blocks are marked as ACKED, if a positiveacknowledgement is received, or as NACKED, if a negativeacknowledgement is received. In this procedure, the RLC updates theACKS and NACKS tables as follows:

. Whenever an RLC block is positively acknowledged, ACKS [CS][RXQ] = ACKS [CS][RXQ] + 1, where CS indicates the codingscheme with which this RLC block was transmitted and RXQ refersto the RXQUAL value received in this particular Packet DL Ack/Nackmessage.

. Whenever an RLC block is negatively acknowledged, NACKS [CS][RXQ] = NACKS [CS][RXQ] + 1, where CS indicates the codingscheme with which this RLC block was originally transmitted andRXQ refers to the RXQUAL value received in this particular PacketDL Ack/Nack message.

If the value of the parameter adaptive LA algorithm (ALA) is N(disabled), the RLC does not update ACKS and NACKS tables but onlythe initial values of those tables will be used when the LA algorithm selectsthe optimal CS.

The ACKS and NACKS tables contain ever-increasing figures. In the longrun the figures would overflow resulting in erroneous behavior. To solvethis, both figures are divided by 2, when the sum (ACKS [CS][RXQ] +NACKS [CS][RXQ]) for CS and RXQ exceeds a certain threshold value.

DN03299216Issue 9-0 en20/03/2008



Coding scheme selection in downlink direction in RLC acknowledgedmode

After the bitmap is processed, the LA algorithm selects the optimal codingscheme for a TBF as follows:

1. The throughput of the link is estimated for each coding schemeseparately as follows: throughput [CS] = K * ACKS [CS][RXQ] /(ACKS [CS][RXQ] + NACKS [CS][RXQ]) * RATE[CS], where: CS =CS-1, CS-2, CS-3, CS-4, if CS-3 and CS-4 support is enabled in theterritory, otherwise CS = CS-1, CS-2.. K is a correction factor that takes into account the throughput

reduction due to the RLC protocol stalling. RXQ is the RXQUAL value that was received in the newly-

processed Packet DL Ack/Nack message. RATE[4] -table contains the theoretical maximum throughput

values for the available channel coding schemes

2. The coding scheme is selected based on the highest throughput withthe condition of BLER (CS) < QC_ACK_BLER_LIMIT_T , whereBLER(CS) = NACKS [CS] [RXQ] / (ACKS[CS] [RXQ] + NACKS [CS][RXQ]). If no CS fulfills this condition, the coding scheme CS-1 isselected.

The correction factor K depends on the BLER and on the number of RLCradio blocks scheduled to the TBF within the RLC acknowledgementdelay. Its value has been determined by simulations.

Coding scheme selection in downlink direction in RLC unacknowledgedmode

In unacknowledged mode RLC does not have to update the ACKS andNACKS tables but it can use the same ACKS and NACKS tables updatedby the TBFs in acknowledged mode.

The coding schemes that are in an unacknowledged mode are selected bychoosing the highest CS for which BLER (CS) <QC_UNACK_BLER_LIMIT_T, where BLER (CS) = NACKS [CS] [RXQ] /(ACKS[CS] [RXQ] + NACKS [CS] [RXQ]) and RXQ is the RXQUALestimate that is received in the Packet DL Ack/Nack message. If theseconditions are not fulfilled the coding scheme CS-1 is selected.

If the MS does not aswer to polling, the coding number will be decreasedstep-by-step as follows:



. If one Packet DL Ack/Nack message is missed with CS-4, then thecoding scheme is changed to CS-3.

. If two subsequent Packet DL Ack/Nack messages are missed withCS-3, then the coding scheme is changed to CS-2.

. If three subsequent Packet DL Ack/Nack messages are missed withCS-2, then the coding scheme is changed to CS-1

Operation in uplink direction

In UL direction the channel quality estimate can be either RXQUAL orGMSK_BEP depending on the Abis interface. The PCU data frame used inthe non-EDGE Abis interface reports the channel quality in terms ofRXQUAL, which is expressed with three bits. In this case the only possiblecoding schemes are CS-1 and CS-2. Whereas the PCU master data frameused in the EDGE Abis interface reports the channel quality in terms ofGMSK_BEP, which is expressed with four bits. The possible codingschemes are CS-1, CS-2, CS-3 and CS-4.

The PCU uses two 2-dimensional tables (ACKS and NACKS) for LAoperation. In these tables, the first index refers to the coding scheme andthe second index refers to the RXQUAL or GMSK BEP value. Initially theACKS and NACKS tables are initialised to the values obtained from thesimulations.

The PCU has separate ACKS and NACKS tables as well as separateinitialisation for hopping and non-hopping BTSs.

In case of RXQUAL, the RLC averages the RXQUAL estimates sent bythe BTS for the correctly received RLC radio blocks. This is done for eachuplink TBF.

In case of GMSK_BEP, the RLC averages the GMSK_BEP estimates sentby the BTS for both correctly and erroneously received RLC radio blocks.This is done for each ULTBF. The GMSK_BEP estimate is made also fromthe bad frames because the GMSK_BEP estimate for successfullyreceived CS-4 blocks alone approaches zero in all radio conditions (thereis no error correction in CS-4).

During the UL data transfer the PCU updates the ACKS and NACKStables as follows:

Whenever a new RLC block is successfully received, ACKS [CS][RXQ] =ACKS [CS][RXQ] + 1, where CS indicates the coding scheme with whichthis RLC block was transmitted and RXQ refers to the current RXQUAL orGMSK BEP estimate for this UL TBF. Whenever a RLC block is received

DN03299216Issue 9-0 en20/03/2008



unsuccessfully, NACKS [CS][RXQ] = NACKS [CS][RXQ] + 1, where CSindicates the coding scheme with which this RLC block was transmittedand RXQ refers to the current RXQUAL or GMSK BEP estimate for this ULTBF.

As in the DL case the figures in the ACKS and NACKS tables are limitedso that when the sum (ACKS [CS][RXQ] + NACKS [CS][RXQ]) for certainCS and RXQ exceeds a certain threshold value, both figures are dividedby 2.

Coding scheme selection in uplink direction in RLC acknowledged mode

1. The throughput of the link is estimated for each coding schemeseparately as follows: throughput [CS] = K * ACKS [CS][RXQ] /(ACKS [CS][RXQ] + NACKS [CS][RXQ]) * RATE [CS], where: CS =CS-1, CS-2, CS-3, CS-4, if CS-3 and CS-4 support is enabled in theterritory, otherwise CS = CS-1, CS-2. K is a correction factor thattakes into account the throughput reduction due to the RLC protocolstalling, RXQ is the current RXQUAL or GMSK BEP estimate for thisUL TBF and RATE [4] -table contains the theoretical maximumthroughput values for the available channel coding schemes.

2. The coding scheme is selected based on the highest throughput withthe condition of BLER (CS) <QC_ACK_BLER_LIMIT_T, whereBLER (CS) = NACKS [CS] [RXQ] / (ACKS [CS] [RXQ] + NACKS[CS] [RXQ]). If no CS fulfills this condition, the coding scheme CS-1is selected. The same correction factor table K can be used as in theDL case.

Coding scheme selection in uplink direction in RLC unacknowledgedmode

In unacknowledged mode the RLC message does not have to update theACKS and NACKS tables but it can use the same ACKS and NACKStables that are updated by the TBFs in acknowledged mode. The codingschemes are selected in unacknowledged mode as follows:

The coding schemes that are in an unacknowledged mode are selected bychoosing the highest CS for which BLER (CS) <QC_UNACK_BLER_LIMIT_T, where BLER (CS) = NACKS [CS] [RXQ] /(ACKS [CS] [RXQ] + NACKS [CS] [RXQ]) and RXQ is the currentRXQUAL or GMSK BEP estimate for this UL TBF. If these conditions arenot fulfilled for any CS the coding scheme CS-1 is selected.



12.11 Coding scheme selection in EGPRS

In the EGPRS air interface, each radio block consists of four bursts, whichare all modulated either using Gaussian Minimum Shift Keying (GMSK) orPhase Shift Keying (8-PSK). The modulation is blindly detected by thereceiver using training sequences. The radio blocks include a protectedheader, which has one format for GMSK and two formats for 8-PSK. Thetwo formats of 8-PSK are differentiated from each other using stealing bits.The information on the used modulation and coding scheme (MCS) is thencarried in the protected header. The coding schemes are listed in the tablebelow, and the exact formats are specified in the GSM Specification(05.03).

Table 62. EGPRS Coding Schemes MCS-1 - MCS-4

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

Peak throughput (bps/timeslot)

8800 11200 14800 17600

Modulation GMSK GMSK GMSK GMSK

MCS family C B A C

Format of protectedheader

3 3 3 3

RLC Blocks in radioblock

1 1 1 1

Table 63. EGPRS Coding Schemes MCS-5 - MCS-9

Name MCS-5 MCS-6 MCS-7 MCS-8 MCS-9

Peak throughput (bps/timeslot)

22400 29600 44800 54400 59200

Modulation 8–PSK 8–PSK 8–PSK 8–PSK 8–PSK

MCS family B A B A A

Format of protectedheader

2 2 1 1 1

RLC Blocks in radioblock

1 1 2 2 2

DN03299216Issue 9-0 en20/03/2008



In downlink packet transfer the PCU selects the MCS for each downlinkradio block within a TBF. Original transmissions may be performed in anyMCS, but for retransmissions of RLC blocks the coding scheme must bechosen to be the same as the original one or in some cases it can bechanged within an MCS family. The mechanisms used for the switch mayinclude padding the block with dummy bits, and/or changing the number ofRLC blocks in a radio block.

In uplink the PCU commands the MS to use a certain MCS in thePACKET_UPLINK_ASSIGNMENT message and can change thecommanded MCS in the PACKET_UPLINK_ACK/NACK orPACKET_TIMESLOT_RECONFIGURE message. The commanded MCSis used for all initial transmissions. Retransmissions of RLC blocks obeythe same restrictions as in downlink, but the MCS selection is controlled bythe commanded MCS according to rules in the GSM Specification (04.60).

All the EGPRS coding schemes from MCS-1 to MCS-9 are supported withincremental redundancy.

Initial MCS (MCS used before any measurement data is available) iscontrolled by the operator-modifiable parameters Initial MCS foracknowledged mode (MCA) and Initial MCS for unacknowledgedmode (MCU).

For synchronisation purposes, the network sends at least one radio blockevery 360 ms using a MCS or CS low enough that all mobiles can beexpected to be able to decode the block. If there are only EGPRS TBFs inthe timeslot, the synchronisation block is sent using CS-1 or a low enoughMCS. If there are GPRS TBFs as well, the synchronisation block is sentusing CS-coding.

EGPRS Link Adaptation Algorithm

For the acknowledged mode, the link adaptation algorithm is designed tooptimise channel throughput in different radio conditions. For theunacknowledged mode, the algorithm tries to keep below a specified BlockError Rate (BLER) limit. The algorithm is based on Bit Error Probability(BEP) measurements performed at the MS (downlink TBF) and the BTS(uplink TBF). BEP measurement consists of the mean and cv (= coefficientof variance = standard deviation / mean) of burstwise BEP, calculated overone radio block and averaged using an exponentially-forgetting filter. MeanBEP is expressed using 5 bits (range 0...31) and cv BEP using 3 bits(range 0...7). The operator can offset the reported mean BEP values usingthe parameters mean BEP offset GMSK (MBG) and mean BEP offset8PSK (MBP). The same offset is applied in both directions (uplink anddownlink).



The PCU chooses a lower MCS than what the Link Adaptation algorithmallows, if there is no room in the dynamic Abis pool for the higher MCSallowed by the LA.

Link Adaptation can be enabled and disabled with the parameter EGPRSlink adaptation enabled (ELA).

LA in the acknowledged mode

The algorithm includes an internal MCS selection table to select the MCSthat optimises throughput based on the BEP measurements. Both meanBEP and cv BEP are used as inputs. Also the desired modulation isselected at this step, taking into account the BEP values of bothmodulations.

In some cases, the MCS that has the highest throughput also has arelatively high BLER. In that case, although the throughput is high, there isalso a high number of retransmissions and therefore the requirement onreceiver IR memory is high and the delay can be quite large. The operatorhas the possibility to limit the estimated BLER to a certain value. Thisvalue is controlled by the parameter maximum BLER in acknowledgedmode (BLA). The algorithm computes a BLER estimate for each MCSbased on BEP measurements. Then the estimates are compared to theBLER limit, and an MCS whose BLER is higher than the limit is not allowedeven if its estimated throughput is the highest one.

The algorithm also has an internal mechanism to take into account IRmemory overflows of the MS.

For retransmissions, the algorithm preferably uses high coding schemes,so that a block first transmitted in MCS-6 (MCS-5) is usually retransmittedin MCS-9 (MCS-7). This gives up to 2 dB better throughput performancethan plain MCS-6 (MCS-5). If the BEP values are poor, then lower MCSs(MCS-5 and MCS-6) can be used instead.

LA in the unacknowledged mode

The BEP measurements are used to calculate an estimate of the BLER foreach MCS. Then the highest MCS whose BLER is lower than the operatoradjusted parameter maximum BLER in unacknowledged mode (BLU) isselected to be used for the next transmissions.

DN03299216Issue 9-0 en20/03/2008



12.12 Power control

GPRS power control consists of the uplink power control. Due to the databursts in traffic, the power control is not as effective as for circuit switchedtraffic.

Power control is used for optimising the signal strength from MS to BTS.The operator can use the cell-specific parameters binaryrepresentation ALPHA (ALPHA) and binary representation TAU(GAMMA) to optimise the signal strength. The gamma parameter (ΓCH inthe figure) sets the minimum MS output power level, and the alphaparameter (α in the figure) sets the slope for field strength effect to uplinkpower level.

Figure 36. Uplink power control

The power of each block needs to be sufficient for two MSs:

. The MS receiving the data

. The MS receiving the Uplink State Flag (USF determines the uplinktransmission turn in case several mobiles have been assigned to thesame uplink PDTCH).

05101520253035

-45

-50

-55

-60

-65

-70

-75

-80

-85

-90

-95

-100

-105

-110

Signal Strength (dBm)

gamma_ch = 30 alfa = 0.8

gamma_ch = 20, alfa = 0.3

Uplink power control

MS Outpu tPower (dBm)



12.13 MS Radio Access Capability update

When the PCU needs to know the MS's RAC information, but theinformation is not available in the PCU, the PCU initiates an MS RACenquiry from the SGSN. The enquiry is carried out by the Gb interfaceRadio Access Capability Update procedure defined in 3GPP 48.018.There are two PRFILE parameters controlling the procedure. ParameterTGB_RAC_UPDATE defines T5 /48.018/, and parameterRAC_UPDATE_RETRIES defines RA-CAPABILITY-UPDATE-RETRIES /48.018/.

DN03299216Issue 9-0 en20/03/2008



13 Implementing GPRS

13.1 Implementing GPRS overview

Purpose

Implementing GPRS means activating GPRS in BSC.

You can implement GPRS in the network by using BSC MMI or NokiaNetAct. In Nokia NetAct, GPRS parameters can be modified with PlanEditor and the Routing Area can be created with CM Editor.

For detailed instructions, see Activating and Testing BSS9006: GPRSunder Test and activate/Data in the PDF view.

Before you start

To enable GPRS in a BSC, you must have valid licences for the following:

. PCU or PCU2

. GPRS or EGPRS

Steps

1. Enable GPRS in the BSC.

2. Modify GPRS.

Typical instances for modifying GPRS are caused by changes incapacity, and related tasks could thus be, for example, modifying theGb interface or routing areas (RAs).

3. Disable GPRS in the BSC.

DN03299216Issue 9-0 en20/03/2008


Implementing GPRS

Disabling GPRS is a reverse operation to that of taking GPRS intouse, starting from disabling GPRS on a cell level to deleting theRouting Areas (RAs) and removing the Gb interface connection andrequired units.

It is possible to disable GPRS on a cell or TRX level, and not todisable GPRS altogether. This way, you only need to activate GPRSagain in the cell or the TRX to bring GPRS into use.

Further information

. Activating and Testing BSS9006: GPRS

. Enabling GPRS in the GSM radio network in Nokia NetAct ProductDocumentation



14 Implementing EGPRS

14.1 Implementing EGPRS overview

Before you start

You can implement EGPRS in the network by using BSC MMI or NokiaNetAct. For more information on implementing EGPRS with Nokia NetAct,see Building and Extending EDGE Coverage in Nokia NetAct ProductDocumentation.

The process of implementing EGPRS is similar to GPRS activation, exceptthat with EGPRS, you need to create the EGPRS Dynamic Abis Pool(EDAP) in the BSC and the BTS, attach it to the TRX and modify the EGENAparameter in the BSC.

Prerequisites

. GPRS must be enabled in the cell and EGPRS enabled in the BTSto enable EGPRS traffic in the BTS.

. All the TRXs that will be using EGPRS must have EDGE-capablehardware.

. Make sure you have an EGPRS licence installed. The licence isbased on capacity, that is, the number of TRXs. When installing thelicence, the initial state should be set to 'CONF'.

. Take into account the following concerning EDAP:. When the TRX has been created with EDAP defined at the

BSC, and EGPRS is enabled, the TRX must be attached toEDAP on the BTS side as well. Otherwise the Base ControlFunction (BCF) configuration fails.

. EDAP in the BSC must be inside timeslot (TSL) boundariesdefined in the BTS.

DN03299216Issue 9-0 en20/03/2008


Implementing EGPRS

This requirement has to be taken into account also whenmodifying EDAP size or changing the first and/or the last TSL.The TSL indexes in the BSC and BTS also have to match,regardless of how the TSLs are routed through thetransmission network. In other words, when modifying EDAP,the size of EDAP in the BTS has to be the same as the size ofEDAP in the BSC.

. Creating, modifying or deleting EDAP in the BSC causes aterritory downgrade/upgrade procedure to all territories servedby the PCU in question. This immediately pauses andresumes ongoing EGPRS/GPRS connections.

. The maximum EDAP size is 12 TSLs.

. EDAP must be located on the same ET-PCM line as TRXsignalling and traffic channels.

. There are no specific commissioning tests concerning EDAP.

. EDAP must be located on the same BCSU as the Gbinterface.

Steps

1. Configure EDAP for BTS

a. Open Nokia UltraSite BTS Hub Manager (UltraSite BTS) orBTS Manager (MetroSite BTS).

b. Open Traffic Manager.

c. Edit timeslots (TSLs) according to your network configurationplan and create EGPRS Dynamic Abis Pool (EDAP).

d. Modify EDAP end TSL, attach EDAP to the TRXs and clickOK.

e. Click OK in Traffic Manager.

Traffic Manager makes the required cross connections andsaves the D-Bus allocation to the master FXC.

f. Open BTS Manager (UltraSite BTS, not required with UltraSiteCX6.0 SW).

g. Update Abis allocation in the BTS (not required with UltraSiteCX6.0 SW).

In the Tools menu, click Update Abis Allocation.

Expected outcome

Check that all TRXs are up and running. During the modification,there is no GPRS territory downgrade.

Further information



For instruction on Flexi EDGE BTS, see Nokia Flexi EDGE BTSCommissioning, section Changing the settings of a commissionedBTS in Nokia Flexi EDGE Base Station Product Documentation.

2. Enable EGPRS in BSC

To enable EGPRS in a cell you first have to create the EGPRSDynamic Abis pool (EDAP) and then create a TRX which uses thepool. When the TRX using EDAP is created, GPRS must bedisabled in the cell. GPRS must be enabled in the cell (parameterGENA set to Y) and EGPRS enabled in the BTS (parameter EGENA setto Y) to enable EGPRS traffic in the BTS. If GENA is set to N thenEGPRS traffic is also disabled.

For detailed instructions on creating and enabling EDAP in the BSCusing BSC MML commands, see Activating and Testing BSS10083:EGPRS under Test and activate/Data in the PDF view.

Alternatively, you can create and enable EDAP in the BSC using theNetAct Radio Network Manager (only one object) or CM Editor(single or mass operation). For instructions, see Building andExtending EDGE Coverage in NetAct documentation.

3. Test the activation of EGPRS

For detailed instructions, see Activating and Testing BSS10083:EGPRS under Test and activate/Data in the PDF view.

4. Modify EDAP timeslots

a. Lock the BTS (EQS).

b. Disable EGPRS for the modified TRXs that are attached toEGPRS Dynamic Abis Pool (EDAP) (EQV).

c. Unlock the BTS (EQS).

GPRS calls are passed.

d. Open Nokia UltraSite BTS Hub Manager (UltraSite BTS) orBTS Manager (MetroSite BTS).

e. Open Traffic Manager.

f. Modify EDAP.

Open EDAP Properties dialog by right-clicking on top of theincoming EDAP, or double-click EDAP and select EDAPProperties.

g. Modify EDAP end timeslot and click OK.

h. Open BTS Manager (UltraSite BTS, not required with UltraSiteCX6.0 SW).

DN03299216Issue 9-0 en20/03/2008


Implementing EGPRS

i. Update Abis allocation in the BTS (not required with UltraSiteCX6.0 SW).


j. Update Abis allocation in the BSC (ESM).

You can modify the Dynamic Abis Pool in the BSC with theMML command ESM or do the same modification with RadioNetwork Manager in NetAct. For more information, seeBuilding and Extending EDGE Coverage in Nokia NetActProduct Documentation.

k. Lock the BTS (EQS).

l. Enable EGPRS (EQV).

m. Unlock the BTS (EQS).

Expected outcome

All TRXs are up and running and CS and EGPRS calls are passed.

Further information


5. Deactivate EGPRS in BSC

For detailed instructions, see Activating and Testing BSS10083:EGPRS under Test and activate/Data in the PDF view.

6. Remove EDAP from BTS

a. Open Nokia UltraSite BTS Hub Manager (UltraSite BTS) orBTS Manager (MetroSite BTS).

b. Open Traffic Manager.

c. Remove EDAP.

Delete EDAP by right-clicking on top of the incoming EDAPand selecting Delete Signal.

d. Open BTS Manager (UltraSite BTS, not required with UltraSiteCX6.0 SW).

e. Update Abis allocation in the BTS (not required with UltraSiteCX6.0 SW).


Further information




Further information

. Activating and Testing BSS10083: EGPRS

. Enabling EDGE in the Nokia BSS in Nokia NetAct ProductDocumentation

DN03299216Issue 9-0 en20/03/2008


Implementing EGPRS

15 Configuring Intelligent DownlinkDiversity

15.1 Functional requirements and restrictions

BTS hardware requirements

EDGE-capable TRXs and EDGE baseband units (BB2E/BB2F) arerequired for implementing Intelligent Downlink Diversity (IDD).

BTS software requirements

Nokia UltraSite BTS CX3.0 and Nokia Flexi EDGE BTS EP2.0 onwardssupport IDD.

Restrictions

. In software releases prior to UltraSite BTS CX4.1, IntelligentDownlink Diversity (IDD) sector cannot share a cabinet with abaseband (BB) hopping sector or antenna hopping sector, becauseIDD uses the BB hopping hardware in a different mode.

IDD sector with radio frequency (RF) hopping is possible, IDD sector(with or without RF hopping) can share a cabinet with an RF hoppingsector and/or another IDD sector.

. In software releases prior to UltraSite BTS CX4.1, a sector usingboth IDD and BB hopping is not possible.

DN03299216Issue 9-0 en20/03/2008


Configuring Intelligent Downlink Diversity

15.2 Supported configurations

The BTS can be configured to two different modes: IDD with 4-way uplinkdiversity (4UD) and IDD without 4UD. 4UD without IDD cannot be used.The BTS can simultaneously have normal TRXs/sectors, TRXs/sectorswhich function in IDD mode, and TRXs/sectors in IDD and BB hoppingmode with RTC.

It has to be possible to freely define the relationship between IDD mainand auxiliary TRX so that the existing antenna cabling can be used.

UltraSite IDD configurations

Figure 37. UltraSite IDD configuration – IDD only

There can be up to 6 pairs of IDD main and auxiliary TRXs. 4UD is notused.

MHA MHAMain transceiver with 2-way

reception and normal output power

Aux. Transmitterwith normal output power, no reception

IDD DOWNLINK AND 2-WAY DIVERSITY UPLINK1(main+aux.)+1(main+aux)+1(main+aux)2 feeders / cell

MTRX

ATRX



Figure 38. UltraSite IDD configuration – IDD and 4UD

The maximum configuration can be 2 IDD TRX+2 IDD TRX+2 IDD TRX.4UD is used.

4-WAY DIVERSITY UPLINK AND IDD DOWNLINK2+2+2Four feeders / cell

MHA

MTRX

ATRX

MHAMTRX

ATRX

MTRX = Main TRXATRX = Auxiliary TRX

DN03299216Issue 9-0 en20/03/2008



Figure 39. UltraSite IDD configuration - IDD only

The maximum configuration can be 6 IDD TRX. 4UD is not used.

15.3 Configuring BTS to IDD mode with BTS Manager

Defining IDD configuration in the BTS

Make sure that the desired BB2x and TSxB units have been installed andthe cables connected according to the figures in Supported configurations.Define the same hardware and cabling configuration with BTS HWConfigurator.

Start the manual commissioning procedure with BTS Manager. The IDDand 4UD parameters are defined on the Set Intelligent DownlinkDiversity page of the Commissioning Wizard. The following IDD-relatedinformation per TRX needs to exist: usage of IDD, mode of the IDD TRX(main/auxiliary) and IDD partner TRX, and 4UD usage. This informationhas to be saved permanently to the BTS system data (to VTXA/BOI) sothat it is available after resets.

2-WAY DIVERSITY UPLINK AND IDD DOWNLINKRTC combiningTwo feeders per cell6 IDD TRXs in one cabinet

MHA

MTRX

ATRX

MTRX

ATRX

MTRX = Main TRXATRX = Auxiliary TRX

ATRXATRXATRXATRXATRXATRX

MTRX

ATRX

MHA



The BTS checks the validity of the configuration message received fromBTS Manager. For example, both the main and auxiliary TRXs have tobelong to the same frequency band and both have to be EDGE-capable.The main and auxiliary IDD TRXs have to be connected with differentantennas and they should be connected to different RTCs in case of RTCconfigurations.

Adding a TRX to IDD configuration

Adding an IDD TRX (main TRX and auxiliary TRX) has to be carried outvia the commissioning procedure. If the BTS is already commissioned, youhave to undo the commissioning first. From UltraSite BTS CX4.1 softwarerelease onwards, you can add an IDD TRX at any state of the BCF withBTS Manager, providing that the BCF is locked during the procedure.

Removing IDD configuration

If you want to return an IDD TRX to ‘normal’ operation, you have to undothe commissioning and redo it manually. From UltraSite BTS CX4.1software release onwards, you can remove the IDD configuration at anystate of the BCF, providing that the BCF is locked during the procedure.

The BTS is first taken to local use, that is, the Abis has to be disconnected.Both TRXs (IDD main TRX and IDD auxiliary TRX) have to be configuredwith BTS Manager as normal TRXs. The Abis transmission has to berouted from the BSC to the BTS for the new normal TRXs. The branchingtable at the BTS has to be defined for the new normal TRX and the newTRX has to be defined to the BSC.

Transmission

The Abis transmission has to be defined only to the TRXs defined at theBSC. Signalling and traffic timeslots are branched only to the IDD mainTRXs and normal TRXs. This can be done manually with BTS Manager orautomatically by Autoconfiguration. Autoconfiguration has knowledgeabout which TRXs are auxiliary TRXs.

BTS initialisation

When the BTS starts up, it takes into account whether it is configured toIDD (and 4UD) mode. IDD mode means that the BTS has at least onemain-auxiliary TRX pair. If software downloading is needed when the BTSstarts up, new software is also loaded to the auxiliary TRXs. If theBTS_CONF_DATA message contains definitions for TRXs, which havebeen defined to auxiliary mode during commissioning, alarm 7606 withnew alarm details is activated. The alarm details indicate thatBTS_CONF_DATA contains definitions for the TRX defined to IDD auxiliarymode.

DN03299216Issue 9-0 en20/03/2008



If the BTS has non-EDGE TRXs installed and is commissioned to IDDmode, alarm 7606 is activated with the new alarm detail. The alarm detailwill indicate that the TRX does not support IDD mode.

In an RTC configuration, the main TRXs are connected to one RTC andauxiliary TRXs are connected to another RTC. When an RTC configurationis used, the RTC tuning of the IDD carriers (=IDD main and auxiliary TRX)can be done simultaneously, as the IDD main and auxiliary TRXs arephysically connected to different RTCs. The transmission of dummy burstscan be activated from both transmitters to the RTC cavities.

15.4 Configuring IDD in the BSC

In the BSC, create the BTS with the EQC command and the TRXs with theERC command. You have to define only IDD main TRXs and normal non-IDD TRXs. Make sure you know the IDD configuration on the BTS sitewhen defining the TRXs in the BSC.

4UD is defined in the BSC with the RDIV parameter: RDIV=Y (4-way RXdiversity is used).

If IDD is used only for boosting the BCCH carrier, the IDD TRX has to bedefined in the BSC as preferred BCCH TRX. This definition ensures thatthe IDD TRX is always used as the BCCH TRX when IDD TRX is in aworking state.

15.5 Alarm handling

There are no specific alarm numbers allocated for IDD.

If the RF module of an IDD main TRX has an alarm in the TX or RX part, itis reported to the BSC as IDD main TRX alarm. If the alarm is blocking,both the main and auxiliary TRXs are blocked out of use. If the RF moduleof an auxiliary TRX has an alarm in the TX part, it is reported to BSC as anon-blocking IDD main TRX alarm. If 4UD is not used, alarms from the RXpart of the auxiliary TRX are not reported and units are not blocked out ofuse. If 4UD is used, alarms from the RX part of the auxiliary TRX arereported to the BSC as non-blocking IDD main TRX alarms. LAPD linkfailure of IDD TRX causes both the IDD main and auxiliary TRX to beblocked out of use. BCCH transmission is stopped in both TRXs.



The auxiliary TRX does not activate alarms related to the Abis interface orD1-bus interface. If the BB module of the IDD main TRX has an alarm, it isreported normally to the BSC. If the alarm is blocking, both the IDD mainand auxiliary TRXs are blocked out of use. If the BB module of the auxiliaryTRX has an alarm, it is reported to the BSC as an IDD main TRX alarm. Ifan auxiliary TRX alarm is reported on the main TRX as a degraded alarm,the main TRX will no longer be a part of IDD hopping; it will work as anormal TRX. In BTS Manager it can be seen that the alarming unit is theauxiliary TRX. Alarms from other units, for example, dual duplex unit,connected to the auxiliary TRX(s) are sent to the BSC as mapped to thecombiner connected to the IDD main TRX(s).

If an auxiliary TRX is hot swapped, both main and auxiliary TRXs are resetand calls are dropped. Replacing the TRX should be performed by usingthe maintenance functions of BTS Manager.

15.6 RX antenna supervision and IDD/4UD

RX antenna supervision can be used in UltraSite BTS configurations.

In UltraSite BTS, IDD can be configured either with or without 4UD; thereceiving signal strength indicator (RSSI) values are displayed on a sectorbasis in both cases. If 4UD is not used, RSSI values for RX antennasupervision are requested only from the main TRXs. The results show themain TRX IDs and RSSI values for two antennas (if RX Diversity Selectionis set).

If 4UD is used, the UltraSite BTS performs RX antenna supervision byusing the RSSI values calculated for the four RX paths, that is, the mainauxiliary TRXs and four antennas. RX antenna supervision recognises theIDD and 4UD configuration. The results show RSSI values for fourantennas. In addition, if any TRX in the sector is in 4UD mode, RX antennasupervision is performed for the sector even if sector based diversity is notused.

15.7 Object state management

When a local TRX lock/unlock command is given to the IDD TRX, bothIDD main and auxiliary TRX are locked/unlocked.

DN03299216Issue 9-0 en20/03/2008



A TRX/BTS lock command from the BSC causes both the IDD main andauxiliary TRX go to a locked state (the BSC only sees the IDD mainTRXs). A TRX/BTS unlock command from the BSC causes both IDD mainand auxiliary TRX to be initialised. In an RTC configuration, related cavitiesare tuned in both combiners.

A BCF lock command from the BSC causes all TRX(s) go to a lockedstate. A BCF unlock causes site reset.

15.8 TRX reconfiguration

Reconfiguration happens when the BSC sends a new BTS_CONF_DATAmessage to the BTS due to some fault situation. From the IDD TRX pointof view it means that the channel configuration of the TRX is changed orthe ARFN of the TRX is changed. During an ARFN change, both the IDDmain and auxiliary TRX and, if RTCs are used, corresponding cavities fromboth RTCs have to be tuned to the new frequency.

15.9 TRX tests

When a TRX test command is activated from the BSC to the IDD TRX, theloop is executed via the IDD main TRX only.

When the test is activated with BTS Manager, it is possible to execute theTRX test to either the IDD main or auxiliary TRX, according to the testactivation command from BTS Manager. In the test activation command,either Loop Test through Main or Loop Test through Auxiliary isselected.

Related topics

. Nokia Smart Radio Concept

. Double Power TRX for Flexi EDGE BTS under Feature descriptions/Radio network performance in the PDF view.

. Activating and Testing BSS20870: Double Power TRX for FlexiEDGE BTS under Test and activate/Radio network performance inthe PDF view.



edge feature nokia(ned)

Documents