gsr9 delta

1

GSR9 Delta

2

• Blank Page

3

GSR9 Delta

Introduction

4

Chapter 1BSS features

• FR27962 - LCF Memory Savings to Prolong Life of GPROC2• FR25423 - Software Patching & • FR25424 - PCU Software Upgrade with no BSC Outage• FR28398 - Increased Network Capacity• FR22168 - Enhance BSC Capacity using DSW & • FR 25002 - BSC Expansion Matrix TDM Redundancy• FR28340 - BSP CPU Utilisation Reduction for Higher Call Handling Capacity• FR28333 - BSC LAN Unacknowledged Mode of Operation• FR23306 - BSC High Load Protection Mechanism Phase 2• FR28337 - BSC SLS Capacity and Flexibility Enhancement• FR28938 - Support of InCell as an Optional Feature• FR26481 - Support for Horizon II Micro Cabinet Identifier &• FR30365 - Support for High Power Horizon II Micro Cabinet• FR22266 - RSL Dimensioning Statistics• FR25867 - New Drop Call Rate (DCR) Classes• FR32340 - Cell OOS Timer

5

Chapter 2Increased PCU Capacity Features

• FR26740 - High B/W Interconnect between BSC & PCU (PSI)

• FR27955A - Software Support for High B/W and/or E1 BSC/PCU Interconnect• FR28351 - Add New BSC/PCU Hardware to Increase GPRS Capacity

• FR28006 - Packet/Coaxial Interface Module

• FR22415 - Increase the PCU Database Capacity

6

Chapter 3GPRS Features

• FR27717 - Support of RESUME at Intra-BSC level• FR23292 - Support for Extended Dynamic MAC Mode at the Air Interface• FR27703A - GSR9 QoS• FR30452 - DUAL PCU Mode• FR28000 - Increase Throughput of PRP• FR26881 - Support for Release 4 Based Extended Uplink TBF Mode• FR30828 - CTU2-D Asymmetric EDGE Feature

7

Chapter 4

OMC-R Specific Features

• FR27508 - BSS User Security Management

• Platform Support

• FR25663 - Implementation of Secure Services on Solaris based O & M products.

• Enterprise Backup Server

• FR27751/27752 3GPP Release 6 Performance Management IRP 2G. 3GPP Upgrade to Release 6 for 2G element manager FM and CM functionality.

8

• Blank Page

9

GSR 9 BSS Features

Chapter 1

10

Chapter 1BSS features

• FR27962 - LCF Memory Savings to Prolong Life of GPROC2• FR25423 - Software Patching & • FR25424 - PCU Software Upgrade with no BSC Outage• FR28398 - Increased Network Capacity• FR22168 - Enhance BSC Capacity using DSW & • FR 25002 - BSC Expansion Matrix TDM Redundancy• FR28340 - BSP CPU Utilisation Reduction for Higher Call Handling Capacity• FR28333 - BSC LAN Unacknowledged Mode of Operation• FR23306 - BSC High Load Protection Mechanism Phase 2• FR28337 - BSC SLS Capacity and Flexibility Enhancement• FR28938 - Support of InCell as an Optional Feature• FR26481 - Support for Horizon II Micro Cabinet Identifier &• FR30365 - Support for High Power Horizon II Micro Cabinet• FR22266 - RSL Dimensioning Statistics• FR25867 - New Drop Call Rate (DCR) Classes• FR32340 - Cell OOS Timer

11

LCF Memory Savings to Prolong the Life of a GPROC2

FR 27962

12

Feature Overview

GSR9 introduces a higher capacity BSC in terms of carriers, sites, CICs, etc. and as such, requires additional memory for the database object as well as the normal increase in object size due to adding functionality in support of features in the release such as QoS etc.

The GSR9 load will exceed the GPROC2 maximum available memory.

This software feature will save some LCF memory (about 3.5M) to prolong the life of existing GPROC2.

OverviewIt will not load GPROC2 with PSI object, GPROC3-2 PQ2 object and PCU related objects in the initialization of a GPROC2 or BSC. It also removes half of the BTS objects from each of the GPROC2-LCFs in order to save memory. During a BTS site initialisation, the pool GPROC2 and GPROC3 have higher priority to be selected as source to download the BTS. If there is no available pool GPROC2 or GPROC3 for code loading, the BSC uses two GPROC2 LCFs as source to download the BTS. Each GPROC2 will have a different half of the BTS objects. In the two source GPROC2-LCFs, only one is assigned as the controller, the other one functions as a 2nd source. A GPROC can be assigned as the 2nd source for multiple download controllers at a time. As a controller GPROC only supports one BTS download at a time, the number of parallel BTS downloading is determined by the number of total available GPROCs in the BSC. In GSR9, this number will be same with pre-GSR9 releases.A pool GPROC2 contains all the BTS objects. When a pool GPROC2 is assigned as LCF or OMF, the BSC will determine which group of objects this board will store. The BSC then commands the board to delete BTS objects which are not in the selected group. After half of the BTS objects are removed, the GPROC2 will have enough memory for starting the LCF or OMF function. The controlling IP uses the objects on the local board and 2nd board to download the BTS.

13

Feature Overview




When a single GPROC2 jumping into RAM needs to be assigned as a LCF, the same scenario happens to the GPROC for stripping half of BTS objects.After a GPROC2 is assigned as a LCF, BSC CA will determine which group of BTS objects this LCF will store and will label the LCF with a group ID. The range of ID is 0 or 1. The CA will save the BTS objects grouping information internally. After a BSC jumps into RAM state, the BSC will divide the BTS objects except for those used by both BSC and INCELL BTS into 2 groups (0 and 1). The size of objects in the 2 groups should be as even as possible. The recommended value for the difference is less than 100Kb. The BSC will delete a BTS object from a LCF if the object has a different object group id as the LCF group id. Before the CA starts the LCF function on a GPROC2, the CA will send a message to GPROC2-LCF COM to purge the BTS objects not needed for this board, by using the existing COM interface.A GPROC can only be the controlling source for one download session at a time as determined by the design of the IP process. When a GPROC2 is selected as controlling source to cross load a GPROC3, the second source must be a GPROC3. In selecting source for code loading a BTS or GPROC2, the pool GPROC2 and GPROC3 shall have higher priority than GPROC2-LCF or GPROC2-OMF, and Pool GPROC2 shall have higher priority than GPROC3. Note: “Pool GPROC” means a GPROC which is in Enabled-Unlocked state.

A “Pool GPROC” is in RAM state.

14

Feature Overview




When GPROC2-LCF or GPROC2-OMF is selected as the controlling source to load a BTS or GPROC2, the BSC shall use another GPROC as the second source. When two GPROC2-LCFs are selected to load a BTS or GPROC, each GPROC2-LCF shall have a different half of the BTS objects. When the GPROC2-OMF is selected as controlling source for code loading a BTS, the 2nd source must be a Pool GPROC or GPROC3.

Notes: 1. All BTS objects are removed from GPROC2-OMF. This was introduced by

GDBP feature.2. The CSFP must be a GPROC3 in GSR9 otherwise the GPROC cross load

may fail due to the GPROC2 being out of memory.3. The BSC will select GPROC3 as source in GPROC LAN broadcast cross

loading.4. When an LCF is assigned to a pool GPROC2 which was selected as the

source GPROC for a on going xload and BTS download session, the on-going xload and download session shall be killed and a new source to continue xloading/downloading will be selected.

5. During the source reselecting procedure, the xload target GPROC and the download target BTS shall not reset and continue the xload/download code from the new source.

15

New, modified and deleted commands

There are no new commands introduced with this feature

There are no new alarm threshold database elements introduced

The are no modified commands at the BSS as a result of this feature

There are no deleted commands as a result of this feature

16

BTS Downloading

BTS Downloading

During BTS site initialisation, the BSC can select one GPROC2 as controller to download to the BTS.This is the same with pre-GSR9, however the difference is BSC will select another GPROC as 2nd source and send the ID of 2nd GPROC to the controller GPROC.The controlling IP use the objects on the local board and 2nd board to download the BTS.

17

INCELL Download

1. CA commands LCF-2 to download to BTS, using LCF-1 as the 2nd source.2. BTS queries the LCF-2(IP) about the object status and calculates the

download list.3. BTS requests LCF-2(IP) for download an object.4. LCF-2(IP) fetches object block from the local COM and LCF-1(COM).

18

MCELL Download

1. CA commands LCF-2 to download to BTS, using LCF-1 as the 2nd source.2. LCF-2(IP) queries the BTS object status and calculates the download list.3. LCF-2(IP) commands LCF-2(COM) to download BTS object set 2.4. After step 3 is completed, LCF-2(IP) orders LCF-1(COM) to download BTS

object set 1.

19

COM Multiple Downloads

A GPROC can be assigned as the 2nd source multiple times at a time. But the controller GPROC can only work with one BTS download at a time.

This is mainly because the IP design only supports one download session.BSC shall support a GPROC assigned as 2nd source for a maximum of 10 code

loading sessions at a time.

Note:

1. With this function, in GSR9, if the BSC has N GPROCs in service, the BSC can support downloading a maximum number of N BTSs in parallel.

2. This number is the same with pre-GSR9 release.3. The COM process is already able to support multiple code load dialogs.4. The IP process on the controller GPROC communicates with COM on the 2nd

source GPROC directly.

20

• Blank Page

21

Software Patching & PCU Software Upgrade with no BSC Outage

FR 25423, FR25424

22

Feature Overview

This feature would allow software to be dynamically modified without requiring box restarts. Patch fixes will not be applicable to all problems, particularly those where multiple software processes rely on the layout of a particular data structure. Problems involving fixes confined within a single code object will be ideal candidates for patching.

This is a customer visible feature.

This feature allows a new software release to be loaded on the PCU without impacting the BSC.

Customers can get service packs upgraded more readily for PCU issues and allow easier resolution of PCU problems without impacting voice call revenue, however GPRS calls will be dropped during PCU software upgrade.

OverviewThis functionality will be supported using CSFP download and swap procedure.The BSC would recognize that BSC objects are not changed therefore BSC will not reset during PCU software upgrade, only the PCU would swap & reset.The PCU will be able to take download in background mode and swap code objects after code download is complete.To support download of patches and applying patches to affected processes, the current code download mechanism will be impacted.Conventional download is used by the operator to download a complete software load and/or database, the BSS in this case will boot up in ROM. When the software load includes a patch object, which is identified by a unique code object number just like the rest of the code objects, the patch object will be downloaded to the BSS and XCDR in the same way as existing code objects.For CSFP download, code is loaded to a CSFP board. BSC will then codeload the CSFP software load and then start to propagate respective code objects to BTSs in the system.In GSR9, respective PCU code objects will be loaded onto PCU as well. Only objects that are different from CSFP load will be downloaded.

23


There are new elements introduced with this feature:• nePatchObjectVer• nePatchObjectLev• Csfp_flow


The are no modified commands at the BSS as a result of this feature


24

New Elements

Parameter Min Max Default Value Definition nePatchObjectVer 0

255 0 Specifies version of patch object.

Version of 0 indicates that there is no patch object included in this point release.

Parameter Min Max Default Value Definition nePatchObjectLev 0

255 0 Specifies patch object level

installed in BSS. Zero specifies no patch level. The actual max imum patch level to be installed is according to number of patch levels as specified in the patch object.

The new element – nePatchObjectVer is the version of the patch object which is distributed throughout the BSC/XCDR. It can be displayed at the OMC-R.The new element – nePatchObjectLev is patch object level which is distributed throughout the BSC/XCDR. It can be displayed at the OMC-R.

25

New PCU Element

Parameter Min Max Default Value Definition csfp_flow 10

100 10 This parameter selects the CSFP

flow control value that controls the amount of GSL link utilization that a CSFP download from BSC to PCU may use. Selectable in a range from 10 to 100 in steps of 10. The default value is 10%.

The new PCU element - csfp_flow selects the CSFP flow control value that controls the amount of GSL link utilization that a CSFP download from BSC to PCU may use.

Note:1. A value of 100 does not mean the link will be 100% utilized during the download,

only that CSFP downloads can proceed at the maximum throughput rate.

26

Patch Object Install and Allocation of Patch Level

OMC BSS

PatchLevelSet(CodeVersion,nePatchLevel,nePatchObjectVersion)

Patch Install

BTS

Patch_install_ack

Patch_install_complete (PatchLevel,Patchstatus) )

BSS Present

…….

Code Object Download Complete

Patch Install

IP directs COM to COM dialog to distribute the patch object to all network entities

PatchLevelSetResp(Status)

PatchLevelStatusNotification(CodeVersion,nePatchObjectVersion,nePatchLevel,Patchlevel Status)

27

Code Swap Procedure with Full BSS Reset

OMC BSS BSP BSC CSFP

Swap_codeload

Code version_upgradetype_query

BTS CSFP

Codeversion_upgradetype_response (upgrade_type,version)

Swa

p_codeload_resp (Status,NeUpgradeType)

Swap_codeload_ack (NeupgradeTypeResp)

Reset

Reset


28

Installing A New Patch OMC BSS

PatchLevelSet(CodeVersion, nePatchLevel,nePatchObjectVersion)

Patch Install

BTS PCU

Patch_install_ack

Patch Install

Patch_install_ack

Patch_install_complete (PatchLevel,Patchstatus)

Patch_install_complete (PatchLevel,Patchstatus))

BSS Present

…….

Code Object Download Complete

Patch Install

IP directs COM to COM dialog to distribute the patch object to all network entities

PatchLevelSetResp(Status)


The patch level can be changed via a PatchLevelSet action from the OMC.This action will cause the BSS to broadcast to all network entities, the new patch level.Once each BTS and the PCU have installed the new patch level, they will send back to the BSC, the patch level installed, and a status.If installing any of the individual patch levels up to and including the designated patch level has failed, then the status will indicate failure and the BSS will back out all patch levels and return to a patch level of 0 and will not reinstall a patch level until a new patch object is downloaded.The Figure shows the procedure to install only a new patch object and to apply patch levels to various subsystems.Patch levels can be de-installed by the Code Object Manager (COM) from boards which they reside.

29

Code Swap

OMC BSS BSP BSC CSFP Swap_codeload

Code version_upgradetype_query

BTS CSFP PCU CSFP

Codeversion_upgradetype_response (upgrade_type,version)

Swap_codeload_resp (Status,NeUpgradeType)

Swap_codeload_ack (NeupgradeTypeResp)

Reset

Reset

Reset


The Figure shows alterations needed to current code swap procedure to support the features.The scenario shown is when OMC acknowledges with a Full BSS Reset.

30

• Blank Page

31

OMC Support for Software Patching & PCU Software Upgrade with no BSC Outage

FR 25423, FR25424

32

Viewing theSoftware Inventory

To View the Software Inventory for a particular BSS:

1. Open the BSS D.V.2. Select Options > NE Software

33

NE Software D.V.

In the View we can see the Current and New software load for the BSS and the CSFP.If the Current or New loads do not have a Patch Version or Level associated with them the values are set to 0 (zero).

When a new load is to be set for BSS or CSFP the D.V. is placed in the Edit mode and the New Software or New CSFP load buttons are selected.This opens the Software Inventory Window.

34

Software Inventory Dialogue

The new load is selected in this window and then double clicked to add it to the BSS Software D.V.The Software window closes and focus is returned to the BSS Software D.V. where the Software and Patch information can be viewed.

35

Viewing and Selecting the Patch Level

The Patch Version is set and by default the Patch Level is set to the highest available in that Version.

By selecting the Patch Level Button the Patch Level D.V. is opened and the level required can be selected from the list.This procedure would be used if you required an earlier Patch level to be loaded onto the BSS.

Once the Software and Patch details have been set up a conventional or CSFP download can be initiated.

36

Activating the NE Patch

To send the Patch information to the BSC:

1. Select Load Mgt > Set NE Patch Level.2. In the confirmation window select OK to download the Patch Object or select

Cancel to Cancel.3. If you select Cancel another confirmation screen opens where you can select

OK to cancel.

37

Setting CSFP Flow

To set the PCU CSFP Flow value:

1. Open the PCU D.V.2. Select Edit - Edit3. Scroll down or find the PCU CSFP Flow value section4. Set the value to the desired figure5. Select File – Save File – Close

The value can be from 10 to 100 in steps of 10 (10, 20, 30 etc)

Default in the OMC-R D.V. is 0 which effectively turns off the CSFP Flow Control Function.

38

• Blank Page

39

Increased Network Capacity

FR 28398

40

Feature Overview

The increase in Network Capacity in GSR9 has implications on:

The configuration of the BSC• There will be an increase in the number of boards required – actual numbers are dependent on which GPROC boards (GPROC2 GPROC3, GPROC3-2) are hosting the software functionality.• The number of boards affect the number of messages sent on the LAN and sent/received from the boards.

The boards that will be used• Another GSR9 feature will allow the use of an E1 MTL that services up to the equivalent of 16 DSO MTLs, which is terminated by a GPROC3-2. There will be increased messages sent from the E1 MTL terminating GPROC3-2. Prior to this feature, a GPROC2 terminates only two DSO MTLs.

This feature, along with others has been implemented to increase Network Capacity. It is a purchasable feature. All features are restricted by the option “incNetCapacityOpt”. Value = 0 is restricted, Value = 1 is not restricted

The feature would increase the BSS database to over 6MB and up to 8MB.Up to 250 cells/sectors are supported.The number of sites increases from 104 (1 BSC, 100 BTSs and 3 PCUs) to 142 (1

BSC, 140 BTSs and 1 PCU).The number of active RF carriers increases from 512 to 750 per BSS.Trunk Circuits are increased from 3200 to 4800 CICs per BSC.It is expected that with 4800 CICs and 180k BHCA on the GSR9 Traffic Model, the

number of E1 HSP MTLs should not exceed 4.The Maximum number of BSC-XCDR connections that a BSC will support will

increase from 27 to 42.Note:1. The GSR8 RXCDR already supports 4800 CICs with AMR HR and/or GSM HR

enabled.

Benefits:1. Increased capacity2. Increased operability3. Increased performance4. Reduced CAPEX (CAPital EXpense)

41


There are new elements introduced with this feature


The are modified commands at the BSS as a result of this feature:Equip 0 siteEquip<site number>RTFEquip<site number>DRIEquip 0 CICAdd_conn

There is a new statistic:lanstats – new emon command

- shows number of messages packed/not packed between processors

The operator can equip more BTS sites, more RTFs and DRIs and more CICs at the BSC by the following commands:

equip 0 siteequip <site number> RTFequip <site number> DRIequip 0 CIC

The operator can add more connections between BSC and RXCDR by add_connThe number of ATERs increases from 6696 to 10416

42

MMI Commands

MMI commands affected:

• Equip• Disp_options• chg_element/chg_cell_element (for the incell_support element)

43

Benefits/Limitations

Benefits:

• Ability to configure bigger BSCs• Less infrastructure cost

Limitations: • Enough cabinets/cages/boards must be installed to support the increased database• The number of Cells allowed per BSC is still limited to 250• BSC LAN limitation• OMP CPU limitation• OMP memory limitation• OML bandwidth• RSL bandwidth

The critical parameter defining the BSC size is not the BHCA, which is very dependent on the call duration, but the Erlangs it can support.It is a common tactic for vendors to claim a high BHCA which on closer inspection is achieved by assuming very short call durations in the call model.The Erlangs per BSC is the parameter that defines how many simultaneous calls the BSC supports.This in turn is determined directly by the Trunks / CICs.There are of course other factors as illustrated on the next slide.

44

BSC Call Bottlenecks GSR6 – GSR9384 TRX

750 TRX

750 TRX

512 TRX

3200 CICs GPROC2

3200 CICs

3200 CICs

4800 CICs

GPROC2

TDM

GPROC3 -2

GPROC3 -2

TDM

A-int E1s

TDM

TDM A-int E1s

A-int E1s

A-int E1s

GSR6

GSR7/8

GSR9 4800 CICs

GSR9 3200 CICs

Abis E1s

Abis E1s

+ Abis E1s (PSI)

+ Abis E1s (PSI)

The first bottleneck is the number of TRX supported. 750 TRX is more than enough to support 4800 CICs, bearing in mind site configuration dependencies and HR.The second bottleneck is E1s. Abis, Ater and A interface E1s should be considered. In GSR9, the PSI card will remove GDS and GSL from impacting the BSC E1s supported by the MSIs – this frees up more E1s for Abis, Ater and A interfaces. With the PSI cards, the E1s required to support 4800 CICs are just sufficient provided careful E1 planning is employed.The third bottleneck is CICs or Trunks. It is crucial that the number of CICs supported in the BSC be increased to 4800 at least. A GSR9 BSC with 3200 CICs will not support many calls in addition to the GSR8 BSC. The GSR8 RXCDR already supports 4800 CICs (If AMR HR and/or GSM HR are enabled).The fourth bottleneck is processing power and the LAN. An estimate indicates that the increase in processing speed provided by the GPROC3-2 cards should be sufficient to support up to 5000 CICs, or 360,000 BHCA at 50s call duration.The same model also indicates that provided FR28333 BSC LAN Unacknowledged Mode of Operation and FR28340 BSP CPU utilization reduction for higher call handling capacity are supported, together with planning considerations to reduce paging load at the BSC and the implementation of a more efficient Ater search algorithm, then the BSC LAN and the BSP should be able to cope with 4800 CICs.More accurate analysis as well as proposals for paging load reductions are planned for delivery by Systems Engineering at the appropriate MGates.

45

BSC Call Bottlenecks GSR6 – GSR9384 TRX

750 TRX

750 TRX

512 TRX

3200 CICs GPROC2

3200 CICs

3200 CICs

4800 CICs

GPROC2

TDM

GPROC3 -2

GPROC3 -2

TDM

A-int E1s

TDM

TDM A-int E1s

A-int E1s

A-int E1s

GSR6

GSR7/8

GSR9 4800 CICs

GSR9 3200 CICs

Abis E1s

Abis E1s

+ Abis E1s (PSI)

+ Abis E1s (PSI)

The fifth bottleneck is the TDM highway.The new GPROC3-2 boards with their increased processing power reduce the total GPROCs required, while an efficient E1 planning strategy which is necessary to minimise E1 links will also minimise MSI impact on the TDM highway.With these, the TDM highway in a 7-BSU shelf BSC should be sufficient for 4800 CICs in GSR9.Should further TDM timeslots be required, for example in a high data deployment, then up to 8 BSU shelves could be deployed.One BSU shelf supports 1016 TDM timeslots, one GPROC3-2 board needs 32 TDM timeslots, one MSI needs 64 TDM timeslots.

46

Recommended GSR9 BSC maximum capacities:

180,000 (call duration 96s)288,000 (call duration 60s)

Maximum BHCA rating

112T1/E1 links

4800Trunks (CICs)

750Active RF carriers-

250BTS Cells (sectors)

140BTS Sites

GSR9Item

It is recommended that the GSR9 BSC maximum capacities used are as shown on the slide.

47

Network Performance

Stats Impacts:

• Increase to stats file size from ~2.5Mbytes to ~4Mbytes• 4M expected to be compressed to 1M with compressed ratio of 75%• Current top stats upload rate: 5 Kbits/sec• Expected upload time: 17 minutes maximum

In order to make better distribution of stats traffic over RSLs the BSC CSP uses two stat buffers to gather stats from multiple SITEs in parallel, i.e. stats from multiple BTSs are gathered concurrently, likewise stats from BSC/RXCDR DSFs are gathered in parallel. Stats are gathered, sorted and compressed before being uploaded to the OMC-R. The time needed for collection and forwarding of statistics at regular intervals should not increase as a result of this new capacity.

48

Feature Interactions

• FR28398: Increased Network Capacity • FR28340: CPU Utilisation Enhancement• FR28333: LAN Packing• FR22168: Enhanced BSC Capacity Using DSW2• FR28337: High Speed MTL• FR23306: BSC High Load Protection Mechanism• FR22169: Support 96 MSI at BSC (GSR8)

49

Enhanced BSC Capacity using DSW &BSC Expansion Matrix TDM Redundancy

FR 22168FR 25002

50

Feature Overview

This feature, along with others, has been implemented to increase Network Capacity.

The increase in capacity is as follows:

512 carriers to 750 carriers3200 CICs to 4800 CICs

120K BHCA to 180K BHCA

This feature is restricted by the option “incNetCapacityOpt”.This feature is also often referred to as double clocking the TDM highway. This feature will expand the number of TDM timeslots in the BSC, when DSW2s and DSWXs are (exclusively) used, from1024 to 2048 (i.e. double capacity) in one switch cage using bank0/1 extension mode. The switch cage uses 1024 TSs (BANK 0), extension cages share the rest 1024 TSs (BANK1).

51

Expansion

D S W

Bank 1

Master switch cage

Parent switch cage

Parent switch cage

Parent switch cage

Child non-switch cage




D S W

D S W

D S W

Up to 2 More Child Cages




Extension/Expansion using DSW

The maximum supported extension/expansion combination for a BSC is up to four DSW cages with the TDM in each DSW, housing cages extended to up to three extension cages.

Bank 0 (1024 timeslots) is available to the master, or expansion, cage.Bank 1 (1024 timeslots) is available to all extension cages off of that master or

expansion cage.There are up to 4 master/expansion cages, thus supporting 2048 * 4 TS.

Note;1. Actual availability is slightly less due to some reserved timeslots and

fragmentation during assignment.

52

Bank 0/1 Extension

The double clocking of the TDM highway will allow for maximum (2048 X 4) 8192 TDM timeslots, with limits of 2048 per DSW2, 1024 per cage. This will allow for additional equipment to be supported, such as MSIs or PSIs in multiple cages. Although the TDM bus is operating at double rate, the bit rate is reduced to single rate within individual cages, thus compatible with existing cards. A minimum of 6 cages is required for supporting 4800 CICs. Any device may use the extra timeslots (GPROCS, GDP, GDP2, EGDP,MSI, PSI XCDR, etc.).

The slide shows:1. Two Cages each with a DSW installed.2. Expansion DSWX cards used to allow the DSWs to communicate with each

other and transfer data at Double Rate.3. Extension DSWX or KSWX cards used to allow bank 1 of each primary DSW

cage to communicate with child (Extension) cages at Standard Rate.4. Bank 0 TDM in each Primary Cage communicating with boards within that

cage at Standard Rate.

For Extension cages a KSWX cannot communicate with a DSWX.This ability cannot be restricted.The RXCDR is not affected.

53

Bank 0/1 Extension

The reset_device command is used to transition to Enhanced Capacity mode in the BSC where the master and redundant DSW/DSWX are present.

The command will be rejected if the detected hardware contains a KSW/KSWX.As in the RXCDR, rules will be applied when assigning timeslots to banks 0 and 1

in order to minimize impact when a BSC is forced out of enhanced capacity mode (e.g. a DSW2 is replaced with a KSW).

In some cases such a transition may cause some conflicting devices using TDM timeslots which overlap others (as per the bank 0/bank1 operation) to be removed from service (as is the case today in the RXCDR).

Note that the RXCDR currently supports this (Enhanced capacity) mode of operation and the above behaviour is already accounted for in the software.

54

Bank 0/1 Extension

The implementation of double rate TDM along with the DSWs ability to store timeslots in two separate banks (bank 0 and bank 1), allows the transcoder subsystem to handle twice as much TDM traffic as the standard rate TDM configuration, thus allowing for double capacity.

The BSC shall detect the switching board types (KSW/KSWX/DSW2/DSWX) at site initialisation. If and only if both primary and secondary TDM highways fully constitute DSW2/DSWX, the BSC shall enable enhanced capacity mode. Otherwise the BSC will run in single rate mode.

Note:1. The BSC initializes in Single Rate Mode (Primary Highway) to perform

verification procedures.2. Only on completion of these activities and activating all devices will the BSC

perform the switching hardware checks, and if OK will configure the Secondary TDM Highway in Double Rate Mode and swap to the Secondary TDM Highway to enable Bank0/1 for Enhanced Capacity support with minimal delay.

3. If the BSS SW at the BSC determines during site initialization that enhanced capacity mode is not available, the BSS SW at the BSC shall generate an alarm for OOS MMSs disabled due to Enhanced Capacity Mode unavailable with the reason “DSW/DSWX Required”. The alarm will be cleared once all KSW and KSWX switching hardware is replaced by DSW and DSWX switching hardware and the operator has enabled enhanced capacity mode.

55

MMI Commands

MMI-RAM 0115 -> reset_device 0 TDM

The BSS SW at a BSS shall enable enhanced capacity mode via reset_device TDM command if the detected hardware contains the master and redundant DSW/DSWX and not KSW.

reset_device <location><device_name><device_id1>< device_id2>< device_id3>

location0 or BSC BSC1 to 140 BTSpcu or pcu_0 PCU

MMI Commands

If the reset_device 0 TDM command is issued the Software will attempt to enable Enhanced Capacity Mode where the master and redundant DSW/DSWX are present.

56

• Blank Page

57

BSC Expansion Matrix TDM Redundancy

FR 25002

58

FR 25002 BSC Expansion Matrix TDM Redundancy

Currently, in the event of failure of the Extension matrix, eg. active fibre disconnected, the software is designed to alarm and wait for OMC-R action. This is on the presumption that the status of the redundant Extension is not known.

For a multi-cage BSC/RXCDR, equipped with redundant KSW/DSW2, this feature ensures that in the event of a failure in the operational KSW/DSW2 extension matrix an immediate (less than 30 seconds) switch over of the redundant TDM highway is initiated.

If there is a reason not to switch, e.g. the redundant TDM highway is known to be out of service (as a result of the daily test), then a major alarm is sent to the OMC-R as per existing functionality. If the swap is unsuccessful then the BSC resets.

This gives an improvement in system availability through automatic switching to backup TDM bus if one is known to be available.

59

Technical Overview

Modification to the hardware fault management (HWFM) of the KSW/DSW2 Expansion matrix to ensure that the TDM highways are handled properly. This is required to meet the GSR9 Reliability and Availability target. Previously, operator intervention is required to initiate certain types of TDM swap which can result in a long service outage.

Currently upon detecting a fault in the active Expansion Matrix with a Redundant Expansion Matrix equipped, the fault manager maintains call processing but does not initiate a TDM swap. The system waits for the OMC-R to command a swap to the redundant TDM bus and associated expansion matrix. This is done because the Fault Manager does not know whether the redundant is OK as it has not likely been tested since boot-up.

There are two parts to the modified behavior:

1. The system will automatically swap to the redundant TDM highway upon detection of a fault.

2. An automatic daily swap to the redundant highway.

60

Technical Overview cont’d

The revised functionality for the first part is as follows:

1) During Initialization if a highway fails TDM loopback then an alarm shall be raised. (This is existing functionality.)2) If a fault occurs on a busy highway then if the redundant is E/U a swap will occur and:2a) an alarm raised on the faulted highway (D/U).2b) If the fault on the now D/U highway is cleared, the highway is restored to E/U (and the alarm

cleared).3) if a fault occurs on a busy highway and the redundant is Disabled or Locked, a new alarm type (indicating why no swap occurred and operator intervention is required) is reported and no other action is taken.

The swap mechanism will work as follows:

1) The operator can set a time for a swap to occur from the active highway to the standby highway.2) At the specified time the system swaps TDM highways (and notifies the operator).3) If no problem is encountered the system remains running in this state.4) If there is a fault detected on the new active side the system shall switch back to the previous (good) highway and report the event.

61

OMC-R Support forBSC Expansion Matrix TDM Redundancy

FR 25002

62

Turning the TDM Switchover Feature On/Off

To Turn the Feature on and off:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Search for or Scroll down to the Switchable Features List / TDM Availability

Enhancements Enabled (tdm_switch).4. Click on the button and select Enable/Disable.5. Select File > Save – File > Close.

By Default the Feature is Disabled.

63

Selecting the SAP Audit Schedules

To Change the TDM Switchover Time:

1. Open the Navigation Tree2. Highlight SITE 0 (BSC) under a BSS.3. Select Config_Mgt > SAP Audit Schedules.4. This opens the Schedules D.V.

64

To Change the TDM Switchover Time cont’d:

1. Find and select the TDM swap_test in the list2. Select Edit > Detailed View3. This opens the SAPAuditSchd D.V.

65

Setting the TDM Switchover Time

To Change the TDM Switchover Time cont’d:

1. Select Edit > Edit from the menu.2. Search for or Scroll down to the Audit Information Section.3. Change the Start/End and Interval Time as Required.4. Select File > Save – File > Close.

66

• Blank Page

67

BSP CPU Utilisation Reduction for Higher Call Handling Capacity

FR 28340

68

Feature Overview

This feature, along with others has been implemented to increaseNetwork Capacity.

The BSP CPU Utilisation Improvement feature is one of a number features targeted at GSR9 with the aim of supporting an increase in call handling capacity with a call load of 180K BHCA (96s call duration).

The specific aim of the BSP CPU Utilisation improvement feature is to improve the CPU utilisation at the BSP by improving the efficiency of the Ater allocation algorithm.

All features are restricted by the option “incNetCapacityOpt”.

The current algorithm was introduced in GSR7 with AMR phase 2.The GSR7 memory restrictions resulted in a 3 tier search algorithm designed to reduce the search time but without a high memory impact. However the resulting algorithm is not scalable and so as the load increases the search time and effort increases.In GSR9 CPU efficiency is the main focus and memory is less of an issue so the Ater search algorithm can be redesigned to be more efficient and more scaleable at the cost of higher memory usage.The new algorithm is a list based algorithm where Aters are allocated from the top of the available lists to minimise the search.

69

overload

overload

76%

Current

360k BHCA

250k BHCA

180k BHCA

34%34%68060

33%PQ II

24%24%68060

overloadPQ II

48%49%68060

65%PQ II

AM / SM splitAM optimisationGPROC 3-2proocessor

overload

overload

76%

Current

360k BHCA

250k BHCA

180k BHCA

34%34%68060

33%PQ II

24%24%68060

overloadPQ II

48%49%68060

65%PQ II

AM / SM splitAM optimisationGPROC 3-2proocessor

GSR9 Reference Service Mix Loadings on BSP(Behavioural Model data GSR9 reference service mix)

Performance and Capacity:

With the new Ater search algorithm, in conjunction with other GSR9 features, the GSR9 BSC shall support 180,000 Busy Hour Call Attempts (BHCA) under an appropriate configuration.The BSS will have the ability to support an increased number of calls in a mixed FR and HR call load.The BSC shall assure the mean BSP CPU utilization will not exceed 70%.The main change of this feature will focus on Ater allocation.Compared with AMR Phase 2, when a new call (mobile origination, mobile termination, external handover from MSC), CIC remap, or Ater switchover is initiated, BSC shall allocate resources by following the different allocation rulesFor an existing call rate change, BSC shall allocate Ater resources by following the different allocation rules

70

AM functionality

MMS 1 0

MMS 1 0

E1

MMS 0 0

GDP 1 0

BSC

RXCDR

E1 to BTS

E1 to MSC

32 timeslots

Ater (8k/16k)

SM

AMSM

AM

MMS 1 0

MMS 1 0

E1

MMS 0 0

GDP 1 0

BSC

RXCDR

E1 to BTS

E1 to MSC

32 timeslots

Ater (8k/16k)

SM

AMSM

AM

0 1 2 3 4 5 6 7

TS0

0 1 2 3 4 5 6 7

TS1

0 1 2 3 4 5 6 7

TS30

0 1 2 3 4 5 6 7

TS31

MMS 0GRP 0 GRP 1 GRP 2 GRP 3

0 1 2 3 4 5 6 7

TS0

0 1 2 3 4 5 6 7

TS1

0 1 2 3 4 5 6 7

TS30

0 1 2 3 4 5 6 7

TS31

MMS 0GRP 0 GRP 1 GRP 2 GRP 3

AM - Allocation Manager is responsible for dynamic allocation of terrestrial backing resources between the BSC and BTS, as well as dynamic allocation of Ater resources (16K group of timeslots on E1 link) between the BSC and RXCDR.

71

Feature Basics – Existing Method

Current Algorithm performs a linear search across All Aters to find a suitable free one

AM Optimisation:New search algorithm to efficiently manage FR and HR Aters.Maintain separate link list for each type of Ater source.Increased speed at cost of higher memory usage.Constant Time Search and Release of FR and HR Aters.Negligible load on BSP even in high capacity system.Utilises same GPROC 3 card.

72

Underlying Problem – maintaining interacting Free Resource lists

Pointer to Free Ater

Assign an HR Ater as half of this FR Ater in order to meet

demand

Problem: Free List pointer is no longer valid because the FR

Ater is now 2 HR Aters.

Simple solution is to maintain a list of Free FR Aters

that we can assign from, without searching the

entire Ater set.

Current Algorithm performs a linear search across All Aters to find a suitable free one

73

Solution : Double Linking

FR Ater Free List

FR_ptr

FR_ptr *

HR_ptr *

HR Ater Free List

HR_ptr

HR_ptr

HR_ptr *

FR Ater structure

HR Ater structure

Solution:

Two separate lists are kept relating to Full Rate and Half Rate Aters.

74


In GSR9, BSP Enhancement has interactions with the features of:

• AMR Phase 2• GSM Half-Rate• Dynamic Allocation of switch (RXCDR-BSC) Circuits• eMLPP • Emergency Call Pre-emption

In GSR9, BSP Enhancement has interactions with the features of:

AMR Phase 2GSM Half-RateDynamic Allocation of switch (RXCDR-BSC) CircuitseMLPP Emergency Call Pre-emption

75

BSC LAN Unacknowledged Mode of Operation

FR 28333

76

Feature Overview

The objective of this feature is to enable the GSR9 BSC LAN to support at least 180kBHCA and if possible, 250k BHCA, using the GSR9 traffic/call model. This feature, along with others has been implemented to increase Network Capacity.


77

Feature Benefits

• Packs messages going to the same destination together

• More efficient under heavy traffic conditions

• LAN congestion more likely to occur for increased number of messages, regardless of the messages size

• Therefore beneficial to send less messages but with larger sizes

• Interrupts per second from the LAN are decreased

The support of message packing on the LAN is an unrestricted feature.LAN packing refers to an algorithm whereby when a message is scheduled to be sent over the LAN to a particular destination, the GPROC transmit buffers are checked for other messages with the same destination.If such messages are found, they are then collated with the original message to produce a larger message, which is then sent across the LAN.On arrival, this concatenated message is then spilt out again.This will increase the efficiency of the LAN by reducing the number of messages sent.The packing algorithm takes advantage of the existing delays that accrue as transmit queues get longer with increasing traffic so packing efficiency increases as traffic load increases.The LAN Packing mechanism shall be implemented on the BSC, InCell BTS and the RXCDR and shall be implemented on GPROC2, GPROC3, GPROC3-2 and above.A GPROC that has just been brought into service sends a notification message to inform all other GPROCs that it supports the message packing/unpacking mechanism. It will only pack messages to other GPROCs that can support the unpacking mechanism. Other GPROCs then respond with a special MDL message notifying of LAN packing support.Paging messages are broadcast from the MTL-LCF to all/several different GPROCs (RSL-LCFs) simultaneously rather than on a point-to-point basis.

78

Maximum unpacked-equivalent message loads than can be supported using LAN packing

RSL-LCF: 960 messages/s MTL-LCF: 1200 messages/sBSP: 1730 messages/s

6 GPROC3-2 MTL-LCF8 GPROC3-2 RSL-LCF1 GPROC3 BSP4 DSW2

250k BHCA Greenfield (GSR9 call model with 60s call duration)

RSL-LCF: 770 messages/s MTL-LCF: 860 messages/s BSP: 1760 messages/s

4 GPROC3-2 MTL-LCF16 GPROC2 RSL-LCF1 GPROC3 BSP 4 DSW2

180k BHCA Legacy (GSR9 call model with 96s call duration)

RSL-LCF: 860 messages/s MTL-LCF: 970 messages/sBSP: 1420 messages/s

4 GPROC3-2 MTL-LCF8 GPROC3-2 RSL-LCF1 GPROC3 BSP 4 DSW2

180k BHCA Greenfield (GSR9 call model with 96s call duration)

Exec Message loads[1]ConfigurationsDeployments

[1] The messages listed are for sent or received.

The expected maximum effective message rates (unpacked) that can be supported using the LAN packing mechanism are dependent on deployment but an indication is provided in the Table shown, together with the associated deployments.The LAN I/O message rate should not exceed 600 msgs/s in Acknowledged Mode (limited due to LAN I/O coprocessor on each GPROC) and 1400 msgs/s in Unacknowledged Mode.

Operation:EXEC to pack messages in the message queues to the same destination each time EXEC has a message to transmit to another GPROC.Each time a GPROC receives an I-frame it will unpack the messages and route them to their respective destination software processes within the GPROC.

79

GSR9 Call Model

•180k BHCA (96s Call Duration)•250k BHCA (60s Call Duration)

•Implications on the LAN:–Number of cages

•typically 6•4 expansion + 2 extension cages

–Number of GPROCs •dependent on GPROC2, GPROC3 or GPROC3-2 usage)

–Number of DSW2s•4 with 2 in B0/B1 operation

–Number of switch connection requests•Worst case 2 per call setup, tear down and 2 per handover on average•Typically 1 per call setup, tear down and 2 per handover on average•2 handovers per call

80

LAN Congestion Mechanisms

• Token ring– LAN rate is 16 Mbps– Token is 3 octets– The BSP needs to transmit far more

messages than other GPROCs• TMS380 processor

– Limits the number of msgs/s transmitted per GPROC

– Ack: 600 msgs/sec/GPROC– UnAck: 1400 msgs/sec/GPROC

LANXGPROC

0

GPROC 1

GPROC 2

GPROC 3 GPROC

4

GPROC 5

GPROC 6

GPROC 7

TX RX

TOKEN

81

TMS380 Bottleneck: UnAck & Packing Solutions

600 msgs/s

600 msgs/sBigger msgs

1400 msgs/s

GPROC

- 1 message - 1 message - 1 message

GPROC GPROC

Current LAN packing UnAck Mode

How does it work?

Most recent Q_BLOCK queued to LAN hardware is examined.

If new msg to write will fit in this Q_BLOCK and Q_BLOCK has not been “en-queued” to actual hardware, memcopy new msg to end of Q_BLOCK and increase Q_BLOCK length field by msg length.

Modification of receive side to unpack incoming messages : use MSG_HDR->length to know when one msg ends in a packet and another begins

Additional checks to ensure packed messages only sent to destination GPROC that supports receiving packed LAN msgs

LAN packing in Ack ModeWill be implemented in GSR9

LAN packing in UnAck ModeNot supported in GSR9

82

• Blank Page

83

BSC High Load Protection Mechanism Phase 2

FR 23306

84

Feature Overview


This feature provides CPU utilization overload protection for the BSP.

The feature monitors the BSP CPU utilization in real-time. When the BSP CPU utilization jumps over the overload threshold, the feature starts controlling the amount of assignment requests andnon-imperative handovers to be handled by the system, by dropping them at random, so that the CPU utilization of the BSP can be kept under a safe level.


The BSS system only has one active BSP equipped.The availability of the BSP is critical for the system as it is responsible for BSS site management (FM, ALARM, STATS etc.)As the BSP also controls the switch management (SM) and circuit management (AM) functions the BSP CPU will have high utilization when the system is working under high call processing load.

The target of the feature is to make the BSP able to work reliably around 90% CPU utilization when the system receives excessive requests for calls and handovers which exceed the maximum processing capability of the BSP.As the feature makes the system more stable under high load of service requests, the operator may plan the BSP to work in a higher CPU utilization in normal time.

85

MMI Commands

Parameter Min Max Default Value Definition bsp_overload_protection 0 1 1 0: Disabled

1: Enabled

Display: bsp_overload_protection <location>i.e. <bsc>

Change: chg_element bsp_overload_protection <value><location> i.e. <1> <bsc>

The operator can enable/disable this feature by changing the value of the new database element “bsp_overload_protection”.

When the feature is enabled, the feature will be triggered automatically when the BSP jumps into CPU overload state.

This element can be displayed and changed at the OMC.It can be changed inside and outside of SYSGEN mode.It is optional in the creation of a BSS.

Possible Causes of High BSP CPU Utilisation:

1. While the BSC is processing a huge number of requests for handover and call setup/release, the BSP exhausts the available CPU resources.

2. A great number of alarms are generated in the BSS.3. A software fault in some BSP process causes high CPU utilization.4. Hardware fault.

86

Terminology and System Settings

BSP “safe-overload” threshold: The threshold of CPU utilization for the BSP transiting from non-overload state into “safe-overload” state.

BSP “critical-overload” threshold: The threshold of CPU utilization for the BSP transiting from “safe-overload” state into “critical-overload” state.

BSP “safe-overload” state: When the BSP CPU utilization is in the range of “safe-overload” threshold to “critical-overload” threshold, the overload control mechanism starts the control. The BSP has a high CPU utilization but still works reliably.

BSP “safe-overload” target point: This term is used when the CPU utilization is at mid-point between “safe-overload” and “critical-overload” thresholds. The control mechanism will attempt to move the utilization toward the mid-point when BSP is in “safe-overload”state, therefore it takes different action when the BSP CPU utilization is above and below the mid-point.

The “safe-overload” and “critical-overload” threshold are hard coded.

87

BSP Overload State Transition

No Overload Safe Overload

Critical Overload

utilization > 95Get BSP out of

this state

85 ~ 95Keep BSP in this

stateUtilization < 85Do nothing but monitor

the utilization

System Operation

The BSP calculates the CPU utilization and broadcasts to all LCF boards periodically (every 5 secs).When the CPU utilization goes over 85%, the BSC generates an alarm “BSP safe overload”.When the CPU utilization goes over 95%, the BSC generates an alarm “BSP critical overload”.The control mechanism attempts to prevent the BSP moving from “safe overload”into “critical overload” state.If the database element “MSC_BSS_OVERLOAD_ALLOWED” is enabled, the BSC will send “overload” message periodically to the MSC when the BSP is under overload state.(Cause Value: “processor overload”)

88

Rebalance LCFs every 5 seconds by overriding locally computed refresh values.

Transmits computed refresh values to BSP on demand;Resets computed refresh value to value specified by BSP (if rebalancing is being done).

Transmits computed refresh values to BSP on demand. Resets computed refresh value to value specified by BSP (if rebalancing is being done).

5) 88% ≤ U < 93%

If BSP utilization is > 88%, rebalance LCFs every 5 seconds by overriding locally computed refresh values.

Slow increase of computed refresh valueSlow increase of computed refresh value

4) 80% < U ≤ 90%

BSP periodically computes moving average of its utilization, and multicasts to MTL-LCFs & RSL-LCFs.

Rapid increase of computed refresh value

Rapid increase of computed refresh value

3) U ≤ 80%

BSP periodically computes moving average of its utilization;Multicasts to MTL-LCFs & RSL-LCFs.

Computed refresh value (value used to reset token bucket) set to minimum

Computed refresh value (value used to reset token bucket) set to minimum

2) Initialization

BSP periodically computes moving average of its utilization and multicasts moving average to MTL-LCFs & RSL-LCFs.

Monitor BSP Utilization message and respond as described below.Load tracking

Monitor BSP Utilization message and respond as described below.

Load tracking (as described in white paper)

1) ALL

BSP ActionsRSL-LCF ActionsMTL-LCF ActionsBSP utilization (U)

89

Critical overload alarms/ events logs / notifications to OMC-R; Transmit “OVERLOAD” to MSC with cause value = “PROCESSOR OVERLOAD” in accordance with GSM 48.008 specifications.

Computed refresh value set to minimum.Reject all HO requests;Send “OVERLOAD ONSET”message to BTSs.

Computed refresh value set to minimum.

8) U ≥ 95%

Major overload alarms/ events logs /notifications to OMC-R;Transmit “OVERLOAD” to MSC with cause value = “PROCESSOR OVERLOAD” in accordance with GSM 48.08 specifications.

50% reduction in computed refresh value.Reject all non-imperative HO requests;Reject inbound Inter-BSS HO requests; Send “OVERLOAD ONSET”message to BTSs.

50% reduction in computed refresh value, not below the minimum value.

7) 93% ≤ U < 95%

Minor overload alarms/events logs /notifications to OMC-R(refer to RSL-LCF Congestion Control SFRAS in GSR8 for similar alarming situation)

CM SERVICE REQUEST accept/reject (as described per white paper).

Page admission/dropping (as described per white paper).

6) 90% ≤ U < 93%

BSP ActionsRSL-LCF ActionsMTL-LCF ActionsBSP utilization (U)

90

Token Value Adjustments

80 82 84 86 88 90 92 94 96 98787674 CPU utilization %

Token

Adjustment

No Overload Safe OverloadCritical

Overload

Slowly increase token;Drop call may occur

Slowly decrease token

Rapidly decrease token

82 84 86 88

No Overload

Rapidly increase token;

Note: Probability of being in overload state for too long is low:The probability of BSP going too far over critical overload from safe-overload state is small (messages may be dropped in safe overload state).The control cycle is sufficiently fast (5 seconds) to reduce the BSP CPU utilisation from the sudden change to critical overload state.The LCF keeps two types of tokens separately for “assignment request” message from MSC and non-imperative “handover recognized received” message from BTS. A “handover recognized received” message can be identified as non-imperative by a field in the message.In a BSP broadcasting cycle, the LCF is not permitted to process each type of message more than the number of corresponding tokens. This is because these two messages will cause the LCF to send a message to the BSP.The LCF tracks the numbers for “assignment request” and non-imperative “handover recognized received” messages handled by the SSM in the last BSP broadcasting cycle. When the LCF receives the BSP CPU utilization message from the BSP, it calculates the new number for the tokens. The new tokens are used to control the number of message permitted to be processed in the coming cycle.

91

AlgorithmsOverload Control Algorithm – 1

• Overload Control (5 seconds cycle):

• CPU utilisation Thresholds:

• 70%: Load-control threshold; 85%: Safe-overload threshold

• 90%: Target Utilisation; 95%: Critical overload threshold

• The following actions will take place in the LCFs:

• CPU utilisation <70%

• Calculate the token value but not used to drop calls

• 70% <CPU utilisation <85%

• Rapidly increases token value by 10%

•CPU Utilisation <90%

• Slowly increase token value by 5%

•90% <CPU Utilisation <95%

• Slowly decrease token by 5%

•CPU Utilisation >95%

• Rapidly decease token by 10%

Algorithms:

Token bucket shaping algorithm is applied in this feature to control the load.Whenever the transmitter (LCF) sends a packet to the receiver (BSP), it removes a token from its bucket (that is, decrements the counter).If the bucket becomes empty (that is, the counter’s value is zero), the transmitter will no longer send packets to the receiver; instead, it will drop them.The receiver (BSP) periodically sends CPU utilization information to the transmitter, so that the bucket can be recalculated for the number of tokens (that is, the counter is updated with the re-calculated number of tokens).There are two token buckets defined for token bucket algorithm at SSM.One is for the assignment request messages from MSC, another one is for the non-imperative “handover recognize received” message.

92

Algorithms

Overload Control Algorithm 2

The following actions will take place in the LCFs once the token value is reached and the BSP CPU utilization is above 70%:

• Drop non-imperative handovers (RSL-LCF)

• Drop incoming inter-bss handover requests (RSL-LCF)

• Send OVERLOAD message to MSC periodically (MTL-LCF)

93


• The feature has interaction with GSR8 feature RSL Congestion Control on the function of sending overload message to MSC.

• The overload message can be triggered by RSL congestion as well. Only when both RSL congestion and BSP overload abate will the BSC stop sending the “overload” message to the MSC.

• The value for safe_overload guard timer is one minute.

94

Performance & Capacity

This feature doesn’t introduce any new impact to performance and capacity of the system. It makes the system more robust. This feature adds reliability and availability to the system under “high load”.

95

StatisticsNew Stats:PROCESSOR_SAFE_OVERLOAD: This statistic provides a measurement of total time the active BSP is working in “safe-overload” state of between 85% and 95%.

PROCESSOR_CRITICAL_OVERLOAD: This statistic provides a measurement of total time the active BSP is working in “critical-overload”state of above 95%.

HO_BLKD_BSP_OVERLOAD: This statistic provides a measurement for the number of non-imperative handover recognized message dropped by LCF due to BSP CPU overload.

Changed Stats:The existing statistic MA_CMD_TO_MS_BLKD was changed to counter array type. A new bin “BSP Overload” is added for the total number of times an assignment request from the MSC could not be processed due to BSP overload.

97

OMC_R Support for BSC High Load Protection Mechanism Phase 2

FR 23306

98

Turning theFeatureOn and Off

To Turn the Feature on and off:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Search for or Scroll down to the BSP CPU Overload Protection section

(bsp_overload_protection).4. Click on the button and select Enable/Disable.5. Select File > Save – File > Close.

99

BSC Signalling Link Set Capacity and Flexibility Enhancement

FR 28337

100

Feature Overview


Each BSC is connected to each MSC with a Signalling Link Set(SLS). Each Signalling link Set can accommodate up to 16 distinctSignalling Links (SL). At present the BSC supports eachsignalling link with a 64kbit/s DS0. However, as the BSC isdeveloped over successive releases, its capacity is increasing to apoint where we now need more capacity for the MTLs.

The increase in signalling loads are as follows:

• Additional CS domain signalling load• Additional service specific SMS and LCS signalling load, (MS

subscription authorization and managing call-related and non-call related positioning requests of GSM LCS which go through MTL).

•


There are several ways to effect SLS enhancement:

1. Increase the size of the Signaling Link to the next PDH quanta [i.e. 1xE1(2Mbit/s) as opposed to 1xTDM channel (DS0/64kbit/s)]

2. Allow a mix of DS0/E1(recommended utilization 15%/40%) Signaling links (depends on both options being supported, i.e.. existing plus 1)).

Note:

1. The MSC must support this feature.

101

GPROC3-2 Solution

LAN PROCTo LAN

LAPD INTF To TDM HW

To KSWMCAP INTFGPROC3-2

(MC68060)

Peripheral

SCCP_Pre

MTPL3/SCCP

SDRAM

SDRAM

SRAM

16MB

2 MB

64MHZ 32-bit

HDLC

128 MB

Backplane

MTPL2

PQII

At least one GPROC3-2 is required for hosting HSP LCF in BSC.Simple code change. CPU utilization balanced on MC68060 and PQII.DB access at PQII only required for timers, configuration parameters and etc (no

need to access cell id, and page group info for paging handling).Software objects backward portable on GPROC3 and GPROC2.This feature utilizes and requires the GPROC3 phase2 hardware at the BSC for

hosting HSP LCF to increase the MTL capacity.HSP LCF has the highest priority to pre-empt the GPROC3-2 over other

functions.The SCCP_Pre functionality is split from MTPL3 as a new process located at

PQII of GPROC3-2 to handle the downlink message sent from MSC.The E1 2MB MTL is terminated on a single GPROC3-2 with a PQII.Feature would allow the equipage of 16 MTLs (as it is now).Based on current CPU utilization of a GPROC2 with 2 x 64K MTLs, it is estimated

that a GPROC3-2 could terminate 6 x 64K MTLs or 20% of a 2MB MTL.

Note:1. gproc_slots must be set to 32

102

Feature Advantages

• Supports larger BSCs

• Provides more flexibility of configuration for MTL support

• Increases capacity for MTL (MSC transmission link) support

Feature Advantages1. GPROC requirements are reduced. This proposal would require one GPROC3-2 with

PQ2 per 2MB MTL.2. Better availability.

1. This proposal would allow equipping up to 16 x 2MB MTLs with the ability to bring all equipped links into service.

2. Full MTP change over and change back functionality would be supported. (Existing proposal only allows one 2MB link to come into service).

3. If more than one 2MB MTL is provisioned, the remaining MTLs remain in a hot standby state.

4. Swapping over to the standby would result in the signaling going out of service and then coming back into service.

3. No additional TDM timeslots would be needed. No additional work to support GPROC-GPROC links via the TDM highway.

4. Device management is simpler, should be more robust and have fewer bugs. (Device management of Master GPROC3 with slave GPROCs is more complex and has more error legs.)

5. Assuming 20% utilization, 3 x 2MB MTLs would be the equivalent of 16 x 64K MTLS. This could be done with 3 x 2MB MTLS on GPROC3s verses the current 16 MTLs on 8 GPROC2s. That is a substantial decrease in GPROC card slots.

Note:1. MSC must support HSP MTL

103

Feature Limitations

This feature doesn’t support the sub_equipped MTL functionality.Sub_equipped MTL allows number of MTL timeslots in MTL equipage to be

any value between 1 and 31 inclusive.

This feature doesn’t support the configuration of mixing HSP MTL and DS0 because there is no MSC support for this function at this stage and we are not sure if there are any vendors planning to support it in the near future.

This feature doesn’t support Bellcore SS7 specification on High Speed MTL.

104

Configuration

BSC 1 RXCDR MSC

BSC 2

MTLs& CICs

CICs HSP MTL

CICs & MTL

CICs

No Point in MTL going via RXCDR any more

A single LCF (GPROC3-2) will only be able to support 1 HSP MTL (or up to 2 x 64Kbps MTLs per LCF) max_mtl on the LCF must be 31

Valid range of max_mtl on LCF is 0,1,2 or 31Number of MTLs allowed on one BSC remains the same (16)Can not have a mixture of HSP MTLs and 64Kbps MTLs on one BSCMSC can support 64K MTLs on one BSC at the same time as HSP MTLs on

another HSP MTL will be required when more than 16 64Kbps MTLs are required

according to Network Planning Guide 68P02900W21.

Note taken from the Guide below:

1. It is recommended that the C7 links be designed to operate at no more than 20% link utilization when the MTL is running on a GPROC1 and no more than 40% utilization when the MTL/LMTL is running on a GPROC2 or GPROC3.

2. Before use of the 40% utilization for GPROC2 or GPROC3, it is imperative that the operator verifies if the MSC vendor can also support 40% utilization at the MSC end. If not, then only 20% link utilization should be used for GPROC2 and GPROC3.

105

Modified CommandsThe BSC will support the following modified MMI commands:

equipmtl_ratemax_mtlsmax_cblsmax_oplsmax_gslsmodify_valuereassignchg_elementdisp_equipmentdisp_mms_ts_usagedisp_hdlc

106

Modified Commands – cont’d

max_mtls - This element specifies the maximum number of DSO channels the BSP or LCF can manage as MTLs.0~2: 64k MTL31: HSP MTL (This attribute can be set to 31only if the Increased Network Capacity optional feature is unrestricted).Other values (3 to 30) are invalid

max_cbls This element specifies the number of CBL devices which the LCF can manage. Increasing the value may reduce the link capacity of the LCF. The max_cbls must be zero when max_mtls is set to 31.

max_opls This element specifies the number of OPL devices the LCF can manage. The max_opls must be zero when the max_mtls is set to 31.

max_gsls This parameter can be used only if the GPRS feature is unrestricted.

The sum of all max_gsls specified by the equipped LCFs must be greater than or equal to the total number of GSLs equipped. The value for max_gsls must not exceed the available LCF HDLC channel capacity. The max_gsls must be zero when max_mtls is set to 31.

The BSC will support the modified MMI command modify_value to modify any of the shown parameters.This command can only be entered at the BSC.Modify_value<location><value_name><new_value><dev_func><dev_func_id1><dev_func_id2><dev_func_id3>

107

Modified Commands - equip

The MSI must be equipped first

i.e. equip 0 MTL

Prompt Optional Range Default Enter the device identification for this MTL: N 0~15 none Enter the rate of this MTL: N* 1: 64kbps MTL

31: HSP MTL Other values reserved

1

Enter the first MMS description for this device: N 0~123 none Enter the second MMS description for this device: N 0~1 none Enter start timeslot on MMS where this device appears:

N** 1~31 (E1)

none

•* Only when Increased Network Capacity feature is unrestricted, this value can be set to 31.•** If MTL rate is 31, this value must be 1.•If user attempts to equip a mixture of MTLs, the equip command shall be rejected.

108

Modified Commands - equip

Equip<location><dev/func_name>i.e. equip 0 LCF

Prompt Optional Range Default Enter the function identification for the LCF: N 0~24 none Enter the number of DS0 channels the LCF can manage as MTLs:

N 0,1,2,31* none

Enter the number of LMTL the LCF can manage:

Y** 0~2 none

Enter the number of CBL the LCF can manage:

Y** 0~1 none

Enter the number of GSL the LCF can manage:

Y** 0~12 none

Note:

* For processing 64k MTL, valid value is 0,1 or 2 for all types of GPROC. For HSP MTL, the valid value is 31. In GSR9, value between 3 & 30 are invalid.

** these prompts only pop up when MTL DS0 channels handled by the LCF is set to 0,1 or 2.

109

Modified Commands – mtl_rate

mtl_rate <*>

Parameter Min Max Default Value Definitionmtl_rate 1 31 1 1 : 64kpbs MTL

31 : HSP MTL Other values are reserved.

This attribute cannot be set to 31 if the Increased Network Capacity optional feature is restricted.

The BSC will support the new per MTL element, mtl_rate which specifies the number of DS0 that the MTL uses.The OMC can display this item.

110

Modified Commands – reassign

The BSC will support the modified MMI command “reassign” for reassigning a MTL to LCF. The command changes the assignment of a child_dev device from its current parent_func to a new parent_func.

reassign<location><child_dev_name><child_dev_id1><chil_dev_id2><child_dev_id3>[<to>]<parent_func_name><parent_func_id1><parent_func_id2><parent_func_id3>

i.e. reassign a HSP MTL onto a GPROC3-2reassign 0 MTL 0 0 1 LCF 0 0 0

Prerequisite:

1. All GPROCs at the BSC (including the BSP) must be stable for at least 5 consecutive minutes since any GPROC has been transitioned.

111

Load Balancing

mtl_loadshare_granularity =0 (Default)load sharing granularity is set to 16 which means 16 logical links mapped to equipped physical MTL links. If this is the requested value, BSS accepts the change only if all equipped MTLs have the same mtl-rate.

mtl_loadshare_granularity =1load sharing granularity is set to 64 which means 64 logical links mapped to equipped physical MTL links. If this is the requested value, BSS accepts the change regardless of the equipped MTLs mtl-rate.

mtl_loadshare indicates the number of virtual MTL circuits used for load balancing.

The Element mtl_loadshare_granularity must be set to 1 before the mixed MTLs equipage.This CM parameter determines the load share granularity when mapping logical links to physical links.DB change does not take effect until all the MTLs are locked. This item exists in BSC and OMC-R. The BSC supports the modified command chg_element for the item.

112

New Timer for HSP MTL

A new timer (ss7_hsp_l2_t1 for HSP MTL) is used for signalling link alignment procedure called Timer Alignment Ready in ITU Q703.

This can be displayed using disp_element <location> command and can be changed using a chg_element <value><location> command at the BSC or OMC. It can be accessed/updated both in and out ofSYSGEN Mode.

i.e.chg_element ss7_hsp_l2_t1 <value><location>(each value step indicates a millisecond)Min: 25000 (25secs)Max: 350000 (350 secs)Default: 300000 (300 secs)

When bringing an MTL link into service it guards for the MSC response to a message confirming that the link is acceptable.

113

Modified Commands – disp_equipment

disp_equipment <location> [<dev/func name> <id1> [<id2>] [<id3>]] [full]

Example 1: displaying a HSP MTLMMI-RAM 0115 -> disp_equipment 0 mtl 1 0System responseDevice ID for the MTL: 1Link rate for the MTL: 31First MMS identifier for this device: 0Second MMS identifier for this device: 1Timeslot on MMS where this device appears: 1

Example 2: displaying a MTL LCF handling HSP MTLMMI-RAM 0115 -> disp_eq 0 lcf 1Function ID for the LCF: 1Number of DS0 channels the LCF can manage as MTLs [max_mtls]: 31Number of CBLs the LCF can manage[max_cbls]: 0Number of GSLs the LCF can manage[max_gsls]: 0

The BSC will support the modified MMI command disp_equipment for MTLThis command displays the software and hardware information of equipped devices and functions.Information displayed includes the parameters entered for a specific device or function using the equip command.

114

Modified ‘disp’ Commands – cont’d

disp_mms_ts_usage <site><MMS id> <MMS port>

disp_hdlc <site> lcf<id>

The BSC will also support modified MMI command disp_mms_ts_usage to support HSP MTL.This command displays the timeslot usage on any MMS link.The BSC will also support the modified MMI command disp_hdlc to support HSP MTL.This command displays the HDLC channel assignment types of an in-service GPROC device or function.

115

PerformanceThe biggest impact of this feature is on the collection and forwarding of additional statistics due to the increased number of managed objects.There is no increase in upload and collection time intervals.

New statistic: All current stats will be supported and there is an additional stat: (MTP_SL_ERROR_RATE_HSP) for HSP MTL.This statistic can be used to analysis MTP C7 performance and find faults on the SL. The statistic tracks the number of times that a Signalling Link (SL) is lost due to the Error internal monitoring threshold (TE) is reached during the monitoring period.

New alarm:All current alarm will be supported and there is an additional PM alarm:“Alarm: 13. MTL: SL failure - excessive error rate on HSP MTL- PM” for the HSP MTL.This alarm will be generated each time the threshold associated with the statistic MTP_SL_ERROR_RATE_HSP is reached

The threshold is set using the chg_stat_prop command.

116

Modified Key Statistics

• MTL_UTILISATION_RX• MTL_UTILISATION_TX

– Same Raw stats used as on GSR 8 for these Key Stats)

– Other parameter used: MTL_Rate • Modified input to the key stat. • There is now a valid input of 31

117


There are two features that have interactions with this feature:

• LAN Packing operation mode required To enable the GSR9 BSC LAN to support at least 180 kBHCA, and ifpossible 250k BHCA, using the GSR9 traffic/call model. It is required to hit the CPU and MTL utilization recommendation under the 180kBHCA by using the GSR9 call model.

• GPROC3-2 HSP MTL is terminated on GPROC3-2 with PQII processor. There is only one HSP MTL per GPROC3-2 board. HSP LCF has the highest priority to preempt the GPROC3-2 over other functions (except for OMF). The SCCP_Pre functionality is split from MTPL3 as a new process located at 68060 of GPROC3-2.

118

• Blank Page

119

OMC-R Support for the BSC Signalling Link Set Capacity and Flexibility Enhancement

FR 28337

120

BSS D.V. Showing Increased Network Capacity Feature

For the feature to operate it must be shown in the BSS Features list and must be un-restricted (Enabled).

121

Setting the T1 SS7 HSP L2 Timer

The timer can be set to:

Min: 25000 (25secs)Max: 350000 (350 secs)Default: 300000 (300 secs)

This timer guards against the failure of the link to establish.If it times out the system will attempt a new connection set up.

122

Setting the MTL rate for HSP Operation

When creating the MTL in order to use the HSP feature the MTL Rate must be set to 31.The MMS Timeslot Identifier must be set to 1.

123

Creating the LCF

When creating the LCF function the value for Max Number of MTL (max_mtls) should be set to 31 for the HSP.When Max Number of MTL is set to support the HSP (31) the CBLs and GSLs must be set to 0 (zero).Any attempt to change CBLs or GSLs to non zero will cause a failure to create the LCF function.

124

• Blank Page

125

Support of InCell as an Optional Feature

FR 28938

126

Feature Overview

This feature is to provide the ability to restrict the use of InCell BTS sites within a network if necessary.

Therefore the use of InCell becomes a purchasable option in GSR9.

In order to restrict the use of InCell BTS, before equipping any cabinet type that belongs to GPROC group (cabinet_type ranged from 0 to 9), the InCell support option must be unrestricted.

127

MMI Commands

IncellOpt

0 = restricted1 = unrestricted

N/A10IncellOpt

Value DefinitionDefaultMaxMinParameter

disp_optionsFeature 74

chg_element/chg_cell_elementFor the incell_support element

The IncellOpt parameter indicates whether or not the InCell Support feature functionality is unrestricted in the BSS software.The OMC can display this item.

128

MMI Commands

MMI-RAM 0115 -> equip bsc SITEEnter the site identifier: 1Enter the type of BSP or LCF: LCFEnter the function identifier for the BSP or LCF: 0Enter the RSL type: 64Does the site use dynamic allocation of terrestrial backing resources: No

MMI-RAM 0115 -> equip 1 CABEnter the CABINET identifiers: 0Enter the cabinet type: bts_5Enter the frequency type: pgsm, dcs1800

Equip

Equipage:InCell BSC cabinet can be equipped whether this feature is restricted or not.BSC(BSC-CM ) shall check InCell Support feature is unrestricted before allowing

any equipage of InCell BTS sites. The BSC will support the equip InCell BTS Cabinet if IncellOpt is purchased and

reject any InCell BTS Cabinet equipage if feature is restricted or not purchased.

Cabinet Types Are:1. bts4d_48V (0)2. bts4d_27V (1)3. bssc_48V (2)4. bssc_27V (3)5. bts_dab (4)6. Bssc_dab (5)7. Excell_4 (6)8. Excell_6 (7)9. Topcell (8)10.bts_5 (9)

129

OMC-R Support for Support of InCell as an Optional Feature

FR 28938

130

BSS Detailed View

In order for InCell to be used in a BSS the InCell feature must be visible in the BSS D.V. Features list and must be Un-Restricted (Enabled)

131

Support for Horizon II Micro Cabinet Identifier & Software Support for High Power Horizon II Micro

FR 26481FR 30365

132

Feature Overview

The Horizon2micro cabinet already exists as a hardware only solution.

These features will provide the software to govern the transmit power of the Horizon2micro and Horizon2micro High Power BTS platforms and differentiate cabinet types.

Post this feature being implemented, if you equip this cabinet as a Horizon2macro or Horizon2mini, then an alarm will be raised but the Horizon2micro will come into service.

Notes:

1. The Horizon2micro will not support Dual Band within a single cabinet.2. For Dual Band, an extension Horizon2micro cabinet must be equipped.

133

Feature Overview

This software support feature will focus on:

• New cabinet identifiers for main and extension cabinets

• Limited range for max_tx_bts

• Suppression of EAS opto alarms 9-16 regarding PIX ports 9-16 and relay 4

• Suppression of alarms 4, 6 & 8 (for Site device where FMUX0, FMUX1 & FMUX2 support a Horizon2micro extension cabinet)

134

Benefits

• Remote identification by the OMC-R of the cabinet type for network auditing and tracking activities

• Easier site equipage

• Automatic control of BTS transmit site power

Remote identification by the OMC-R of the cabinet type for network auditing and tracking activities

Easier site equipage

1. Prior to GSR9, the Horizon2micro will be equipped as either a Horizon2macro or Horizon2mini in the BSC configuration database.

2. Equipage of these site types prompts for redundant devices not available in the Horizon2micro.

3. This feature will support Horizon2micro specific site type equipment requirements with a corresponding reduction on the number of devices to be equipped. (i.e. only 1 BTP per cabinet – id 0)

4. The configuration management software will audit requested site equipage and ensure the correct number and type of devices are equipped. For example, only one CTU2 will be allowed per cabinet in the database.

135

Benefits

• Remote identification by the OMC-R of the cabinet type for network auditing and tracking activities

• Easier site equipage

• Automatic control of BTS transmit site power

Automatic control of BTS transmit site power

1. Prior to GSR9, there are no restrictions in the software for RF transmitting power and so it is possible to operate the unit at macro levels which could result in hardware damage if maintained for long periods.

2. This feature will automatically restrict the Horizon2micro platform within the specified limits for this site type.

3. Since this is designed to meet the micro platform requirements, it is desirable to ensure that the RF output power is restricted to acceptable levels for the operating environment.

4. The software will also disable a CTU2 from coming into service if it has been calibrated in single density mode and is configured for double density mode with max_tx_bts setting of 5 or 6.

5. This also applies for bts_txpwr_max_inner, in the case of dual band cells.6. This is to ensure that the unit is operating within specified limits of the product.7. The high power version of Horizon2micro does not have a separate cabinet

type however when the radio is brought into service the software will detect the cabinet type is high power and allow the appropriate levels to be transmitted.

136

MMI Commandsequip_device

Parameter M in M ax Default Value Definition Cabinet_type 0 29 No default An entered value 28 or

“HORIZON2MICRO ” means the cabinet is a H2micrp. An entered value 29 or “HORIZON2MICRO_EXT” means the cabinet is a H2micro extension.

Table 1 – C AB device Attribute Values equip <site> CABEnter the cabinet identifier: 0Enter the cabinet type: Horizon2micro or 28Enter the frequency type: PGSM or 1

equip 8 easEnter the 1st id (cabinet) for the EAS: 0Enter the relay wiring of the 3 relays (0-N/O, 1-N/C):1 1 1Enter the no alarm condition for the 6 optos (0-closed, 1-open): 0 0 0 0 0 0 Enter each opto whose state changes are to be reported: 1 2 3 4 5 6

BSS Software Support:1. The BSS will permit the user to run rf_lopback tests but not vswr_monitor tests in a

Horizon2micro cabinet.2. The BSS will not prompt for combiner information if a DRI is to be equipped to a cabinet of type

Horizon2micro or Horizon2micro_ext.3. The BSS will allow the operator to modify the tcu_port parameter to a value no greater than 0

where the DRI is equipped to a Horizon2micro cabinet.4. The BSS will allow the operator to equip a DRI where the antenna_select parameter is 1 or 2

only.5. The BSS will not allow the operator to modify the value of antenna_select parameter to any value

other than 1 or 2.6. The BSS will only allow the operator to equip opto alarms 1-6 to EAS at Horizon2micro master

and extension cabinets (7 to 16 are out of range).7. The BSS will take the DRI OOS if the FRU type H2micro and CTU2 Tx power is out of range and

raise an alarm.8. The maximum transmit power at the top of the cabinet is as follows:

EGSM DCS1800SD 4W (36dBm) 3.2W (35dBm)DD 2W (33dBm) 1.6W (32dBm)

9. The BSS will support Door Open alarms be raised for H2micro.10. The BSS will support a master cabinet and up to a max of 3 expansion cabinets.11. The BSS will allow micro and macro cells to coexist at a site.12. The EAS device corresponds to external customer-defined alarm inputs at a H2micro BTS.

137

unequip_device

disp_equipment

MMI Commands – cont’d

unequip <site> CAB 15 0 0 (cabinet must be locked)

disp_equipment <site> CAB 15 0 0 fullCabinet id: 15Cabinet type: Horizon2microFrequency type: PGSMHardware information:FRU:Horizon2_microKit Number: N/ASerial Number: N/AHardware Version Number: N/APSU:M4-48 DCKit Number: N/ASerial Number: N/AHardware Version Number: Unavailable

The BSS will support display disp_eq CAB full information for Horizon2micro in the same format as Horizon2mini.

138

modify_value

MMI Commands – cont’d

modify_value 5 cabinet_type 28 CAB 0 0 0

modify_val 6 opto_reporting on eas 0 0 0Enter the opto(s) whose state changes should now be reported: 1 3 6

139

OMC-R Support for Horizon II Micro Cabinet Identifier

FR 26481

140

Cabinet Selection D.V.

When creating a Cabinet the Cabinet Type drop down menu now supports Cabinet Type 28 & 29.

141

RSL Dimensioning Statistics

FR 22266

142

Feature Description

This Feature will enable the operator to determine the number of octets sent over the Abis interface.

In this way link utilization could be determined.

This would enable Abis dimensioning using methods already used in other links such as the MTL.

This statistic will help in detecting the causes of various resets at BSC level on the network.

This statistic will be useful in trouble shooting and RSL provisioning without a visit to site to install a protocol analyzer.

143

Technical Description

Prior to this release RSL provisioning is achieved by the use of a call model equation provided in the Motorola planning manual.

The equations provided in the planning manual are for initial/early network rollout and they do not take into account aspects that can be enabled/disabled at the MSC such as authentication, ciphering, etc or the variable length of the paging messages and SMS messages.

The new RSL dimensioning stats will be available on a per RSL basis, so if a site has 2 RSL links, then there will be 2 sets of RSL dimensioning stats.

144

New Statistics added

3 raw stats defined per RSL in BSC:

RSL_TX_OCTETSRSL_RX_OCTETSRSL_LINK_INS

2 key stats defined in OMC:

RSL_TX_UTILIZATIONRSL_RX_UTILIZATIONRSL_LINK_INS

3 new raw stats and 2 key stats are introduced by this feature.

3 raw stats defined per RSL in BSC:

RSL_TX_OCTETSRSL_RX_OCTETSRSL_LINK_INS

2 key stats defined in OMC:

RSL_TX_UTILIZATIONRSL_RX_UTILIZATIONRSL_LINK_INS

145

Description of RSL_LINK_INS (Duration)

The RSL_LINK_INS statistic tracks the time that a RSL link is in service within apredefined interval.

PeggingThis statistic is started when the RSL link is in service and ends when the RSL link becomes OOS within a predefined interval.

AnalysisReference - None.Usage - RSL Congestion Control. Quality of service.Basis - RSL link.Type - Duration.

146

Description of RSL_RX_OCTETS (Counter)

The RSL_RX_OCTETS statistic collects the total length of octets transmitted over the RSL link from BTS to BSC when the RSL link is in service within predefined interval.

PeggingThe BSC collects the octets and provides a cumulative length of octets transmitted over an RSL link from BTS to BSC.For pre GPROC3-2 board, due to Chipset, the octets count is based on payload and LAPD header information. This does not include retransmissions and supervisory frames.The above limitations do not exist on GPROC3-2 boards as the LAPD protocol is provided by software.

AnalysisReference - None.Usage - Uplink utilization. Trouble shooting. RSL provisioning.Basis - RSL link.Type - Counter.

147

Description of RSL_TX_OCTETS (Counter)

The RSL_TX_OCTETS statistic collects the total length of octets transmitted over the RSL link from BSC to BTS when the RSL link is in service within predefined interval.

PeggingThe BSC collects the octets and provides a cumulative length of octets transmitted over an RSL link from BSC to BTS.For pre GPROC3-2 board, due to Chipset, the octets count is based on payload and LAPD header information. This does not include retransmissions and supervisory frames.The above limitations do not exist on GPROC3-2 boards as the LAPD protocol is provided by software.

AnalysisReference - None.Usage – Downlink utilization. Trouble shooting. RSL provisioning.Basis - RSL link.Type - Counter.

148

OMC-R Key Statistics

OMC can use the following formula to calculate the key statistics:

RSL_RX_UTILIZATION = RSL_RX_OCTETS * 8--------------------------------------------------------------(RSL_LINK_INS/1000)* (rsl_link_rate * 16000)

RSL_TX_UTILIZATION = RSL_TX_OCTETS * 8--------------------------------------------------------------

(RSL_LINK_INS/1000)* (rsl_link_rate * 16000)

rsl_link_rate in the formula is:

1 if the link is 16K bandwidth4 if the link is 64K bandwidth

149

New Drop Call Rate (DCR) Classes

FR 25867

150

Feature Description

This Feature will enable the operator to determine the number of calls that were terminated on the SDCCH as apposed to those terminated on a TCH.

The feature also expands the TCH reporting to enable differentiation between Full Rate (FR) and Half Rate (HR) TCH calls.

This feature will be useful in trouble shooting the Air Interface functionality.

151

New Statistics added

3 raw stats defined per Cell are:

RF_LOSSES_SDRF_LOSSES_TCHRF_LOSSES_TCH_HR

By using the RF_LOSSES_TCH & RF_LOSSES_TCH_HR the operator can determine the Number of Full Rate and Half Rate calls that have been affected.

3 new raw stats are introduced by this feature.

3 raw stats defined per Cell are:

RF_LOSSES_SDRF_LOSSES_TCHRF_LOSSES_TCH_HR

By using the RF_LOSSES_TCH & RF_LOSSES_TCH_HR the operator can determine the Number of Full Rate and Half Rate calls that have been affected.

152

Description of RF_LOSSES_SD (Medium Counter Array)

0 RX quality in uplink direction1 RX quality in downlink direction2 RX level in uplink direction3 RX level in downlink direction4 Others

The Others bin includes the following:

• After analyzing the measurement report, the statistic cannot be classified to bin 0 to bin 3.

• There is no measurement report available.

0 1 2 3 4

The RF_LOSSES_SD statistic tracks the number of calls lost while using a SDCCH. If a TCH is reconfigured to a SDCCH only the SDCCH statistics are configured.

PeggingThis statistic pegs the number of calls that were terminated due to RF problems.The statistic is pegged in the bins.The BTS implements an algorithm to determine the bin to be pegged.When a dropped call occurs, the algorithm analyzes the UL and DL measurement reports

in the BTS and generates a reason code.The BTS then pegs the statistic.If the specified threshold is exceeded, the 0. CELL: Radio frequency losses while using

an SDCCH - PM alarm is generated.

Usage - RF loss. Congestion. Quality of service monitoring. Fault finding. Installation and commissioning.

Basis - Cell.Type - Medium counter array.Alarm - Major.

Key statistics: RF_LOSS_RATESDCCH_RF_LOSS_RATE

153

Description of RF_LOSSES_TCH (Medium Counter Array)

0 RX quality in uplink direction1 RX quality in downlink direction2 RX level in uplink direction3 RX level in downlink direction4 Timing Advance (not in GSR9)5 Sharp decrease of signal level6 Others




0 1 2 3 4 5 6

The RF_LOSSES_TCH statistic tracks the number of FR & HR calls lost while using a TCH.

PeggingThis statistic pegs the number of calls that were terminated due to RF problems.The statistic is pegged in the bins.The BTS implements an algorithm to determine the bin to be pegged.When a dropped call occurs due to RF problems on TCH, the algorithm analyzes the UL and DL measurement reports in the BTS and generates a reason code.The BTS then pegs the statistic.If the specified threshold is exceeded, the 0. TIMESLOT: Radio frequency losses while using a TCH– PM for RF_LOSSES_TCH statistic is generated.

Usage - RF loss. Congestion. Quality of service monitoring. Fault finding Installation and commissioning.Basis - Timeslot.Type - Medium counter array.Alarm - Major.

Key Statistics: RF_LOSS_RATETCH_RF_LOSS_RATE.

154

Description of RF_LOSSES_TCH_HR (Medium Counter Array)

0 RX quality in uplink direction1 RX quality in downlink direction2 RX level in uplink direction3 RX level in downlink direction4 Timing Advance (not in GSR9)5 Sharp decrease of signal level6 Others




0 1 2 3 4 5 6

The RF_LOSSES_TCH_HR statistic tracks the number of HR (AMR and/or GSM) calls lost while using a TCH.

PeggingThis statistic pegs the number of calls that were terminated due to RF problems.The statistic is pegged in the Bins.The BTS implements an algorithm to determine the bin to be pegged.When a dropped call occurs due to RF problems on TCH, the algorithm analyzes the UL and

DL measurement reports in the BTS and generates a reason code.The BTS then pegs the statistic.There is no alarm associated with this statistic.

Usage - RF loss. Congestion. Quality of service monitoring. Fault finding. Installation and commissioning.

Basis - Timeslot.Type - Medium counter array.

155

Cell OOS Timer

FR 32340

156

Introduction

•The BSC Reset Management Feature (FR22322), introduced at GSR8.

•Introduction of a configurable Cell OOS Timer.

•Allows operators to delay the cell OOS message sent by the BSC to the MS.

•Applies to time enhanced resets managed by the BRM feature only.

•Resets for other reasons likely to cause a significant outage will be managed in the current way.

•Roaming mobiles will remain on the network during the BSC reset until the timer expires and the cell OOS message is received.

•Currently mobiles will search for an alternative network.

•If the BSC can recover within the timer period the roaming mobiles will remain in the network.

The BSC Reset Management Feature (FR22322), introduced at GSR8 release, significantly improves the time taken for a BSC to re-establish call processing capabilities. The introduction of a configurable Cell OOS Timer will allow operators to delay the cell OOS message sent by the BSC to the mobile for a short period, allowing the BSC an opportunity to recover call processing. This applies to time enhanced resets managed by the BRM feature only, resets for other reasons likely to cause a significant outage will be managed in the current way.

Significantly, roaming mobiles will remain on the network during the BSC reset and until the timer expires and the cell OOS message is received. Currently mobiles will search for an alternative network as soon as the reset is initiated. If the BSC can recover within the timer period the roaming mobiles will remain in the network.

157

Description

The cell_barred_delay parameter specifies the period the BSS delays sendingSystemInformationUpdate message to the MS during global reset procedure.

This then allows the MS to remain in service during the BSS reset.


0 to 250 secondsDefault 0

If the timer is set to zero the feature is effectively turned off.

DescriptionThe cell_barred_delay parameter specifies the period the BSS delays sending SystemInformationUpdate message to the MS during global reset procedure.

Device/Function BSSType A (no operator actions)Supported by OMC-R GUI YesCell description required YesDependencies None

Change command strings

chg_element cell_barred_delay <new_value> 0

Display command strings

disp_element cell_barred_delay <location> <cell_desc> Values

Value type IntegerValid range 0 to 250Default value 0

158

Setting the Cell Barred Delay Timer

To Set the Timer Value:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Search for or Scroll down to the Switchable Features List / Cell Barred

Delayed (cell_barred_delay).4. Type in the desired Delay Period.5. Select File > Save – File > Close.

By Default the Timer is set to 0 (zero).

159

Increased PCU Capacity Features

Chapter 2

160

Chapter 2Increased PCU Capacity Features

• FR26740 - High B/W Interconnect between BSC & PCU (PSI)

• FR27955A - Software Support for High B/W and/or E1 BSC/PCU Interconnect• FR28351 - Add New BSC/PCU Hardware to Increase GPRS Capacity

• FR28006 - Packet/Coaxial Interface Module

• FR22415 - Increase the PCU Database Capacity

161

High B/W Interconnect between BSC & PCU (PSI)

FR 26740

162

Feature Overview

This feature includes the support of the PSI into the current GSM BSC product in place of the MSI and the support for the U-DPROC2 operating as PXP. The PSI interface will be used to provide a high bandwidth GbE interconnect between GSM BSC and the PXP in the PCU cage.

Benefits:

• Increased PCU capacity and capability.

• A large reduction in the amount of cabling required between the BSC and the PCU.

• Reduced configuration complexity.

• Reduced maintenance requirements.

OverviewThe feature was requested to reduce the number of cables needed between BSC and PCU. It enables higher capacity configurations to be handled by the BSC. Target customer is heavy EDGE users, where the number of E1s required to the PCU results in lower site capacity on the BSC. Instead of using 2 MSIs to allow up to 120 timeslots of EDGE data, one slot is occupied by a PSI to allow over 120 timeslots. The BSC shall allocate 32 TDM timeslots per block for the PSI. The freed MSI slot can be used for 2 downstream or upstream span lines.The PSI is a Packet Subrate Interface card. There will be a max of 12 PSI per BSC. The BSC will support a maximum of 4 PSIs per cage (if other MSI slots are empty). Maximum of 3 PSIs per cage is recommended due to power supply limitations. The PSI device will occupy an MSI slot in the current BSC cage, but is restricted to slots 6, 7, 12 and 13 due to top of cabinet interconnect.The PSI cards primary function is to terminate GPRS TRAU and transfer the TRAU payload to the PCU (PXP) over Ethernet. Other card functions include MCU access to packet data and up to 128 channels of HDLC data via the backplane. The physical interface from the PSI card is a 1000BASE-T over 4 pairs of copper wire. This same connection can be operated in 100BASE-TX mode of operation as well, utilizing 2 pairs of copper wire. (The dual 100 Mbps links, available as an alternative to the 1000BASE-T, are disabled at all times.)The standard backplane connections can be used, with a PBIB-ES or PT43-ES board replacing the BIB or T43 board, respectively, at the top of the cabinet.

163

Feature Overview

This feature includes the support of the PSI into the current GSM BSC product in place of the MSI and the support for the U-DPROC2 operating as PXP. The PSI interface will be used to provide a high bandwidth GbE interconnect between GSM BSC and the PXP in the PCU cage.

Benefits:

• Increased PCU capacity and capability.

• A large reduction in the amount of cabling required between the BSC and the PCU.

• Reduced configuration complexity.

• Reduced maintenance requirements.

On the PBIB-ES, the first two ports allow for balanced span line connections and the 3rd port connects a single Gigabit Ethernet from the PSI card into a RJ45 connector. This link is referred to generically as the Ethernet Link unless it is required to specify 100BASE-TX or 1000BASE-T modes of operation. On the PT43-ES, the first two ports are used for unbalanced coaxial cable connections and the 3rd port is used for the Gigabit Ethernet (using a RJ45 connector). The same electrical characteristics and protection for the unbalanced coaxial cable connections provided by the T43 board shall be provided for the PT43-ES. A new cover will also be provided with the PT43-ES.Each PSI is connected point-to-point to a DPROC2 card in the PCU. The maximum number of PCU cages supported in GSR9 is 1 and there are at most 12 DPROC2s in the PCU cage, therefore there is a maximum of 12 PSIs per BSC.Power and TDM timeslot constraints are such that each BSC cage will support 0, 1 or 2 PSIs. The PSI shall be equipped as a new device. Its child shall be the ETH device representing the physical link between PSI and DPROC2. The BSC shall support codeloading and initialization of the PCU through the PSI card. Hardware specific information will be presented when disp_equipment with the full option is used. TDM timeslot usage of the PSI card shall be determined during initialization. The PSI itself can support up to a full 1024 TDM timeslots (unrealistic/not supported).

164

Feature Limitations

• The 1000 BASE-T or 100 BASE-TX ETH link between the U_DPROC2 and the PSI requires a direct connection.

• The path has to be CAT5E cable and less than or equal to 100m in length.

• The use hubs, switches, routers etc. is not supported.

165

New, modified and deleted commandsThere following new command is introduced with this feature:• equip BSC PSI

The are modified commands at the BSS as a result of this feature:• New Equip GDS +prompts• New Equip GSL prompts

There are no new alarm threshold database elements introduced for the PSI, Eth and GDS devices

166

Functionality - New Devices

• PSI

Child device of CAGErestricted to slots 6, 7, 12 and 13.

ETH

Child device of PSI. Auto equipped while parent PSI is equipped.

(BSC) GDS

Child device of (BSC) ETHIn pair with PCU GDS on PXP.Auto equipped while pair GDS is equipped on PXP.

Two new device types are introduced with this feature.One is PSI and another is ETH.The PSI is a child device of CAGE and ETH is a child device of PSI.

167

Functionality – Capacity & Performance

• One PSI can support 30 GSLs• It is configurable

• One PSI can support 320 connections of TDM timeslots• It is configurable• The number of TDM timeslots for TRAU is (Total TS Num – GSL num)

• One PSI has a MCU (MPC8260 controller ) and 17 DSPs. (16 working, 1 testing).

• Each DSP can support 35 carriers• Each DSP can support 30x32K PDCH, or 30x64K PDCH, or 60x16K PDCH

168

GSL***

PSI

BSS

BSC SITE

CAB

CAGE

LCF

GPROC

OMF

ETH*

* Auto-equipped** Supports TRAU and LAPD*** Assigned to an LCF by FM

: New device

Glossary:ETH : Ethernet Port GSL : Signalling Link to PCUGDS : Path between PSI ETH and DPROC (PXP) ETH

GDS**

GSLs

New Devices and Hierarchy Diagram

Note: The ETH is automatically equipped/unequipped when the parent PSI is equipped/unequipped

Associated Devices•GDSs can be assigned to ETH ports.

Both sides of the GbE link are identified – ETH port and PXP ETH port on the PCU.

Exactly one GDS can be assigned per PSI ETH port.•GSLs can be assigned to ETH ports.

Again, both sides of the link are identified.More than one GSL can be assigned per PSI.

•Each PSI is connected to a U-DPROC2 operating as PXP.Always a one to one association.

169

BSC Equipment Hierarchy – Mixed config

ETH*

BSS

BSC SITE

CAB

CAGE

LCF

GPROC

OMF

PSI

* : Auto-equipped

: New device

Glossary:ETH : Ethernet Port GSL : Signaling Link to ePCUGDS : Path between PSI ETH and U-DPROC2 ETH

GDS(TRAU+GSL)

GSLGDS-TRAU

GSL

MSI

MMS MMS

TDM highway

GSR9 Mixed deployment - (Legacy and new hardware)

On the BSC, one PSI for every PXP (PSI device takes the place of MSI in BSC slots 6,7,12 and 13.PXP has more than double PRP capacityMixed BSC-PCU connectivity

Connectivity between BSC (through MSI) and PRP/PICP (DPROC or U-DPROC2 boards) in the PCU is E1sConnectivity between BSC (PSI) and PXP (U-DPROC2) is GbEthernet

GSLs can take either the E1 path (MSI PICP) or the GbE path (PSI-PXP)GBLs can terminate on PXPs and/or PICPs (DPROC or U-DPROC2)

170

The (GbE) Ethernet connection between BSC and ePCU

PSI MCU SoftwareThe MPC8260 controller (MCU) has the following functions:Responsible for code-load for all DSPs. Responsible for setting up the TDM highway maps. Terminates all 64k HDLC links for GSLs. Data is routed through the on-board ethernet switch to the GbE port. MCU will collect stats and alarmsDSP functions:Essentially does the same functions as the NIB code for TRAU-GDS.

Performs TRAU header huntingPerforms dibit extraction

Responsible for ensuring each timeslot of the TDM has data every block period.Inserts idle frames if data for a timeslot isn’t received from PCU in time.Bundles data from the same carrier into a single UDP packet.PSI FMPSI and PXP are in pairsIf either of the pair fails, both are taken OOSN + M Redundancy

Up to 12 PSI/PXP pairs can equippedSignaling and traffic load is shared amongst in-service PSI/PXP pairsIf one (pair) fails, the load is redistributed amongst remaining in-service PSI/PXP pairs.

171

MMI Command – Outside of SYSGEN Mode

equip BSC PSI

Enter the PSI identifier: Enter the cage number: Enter the slot number: Enter the number of TDM timeslot blocks: Enter the maximum number of GSLs on this PSI: Enter the PCU base GDS IP Address: Enter the PCU GDS Subnet Mask: Enter the PCU GDS Router IP Address: Enter the WebMMI IP address:Enter the WebMMI subnet mask: Enter the WebMMI router IP address: Enter the NSEI value: Enter the PRP Fanout Mode:

Notes : PRP Fanout Mode element will be skipped and set to the default value during the PCU equipage when Increase the Throughput of PRP is restricted.

The BSC will default the gds_subnet_mask , gds_router_ip_address and prp_fanout_mode during the PCU equipage if no value is entered. If the PSI- MCU is assigned an IP address then the 17 DSPs would each be assigned a unique address.

The range of 18 for the PSI addresses (MCU+17 DSPs) and 24 for PCU addresses (to cover DPROC slots 1-6, 11-16) will be expanded by consecutively numbering the host id of the IP address

172

MMI Command – Equip BSC PSI

The IP address of the router. The value of 0.0.0.0 means no router is in use.

RW3b0.0.0.0255.255.255.254

0.0.0.0router_ip_address

Subnet maskRW3b255.255.255.0

255.255.255.224

255.0.0.0

subnet_mask

The base IP address to be used for the MCU. There must be 17 contiguous addresses available after the base address for the DSPs. The IP address shall be entered in dotted quad notation.

RW3bN/A255.255.255.237

0.0.0.1base_ip_address

A maximum number of GSLs that will be supported on this PSI.

RW3b0300max_gsls

Number of TDM 32-timeslot blocks reserved for PSI

RW3b2102tdm_ts_blocks

Slot numberRC1N/A136slot

Cage numberRC1N/A150cage

First device ID. Second and third IDs are optional and shall be set to 0.

RC1N/A110device_id

DescriptionAccessTypeDefaultMaxMinParameter

parent_device (identifies the parent device of ETHernet)Value 1 or PSIValue 2 or DPROCdevice_id1st identifier: PSI unique identifier2nd identifier: identifier Ethernet porttdm_ts_blocks (No. of TDM 32-timeslot blocks reserved for this PSI)Range 2 to 10 (Default=2)max_gsls (max no. of GSLs supported by this PSI)Range 0 to 30 (Default=0)The BSS will support a maximum of 180 GSL links per PCU.ETH is an Ethernet port on the PSI card at the BSC or on the PXP DPROC card at the PCU used for GDS functionality. This is auto equipped.

173

New Database Elementsdsp_error_incValue 0-255(Default=1)

dsp_error_gen_threshValue 2-255(Default=6)

dsp_error_clr_threshValue 0-253(Default=0)

psi_trau_fill_frames_thresholdRange 1-100%(Default=10)

eth_rx_errors_ thresholdRange 1-100%(Default=10)

eth_tx_errors _thresholdRange 1-100%(Default=10)

dsp_error_inc - This is a new database parameter (Motorola specific) which identifies the value by which the error count is incremented if an error indication is received for a DSP during a GPRS Alarm Increment Time Period.dsp_error_gen_thresh - This is a new database parameter which identifies the value which the error count must be equal to or greater than for an alarm to be generated for a DSP.The dsp_error_inc and the dsp_error_gen_thresh parameters are restricted by the Enhanced Circuit Error Rate Monitor restrictable feature.When the dsp_error_inc parameter is set to 0 outside of sysgen mode the operator is warned that this will prevent any more DSP alarms from being generated.dsp_error_clr_thresh - This is a new database parameter which identifies the value for which the error count must be equal or less than for an alarm to be cleared for a DSPpsi_trau_fill_frames_threshold: The new per BSS element specifies the maximum allowable percentage of all TRAU frames transmitted that can be fill frames.eth_rx_errors_threshold: The new per BSS element specifies the maximum allowable percentage of Ethernet frames received in error of all frames received.eth_tx_errors_threshold - The new per BSS element specifies the maximum allowable percentage of Ethernet transmit errors of all frames transmitted

174

New Equip GDS Prompts

Enter the GDS identifier:Enter the GDS connectivity: 0 or E1, 1 or Ethernet

If 0 or E1:Enter the BSC MMS identifier: PSI id (0 to 11)Enter the PCU MMS identifier: DPROC id (1 to 16)

Enter the GDS type: 0 or TRAU, 1 or LAPD, 2 or LAPD_TRAU

If 1 or Ethernet:BSC ETH ID/PSI ID (id, port), 1 0PCU ETH ID/PXP ID (id, port), 2 0

The BSC will automatically assign LAPD_TRAU as the GDS type if the GDS connectivity is "Ethernet". The max number of LAPD_TRAU_GDS is the physical limitation by ETH port, i.e. 1 per PXP, 12 per PCU.The BSC will calculate a LAPD_TRAU GDS capacity based on the number of TDM timeslots allocated to the associated PSI minus the value of the PSIs’ max_gsls parameter.The BSC will support a maximum of 30 GSLs on a LAPD_TRAU GDS.The BSC will prompt for the BSC ETH ID and the PCU ETH ID during GDS equipage if the connectivity is "Ethernet".

175

New Equip GSL Prompts

Equip GSL Prompts• Enter the GSL identifier:• Enter the unique GDS identifier:• If gsl_lcf_mapping = manual

Enter LCF identifier

gsl_lcf_mapping- Supported in Sysgen mode only- Auto maps GSLs to LCF

- In automatic mode the system distributes the equipped GSLs to usable LCFs.

- In manual mode, the operator is prompted to specify the LCF during equipage of a GSL

max_gsls- Specifies maximum number of GSLs per LCF- On a per LCF basis.

176

MMI Impacts

Following commands shall support PSI device:

Equip/unequipdisp_equipmentlockunlockstatereset_deviceins_devicedevice_auditquery_audit

The BSC supports the modify_value command for the PSI parameters tdm_ts_blocks and max_gsls.The BSC supports the modify_value command for the base_ip_address parameter.

Following commands shall support ETH device:

disp_equipmentlockunlockstatereset_deviceins_devicedevice_auditquery_auditchg_audit_sched

177

New Statistics

• ETH_RX_ERROR• ETH_TX_ERROR• ETH_RX_BYTE• ETH_TX_BYTE• ETH_RX_PKT• ETH_TX_PKT• PSI_TRAU_FILL_TX_FRAMES

The ETH_RX_ERROR statistic keeps count of the number of Ethernet Receive errors per ETH device on a PSI card.The ETH_TX_ERROR statistic keeps count of the number of Ethernet Transmit errors per ETH device on a PSI card.The ETH_RX_BYTE statistic keeps count of the number of received bytes per ETH device on a PSI card. The count is kept on a per 1000 events.The ETH_TX_BYTE statistic keeps count of the number of transmitted bytes per ETH device on a PSI card. The count is kept on a per 1000 events.The ETH_RX_PKT statistic keeps count of the number received packets per ETH device on a PSI card.The ETH_TX_PKT statistic keeps count of the number transmitted packets per ETH device on a PSI card.The PSI_TRAU_FILL_FRAME_TX statistic keeps count of the TRAU fill transmit frames generated on a per ETH device basis on the PSI board.

178

Performance Measurement

Statistics to be kept per PSI:

s.1 1000BASE-T transmit error count s.2 1000BASE-T receive error count s.3 1000BASE-T transmit byte count s.4 1000BASE-T transmit packet count s.5 1000BASE-T receive byte count s.6 1000BASE-T receive packet count s.7 TRAU fill frame transmit count (incremented when a frame is not received from the FlexiBSC in time to send at the required time and a fill frame was needed to keep the TRAU in sync to the channel coder.)

The MMI command disp_stat_prop and disp_statswill support these new statistics.

Other PSI based alarms and statistics to be supported for this feature may include:

a.1 1000BASE-T no carrier detect a.2 1000BASE-T excessive transmit errors a.3 1000BASE-T excessive receive errors a.4 TRAU excessive fill frames transmitted a.5 Applicable TDM and device alarms similar to MSI.

a.2, a.3, and a.4 are threshold errors and require a threshold setting to be specified.

179

Software Support for High B/W and/or E1 BSC/PCU Interconnect / Add New BSC/PCU Hardware to Increase GPRS Capacity

FR 27955A / FR 28351

180

Feature Overview

Software support for ‘High bandwidth’ and/or existing E1 BSC/PCU interconnect (new software on old HW).

The purpose of this feature is for GSR9 backward compatibility. It allows network operators to reuse existing DPROC hardware in PCU with GSR9, GSR9+ SW releases.

It allows hardware upgrade before software upgrade for U-DPROC2 used as legacy DPROC.

It also allows mixed mode operation (old DPROCs working with new U-DPROC2 boards).

This feature is dependent on the FR28351 (ePCU) setThe dependencies for enabling this feature are:

High B/W interconnect between BSC and PCU (PSI)Increased PCU database capacityPacket or coaxial interface moduleIncreased PRP throughput

181

Feature Overview

This feature introduces new DPROC hardware with increased processing power and a new PMC module which supports a Gigabit Ethernet connection for increased throughput of TRAU data between the PCU and BSC.

The PCU hardware will continue to use the Compact PCI chassis as a packet control unit platform.

This feature increases the GPRS capacity on the current PCU and BSC hardware platform by introducing new hardware named the U-DPROC2. This feature supports the U-DPROC2 configured as PXP. The U-DPROC2 board can support Ethernet link which is considered to have no link capacity limitation (100Mbps or 1000 Mbps) for EPG, and the process capability of PD timeslots for the board is improved highly. Each U-DPROC2 must be mated with a U-DPROC2 RTM. Pairing a U-DPROC2 board with a Legacy RTM module or pairing a Legacy DPROC board with a U-DPROC2 RTM module is not supported. A PXP combines the functionality of the Current PICP and PRP on one DPROC. Only a U-DPROC2 can be configured as a PXP.All existing hardware will work with the newly introduced DPROC2 (U-DPROC2) cards. The selection of cards do not use the Intel based processors. There will be 4 new FRU's introduced to the PCU. This includes the scheduling blade, PICP blade, and 2 RTM (Rear Transition Module - 1 for each blade type). The DPROC2 will support different functionality by swapping out the on board PMC and E1 interface modules. The PRP uses a DPROC2 card with 2 PMC modules. The PICP uses a DPROC2 with 1 E1 PMC module. This card supports 1 to 8 Gb E1 links (no LAPD links). The PCU will support both DPROC2, and legacy DPROC boards. Legacy DPROC cards can coexist with DPROC2 cards providing a migration path to higher capacity scenarios.E1 PMC modules on pre-existing DPROCS will go to the low power state.Each PSI module residing in the BSC provides a 1GB Ethernet link to a PRP/DPROC2 card in the PCU.

182

Legacy PCU Equipment Hierarchy

BSC

PSP1DPROC (PICP)

MSI3

MMS2

GBL GDS(LAPD)

DPROC (PRP)

MSI

MMS2

GDS(TRAU)

NOTES: 1. Indicates automatically equipped devices, when a PCU is equipped.2. Indicates automatically equipped device, when an MSI is equipped. 2 MMSs are support by the current MSI3. Up to 2 MSIs are supported on DPROC4. An equipped DPROC can be hosted on both a HW DPROC and U-DPROC2

PCU

CAGE1

CAB1

GSL

GSR9 Legacy deploymentNumber of PRPs & PICPs not changed

Up to 9 PRPs (any combination of U-DPROC2/PRPs + DPROC/PRPs)Up to 3 PICPs (any combination of U-DPROC2/PICPs + DPROC/PICPs)

DPROC has limitation of each NIB can support either GBL or GSL links. 2 E1s per NIB, 4 E1s total.U-DPROC2 software must support both types of signaling links on same PMC but not over the same E1. 4 E1s total.

All connectivity between BSC and PCU is E1s.U-DPROC2 functions as current DPROC.

Either a PRP or PICP; not both

GSR9 Mixed deployment - (Legacy and new hardware)- Combination of Universal U-DPROC/RTM and Legacy DPROC/RTMOn the PCU, total of up to 12 DPROC type boards:

Up to 9 PRPs (U-DPROC2/PRPs + DPROC/PRPs)Up to 3 PICPs (U-DPROC2/PICPs + DPROC/PICPs)Up to 11 PXPs (U-DPROC2)With this feature the PCU will have less maintenance requirements and configuration complexity is also reduced.

183

ePCU Equipment Hierarchy

DPROC (PXP)

ETH*

BSS

BSC SITE

PCU

CAB*

CAGE*

MSI**

MMS*

GBL

PPROC*

: New device

* : Auto-equipped

** : support up to 3 E1 interfaces for GBLs MMSs, *** : By default support TRAU

DPROC (PRP)

GDS(TRAU)

MSI*

MMS*GDS***

DPROC (PICP)

MSI3

MMS2

GSL

PSP*

GSL

GDS(LAPD)GBL

The BSS will support 4 variants of the PCU Cabinet:Static Frame Legacy CabinetSwing Frame Legacy CabinetStatic Frame Common Data CabinetSwing Frame Common Data Cabinet

Note that use of the CDC Swing Frame cabinet, in EDGE configuration, with all 3 PCUs fitted, and with all cables connected is not recommended as air flow of the cabinet is severely restricted. Special consideration should be given to environmental and ease of maintenance issues in this configuration.

The OMC will need to recognize the new DPROC2, and PSI hardware. All alarming and stats need to be supported for these new devices. Codeload management for these cards needs to be supported for upgrade and rollback.

184

Impact

This feature disables 3 x PCU feature:

• No impact expected for MMI/OM/SW Apps.- Feature will show up as not available on OMC.- MMI command prompts will act like 3xPCU is not available.

- pcu_redundancy element is forced to 0, primary_pcu cell elementis always 0.

-1 = The cell has no primary PCU or GPRS has never been enabled.

0 = The PCU 0 is the cell primary PCU.

-10-1primary_pcu


Benefits•Reuse of current FRUs (i.e. :DPROCS, NIE) on ePCU•Allows use of U-DPROC2 as a Legacy DPROC

- Introduce ROHS/WEE compliant U-DPROC2 boards as replacement for legacy DPROC’s

- GSR9 SW load release allows hardware upgrade from LegacyDPROC to U-DPROC2 board

•Allows mixed mode operation (Legacy DPROC working with new U-DPROC2 boards)

- Increase existing capacity•Reduced configuration complexity •Improved availability

185

DD1 (new hardware, legacy configure)

This feature supports 2 deployment modes (shown as DD1 and DD3) when U-DPROC2 and legacy DPROC are used at the same time in PCU.For DD1, the U-DPROC2 serves as a PRP or PICP just as legacy DPROC. The PRP capacity/throughput is (280/70) in mode 1 (with rolling blackout mechanism). The PRP capacity/throughput is (140/140) in mode2 (without rolling blackout mechanism). Therefore, capacity is reduced for increased throughput. There are up to 9 PRPs and 3 PICPs can be configured in PCU as legacy. All connectivity between BSC and PCU is E1s.

186

DD2(new hardware, new configure)

DD2, the PCU is configured with all U-DPROC2 boards with all of them configured as PXP All boards are connected with PSI board in BSC via Ethernet link. The software architecture will use the Linux OS for all boards except for the interface boards (NIB and PSI).The existing MPROC will keep the same functionality.The carrier boards process packetized TRAU from PSI cards and distribute it to PMC modules or DPROC2/PRP boards, or handle the data themselves and send resulting data over cPCI backplane to PICP boards.The PICP boards process traffic from PRP processors (over cPCI backplane), handle inter-PICP flow control coordination from all Gb links, and transfer data across the E1s. The PRP boards process packetized TRAU from cPCI backplane as RLC/MAC blocks, and sends Gb link traffic back over cPCI backplane to PICP boards. PMC modules process packetized TRAU from the carrier board as RLC/MAC blocks and sends Gb link traffic back to the carrier boards. The DPROC2 boards (whether configured as PRP or PXP) and Processor PMC modules have the same function.The PSI boards are used to header-hunt TRAU data, packetize the data and send over GbE. They will also take incoming GbE data and send them over TDM bus. GSL link modifications will be needed. The PSI will perform LAPD HDLC functions and pass on data to direct connected carrier PRP board.The design will determine where LAPD equivalent links terminate on PCU (MPROC or PICP or PRP or PXP).

187

DD3 (mixed deployment)

The connectivity between BSC can be E1s (between MSI in BSC and PRP/PICP in PCU) and Ethernet (between PSI in BSC and PXP in PCU).

For DD3, The PCU shall allow DPROC(PICP), DPROC(PRP), and U-DPROC2(PXP) coexist in the same PCU cage. Up to 11 PXPs with one PRP or PICP can be configured in PCU. PXP has more than double PRP capacity. The connectivity between BSC can be E1s (between MSI in BSC and PRP/PICP in PCU) and Ethernet (between PSI in BSC and PXP in PCU). PXP has more than double PRP capacity – It increases PRP capacity/throughput (280/70) in this mode (with rolling blackout mechanism)

188

GSR9 Legacy Deployment - Data Path

PCU

BSC cage

BSC cage

MSI

MSI

Cell A

Cell BPMC Cell A

Cell B

PMCCell C

Cell DCell C

Cell D

PMCCell G

Cell FCell G

Cell F

MSI PMC Base

BoardLAPD GDS (GSLs)

DPROC/PRPs DPROC/PICPs

TRAU GDSs

cPCI bus

GB

PRPFR

PMC

PRP

PRP

FR

PMC

GB

GBL 1

GBL 2

The data path is identical to that of GSR8DPROC can be either old board or new U-DPROC2

189

GSR9 Mixed Deployment Data Path

PCU

BSC cage

BSC cage

PSIPSI

Cell A

Cell B

Cell A

Cell C

Cell D

Cell G

Cell F

MSI

Cell D

cPCI bus

PRP PRP

GBFR

PRP

FR

PRP

PRP

GBL 1

GBL 2GB

FR

GB

PICPU-DPROC2/PRP or DPROC/PRP

PXP

PXP

PMC Cell G

Cell FPMC

Data can take one of many GBL pathsGBL balancing across PXPs and PICPs

190

• Blank Page

191

Packet/Coaxial Interface Module

FR 28006

192

Feature Overview

This feature provides 2 new interface cards: PBIB-SE and P-T43

PBIBPT43GSR9

BIBT43Pre-GSR9

120 Ω75 Ω

Interface board

193

Description

T43 & BIB• Two top panels of current BSC to the E1 transmission system• 75 ohm coaxial & 120 ohm twisted pair E1 links

T43 PT43• T43: 3 MSI• PT43: 2 x MSI + 1 PSI

BIB PBIB• BIB: 3 MSI• PBIB: 2 x MSI + 1 PSI

194

PBIB and PT43

PBIB-ES cover PT43-ES cover

195

PT43-ES Circuit Board

196

PBIB-ES Circuit Board

197

PBIB-ES With Cover

198

• Blank Page

199

Increase the PCU Database Capacity

FR 22415

200

Feature Overview

This feature removes the CM database restriction that inhibits an explicit request for more PDCH than GDS and PRP resources that are equipped in the database. Therefore the customer can setup more GPRS TSs in their system than PRP can support and the limited resources should be delivered to the requested BTS dynamically.

This situation can already occur in legacy equipment if a PRP or GDS does not come into service and the legacy algorithm deals with the situation in a robust manner. Therefore, no algorithmic change is required.

This entails making the required database structure size increases to support the increased capacity of the Enhanced PCU (i.e., estimated at 4050 PDTCH’s when fully populated with the new U-DPROC2 boards).

201

MMI Commands

The following formula will no longer be enforced:

(no. of PRPs equipped x 120 timeslots) >= (the sum of max_gprs_pdch for each carrier in all cells).

RF Parameters:

res_gprs_pdchsres_ts_less_one_carrierswitch_gprs_pdchssw_ts_less_one_carrier

The BSC will disregard the total PRP timeslot resources available at the PCU during a PRP, PXP DPROC or GDS un-equipage.

The BSC will also disregard the total PRP timeslot resources available at the PCU during an attempt to modify the value of the shown RF parameters:

Customer will not be rejected when PDCH is over-provisioned.

It can save operator's CAPEX, especially at the initial stage of GPRS deployment and at the place there is only requirement for GPRS coverage.

202

• Blank Page

203

OMC-R Support for High B/W Interconnect between BSC & PCU (PSI)

FR 26740

204

CreatingPSIfromtheNavigationTree

To create a PSI from the Navigation Tree:

1. Open the Tree to display Site 0 (BSC) hardware.2. Select the PSI to highlight it.3. Select Edit – Create from the main menu to open the Detailed View form.

205

Completing thePSI Detailed View

Fill out the PSI D.V. as follows:

1. Enter the RDN Instance or accept the default.2. Enter the Number of TDM Timeslot blocks (2 to 10) This is the number of 32

Timeslot Blocks required.3. Enter the Number of GSLs On the PSI (0 – 30)4. Enter the Cage ID.5. Enter the slot number (6,7,12,13)

206

Completing thePSI Detailed View

Fill out the PSI D.V. cont’d as follows:

6. Add any additional Information.7. Enter the Base IP Address. This should align with the IP addresses used at

the PCU. The system will allocate this address to the PSI MCU and then 17 consecutive addresses for each of the DSPs.

8. Accept or change the subnet mask.9. Select File > Create and wait for the system to create the entity.10.Select file > close to exit the D.V.

Once created the PSI will appear in the Navigation tree Window.

207

Auto Creation of ETH under the PSI

When the PSI is created the ETH is automatically created.If the PSI is deleted the EHT will be automatically deleted.

208

Creating the PXP from the Navigation Tree

To create the PXP from the Navigation Tree:

1. Navigate to the DPROC entity under the PCU and click on it to highlight.2. Select Edit – Create from the main menu to open the Detailed View form.

209

Completing thePXP Detailed View

Fill out the PXP D.V. as follows:

1. Select the button opposite DPROC Type and select PXP from the drop down menu

2. Enter the RDN Instance or accept the default.3. Select File > Create and wait for the system to create the entity.4. Select File > Close to exit the D.V.

Once created the PXP will appear in the Navigation tree Window.

210

Auto Creation of PPROC and ETH under the PXP

When the PXP is created the PPROC and the ETH are automatically created.If the PXP is deleted the PPROC and the EHT will be automatically deleted.

211

Creating the GDS Connectivity

To Create the GDS Connectivity:

1. Open the GDS D.V. from the Navigation Tree.2. Enter the RDN instance number or accept the default3. Scroll down to or Find the Connectivity Information.4. Click on the button opposite GDS Connectivity and select E1 (0) or Ethernet

(1)5. Enter the BSC and PCU identifiers for the MMS or ETH entities6. Select File > Create – File > Close.

The GDS will appear in the Navigation tree.

212

Blank Page

213

GSR 9 GPRS Features

Chapter 3

214

Chapter 3GPRS Features

• FR27717 - Support of RESUME at Intra-BSC level• FR23292 - Support for Extended Dynamic MAC Mode at the Air Interface• FR27703A - GSR9 QoS• FR30452 - DUAL PCU Mode• FR28000 - Increase Throughput of PRP• FR26881 - Support for Release 4 Based Extended Uplink TBF Mode• FR30828 - CTU2-D Asymmetric EDGE Feature

215

Support of RESUME at Intra-BSC Level

FR 27717

216

Feature Overview

This mandatory feature was designed to support Class B MS to do resume procedure initiated from BSS.

Support of GPRS resume within the BSC boundaries after GPRS suspend, eliminates routing area update after entering and leaving dedicated mode.

RESUME is supported at the intra-BSC level only i.e. at BSC boundary RESUME functionality is not supported.

The RAN shall support network initiated intra-BSC RESUME procedures for class B mobile stations as long as the CS call is released in the same Routing Area as the one in which the mobile initiated suspension of data services.

217

Feature Description

This feature realizes Suspend and BSS initiated RESUME at intra-BSC level.When introducing RESUME feature, RSL and GSL load will be reduced, but LCF CPU utilization will be increased.

SuspendThe MS shall request the network for suspension of GPRS services when the MS or the network limitations make it unable to communicate on both GPRS channels and dedicated channel at same time.

ResumeThe Resume procedure is used for the resumption of GPRS service when the conditions for suspension have disappeared (e.g. a suspended class B mobile station has cleared the resources allocated for the circuit switched service).

Suspend DescriptionFor customers, it has the following advantages:1. Mobile subscribers will not suffer from missed calls and SMSs.2. The reduced signalling will have an immediate positive effect in the system

performance as the signalling system load decreases.3. For customers using an "always-on" approach (subscribers always attached) a

considerable amount of signalling traffic is produced with the current system solution (RAU after each circuit switched call).

4. Customers will be able to measure their data traffic directly with Motorola statistics (DATA_BLKS) as these statistics no longer contain data blocks generated byRAUs.

218

Feature Description

This feature realizes Suspend and BSS initiated RESUME at intra-BSC level.When introducing RESUME feature, RSL and GSL load will be reduced, but LCF CPU utilization will be increased.

SuspendThe MS shall request the network for suspension of GPRS services when the MS or the network limitations make it unable to communicate on both GPRS channels and dedicated channel at same time.

ResumeThe Resume procedure is used for the resumption of GPRS service when the conditions for suspension have disappeared (e.g. a suspended class B mobile station has cleared the resources allocated for the circuit switched service).

Current network already realized Suspend procedure, in which BTS directly forward the SUSPEND message to SGSN which is transparent to BSC. In this feature Suspend procedure not only passes through BSC, but also BSC keeps the MS status as “Suspended” in order to implement BSS initiated RESUME procedure.

ResumeThe TS23.060 describes two ways of resuming GPRS service that has been

suspended during a dedicated call:1. BSS support of the Resume procedure over the Gb interface.2. MS initiated resumption by sending the RAU update.

Before GSR9 the network realized the second way of Resumption. This feature realizes the first way.

219

Impact

This feature shall impact following Functional Areas:

BSC Software Impact: CM, MMI, NMASE, PM, RRSM, SSM

PCU Software Impact: GB, RME

Benefits

1. The major benefit is to greatly decrease the number of RAU used for Resumption.

2. GPRS performance is improved by speeding up resumption of GPRS.3. Air interface utilization is improved by decreasing the RAU signalling.

220

Feature Description

Resume initiated by BSS.The BSS determines that the conditions for the GPRS suspension have disappeared.If the BSS is able to request the SGSN to resume GPRS services, the BSS shall send a

Resume (TLLI, RAI) message to the SGSN.The SGSN acknowledges the successful or unsuccessful outcome of the resume by

returning Resume Ack or Nack.

DescriptionThe mobile station will establish an SDCCH. On SDCCH, the mobile station shall transmit a

GPRS SUSPENSION REQUEST-message [PD/TI + MT = 06 34, TLLI (m), RAI (m), Suspension Cause (m)] to the BSC.

The BSC will internally communicate the suspension information to the PCU. The PCU shall send a SUSPEND-message [TLLI (m), RAI (m)] to the SGSN and start T3 (0.1 - 10 s).

The SGSN shall return a SUSPEND-ACK-message [TLLI (m), RAI (m), Suspend Reference Number (m)] to the PCU and consider the mobile station to be suspended for GPRS.

Upon reception of SUSPEND-ACK, the PCU shall stop T3. If T3 expires, the PCU shall repeat the SUSPEND-message max. SUSPEND-RETRIES times ( 3) before O&M is notified.

As part of the release procedure for the circuit-switched transaction the network will send a CHAN_REL-message to the mobile station. This CHAN_REL-message or rather the GPRS Resumption Information Element will tell the mobile station whether the network will autonomously resume GPRS.

If the GPRS Resumption Information Element = successful, no further action is required from the mobile station.

Within the network, the BSC will internally inform the PCU that the condition forGPRS suspension has disappeared.

221

Feature Description

Consequently, the PCU shall send a RESUME-message [TLLI (m), RAI (m), Suspend Reference Number (m)] to the SGSN and start T4 ( 0.1 - 10 s). The SGSN shall respond with a RESUME-ACK-message [TLLI (m), RAI (m)] and shall consider the mobile station to be reachable for GPRS again. Upon reception of RESUME-ACK, the PCU shall stop T4.If T4 expires, the PCU shall repeat the RESUME-message max. RESUME-RETRIES times (3) before O&M is notified. In addition, the mobile station will be forced to perform a routing area update scenario ( by means of a network controlled cell update scenario).

Note: If the mobile station performs an inter-BSC handover or Inter-MSC handover while suspended, the former BSC may convey the Suspend Reference Number, the TLLI and the RAI to the MSC by means of the HND_RQD-message. The MSC will in turn forward this information within the HAND_REQ-message to the new BSC [3GTS 08.08]. Consequently, the new BSC may forward this information to the new PCU upon release of the DCCH. By means of this procedure, this first option to operate Suspend/Resume will work properly even if the PCU and the SGSN change.

222

Feature Description

Radio Link Failure

Resume by RAUThe MS shall resume GPRS services by sending a Routing Area Update Request

message to the SGSN:If the BSS did not successfully request the SGSN to resume GPRS servicesIf the RR Channel Release message was not received before the MS left dedicated

modeIf the MS locally determines that the conditions for the GPRS suspension have

disappeared

DescriptionThe mobile station will establish an SDCCH. On SDCCH, the mobile station shall transmit a

GPRS SUSPENSION REQUEST-message [PD/TI + MT = 06 34, TLLI (m), RAI (m), Suspension Cause (m)] to the BSC.

The BSC will internally communicate the suspension information to the PCU. The PCU shall send a SUSPEND-message [TLLI (m), RAI (m)] to the SGSN and start T3 (0.1 - 10 s).

The SGSN shall return a SUSPEND-ACK-message [TLLI (m), RAI (m), Suspend Reference Number (m)] to the PCU and consider the mobile station to be suspended for GPRS.

Upon reception of SUSPEND-ACK, the PCU shall stop T3.If T3 expires, the PCU shall repeat the SUSPEND-message max. SUSPEND-RETRIES

times ( 3) before O&M is notified. As part of the release procedure for the circuit-switched transaction the network will send a

CHAN_REL-message to the mobile station. This CHAN_REL-message or rather the GPRS Resumption Information Element may tell the mobile station whether the network will autonomously resume GPRS.

If the GPRS Resumption Information Element = unsuccessful, the mobile station is implicitly notified to perform a routing area update scenario.

223

Feature Description

Radio Link Failure

The same applies, if the GPRS Resumption Information Element is not included in the CHAN_REL-message.If the circuit-switched transaction ends abnormally (e.g. radio link failure), the mobilestation also needs to perform a routing area update scenario.As an implementation option, the BSC may inform the PCU whether resumption of GPRS was successfully conveyed to the mobile station within the CHAN_REL-message or not.The theoretically possible time that a mobile station can remain suspended from GPRS depends on the network. In particular the Mobile Reachable Timer ( 64 minutes) and the Purge Timer (time between expiry of the Mobile Reachable Timer and implicit detachment of the mobile station by the SGSN) are important for this consideration.

224

O&M Parameter

bssgp_t4_timer - Guards both Suspend and Resume procedure

The unit is millisecond. 80010000100bssgp_t4_timer


BSS initiated RESUME procedure happens between Clear Command and Clear Complete message.

The default time period of RESUME procedure is 0.8s, the range is 0.1~10s.So the timer set in BSC and MSC should allow this procedure to be implemented successfully.This attribute defines a time interval.This timer is used to guard the round trip of GPRS SUSPEND and RESUME procedures, as per 3GPP TS 48.018, between the PCU and SGSN.The PCU shall start this timer once RESUME PDU or SUSPEND PDU is sent out to SGSN, and the timer will stop when PCU receives RESUME ACK/NACK PDU or SUSPEND ACK/NACK PDU from SGSN.

225

Statistics - NUM_SUSP_RESU_RCVD

DescriptionThis statistic provides the following information:• Number of responses received for SUSPEND and RESUME.• Number of responses not received for SUSPEND and RESUME.• Number of occurrences the RESUME is not triggered due to different reasons.

PeggingThis statistic is pegged for every response received, not received and resume procedure not initiated.

AnalysisReference NoneUsage OptimizationBasis BSSType Large Counter ArrayAlarm NoneThe BSC does not support the chg_stat_prop command for the NUM_SUSP_RESU_RCVD statistic.This command cannot be used to change NUM_SUSP_RESU_RCVD information.

226

Impact

Suspend/Resume has impact on following processes:

SSMGBMRRSMGRPRM

ImpactSSM- track if the MS in Suspend mode or not - initiate RESUME procedure- send Release radio Channel wi/wo Resume Bit Set to RRSM.GBM

- send the Resume message over the Gb to the SGSN- Inform the SSM if the Resume was successful or not- notifies PRM to clean up on-going TBFs for the mobile being suspended

RRSM- receive Release radio Channel from SSM and sends Channel Release to MS- forward suspend message to SSM instead of GBM.GR- checks the valid of SUSPEND ACK/NACK, RESUME ACK/NACK and forwards to GBM - if an erroneous (i.e., PDU missing mandatory IEs) message is received, then GR shall

send BSSGP STATUS PDU to SGSN PRM - clean up on-going TBFs for the mobile being suspended

227

OMC-R Support of RESUME at Intra-BSC Level

FR 27717

228

Setting the Suspend Timer

The Suspend Timer is found in the BSS D.V. under SSM Timers.


100 – 10000 milliseconds (0.1 to 10 sec)Default = 800 milliseconds (0.8 sec)

229

Support for Extended Dynamic MAC Mode at the Air Interface

FR 23292

230

Feature Overview

This unrestricted optional feature provides support of 3 and 4 UL timeslots capability to higher mobile class 11 and 12, thus improving UL throughput (e.g. video and email uploads).

The EDMAC feature is an enhancement feature on normal Dynamic Allocation Medium Access Mode (DA).

This EDMAC feature has impacts on the following software processes/FAs:

- BSC software impact: CM/MMI/NMASE, CSP- PCU software impact: pCM, pLSP, pSSP, ULC, PRM, GTS

In Dynamic Allocation mode, a mobile monitors the assigned PDCHs for the assigned USF value for each assigned PDCH.Whenever the mobile station detects an assigned USF value on an assigned PDCH, it transmits a single RLC/MAC block on the same PDCH.Some mobiles assigned multiple timeslots on the uplink can only monitor USFs on restricted DL timeslots due to its multi-slot class capability, e.g. when DL time slots are less than UL time slots.

The EDMAC feature is introduced to support class 11 and 12 mobiles with 3 and 4 UL timeslots capability.When 3 or 4 uplink timeslot allocation is assigned, EDMAC is required for the request uplink TBF.

231

EDMAC

The Extended Dynamic Resource Allocation MethodExtended Dynamic allocation basically works like dynamic resource allocation. The PCU will only set the EXTENDED_DYNAMIC_ALLOCATION parameter = ,1‘ in the PACK_UL_ASS- or PACK_TS_RECONF-message to indicate extended dynamic allocation.Extended dynamic allocation works as follows :Whenever the mobile station detects an allocated USF (may be different per timeslot) in downlink block K on an allocated timeslot N then not only uplink block (k+1) on the same timeslot N but uplink block (k+1) on timeslot N and all higher numbered timeslots that belong to the allocation, shall be used by the mobile station. After detecting an allocated USF on timeslot N in downlink block k the mobile station shall not listen for the USF’s in downlink block k on the higher numbered timeslots or to the USF’s in those higher numbered timeslots in downlink block (k+1).In case of extended dynamic allocation the PACK_UL_ASS- or PACK_TS_RECONF-message will contain:The information whether EXTENDED_DYNAMIC_ALLOCATION (m) shall beapplied. The information whether or not downlink power control is used and what the offset downlink power level (P0 (o)) relative to BCCH is.The information which power reduction mode shall be used for this TBF( only if downlink power control is used). The information whether USF-detection authorizes the mobile station to transmit only in the next or in the next four uplink radio blocks on this timeslot (USF_GRANULARITY) (m). The assignment of the uplink TFI (o)The possible limitation of a TBF. By means of RLC_DATA_BLOCKS_GRANTED (o) the mobile station can be limited to transfer only the indicated number of uplink radio blocks. The delay between the assignment message and the allocation (TBF_STARTING_TIME (m)

232

EDMAC

The figure illustrates a typical example for the operation of the extended dynamic allocation feature.In this case, a multislot class 12 mobile station has previously received an allocation of TS 0, 1, 2 and 3 on a given ARFCN.Following the rules of extended dynamic allocation, the mobile station is listening in block n to timeslots 0,1, 2 and 3 in downlink direction. In example 1, the mobile station receives its own USF-value on timeslot 0 (note that the mobile station has to receive all parts of downlink block n on TS 0 before the USF-value can be determined because of interleaving). Accordingly, the mobile station is allocated uplink radio block n + 1 on TS 0 and all higher numbered timeslots which belong to the allocation (TS 1, 2 and 3).In radio block n + 1 and according to the rules of extended dynamic allocation the mobile station only needs to listen to TS 0 in downlink direction plus it shall transmit on TS 0, 1, 2 and 3.

Note that the time constraints Tta and Trb are met.

Note that Extended Dynamic Allocation makes only sense in case of multiple timeslots being allocated. Extended Dynamic Allocation is mandatory only for mobile phones with multislot classes 22, 24, 25, 27. It is an optional feature for the PCU.

233

MMI Commands

gprs_mac_mode

Attribute Min Max Default Value Definition

gprs_mac_mode 1 2 1 1 – Dynamic Allocation. 2 – Extended Dynamic Allocation.

The gprs_mac_mode attribute can only be set to the value of 2 if the Extended Dynamic Allocation feature is unrestricted.

edaOpt Parameter Min Max Default Value Definition edaOpt 0 1 0 0 = restricted

1 = unrestricted

The edaOpt parameter indicates whether or not the Extended Dynamic Allocation feature functionality is unrestricted in the BSS software.

The EDMAC is an optional feature for the network.When the EDMAC feature is unrestricted, the support of Extended Dynamic Allocation can be enabled by setting the BSS parameter gprs_mac_mode with the new value of 2.The uplink TBFs with EDMAC will be dropped if the EDMAC is disabled by changing the gprs_mac_mode value.This element indicates the medium access mode that should be used by the PCU.The gprs_mac_mode is restricted by the GPRS optional feature.

234

MMI Commands

gprs_ul_dl_bias

Valid values are 1, 2, 4, and 8This parameter is the multi-slot class to be

used in preload and 1 phase speculative scheduling. GTS shall consider the mobile to be a gprs_com_ms_classmobile station if multi-slot class is not included in the EGPRS Packet Channel Request for all other access types except one phase access.

881Gprs_com_ms_class

0 – uplink biased1 – downlink biased

110Gprs_ul_dl_bias

Value DefinitionDefaultMaxMinAttribute

gprs_com_ms_class

CM Bias Parameters Impacts EDMAC Allocation The UL/DL bias is a mechanism that controls the allocation of time slots to a multi-class MS at the TBF establishment time and during the TBF. This would ensure while a multi-slot class is provided with the highest number of time slots (in a given direction) at the TBF establishment time, the correct number of time slots are provided in a given direction during a TBF. The UL/DL bias at TBF establishment The UL/DL bias at TBF establishment (Initial Bias set up/assignment) is based on the CM database parameter gprs_ul_dl_bias and gprs_com_ms_class (see Table below) depending on whether the multi-slot class capability of mobile is known or not. It is used by GTS when setting up a TBF to attempt to allocate the maximum number of time slots for certain multi-slot classes (where UL / DL allocation can be different).

gprs_ul_dl_bias - This parameter is applied if operator wants more UL timeslots to be allocated to mobiles initially with multislot class 6, 10, 11 and 12 and any multislot class that maps to class 6, 10, 11 and 12.

235

MMI Commands

gprs_ul_dl_bias

Valid values are 1, 2, 4, and 8This parameter is the multi-slot class to be

used in preload and 1 phase speculative scheduling. GTS shall consider the mobile to be a gprs_com_ms_classmobile station if multi-slot class is not included in the EGPRS Packet Channel Request for all other access types except one phase access.

881Gprs_com_ms_class

0 – uplink biased1 – downlink biased

110Gprs_ul_dl_bias

Value DefinitionDefaultMaxMinAttribute

gprs_com_ms_class

When a class 11 or 12 mobile requests an uplink TBF, the network will assign the EDMAC for the uplink TBF if the mobile supports EDMAC and the TBF allocation requires EDMAC mode, and assigns the lowest numbered timeslot in the allocation as PACCH timeslot. PCU will attempt to assign the maximum possible number of UL timeslots (3 for class 11 and 4 for class 12) to the mobile if gprs_ul_dl_bias is set to UL bias. PCU schedules periodic PUAKs for 3 or 4 UL TBFs frequently enough to prevent stalling dependent on number of uplink timeslot (3or 4) used and GPRS or EGPRS TBF mode.

236

GSR9 Possible TS allocation biases for EDMAC

2:3, 1:44:1, 3:254412Yes

2:34:1, 3:253411Yes

UL biased TS allocations

(DL:UL)

DL biased TS allocations

(DL:UL)

Maximum sum of DL and UL allocation

UL (MS Tx capability)

DL (MS Rx capability)

Multislot class

EDA specific

When the EDMAC is enabled but gprs_ul_dl_bias is set to DL bias, or EDAMC is disabled, then the maximum UL TSs allocation will not be more than 2, (in that case, the EDMAC mode won’t be used).

The UL/DL bias during a TBFThe UL/DL bias during a TBF is based on the RLC/MAC estimates the DL / UL throughput and when a change of bias will be informed to GTS. Within the PCU (RME) the bias is monitored, and once determined the PCU (GTS) will attempt to schedule more resource (TS and the resource to support those TS) in the direction of the bias.Additionally, to optimize the EDGE mobile station in EDMAC mode with 3 and 4 timeslots in uplink, the RLC window size needs to be increased to 192 from 128.

237

New Statistics

UL_RADIO_BLKS_GMSK_3_TSUL_RADIO_BLKS_GMSK_4_TS UL_RADIO_BLKS_8PSK_3_TS UL_RADIO_BLKS_8PSK_4_TS UL_TBF_TIME_GMSK_3_TSUL_TBF_TIME_GMSK_4_TS UL_TBF_TIME_8PSK_3_TSUL_TBF_TIME_8PSK_4_TS

Modified Statistics

DL_RADIO_BLKS_4_TSUL_RADIO_BLKS_GMSK_1_TS UL_RADIO_BLKS_GMSK_2_TS UL_RADIO_BLKS_8PSK_1_TS UL_RADIO_BLKS_8PSK_2_TS

Because this feature allows 3 UL and 4UL timeslots allocation for mobile class 11 and 12, similar to the existing performance statistics UL_RADIO BLOCKS and UL TBF TIME for 1 and 2 timeslots, the new PCU performance statistics for 3 and 4 timeslots are introduced to measure the user throughput. New Statistics:UL_RADIO_BLKS_GMSK_3_TSTotal number of RLC radio blocks received from mobiles that support a maximum of 3TS in the uplink direction (mobile multislot classes 11) and not capable of supporting 8PSK in the uplink. The RLC radio blocks are split into the four GPRS channel coding schemes, and the four GMSK EGPRS coding schemes.UL_RADIO_BLKS_GMSK_4_TS Total number of RLC radio blocks received from mobiles that support a maximum of 4TS in the uplink direction (mobile multislot classes 12) and not capable of supporting 8PSK in the uplink. The RLC radio blocks are split into the four GPRS channel coding schemes, and the four GMSK EGPRS coding schemes. UL_RADIO_BLKS_8PSK_3_TSTotal number of RLC radio blocks received from EGPRS mobiles capable of 8PSK on the uplink that support a maximum of 3TS in the uplink direction (mobile multislot classes 11). This stat will also be pegged for 8PSK mobiles whose multislot class is not known before the end of the UL TBF. It is to be noted that the accuracy of the stat may be reduced due to these unknown multi-slot cases. The RLC radio blocks are split into the four GPRS coding schemes and nine EGPRS coding schemes.

238

New Statistics


Modified Statistics


UL_RADIO_BLKS_8PSK_4_TSTotal number of RLC radio blocks received from EGPRS mobiles capable of 8PSK on the uplink that support a maximum of 4TS in the uplink direction (mobile multislot classes 12). This stat will also be pegged for 8PSK mobiles whose multislot class is not known before the end of the UL TBF. It is to be noted that the accuracy of the stat may be reduced due to these unknown multi-slot cases. The RLC radio blocks are split into the four GPRS coding schemes and nine EGPRS coding schemes.UL_TBF_TIME_GMSK_3_TSThis statistic will measure the duration in time of the uplink TBFs for mobiles that support a maximum of 3 TS in the uplink direction and not capable of supporting 8PSK in the uplink. UL_TBF_TIME_GMSK_4_TSThis statistic will measure the duration in time of the uplink TBFs for mobiles that support a maximum of 4 TS in the uplink direction and not capable of supporting 8PSK in the uplink. UL_TBF_TIME_8PSK_3_TSThis statistic will measure the duration in time of the uplink TBFs for mobiles that support a maximum of 3 TS and capable of 8PSK in the uplink direction. UL_TBF_TIME_8PSK_4_TSThis statistic will measure the duration in time of the uplink TBFs for mobiles that support a maximum of 4 TS and capable of 8PSK in the uplink direction.

239

New Statistics


Modified Statistics


Modified statistics:DL_RADIO_BLKS_4_TSTotal number of RLC radio blocks sent to mobiles that support a maximum of 4TS in the downlink direction (multislots classes 8, 10, 11 and 12). The RLC radio blocks are split into the four GPRS channel coding schemes, and the 9 EGPRS coding schemes. Multislot class 14-29, 31-34, 36-39 and 41-45 will be treated as a class 10. Multislot class 30, 35 and 40 will be treated as a class 8.UL_RADIO_BLKS_GMSK_1_TS - shall be modified to support the mobile multislot class 30 and higher. Total number of RLC radio blocks received from mobiles that support a maximum of 1TS in the uplink direction (mobile multislot classes 1, 2, 4 and 8) and not capable of supporting 8PSK in the uplink. Multislot class 30, 35 and 40 will be treated as multislot class 8. This stat will also peg for mobiles whose multislot class is not known before the end of the UL TBF. It is to be noted that the accuracy of the stat may be reduced due to these unknown multi-slot cases. The RLC radio blocks are split into the four GPRS channel coding schemes, and the four GMSK EGPRS coding schemes.

240

New Statistics


Modified Statistics


Modified statistics:UL_RADIO_BLKS_GMSK_2_TS - shall be modified to support the mobile multislot class 30 and higher. Multislot class 11 and 12 shall not be measured by UL_RADIO_BLKS_GMSK_2_TS.Total number of RLC radio blocks received from mobiles that support a maximum of 2TS in the uplink direction (mobile multislot classes 3, 5, 6, 9 and 10) and not capable of supporting 8PSK in the uplink. Multislot class 7 that support greater than 2 timeslots on the uplink will be treated as 2 uplink capable. Multislot class 13 will be treated as a class 9 and multislot class 14-29, 31-34, 36-39 and 41-45 will be treated as class 10. The RLC radio blocks are split into the four GPRS channel coding schemes, and the four GMSK EGPRS coding schemes.

241

New Statistics


Modified Statistics


UL_RADIO_BLKS_8PSK_1_TS - shall be modified to support mobile multislot class 30 and higher.Total number of RLC radio blocks received from EGPRS mobiles capable of 8PSK on the uplink that support a maximum of 1TS in the uplink direction (mobile multislot classes 1,2, 4, and 8). Multislot class 30, 35 and 40 will be treated as multislot class 8. This stat will also be pegged for 8PSK mobiles whose multislot class is not known before the end of the UL TBF. It is to be noted that the accuracy of the stat may be reduced due to these unknown multi-slot cases. The RLC radio blocks are split into the four GPRS coding schemes and nine EGPRS coding schemes.

UL_RADIO_BLKS_8PSK_2_TS - shall be modified to support mobile multislot class 30 and higher. Multislot class 11 and 12 shall not be measured by UL_RADIO_BLKS_8PSK_2_TS.Total number of RLC radio blocks received from EGPRS mobiles capable of 8PSK on the uplink that support a maximum 2TS in the uplink direction (mobile multislot classes 3, 5, 6, 9 and 10). Multislot class 7 that support greater than 2 timeslots on the uplink will be treated as 2 uplink capable. Multislot class 13 will be treated as class 9 and multislot class 14-29, 31-34, 36-39 and 41-45 will be treated as class 10.The RLC radio blocks are split into the four GPRS channel coding schemes, and the nine EGPRS coding schemes.

242

• Blank Page

243

OMC-R Support for Extended Dynamic MAC Mode at the Air Interface

FR 23292

244

Extended Dynamic Allocation Feature Enable

For the Extended Dynamic Allocation Feature to work it must be in the BSS features list and must be Un-Restricted (Enabled)

245

Selecting Mode of Operation

To set the Medium Access Control Mode:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the Medium Access Control Mode function.4. Select “Dynamic access mode (1)” or “Extended Dynamic access mode (2)”

from the popup menu.5. Select File > Save – File > Close.

246

Setting the Uplink/Downlink Bias and the Most Common Multislot Class of GPRS Mobiles

To set the Uplink/Downlink Bias and the Most Common Multislot Class of GPRS Mobiles:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the GPRS Uplink or Downlink bias/Most Common

Multislot Class of GPRS Mobiles.4. Select “Uplink Bias (0)” or “Downlink Bias (1)” from the popup menu.5. Select the Multislot class (1,2,4,8) from the popup menu.6. Select File > Save – File > Close.

247

GSR9 QoS

FR 27703A

248

Feature Overview

GSR9 GPRS Quality of Service includes both enhancements to GSR8 QoS implementation, as well as new QoS Phase II feature, which now provides RAN with consistent QoS frame for real-time traffic support for applications such as video or audio streaming.

249

Benefits

GSR9 Enhancements to GPRS QoS Phase I implementation remove PFM procedures interoperability issues with some SGSN vendors. 3GPP R6 ARP signalling support allows operators more flexibility in setting access and retention priorities for end-users, using same HLR settings for eMLPP and for GPRS QoS.

GSR9 GPRS QoS Phase 2 feature allows operator to guarantee real-time data applications support, such as video and/or data streaming. Real time QoS ensures subscribers are getting data bit rates and delays as per subscription.

QoS Profile - contains a number of attributes, and defines the characteristics of a PFC.

250

Limitations

• Only one real time Packet Flow Context (PFC) can be supported per TBF.

.

Packet Flow Context (PFC) - describes a session, and are established as part of PDP Context.

251

QoS Phase II OverviewQoS Phase II builds on top of GSR8 QoS with a number of

enhancements which include:

– 3GPP Release 6 support for ARP IE (Priority IE)– Throughput Capacity is based on a less conservative budget as

compared to GSR8 by using initial coding scheme values– Configurable MTBR downgrade support, where the operator can

choose whether the existing non-real time PFC can be downgraded or not.

– Ability to enable/disable PFC modification procedures over Gb interface on downgrade/upgrade of a non-real time PFC

– Support for SGSN-initiated PFC modification, signalled via CREATE-PFC-BSS messaging.

Note: All enhancements will be available if GSR8 QoS is unrestricted regardless if GSR9 QoS is purchased or not.

Minimum Throughput Budget Requirement (MTBR) – is throughput budget for each PFC which facilitates BSS during admission control and retention.

The key components of GSR8 QoS (QoS Phase I) enhancement are as follows:Support for ARP (Allocation Retention Priority) derived from the Priority IE as defined in the Release 6 3GPP specifications

Provides Operators the ability to configure ARP ranking scheme in a standard specification compliant mannerBSS to support similar configuration elements for backwards compatibility in case SGSN is not Release6 compliant

Configurable MTBR downgrade support – operator can choose if the existing PFC can be downgraded, or always pre-empted.Support for not triggering PFM messaging to SGSN when a non-real time PFC is downgraded or upgraded due to admission control or retentionSupport for SGSN-initiated PFC modification, signalled via create-bss-pfc

252

8 7 6 5 4 3 2 1

Quality of service IEI octet 1

Length of quality of service IE Octet 2

0 0 spare

Delay class

Reliability class

octet 3

Peak throughput

0 spare

Precedence class

octet 4

0 0 0 spare

Mean throughput

octet 5

Traffic Class Delivery order Delivery of erroneous SDU Octet 6

Maximum SDU size Octet 7

Maximum bit rate for uplink Octet 8

Maximum bit rate for downlink Octet 9 Residual BER SDU error ratio Octet 10

Transfer delay Traffic Handling priority Octet 11

Guaranteed bit rate for uplink

Octet 12

Guaranteed bit rate for downlink Octet 13

Figure 10.5.138/3GPP TS 24.008: Quality of service information element

Supported in GSR8

Additional attributes supported in GSR9

3GPP R6 - QoS Profile/ABQP IE

253

Packet Flow Contexts (PFCs) per TLLI/TBF

TLLI / TBF

PFC – A

PFC – B

ABQP

PDP Context 1

PDP Context 2

PDP Context 3

Best Effort

Signaling

SMS

254

QoS Phase II Overview

QoS Phase II introduces support for real time traffic applications such as audio and video streaming with the following key components:

– Support for Streaming Traffic class– Max Bit Rate enforcement as per the QoS Profile– Configurable streaming downgrade support, where

the operator can choose whether the existing real time PFC can be downgraded

The key components of QoS phase II are as follows:Support for Streaming Traffic class

The Key Requirements for support for streaming are: Support for “Transfer Delay” and “Guaranteed Bit Rate” attributes from the ABQPStreaming users that cannot be admitted with the requested “Guaranteed Bit Rate” and “transfer Delay”characteristics shall be negotiated appropriatelyManage and Control separate flow control buffers per PFC/Traffic class negotiated for each mobile Modification of PCU Scheduling algorithms to take streaming class delay/throughput characteristics into account

Max bit-rate enforcement as per the QoS Profile

255

ARP IE - 3GPP Release 6 SpecificationSGSN Release

sgsn_release parameter has been modified to include R6 support.

New value – 2 : SGSN is compliant with 3GPP Release 6 or newer.

Parameter Min Max Default Value Definition sgsn_release

0 2 0 0: SGSN is compliant with 3GPP Release 1998 or older. 1: SGSN is compliant with 3GPP Release 1999 to any version before Release 6. 2: SGSN is compliant with 3GPP Release 6 to newer.

• SGSN may not be R6 compliant or may not include the optional ARP IE in the CREATE-BSS-PFC message• SGSN must be at least Release 4 compliant. • ARP derived from new BSS configuration parameters based on Traffic Class and Precedence Class • New parameters replace GSR8 ARP configuration, with no dependency on GSR9 QoS

256

ARP IE - 3GPP Release 6 Specification

ARP (Allocation and Retention Priority) IE

• ARP is used for prioritized access and prioritized retention

• PCU will use the ARP IE from the CREATE-BSS-PFC message– If ARP IE received from the SGSN for a PFC, this priority

is used directly– If ARP IE is not received from SGSN for a PFC, use the

precedence class to map ARP

• ARP IE supports priority level (range 1-14), pci and pvi bits.

• Provides operators with a standard, specification compliant way of configuring ARP

Allocation / Retention Priority (ARP) – is a subscription parameter used for PFC ranking for prioritized access and prioritized retention.

257


Priority This element indicates the priority of the request. It is coded as follows:

8 7 6 5 4 3 2 1 Element identifier octet 1

Length octet 2 Priority octet 3

Octet 2 is a binary indication of the length of the rest of the element. Octet 3 is coded as follows:

8 7 6 5 4 3 2 1 spare pci priority level qa pvi octet 3

The 3GPP Release4 version of the standard does not define the ARP IE as part of the CREATE-BSS-PFC procedures. The GSR8 QoS implementation used BSS configurable ARP parameters. GSR9 QoS will use the ARP IE as defined in the Dec 2004 version of the 3GPP Release6 specifications (definition included here, for reference). This element indicates the priority of the request. It is coded as shown:

pci = Pre-emption Capability indicator 0 this allocation request shall not pre-empt an existing connection.1 this allocation request may pre-empt an existing connection.

priority level:6 5 4 30 0 0 0 spare0 0 0 1 priority level 1 = highest priority0 0 1 0 priority level 2 = second highest priority: : : :1 1 1 0 priority level 14 = lowest priority1 1 1 1 priority not used

258


Priority This element indicates the priority of the request. It is coded as follows:

8 7 6 5 4 3 2 1 Element identifier octet 1

Length octet 2 Priority octet 3

Octet 2 is a binary indication of the length of the rest of the element. Octet 3 is coded as follows:

8 7 6 5 4 3 2 1 spare pci priority level qa pvi octet 3

qa = queuing allowed indicator (not supported in GSR9)0 queuing not allowed1 queuing allowed

pvi = Pre-emption Vulnerability indicator 0 this connection shall not be pre-empted by another allocation request1 this connection might be pre-empted by another allocation requestThe priority, pci and pvi attributes of the ARP IE are supported as part of the QoS

Phase II Feature. The queuing allowed indicator is not supported by the BSS.

259

BSS ARP configuration Parameters

57arp_bg_311403Background



101arp_i_be_31913Interactive/Best Effort



77arp_streaming_31313Streaming



Default Value

Parameter NamePVIPriority Level

PCIPrecedence Class

Traffic Class










Default Value

Parameter NamePVIPriority Level

PCIPrecedence Class

Traffic Class

The BSS provides the operator the same level of configurability using the attributes for the cases where the BSS does not receive the ARP IE attribute from the SGSN (SGSN may not be R6 compatible or may not include the optional ARP IE in the CREATE-BSS-PFC message).

260

Basic Admission Control Process

Admission Control (ARP)

Pool of Resources = f (Initial Capacity, GBR/MTBR, Transfer Delay)

Each PFC is allocated its EGBR/MTBR and Transfer Delay (if applicable) out of the Resource Pool

When sufficient resources are available, every PFC is admitted. During congestion, admission control determines whether -

A PFC is admitted if its MTBR or EGBR can be met.If the requested parameters are not met, PFCs of a lower ARP may be downgraded and/or preempted until sufficient resources are made available.As a last resort, the PFC requesting admission may itself be downgraded or rejected.If admission for the new PFC is not successful no downgrades and/or preemptions are performed.

BSS performs PFC level admission control using the ARP, guaranteed bit rate (GBR)/MTBR, Max SDU size and Transfer Delay attributes of the individual PFCs. When a PFC is admitted, the BSS may trigger multiple reschedules for mobiles in the same cell, PFC pre-emption in the same cell or in the cells sharing the same PRP board, or any combination of the above. The basic admission control process is illustrated in the slide.

261

New Database Parameters

mtbr_dowgrade_enabled

= 0 Disabled (Default)

=1 Enabled

A new configuration parameter to control whether bit rate negotiation below initial MTBR is permitted or not for non real-time traffic classes.

If mtbr_downgrade_enabled is enabled, and under congestion scenarios, a non real-time PFC of lower ARP to a PFC requesting admission will negotiate a downgrade in MTBR in order to prevent being pre-empted from the system.

Configurable MTBR Downgrade SupportNew database parameter mtbr_dowgrade_enable is provided to disable or enable PFC MTBR downgrade. When mtbr_downgrade_enable is set to 0, PCU will not consider MTBR downgrade for lower ARP non-real-time PFCs in situation when cell MTBR resources are constrained. Instead, PCU will directly proceed to preempting random lowest rank PFC.When mtbr_downgrade_enable is enabled, PCU will follow standard procedure and first consider if downgrading lower rank PFC(s) can release necessary bandwidth.

262


pfm_sig_enabled


=1 Enabled

A new configuration parameter determines whether or not PFC modification procedures over the Gb interface shall be initiated on downgrade/upgrade of a non-real time PFC, when sgsn_release=2.

When pfm_sig_enabled is enabled the PCU will support PFC modification signalling where a MODIFY-BSS-PFC Request message is sent to the SGSN upon downgrade or upgrade of a non real-time PFC, or in the case of PFC pre-emption, DELETE-BSS-PFC-REQ message will be sent.

An exception to the above is where max SDU size for NRT PFC is negotiated with the SGSN, in this case a MODIFY-BSS-PFC Request message is sent to the SGSN regardless.

263

Streaming Class Support

• streaming_enabled - 0=disabled (default) or 1=enabled

• thp_stream_weight – range=10-40 ; default=40

The PCU will support Streaming Traffic Class with the introduction of a new configuration parameter to enable or disable streaming class support BSS wide.In the event that streaming support was disabled, streaming PFCs would be admitted with the closest matching Interactive Class in terms of MTBR commitment.No dependency with other traffic class THP weighting

Key Requirements for Streaming Traffic Class support:Support for “Max SDU Size”, “Transfer Delay” and “Guaranteed Bit Rate”

attributes from the ABQP • Admission Control

Streaming users that cannot be admitted with the requested Max SDU Size, GBR and TD characteristics shall be negotiated appropriately

• Manage and Control separate flow control buffers per PFC/Traffic class negotiated for each mobile• Modification of PCU Scheduling algorithms to take streaming class delay/throughput characteristics into account• Support for ARP IE as defined in Release6 3GPP Specifications

264

Streaming Class Support

Guaranteed Bit Rate (GBR)Transfer Delay (TD)

• The PCU/BSS does not support transfer delays less than 400ms for RT PFCs.

• GBR & TD are both negotiable ABQP attributes.• Applicable to real-time traffic classes only.

Guaranteed Bit Rate (GBR)Defined as the guaranteed number of bits delivered at a SAP within a period of time (provided that there is data to deliver), divided by the duration of the period. For the GPRS RAN, the guaranteed bit rate is defined as the bit rate at the LLC layer. (as per 3GPP specification)

Transfer Delay (TD)Defines the maximum delay for 95th percentile of the distribution of delay for all delivered SDUs during the lifetime of a bearer service, where delay for an SDU is defined as the time from a request to transfer an SDU at one SAP to its delivery at the other SAP. (as per 23.107 specification)

265

Streaming Admission

GBR vs EGBR for TD 400ms

0.00

20.00

40.00

60.00

80.00

100.00

120.00

140.00

5 7 9 11 13 15 17 19 21 23 25 27 29 31 33

GBR (Kbps)

EGB

R (K

bps)

EGBR(100)EGBR(200)EGBR(300)EGBR(400)EGBR(500)EGBR(1000)EGBR(1500)

Admitting a streaming PFC requesting ABQP of GBR=12kbps with max SDU size=1000bytes & TD=400ms will require 60kbps of bandwidth in order to maintain requested QoS.

Chart: GBR to EGBR relationship for constant 400ms Transfer Delay and various LLC SDU sizes (Bytes).

Streaming traffic class QoS is maintained based on Effective Guaranteed Bit Rate.

Effective Guaranteed Bit Rate (EGBR) is defined as the bit-rate that must be provided across the RLC/MAC in order to support the QoS negotiated with the SGSN, and is a function of the negotiated UL/DL GBR, transfer delay and max SDU size.

EGBR is calculated internally by the QoS algorithm based on BLER, GBR, TD and max SDU size.

EGBR is Motorola defined.

For admission control, EGBR is used for real-time PFCs in the same way as MTBR is used for non real-time PFCs.

266


stream_downgrade_enabled


=1 Enabled

.

Configurable Streaming Downgrade supportNew database parameter streaming_dowgrade_enable is provided to disable or enable streaming traffic class PFCs downgrade. When streaming_downgrade_enable is set to 0, PCU will not consider RT PFC downgrade for lower ARP in situation when cell resources are constrained. Instead, PCU will directly proceed to preempting random lowest rank PFC.When streaming_downgrade_enable is enabled, PCU will follow standard procedure and first consider if downgrading lower rank PFC(s) can release necessary bandwidth.

When this parameter is enabled and the EGBR commitments cannot be met following an admission request from a higher ARP ranked real-time PFC, the lowest ranked real-time PFC will be downgraded through ABQP negotiation in terms of max SDU size and/or TD, and/or GBR.

If not, the lowest ARP ranked PFC will be rejected

267

Max Bit Rate Enforcement

qos_mbr_enabled


=1 Enabled

A new configuration parameter was introduced providing the ability to limit the throughput of real-time or non real-time mobile applied by the ABQP parameter Max Bit Rate (MBR).

UL MBR enforcement is on TBF level

DL MBR enforcement is on per PFC level

LLC PDUs that are received in excess of MBR are not discarded. PDUs will be stored in the DL buffer.

TS allocation limited based on MBR when MBR enforcement enabled

No MBR negotiation

Aggregate BSS QoS Profile (ABQP) – is the summation of one or more similar QoS profiles.

268

Internal BSS ParametersThe following parameters are internal to the BSS, and can be changed

through msg_send via emon:

• min_streaming_transfer_delay - (range 400-4000ms) default=500ms• Determines the minimum transfer delay for a RT PFC that can be

supported by the PCU.• TABR-factor – default=120%• Determines the threshold for TBF Aggregate Bit Rate when timeslot

removal procedures are enforced during congestion.• TD-factor – (range 0-25%) default=10%• Determines the factor by which Transfer Delay will be increased during

ABQP negotiation.• GBR-factor – (range 0-25%) default=0% (no change)• Determines the factor by which Guaranteed Bit Rate will be decreased

during ABQP negotiation.• rt_on_gprs – (range 0-1) default=0• Enables simulated RLC UNACK mode for RT PFC on GPRS for

retransmissions to prevent RLC window stalls.

269

QoS - Removed Parameters

• The following parameters have been replaced by the GSR9 ARP configuration parameters:

• arp_signal_sele• pfc_be_arp

270

New Statistics

PFC_PREMPTIONS_TRAFFIC_CLASS – Counts the number of PFCs pre-empted in each traffic class.

PFC_TRANSFER_DELAY – Counts the number of real-time traffic class PFCs which are admitted with transfer delay in the ABQP parameters.

PFC_GBR_UL – Counts the number of real-time traffic class PFCs which are admitted in the UL with guaranteed bit rate in the ABQP parameters.

PFC_GBR_DL – Counts the number of real-time traffic class PFCs which are admitted in the DL with guaranteed bit rate in the ABQP parameters.

271

New/Modified Statistics

update bins – Add bin PDU_DSCRD_LLC_NONCON_QOS for non-conformance discard

PDU_DISCARD_LLC/CELL

no updatesPFC_REJ_DGRD_PRMPT_CELL

no updatesPFC_REJ_DGRD_PRMPT_PRP

update bins - change to 14 priority levelsPFC_PREEMPTIONS/CELL

update bins - change to 14 priority levelsPFC_DOWNGRADE_FAILURE/CELL

update bins – change to 14 priority levelsPFC_DOWNGRADE_SUCCESS/CELL

update bins – change to 14 priority levelsPFC_UPGRADE/CELL

update bins – add streaming binUL_LLC_DATA_VOLUME/CELL

update bins – add streaming binDL_LLC_DATA_VOLUME/CELL

update bins – add streaming binPFC_REJECT_CAUSES/CELL

PFC_REJECTION_TRAFFIC_CLASS/CELL + update bins – add streaming binPFC_REJECTION_OTHER

update bins – change to 14 priority levelsPFC_REJECTION/CELL

PFC_ADMISSION_TRAFFIC_CLASS/CELL + update bins – add streaming binPFC_ADMISSION_OTHER

update bins – change to 14 priority levelsPFC_ADMISSION/CELL

no updatesTIMER_EXP_PAP_CONV

GSR9 QoSGSR8 QoS

StatisticsThe GSR8 QoS was based on BSS defined ARP values (used to derive ARP ranks) and the ARP values ranged from 1 to 3. The negotiated traffic classes supported in GSR8 was limited to the non real-time traffic classes. Most of the statistics defined for GSR8 QoS had separate bins illustrating the correlation between the traffic classes and ARP values that a particular PFC was admitted/pre-empted or rejected at. GSR9 ARP is based on the release6 definition and includes 14 valid priority levels plus the number of negotiated traffic classes has also grown to include the support for the streaming traffic class. The general philosophy used while updating the GSR8 QoS statistics is that most of the exiting statistics have been split into two. One statistic describes the various bins indicating the mix of the traffic classes and the other statistic describes the mix of the mobiles and their corresponding ARP priority levels (as per the 14 priority levels described in the Release6 of the 3GPP specifications).

272


















GSR9 QoSGSR8 QoS

New StatisticsPFC_PREEMPTIONS_TRAFFIC_CLASS counts the number of PFCs preempted in each Traffic Class.PFC_TRANSFER_DELAY statistic counts the number of real-time traffic class PFCs which are admitted with transfer delay in the ABQP parameters.PFC_GBR_UL statistic is pegged every time a real-time traffic class PFC is admitted in UL. The PFC_GBR_UL statistic counts the number of real-time traffic class PFCs which are admitted with guaranteed bit rate for uplink in the ABQP parameters.PFC_GBR_DL statistic is pegged every time a real-time traffic class PFC is admitted in DL. The PFC_GBR_DL statistic counts the number of real-time traffic class PFCs which are admitted with guaranteed bit rate for downlink in the ABQP parameters.

273


















GSR9 QoSGSR8 QoS

Modified StatisticsPFC_ADMISSION_TRAFFIC_CLASS /CELL (Modified existing GSR8 stats PFC_ADMISSION_OTHER, change name and add streaming bin)PFC_REJECTION_TRAFFIC_CLASS /CELL (Modified existing GSR8 stats PFC_REJECTION_OTHER, change name and add streaming bin)PFC_REJECT_CAUSES /CELL (add streaming bin)DL_LLC_DATA_VOLUME /CELL (add streaming bin)UL_LLC_DATA_VOLUME /CELL (add streaming bin)PFC_ADMISSION /CELL (changed bin to 14 priority levels)PFC_REJECTION /CELL (changed bin to 14 priority levels)PFC_UPGRADE /CELL (changed bin to 14 priority levels)PFC_DOWNGRADE_SUCCESS /CELL (changed bin to 14 priority levels)PFC_DOWNGRADE_FAILURE /CELL (changed bin to 14 priority levels)PFC_PREEMPTIONS /CELL (changed bin to 14 priority levels)PDU_DISCARD_LLC /CELL (add PDU_DSCRD_LLC_NONCON_QOS bin for non-conformance discard)

275

OMC-R Support for GSR9 QoS

FR 27703A

276

Quality of Service Phase 2 Enable

For Quality of Service Phase 2 to work it must be in the BSS D.V. Features List and shown as Un-Restricted (Enabled).

277

Setting the SGSN Release

To set the SGSN Release:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the SGSN Release function.4. Type in the required release value:

0 = SGSN is compliant with 3GPP Release 1998 or older (Default).1 = SGSN is compliant with 3GPP Release 1999 to any version before

Release 6.2 = SGSN is compliant with 3GPP Release 6 to newer.

5. Select File > Save – File > Close.

278

Setting the MTBR Downgrade Enable

To set the MTBR Downgrade Enable:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the MTBR Downgrade Enable function.4. Select Disable (0) (Default) or Enable (1) from the popup menu.5. Select File > Save – File > Close.

When mtbr_downgrade_enable is set to 0 (Disable) the PCU will not consider MTBR downgrade for lower ARP non-real-time PFCs in situation when cell MTBR resources are constrained (congested).

Instead, PCU will directly proceed to preempting random lowest rank PFC.When mtbr_downgrade_enable is enabled, PCU will follow standard procedure

and first consider if downgrading lower rank PFC(s) can release necessary bandwidth.

279

Setting the Support of PFC Modification Signalling Enable

To set the Support of PFC Modification Signalling Enable:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the Support of PFC Modification Signalling Enable

function.4. Select Disable (0) (Default) or Enable (1) from the popup menu.5. Select File > Save – File > Close.

When pfm_sig_enabled is enabled the PCU will support PFC modification signalling where a MODIFY-BSS-PFC Request message is sent to the SGSN upon downgrade or upgrade of a non real-time PFC, or in the case of PFC pre-emption, DELETE-BSS-PFC-REQ message will be sent.

280

Setting the Support of Streaming Traffic Enable

To set the Support of Streaming Traffic Enable:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the Support of Streaming Traffic Enable function.4. Select Disable (0) (Default) or Enable (1) from the popup menu.5. Select File > Save – File > Close.

This turns the Support for Streaming Traffic on/off.

281

Setting the Stream Downgrade Enable

To set the Stream Downgrade Enable:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the Stream Downgrade Enable function.4. Select Disable (0) (Default) or Enable (1) from the popup menu.5. Select File > Save – File > Close.

This turns the ability to Downgrade a streaming service on/off.

282

Viewing the ARP Rankings

To view and set up the ARP Rankings:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the Quality of Service or Quality of Service Phase 2

function.4. Enter the required value for the class of service (Streaming 1-3, Interactive 1-

3 or Background 1-3).5. Select File > Save – File > Close.

The default values are shown.

283

Viewing the ARP Rankings

At GSR9 ARP Ranking is now compliant with the 3GPP Release 6 Specification.The Table indicates how the ARP value is translated into the format for Octet 3 of the ARP IE.

In order to change the ARP Ranking structure the 8 Bit word must be constructed and then used to create the required value to be inserted in the OMC-R D.V.

285

DUAL PCU Mode

FR 30452

286

Feature Overview

The Dual PCU feature allows two BSCs to share a single PCU cage as two independent PCUs. The PCU cage is split into two halves: left and right. Each half of the cage becomes an independent PCU with slightly less than half of the processing capacity of a single PCU. Whereas a maximum config single PCU may have a maximum of three PICP DPROCs and nine PRP DPROCs, each PCU in a Dual-PCU cage may only have a maximum of two PICP DPROCs and four PRP DPROCs.

Each PCU can have its own database and load as long as both loads are Dual PCU capable. If only half of the PCU is to be used in Dual PCU Mode, use of the left hand half is strongly recommended.The left PCU equips PICP DPROC in slots 1 and 2 for GSL span connections and PRP DPROCs in slots 3 to 6 for TRAU GDS span connections. The right PCU equips PICP DPROC in slots 11 (Default) and 12 for GSL span connections, and PRP DPROCs in slots 13 to 16 for TRAU GDS span connections.The MPROC in slot 7, and the DPROCs in slots 1 to 6, obtain their database from the left BSC.The MPROC in slot 9, and the DPROCs in slots 11 to 16, obtain their database from the right BSC. In the Dual PCU mode, each MPROC controls its own half of the PCU cage. At the OMC, the two halves appear separately as two PCUs.Both HSCs are idle.The PCU MPROC executive monitor command prompt implements dual_pcu_mode command to display whether the Dual PCU mode is enabled or disabled. When the PCU is in Dual PCU mode, the BSC MMI state command reports PCU DPROCs equipped in the opposite half of the PCU cage as Disabled-Unlocked and the reason code is Not avail—Dual PCU Mode. Alarms and status change of both MPROCs (PSP) are shown in both the BSCs. Other devices equipped in the other half, such as MSI, MMS, etc, report the same reason code they would normally report if DPROC was OOS.

287

Feature Overview

The prerequisites before an MPROC is inserted into a PCU with another MPROC already running in dual mode are:• The MPROC contains dual-capable software.• The MPROC is enabled for dual mode through the jumper settings.• The two MPROCs monitor the health of each other’s “heartbeat”using an IML cable.

IML is mandatory as it is required for an MPROC to automaticallyreset the other MPROC in the same Dual PCU cage in case it is locked.

This feature is supported only on the MCP820 MPROC board and is enabled or disabled by changing the PUST jumper setting in a jumper block labelled J24 on the MCP820 board. The default setting is for Single PCU mode.Once the IML establishes, heartbeat messages are exchanged between MPROCs. If one of the MPROCs stops sending heartbeats, the other MPROC will assume the first MPROC is dead, and use the HSC to perform a power-cycle of it to return it to service.If the IML cable is pulled while the IML is in service, each MPROC will think the other is dead and attempt a power-cycle.If the operator discovers an MPROC to be hung, and heartbeats are disabled or the IML was not in service, the other MPROC will not attempt to automatically reset it.

288

DUAL PCU Mode

DescriptionThe dual_pcu_mode command displays whether the Dual-PCU mode is enabled or disabled.

Prerequisites This command can be executed only if the MPROC contains the dual-capable software.

Input parametersThere are no input parameters associated with this command.ExampleTo display whether the DUAL-PCU mode is enabled or disabled:[01/01/70 00:00:04] PCU:emon_1107 % dual_pcu_mode

System responseThe state of jumper J24 PUST[0] is: not installedThe state of jumper J24 PUST[1] is: installedThe state of jumper J24 PUST[2] is: not installedThe state of jumper J24 PUST[3] is: installedThe Dual-PCU mode is enabled when only PUST[1] and PUST[3] are installed.

289

DUAL PCU Mode

Default GSLs in slots 1 &2 (left) and slots 11 & 12(right)MPROC 7 controls PCI bus “A”MPROC 9 controls PCI bus “B”Both HSCs are idleDual PCU Mode –MPROC 7 controls PCI bus “A” and takes control of PSU fans/LEDs and Telco LEDsMPROC 9 controls PCI bus “B” and takes control of PSU fans/LEDs if MPROC 7 is not in serviceBoth HSCs are idle

290

MPROC Jumpers

291

MPROC Jumper Settings

To enable the feature, the PUST1 (pins 3 and 4) and PUST3 (pin 7 and 8) jumpers must be installed, while PUST0 (pins 1 and 2) and PUST2 (pins 5 and 6) must be removed. The recommended way to “remove” a jumper is to place it hanging across just one pin without connecting to the other pin, so that the jumper is still present (and thus not lost).

292

• Blank Page

293

Increase Throughput of PRP

FR 28000

294

Feature Overview

The Optional Enhanced PCU feature provides a migration path for operators wanting to expand their existing GPRS capabilities.

This feature will add new "off the shelf" available hardware components.

It strengthens the commitment of providing a cost effective solution to our customers.

It allows operators to build on their investments instead of replacing it.

The current PRP processor has a fanout of 120 PDCHs but only has a throughput of 30 PDCHs due to the constraint of CPU utilization. A rolling blackout mechanism is used to choose which 30 of the 120 PDCH will be serviced in any 20 msec block period.This restricted feature was requested to provide the option to disable the rolling blackout mechanism (timeslot selection algorithm on the PCU (PRP) by reducing the fan-out of the PRP, so that the throughput of the PRP processor is increased to the same as the fan-out of the PRP. The increased throughput of the PRP offers improved support for high throughput services such as HTTP, PoC, and video streaming. This feature resides on BSC and PCU. Because high throughput is required for some services, especially for QoS Streaming (when enabled), a method to increase PRP throughput in PCU is required. If we only consider increasing the depth of the interleaving per PDCH, this method cannot provide more throughput needed by Streaming. Thus Rolling Blackout mechanism is considered to be disabled to increase PRP throughput equal to the PRP fanout.

295

Benefits and Limitations of the featureBenefits:

• This feature increases data throughput per PRP / PXP board. Moreactive timeslots means increase of user data amounts being carried through PCU per block period thus potential increase in customerrevenue.

Limitations:

• With mode 2 enabled the capacity is reduced for throughput due to the total amount of PDTCHs being reduced.

296

Fanout Modes

Mode 1 - This mode allows to configure more PDCHs in a PRP, and RLC datablocks can be only scheduled on a number of PDCHs. The rest of PDCHs in the PRP can be used for RLC control blocks.

Mode 1= Rolling Blackout mechanism Enabled: => Capacity

- A maximum of X timeslots in a PRP are allowed to perform data transfers in each direction (Uplink and Downlink), every block period. The other “In Service” timeslots can transfer Control messages. This number X is less than the maximum number of PDTCHs configurable in the database per PRP.

- At the end of each block period, when the master timeslot is serviced, the top X UL and top X DL timeslots that will respectively receive and transmit data in the next block period are independently selected according to the rolling blackout algorithm.

- This mode allows to configure more PDCHs in a PRP, and RLC datablocks can be only scheduled on a number of PDCHs. The rest of PDCHs in the PRP can be used for RLC control blocks.

The Enhanced PCU feature will enable the PRP processor to be configured in one of two fan-out modes: prp_fanout_modeDependency: Modification is only allowed when GPRS feature is unrestrictedThis attribute indicates the PDCHs fanout mode of the PRP in the PCU. The fanout mode of the PRP provides the preference of more PDCH capacity or higher throughput of the PRP.

297

Fanout Modes

Mode 2 - This mode allows higher throughput of the PRP with fewer PDCHs configured. RLC data blocks can be scheduled on all the PDCHs in the PRP.

Mode 2 = Rolling Blackout mechanism Disabled – (where all PDCHs are serviced during each 20ms block period) => Improved PCU Throughput Performance

- All “In Service” timeslots configured in a PRP are allowed to perform data transfers in both uplink and downlink directions.

- This mode allows higher throughput of the PRP with fewer PDCHs configured. RLC data blocks can be scheduled on all the PDCHs in the PRP.

The BSC will reset the PCU when the value of prp_fanout_mode attribute changes.

Also, with the new DPROC2 hardware, the maximum number of supported PDCHs will be increased in both modes when the DPROC2 is configured as a PXP.

298

PRP/PXP Capacity numbers according to different fun out mode

42/ 42/ 8484/ 21/ 8498/ 98/ 196196/ 49/ 196140/ 140/ 280280/ 70/ 280U-DPROC2/PXP

N/AN/AN/AN/A60/ 60/ 60120/ 30/ 1201DPROC/PRP orU-DPROC2/PRP

Mode 2Mode 1Mode 2Mode 1Mode 2Mode 1

PMC Fanout/ Throughput /# of Mobiles

Base Processor Fanout/ Throughput / # of Mobiles

Total Fanout/ Throughput/ # of Mobiles

Base Processor and PMC module are two parts of U-DPROC2 boards which work together and make up the figures for the total board performance in PXP configuration (DD2 or DD3 mode); refer to ePCU Feature Bundle Strategy Guide for details

1 – Base Processor and PMC module are two parts of U-DPROC2 boards which work together and make up the figures for the total board performance in PXP configuration (DD2 or DD3 mode); refer to ePCU Feature Bundle Strategy Guide for details

PRP configuration modes: Capacity vs. ThroughputIn mode 1 with rolling blackout mechanism enabled, a maximum of X of the total “In Service” timeslots in a PRP are allowed to perform data transfers in each direction, every block period (the num X can be referred in Table 1). This number X is less than the maximum number of PDTCHs configurable in the database per PRP.In mode 2 with rolling blackout mechanism disabled, a maximum of total “In Service”timeslots in a PRP can transmit data in each direction, every block period. Table 1 depicts the detailed processing capacity in mode 1&2. The Increase PRP Throughput feature has interaction with ePCU features bundle and can be enabled on new PCU hardware U-DPROC2 introduced in GSR9. The PXP software device which can be configured on this new board has much higher capacity and throughput. Both capacity and throughput options available on U-DPROC2 and PXP are shown in the Table 1. As well as the U-DPROC2 board increasing throughput, the current DPROC boards can increase throughput when mode 2 is enabled.It is important to note that with mode 2 enabled the capacity is reduced for throughput due to the total amount of PDTCHs being reduced.The increased throughput of the PRP offers improved support for high throughput services such as HTTP, PoC, and video streaming. This feature resides on BSC and PCU. This feature is a restricted one depending on whether the customers need the high throughput in the PCU. That is to say that it is not mandatory to provide the options of mode 1&2 to the customers.From the table, we can see that there is a bigger PRP capacity if prp_fanout_mode is set to 1 compared with 2;and there is a bigger throughput if prp_fanout_mode is set to 2 compared with 1.In other words, the PRP throughput is increased by sacrificing PRP capacity.

299

MMI Commands

equip 0 pcuEnter the PCU Identifier: 0Enter the PCU base GDS IP Address: 10.15.255.222Enter the PCU GDS Subnet Mask: 255.255.255.248Enter the PCU GDS Router IP Address: 10.15.255.221Enter the WebMMI IP address: 127.0.0.2Enter the WebMMI subnet mask: 255.255.255.0Enter the WebMMI router IP address: 127.0.0.1Enter the NSEI value:5047Enter the PRP Fanout Mode: 1

PRP Fanout Mode element will be skipped and set to the default value during the PCU equipage when Increase the Throughput of PRP is restricted.

300

MMI Commands

0 = restricted1 = unrestricted

N/A10prpThptOpt


prpThptOpt

The prpThptOpt parameter indicates whether or not the Increase PRP Throughput with PCU feature is unrestricted in the BSS software.

301

Interaction with QoS Feature

MTBR Resource per PRP board PRP Fanout Mode 1 PRP Fanout Mode 2 DPROC/PRP or U-DPROC2/PRP 25 50 U-DPROC2/PXP Baseboard 40 81 U-DPROC2/PPROC 17 35

If QoS is enabled, the PCU shall commit MTBR resources in either direction by considering the PRP board as resource pool of the max timeslots number defined in the Table shown:

Notes : The 84% of the PRP service capacity is used for resource pool. The rest timeslots of throughput in every option of the table are reserved for headroom of QoS feature. This affects how MTBR is allocated during admission control and retention only and does not affect how throughput is allocated to mobiles in real time.

302

Statistics Impacted

The existing stats PRP_Load is modified to measure PRP load on a per DPROC basis (PRP, PXP baseboard or PPROC).

This stat is impacted to support both mode 1 and 2.

The load of the PRP , PXP baseboard or PPROC for PRP processing board is determined by measuring the number of timeslots pending service for data transfers within a 20 msec block period.

303

Statistics Impactedprp_fanout_mode=1: Rolling Blackout Mechanism Enabled (DEFAULT)

prp_fanout_mode=2: Rolling Blackout Mechanism Disabled

Number of timeslots pending service in a 20 msec block period

PRP Load Statistic %

PRP (DPROC U-DPROC2)

PXP Baseboard PPROC

0-30 PDTCHs 0-49 0-21 0-100

31-60 50-98 22-42 101-200

61-90 99-147 43-63 201-300

91-120 148-196 64-84 301-400

Number of timeslots pending service in a 20 msec block period

PRP Load Statistic %

PRP (DPROC or U-DPROC2)

PXP Baseboard

PPROC

0-60 PDTCHs 0-98 + 0-42 0-100

NA NA NA 101-200

NA NA NA 201-300

NA NA NA 301-400

According to the capacity requirements, the BSS will transfer data for a certain number of timeslots out of all the timeslots in a PRP, PXP baseboard or PPROC, as well as process control messages for rest of timeslots in one 20 msec block period.

The tables show the mapping between the number of timeslots pending service and the prp_load depending on the value of prp_fanout_mode and the DPROC type:

When prp_fanout_mode is set to 2, all the timeslots can be used to transfer data blocks. prp_load will not exceed 100.

Each bin range for this statistic has no change.

304

PCU Performance Analysis

AVG_SIMUL_UL_TBFS_MEAN

AVG_SIMUL_UL_TBFS_MAX

AVG_SIMUL_DL_TBFS_MEAN

AVG_SIMUL_DL_TBFS_MAX

EGPRS_AVAIL_PDTCH_MAX

EGPRS_AVAIL_PDTCH_MEAN

GPRS_AVAIL_PDTCH_MAX

GPRS_AVAIL_PDTCH_MEAN

PRP_LOAD_MIN

PRP_LOAD_MAX

PRP_LOAD_MEAN

Name

DL_BANDWIDTH_INDICATOR_EGPRS

UL_BANDWIDTH_INDICATOR_GPRS

DL_BANDWIDTH_INDICATOR_EGPRS

UL_BANDWIDTH_INDICATOR_EGPRS

DL_BUSY_PDTCH_MAX

DL_BUSY_PDTCH_MEAN

UL_BUSY_PDTCH_MAX

UL_BUSY_PDTCH_MEAN

Name

PCU performance analysisPRP and/or PXP boards performance and CPU utilization in fanout mode 2. Following stats should be observed:

305

OMC-R Support for Increase Throughput of PRP

FR 28000

306

Increase Throughput of PRP with PCU Feature Enable

For the Increase in Throughput of PRP with PCU Feature to work it must be in the BSS D.V. Features List and shown as Un-Restricted (Enabled).

307

Setting the PRP Fanout Mode

To set up the PCU Fanout Mode:

1. Open the PCU D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the PRP FANOUT function.4. Select “Rolling Blackout Enabled (1)” or “Rolling Blackout Disabled (2)” from

the popup menu.5. Select File > Save – File > Close.

308

• Blank Page

309

Support for Release 4 Based Extended Uplink TBF Mode

FR 26881

310

Feature Overview

This restricted feature enhances uplink data performance by minimizing the interruptions of uplink data flow in GPRS/EGPRS networks due to a frequent release and establishment of uplink TBF.

The Extended Uplink TBF Feature requires GPRS Feature to be un-restricted.

In the non-extended uplink TBF mode, the mobile station initiates the release of the uplink TBF by beginning the countdown process. This feature allows the uplink TBF to be maintained during temporary inactive periods, where the mobile station has no RLC information to send. The network determines the release of the uplink TBF. The network continues to allocate USFs for the mobile station during the inactivity period. The mobile sends Uplink Dummy Control Blocks if indicated or RLC data blocks, when new RLC data blocks become available.

A mobile station indicates whether it supports GERAN Feature Package 1 in the Mobile Station Classmark 3 IE, the MS Radio Access Capability IE and the MS Radio Access Capability 2 IE for this Extended UL TBF feature is part of GERAN Feature Package 1. R4 compliance feature in GSR 8.0 already implemented capability of detecting MS support for GERAN Feature Package 1.

311

MMI Commands

extuplinkOpt

Parameter Min Max Default Value Definition extuplinkOpt 0 1 N/A 0 = restricted

1 = unrestricted

The extuplinkOpt parameter indicates whether or not the Extended Uplink TBF feature functionality is unrestricted in the BSS software.

If the extuplinkOpt flag indicates that extended uplink TBF feature is restricted, attempts to change extended uplink TBF specific database parameters will be rejected.

The extuplinkOpt flag can only be unrestricted if GPRS is unrestricted.

312

MMI Commands

ext_ul_dur

Parameter Min Max Default Value Definition ext_ul_dur 0 250 0 0 : When the extended uplink

feature is unrestricted, value of 0 implies extended uplink feature is disabled. By default extended uplink feature is disabled. 24 – 250: When the feature is unrestricted, range represents the possible values for ext_ul_duration and selecting any value in the range enables the feature.

Note: 1 block period is 20msThe maximum duration of Extended Uplink TBF will be 5 seconds (250 data blocks). The uplink TBF will be released when ext_ul_dur expires.

There are two new parameters “ext_ul_dur” and “ext_utbf_nodata” introduced. Parameter of “ext_ul_dur” determines on/off of the feature and the duration of the Extended Uplink TBF.

313

MMI Commands

ext_utbf_nodata

Parameter Min Max Default Value Definition ext_utbf_nodata 0 1 0 0 The R6 mobile station send a

PACKET UPLINK DUMMY CONTROL BLOCK during extended uplink mode. 1 The R6 mobile station may refrain from sending a PACKET UPLINK DUMMY CONTROL BLOCK during extended uplink mode.

The new per CELL parameter - ext_utbf_nodata indicates to the R6 mobile station during extended uplink TBF mode to send or not to send any PACKET UPLINK DUMMY CONTROL BLOCK message when there is no other RLC/MAC block ready to send for this TBF. R4 mobile is always sending UL Dummy Control Block no matter this parameter is set.

This parameter of “ext_utbf_nodata” is broadcasted in GPRS Cell Options IE (part of Pkt System Information messages PSI1, PSI13, and SI13).

314

MMI Commands

ddtr_ctrl_enabled

Attribute name Min Max Default Value Definition Ddtr_ctrl_enabled 0 1 0 0 - disable the functionality related to delayed

downlink TBF release duration and extended uplink TBF duration of cell availability. 1 - enable the functionality related to delayed downlink TBF release duration and extended uplink TBF duration of cell availability.

The existing BSS element ddtr_ctrl_enabled description shall be modified to add the extended uplink TBF duration as a function of cell availability. The modified BSS element - ddtr_ctrl_enabled to enable/disable the functionality related to delayed downlink TBF release duration and extended uplink TBF duration of cell availability.

315

UL TBF message sequence without Extended UL TBF

UL RLC Data Block (CV = 1)

FPUAK (F.I bit is set, RRBP)

MS


0

12

0

12

24

BTS PCU SGSN

V(Q) = V (R)

Packet Control Ack Release TBF

Access and Assignment

24

UL Coattail

The slide shows normal uplink TBF release procedure: When the CV= 0 and V(R) =V (Q) (indicating that all the uplink data blocks have been received correctly), PCU will send the final PUAK with FI (Final-ACK-Indicator) bit set to 1 and include a valid RRBP field in the RLC/MAC control block header, the mobile station will send the Packet Control Acknowledgment (PCA) message to PCU and the uplink TBF will be released.

316

Uplink TBF with extended mode


PUAK (F.I bit is not set)

MS


0

12

24

0

12

24

BTS PCU SGSN

USF

UL Dummy Control Block

USF

V(Q) = V (R)

UL Dummy Control Block

PUAK (F.I = 1 , RRBP)

RRBP

Packet Control Ack

Release TBF

Optionalmax idle time

5sec

The slide shows the Extended Uplink TBF release procedure. When CV=0 and V(Q)=V(R) which indicating all uplink data was received correctly , PCU will keep the uplink TBF for a while instead of setting FI (Final-Ack-indicator) bit to 1 immediately as normal uplink TBF release procedure.

317

Statistics

New Statistics:

EXT_UL_EXIT - tracks number of exits from extended uplink TBF mode

EXT_UL_USF_USAGE - provides a method to traces number of control blocks received during extended uplink TBF mode. It also provides a method to record number of times no activity is recorded at the PCU during extended uplink TBF mode when ext_utbf_nodata = 1

Modified Statistic:

AIR_UL_TBF_FAILURES shall be modified. This statistic provides an overview of the number of abnormal uplink TBF releases that happen in a cell during various phases of the TBFs.

New Statistic: EXT_UL_EXIT - tracks number of exits from extended uplink TBF mode Benefit to the customer: Help to approximate latency improvements

New Statistic: EXT_UL_USF_USAGE - provides a method to traces number of control blocks received during extended uplink TBF mode. It also provides a method to record number of times no activity is recorded at the PCU during extended uplink TBF mode when ext_utbf_nodata = 1Benefit to the customer: · Help to approximate latency improvements.· Help to measure unused bandwidth during extended uplink.

318

Statistics

Modified Statistics for previous new statistics:

stat_mode - The command enables or disables individual statistics.

disp_enable_stat - This command displays enabled stats by CELL, location, or all stats in the system.

disp_stat_prop - This command displays the properties of stats.

disp_stats – Displays the Cell statistics

chg_stat_prop - This command will change relevant statistical information.

319

OMC-R Support for Release 4 BasedExtended Uplink TBF Mode

FR 26881

320

Release 4 Based Extended Uplink TBF Mode Enable

For the Release 4 Based Extended Uplink TBF Mode Feature to work it must be in the BSS D.V. Features List and shown as Un-Restricted (Enabled).

321

Setting the Extended Uplink TBF Duration

To set the Extended Uplink TBF Duration:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the Extended Uplink TBF Duration function.4. Enter the required value in the field box.5. Select File > Save – File > Close.

Value = 0 or 24 to 250 (20mSec block periods)

When the extended uplink feature is unrestricted a value of 0 implies extended uplink feature is disabled.

By default extended uplink feature is disabled.

24 – 250 X 20 mSec block periods giving a Maximum of 5 Seconds.

322

Setting the Delayed Downlink TBF Release Control

To set the Delayed Downlink TBF Release Control:

• Open the BSS D.V.• Select Edit > Edit from the menu.• Scroll down to or Find the Delayed Downlink TBF Release Control function.• Select the required value Disable (0) or Enable (1) from the popup menu.• Select File > Save – File > Close.

The existing BSS element ddtr_ctrl_enabled (Delayed Downlink TBF Release Control) is modified to add the extended uplink TBF duration as a function of cell availability.

0 - disable the functionality related to delayed downlink TBF release duration and extended uplink TBF duration of cell availability.

1 - enable the functionality related to delayed downlink TBF release duration and extended uplink TBF duration of cell availability.

323

Setting the Extended Uplink TBF No Data parameter

To set the Extended Uplink TBF No Data parameter:

1. Open the Cell D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the ext_utbf_nodata (Extended Uplink TBF No Data)

function.4. Select the required value “send PACKET UPLINK DUMMY CONTROL

BLOCK message (0)” or do not send PACKET UPLINK DUMMY CONTROL BLOCK message (1) from the popup menu.

5. Select File > Save – File > Close.

The new per CELL parameter - ext_utbf_nodata indicates to the R6 mobile station during extended uplink TBF mode to send or not to send any PACKET UPLINK DUMMY CONTROL BLOCK message when there is no other RLC/MAC block ready to send for this TBF.

R4 mobile is always sending UL Dummy Control Block no matter this parameter is set.

This parameter of “ext_utbf_nodata” (Extended Uplink TBF No Data) is broadcast in GPRS Cell Options IE (part of Pkt System Information messages PSI1, PSI13, and SI13).

324

• Blank Page

325

CTU2-D

FR 30828

326

Feature Description

With the introduction of CTU2D feature, the new CTU2D radios cansupport both SD and DD EDGE architectures, in addition to thevarious modes supported by legacy CTU2 radios.

As per the CTU2, CarrierA/B definitions and nomenclature also applyto CTU2D.

327

New, modified and deleted commands/Parameters

There are new commands/Parameters introduced with this featureAsym_edge_enabledCtu2d_cap_opt


The are modified commands/Parameters at the BSS as a result of this featureImproved_ts_enableddri_density


328

Edge modes

E E

X T/G

A

B

DD 20W CTU2D PWR /

CTU2 ITS

E E T T T T

X X X T/G T/G T/G

The following are the different Edge modes that the CTU2D radio supports:

· CTU2D SD: This mode is identical in operation to existing CTU2 SD and is only included for reference.

· CTU2D PWR: This mode is also known as ITS Mode whereby the CTU2 and CTU2D operation shall be identical. Of the two carriers, where the TS on carrier A are supporting an EDGE TS, the corresponding TS on carrier B will be blanked, i.e. not supporting anything. Carrier B TS will be capable of supporting only TCH or GPRS PDs where the corresponding TS on carrier A does not have an EDGE TS. The maximum output power of both carriers whether in GMSK or 8PSK mode is 20W

329

Edge modes

E E

T/G

A

B

DD 10W CTU2D CAP

E E E E E E

T/G T/G T/GT/GT/GT/G

or T or G No E

T/G

CTU2D CAP: Of the two carriers, carrier A will be fully EDGE-capable, while carrier B will support GPRS/TCH. No TS blanking is required. The maximum output power of carrier A in 8PSK mode is 10W and GMSK mode is 20W, the maximum output power carrier B(GMSK only) is always 20W.

330

Edge modes

E E E E E E E E A or T or G

E E E E E E E E B or T or G

DD 10W CTU2D ASYM

All PDCHs on this carrier do not

support 8PSK in UL (aka are GMSK

restricted)

CTU2D ASYM: Of the two carriers, carrier A will be fully EDGE-capable, while carrier B will support EDGE on the DL and GMSK (EDGE) on the UL. The maximum output power of carrier A in 8PSK mode is 10W and GMSK mode is 20W, the maximum output power of carrier B in GMSK mode is 20W.

331

CTU2D DRI Density Configuration

CTU2D Capacity feature must be unrestricted and CTU2D must be equipped in H2 (H2 Macro, H2 Micro and H2 Mini or H2 Ext off H2 master.

Double Density Capacity (Capacity)

as currentDouble Density (Double)

as currentSingle Density (Single)

The BSS has been enhanced to allow the operator to specify the density of a DRI in 3 modes using the existing O&M parameter dri_density as follows:

This can be specified at equip time and is also allowed to be changed during normal operation using the modify_value command as per current behaviour. As existing, any changes to the DRI Density requires that any/all associated DRIs are locked.The new mode of “capacity” is only applicable to the new CTU2D radio platform but it is not possible to detect the radio platform in all scenarios, hence radio configuration mismatch handling shall be enhanced to support this as follows:nonCTU2 configured as Capacity – as per existing behaviour with nonCTU2s configured in “double” – retained OOSCTU2 configured as “capacity” – will assume Double density behaviour with the exception that Edge support shall be inhibited.

332

Radio Capabilities

The hybrid of CTU2 and CTU2D can be configured in different operational modes within one cell. The operationalcapabilities of CTU2 and CTU2D are as follows:

Level0Level01(single)enabled/disabledon/offon/off

Level1Level12(double)disabledoffoff

Level1Level12(double)enabled/disabledonOff

Level2Level22(double)DisabledOn/offOn

Level2Level22(double)EnabledOn/offOn

Level1Level33(capacity)Disabledonon/off

Level1Level43(capacity)Enabledonon/off

CTU2 in H2CTU2D in H2dri_densityAsym_edge_enabledCAPacityImproved_ts_enabled

Where the Levels are classified as follows:Level0 – Basic SD Edge/GMSK operation (CTU2/CTU2D Equivalent)

Level1 – Basic DD GMSK/GMSK Operation (CTU2/CTU2D Equivalent)

Level2 – Level1 + Basic DD Edge/GMSK Operation with A Edge and BGMSK with Timeslot Blanking (as per GSR8 ITS) (CTU2/CTU2D Equivalent)

Level3 – Level1 + Enhanced DD Edge/GMSK removes B TS Blanking (CTU2D Only)

Level4 – Level3 + Edge/Edge with B restricted to UL GMSK Only (CTU2D Only)

333

OMC-R Support for CTU2-D

FR 30828

334

BSS Detailed View

For the Improved Timeslot Sharing, the CTU2-D Capacity and the CTU2-D Asymmetric EDGE Features to work they must be in the BSS D.V. Features List and shown as Un-Restricted (Enabled).

335

Enabling/Disabling Asymmetrical EDGE Feature

To Enable or Disable the Asymmetrical EDGE Feature:

1. Open the BTS D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the Asymmetrical EDGE Feature in the GPRS Section.4. Select Disable (0) (Default) or Enable (1) from the popup menu.5. Select File > Save – File > Close.

336

Enabling or Disabling Improved Timeslot Sharing Feature

To Enable or Disable the Improved Timeslot Sharing Feature:

1. Open the BSS D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the Improved Timeslot Sharing section.4. Select Disable (0) (Default) or Enable (1) from the popup menu.5. Select File > Save – File > Close.

337

Setting the DRI Density Mode

To Set the DRI Density Mode:

1. Open the DRI D.V.2. Select Edit > Edit from the menu.3. Scroll down to or Find the DRI Density Function.4. Select Single (1), Double (2) or Capacity (3) from the popup menu.5. Select File > Save – File > Close.

338

• Blank Page

339

GSR 9 OMC-R Specific Features

Chapter 4

340

Chapter 4

OMC-R Specific Features

• FR27508 - BSS User Security Management

• Platform Support

• FR25663 - Implementation of Secure Services on Solaris based O & M products.

• Enterprise Backup Server

• FR27751/27752 3GPP Release 6 Performance Management IRP 2G. 3GPP Upgrade to Release 6 for 2G element manager FM and CM functionality.

341

BSS User Security Management

FR 27508

342

Feature Overview

This feature provides a new username and password management system for the BSS/RXCDR replacing the existing system of sharedpassword access. It is not backward compatible with previous releases.

It provides the operator the ability to set up individual usernames for BSS/RXCDR access.

It provides for standard password management system which includes complexity checking, password ageing and encryption of password information both in password storage and password transfer across systems.

It also provides logging of user sessions therefore providing full traceability and accountability of network changes.

Usernames and passwords are managed at the OMC-R and usernames set-up on the OMC-R are defined across the entire system or on a geographic region basis. A mechanism will be provided at the OMC-R to manage BSS/BTS accounts and an interface from the OMC-R to the NEs will be provided for validation of the account information on user login attempts at individual NEs. A user will have a single username and password which will be valid across all the NEs to which that user has access.The account will be associated with a BSS command partition (level 1,2,3 or 4) which defines the commands accessible on the NEs by that account.The same command partition will apply across all NEs accessible by the user.NE granularity for access is BSC, that means access will be provided to a BSC and all elements under that BSC.

Engineering accounts will be maintained at the BSS.The purpose of these accounts is to let an on-site field engineer open a local session at the BSS when the OML link is either not configured or is not functional.The authentication of the users of these field engineering accounts is under the control of the BSS but the passwords are set up and maintained at the OMC-R.

343

Description• There are two types of user accounts maintained as part of this

feature implementation:

• -NE User Account

• -NE Field Engineer Account

4beatles24level 4fieldeng4

3stooges13level 3fieldeng3

2galvins02level 2fieldeng2

01level 1

DEFAULTPASSWORD

EMON LEVEL

MMI LEVELACCESS LEVEL

ACCOUNT

NE User Account

This is the normal user account which needs to be maintained and managed at the managing OMC-R The OMC-R administrator will be able to create a new username and assign a profile to the user which defines what BSS and EMON command sets that the user may access at the BSS.The omcadmin user can set NE access level for a NE user on OMC-R and when the user logs in to OMC-R, they will be placed at that access level.The default NE access level for the omcadmin user is 4, and for all other users the default is 1.The OMC-R user accounts are further defined in that a user will have access to part or all of the Network depending on the Geographic Partitioning and Region settings for the Network.

344

Description• There are two types of user accounts maintained as part of this

feature implementation:

• -NE User Account

• -NE Field Engineer Account

4beatles24level 4fieldeng4

3stooges13level 3fieldeng3

2galvins02level 2fieldeng2

01level 1

DEFAULTPASSWORD

EMON LEVEL

MMI LEVELACCESS LEVEL

ACCOUNT

NE Field Engineer AccountThese accounts are meant to be used by a field engineer only when physically visiting a site. Three fixed field engineer user accounts fieldeng2, fieldeng3, and fieldeng4 for the NE field engineer accounts are used only for qcomm application or local login purposes.The default passwords for the three field engineering accounts associated with access level 2/3/4 are listed as following:

Level2 field engineer account user name/password is: fieldeng2/2galvins. Level3 field engineer account user name/password is: fieldeng3/3stooges. Level4 field engineer account user name/password is: fieldeng4/4beatles.

OMC-R provides the interface to manage field engineering account passwords and actively synchronizes with BSS when these passwords are changed.It is not possible to change the field engineering account passwords at the BSS.

The table shows the levels of access for filedeng accounts and the default passwords.These accounts are defined on a Network level and are therefore the same for all BSC/RXCDR/BTS local logins. The passwords can be altered at the OMC-R by the System Administrator omcadmin account.

345

BSS User Security

•Access to 4 security levels is controlled by user accounts and passwords•User accounts and passwords are created by the OMC-R administrator and held at the OMC-R•Each level of access will provide the operator or engineer with a subset of the commands available to access and configure the BSS•From GSR9 the chg_l command is non effective

NOTE:

•There is a proposal to re-introduce the chg_level command.•The proposed solution is to continue to support chg_level in GSR9 as a non-functional or dummy command.•It will respond with the same prompts and messages as with GSR8.•This will allow existing scripts to function as expected.•It is assumed that customers will set the appropriate access levels.

Previously access to BSS network elements were provided by a single shared login. From GSR9, OMCR operators and BSS Engineers will be assigned individual usernames and passwords.The usernames and passwords will be assigned by the OMC Administrator and will dictate the level of access for an engineer or OMC operator.The OMC-R accounts created are similar to the UNIX accounts used to login to the OMC-R and are maintained at the OMC-R. When a BSC or RXCDR is connected to an OMCR access to the different levels of the system will be controlled by the usernames and password held at the OMC-R.

Note:There is a proposal to re-introduce the chg_level command which was previously removed under the BSS Security feature as many customer scripts that use remote login from the OMCR to run BSS commands and use chg_level to gain appropriate permissions may fail after upgrade of BSS to GSR9.The proposed solution is to continue to support chg_level in GSR9 as a non-functional or dummy command that will not change access level for a user. It will respond with the same prompts and messages as with GSR8 but otherwise will not perform any changes.This will allow existing scripts to function as expected for users who have the appropriate access level. It is assumed that customers will set the appropriate access levels for users who will need to run these scripts.

346

Customer Impacts– Any scripts/tools developed by the customer that use the

chg_level/chg_password commands should be modified so that they do not use this command for NEs with the GSR9 load. This is because the chg_level/chg_password command are not supported at GSR9. Instead the scripts should be executed only by a user account which has sufficient access level to execute the required commands.

– The NE access level of all the existing users on OMC-R except omcadmin user would be set to level 1 after OMC-R is upgraded to GSR9, so the customer should be aware that some users may not be able to access NE or execute some MMI commands due to the NE access level restriction. The limitation doesn’t apply until after the BSS/RXCDR upgrade to GSR9.

– A Customer Bulletin will be released for BSS user security management feature before GSR9 upgrade to remind these impacts.

It should be noted that the above will not be required if the proposal for the inclusion of chg_level as a non-functional or dummy command is included in the software release.

This will again be notified in a Bulletin prior to the release of the software to the customer.

347

BSS User Security

[18/06/07 13:13:00] MMI-RAM 0115 -> loginPersons authorized by the network operator may access this network element only for approved purposes. Misuse or misappropriation of the resources is prohibited.

Please input default Field Engineer account informationLogin:Password:

Access to the system is controlled by the login command

To change level the user will first have to logout from the current user level,controlled by the ‘logout’ command

When a field engineer logs in at the Site text is displayed indicating Authority to Access and usage of the resources at the Site.

This text is defined at the OMC-R at Network Level. The text can be altered to suite Operators requirements.

The field engineer must enter the level of entry:

fieldeng2fieldeng3fieldeng4

and enter the appropriate password.

Note:

1. If engineers require to change level they must first logout from the current level and login at the new level.

2. If engineers require to rlogin from the OMC-R they must have and use an OMC-R account and not the Local fieldengX accounts.

348

BSS User Security

fieldeng_always _enabled

Add/Change command string

chg_element fieldeng_always_enabled <value> 0

Display command string

disp_element fieldeng_always_enabled 0

ValuesValue type BooleanValid range 0 or 1

0 fieldengX accounts can be used at the NE if and only if OML link is down.

1 fieldengX accounts can be used at the NE always irrespective of the state of the OML link.

Default value 1

Field engineering accounts are for use by field engineers when executing MMI/emon commands locally on the NE equipment.

A parameter fieldeng_always_enabled set at the OMC-R determines when the local accounts can be:

1. fieldeng_always _enabled 0, the fieldeng accounts can be used only if the OML is out of service.

2. fieldeng_always _enabled 1, the fieldeng accounts can be used if the OML is connected or disconnected.

3. The Default is 1

349

OMC-R Support for BSS User Security Management

FR 27508

350

TTY Rlogin

Note the prompt now includes the user id

The security level for rlogin sessions by OMC operators is set up by the OMC Administrator.Omcadmin is always level 4.The security level may only be changed by omcadmin.

Rlogin sessions to an NE show a change at GSR9.The role performing the rlogin session is now indicated in the prompt and is included in square brackets.

351

Admin Options

Two new options are available in the Admin Options window at GSR9:

• NE Field Engineering Password Management

• NE Banner Text Management

352

Setting FieldEngX Password

Introduction to NE Field Engineer Password Management

The NE Field Engineer Password Management form allows an omcadmin operator to manage field engineer usernames and passwords from the OMC-R. The NE Field Engineer Password Management form can be accessed from the Admin menu on the Front Panel.When an attempt is made to open the NE Field Engineer Password Management window by a non-omcadmin operator, the following error message is displayed:

User <user_name> is not authorized to view the information NE Field Engineer Password Management form fieldengX Password

When this field is in Edit mode, the omcadmin operator can set the field engineering password for the fieldengX.The password must be between 6 and 8 characters in length and can be composed from the following set of characters: •from A-Z•from a – z•from 0 – 9•from any of the following characters: ! @ # $ % ^ & *NOTE:The characters of the password entered by the operator will be represented by *.

353

FieldEngX Password Expiry

Field Engineer Password Expiry on the OMC-R Alarms

Alarms may be generated when the password for field engineer (2/3/4) have expired on the OMC-R:

OMC: Password for field engineer (2/3/4) has expired on OMC-RAlarm Code 50000 field engineer 2 Alarm Code 50001 field engineer 3Alarm Code 50002 field engineer 4

Clearing Type: OICSeverity Level: MinorCategory: OMC

It should be noted that the fieldeng passwords never expire on the BSC/RXCDR/BTS sites but will be updated on all sites when the OMC-R passwords are changed due to expiry.

354

NE Banner Text

NE Banner Text Description

This parameter stores the Banner text.This specifies the NE usage policy and is provided by the NE to the user at the time of login with both fieldengX and normal user account.

The following properties are applicable to the parameter:

DataType: StringDisplayable Text: NE BannerGUI Access: RWRange: 1:255Default value:

This Network Element is protected by the Motorola BSS Security Feature. Access by unauthorised persons is prohibited and all users will be verified. For further information contact the OMC-R Systems Administrator.

355

Field Engineer Local Login Restrictions

Setting the Field Engineer Local Login Restrictions at the OMC-R

These accounts are used only when a field engineer physically visits a Site. The fieldeng2, fieldeng3, fieldeng4 accounts are meant only for qcomm or local login purposes.These account passwords never expire at the BTS but may expire at the OMC-R.Also blocking is not supported for these passwords.

There is a BSS parameter “fieldeng_always_enabled” or Field Engineer Always Enabled in OMC-R language that determines when the field engineers can use the local login procedure.

By default they can login locally when the OML is up or down.If the parameter is set to the Default of Enabled the field engineers can login to the BTS when the OML is up or down.If the parameter is set to Disabled the field engineers can only login to the BTS when the OML is down.

356

Setting Up User Profile

Setting Up User Accounts on the OMC-R

The setting up of a users profile has been enhanced at GSR9.The procedure is the same as GSR8 but an extra parameter has to be set to

define the users access to the NEs.

To set up a users profile:

1. Open the User Profile List by selecting Admin > Access Control from the GUI front panel.

2. Highlight the user account and select File > Open.

This opens the users individual Profile D.V. where all aspects of the users access can be set up.

357

Setting Up User NE Access

The top part of the form has not changed from GSR8 and the users access to OMC-R functions can be set up.

The addition of a users access level to NEs’ can now be set up at the bottom of the form.

To set up the NE Access:

1. Select Edit > Edit from the menu.2. Scroll to the bottom of the form and select the button to the right of NE

Access.3. Select the required Level (1-4) for the user.4. Select File > Save – File > Close.

358

• Blank Page

359

Platform Support at GSR9

360

Platform Supported

System Processor (SPLAT)• Netra 20• Netra 440• Sunfire 4800/4900

GUI Server• SunBlade 150• Netra 210• Flexible GUI Server Option

GUI Client• SunBlade 150• Sun Platform Meeting Minimum Specification

The following supported platforms have Motorola customised Jumpstart CDs provided to speed up the operating system installation for a GUI client:• Sunblade 150.

Any other Sun platform satisfying the following minimum specification can be set up as a GUI client by a skilled system administrator:The Minimum Specification for the GUI Client is:

Processor Speed Memory Hard Disk Size Graphics Card270 MHz 128 MB RAM 4 GB Required

361

GUI Sessions Supported

The sessions supported by the Various Platforms is shown.

It should be noted that the number of GUI Servers required to support the Maximum Single Platform capable sessions will vary depending on the GUI Server platforms employed.

362

GUI Sessions Permitted on GUI Server

• The number of GUI sessions permitted is given by the following formula.• This formula has been implemented in the corecheck_gui script.• The corecheck_gui script is used to start GUI sessions.• Maximums_GUIs = (Memory X CPU speed) / 39060) + 1

• Where is• Memory the GUI server memory• CPU Speed the CPU clock speed of the GUI server

The number of GUI sessions permitted is given by the following formula.This formula has been implemented in the corecheck_gui script.The corecheck_gui script is used to start GUI sessions.Maximums_GUIs = (Memory X CPU speed) / 39060) + 1

Where isMemory the GUI server memoryCPU Speed the CPU clock speed of the GUI server

363

Netra 20 Platform

This is the Low End platform and should only be used in small network configurations.

It has its own internal DVD Rom Drive and DAT Tape.It requires an External 3310 Disc Array.

364

Netra 440 Platform

This platform is again in support of the Low end configuration.

It has its own internal DVD Rom Drive.It requires and EXTERNAL DAT Tape Drive.It requires an External 3310 Disc Array.

365

SunFire 4800/4900 Platform

This is the Top End Platform and the recommended platform to safeguard future Network Expansion.The Platform does not have an Internal DVD or Tape Drive.A Media tray must be used for the DVD and Tape Drive functions.It requires an External 3310 Disc Array.

366

Disk partitioning for SunFire 4800/4900 and Netra 20/440 servers

Netra 440s have different controller numbers than those shown in the table.Instead of c1 and c3, Netra 440s use c0 and c1.

For example, the root partition on a Netra 20 is on slice c1t8d0s0 on the main disk and on slice c3t8d0s0 on the mirror disk.However, the root partition on a Netra 440 is on slice c0t8d0s0 on the main disk and on slice c1t8d0s0 on the mirror disk.

367

Disk partitioning for SunFire 4800/4900 and Netra 20/440 servers cont’d

368

OMC-R Single Platform Disk Partition Layout

369

OMC-R Single Platform Disk Partition Layout cont’d

370

• The script verify_platform which checks the configuration of the Flexible Platform should be run before attempting to install the GSR 9 OMC-R. Discrepancies between the platform and the minimum specification result in errors and/or warnings being generated. It is the responsibility of the user to correct these problems before installing the OMC-R. Ensure that you are logged in as root. Insert the GSR 9 OMC-R DVD in the DVD ROM drive. To validate the flexible platform, execute the following: cd /cdrom/cdrom0/s0/suninstall/Flexible

• ./verify_platform

• The following output is displayed:• Verifying Platform..• Platform Configuration: GUI server• Checking OS version..• Installed Operating System: 5.9• OS version is OK• <output omitted.. >• Finished verification of GUI server platform• Check logfile: /var/tmp/verify_platform.<pid>• No warnings were detected• No errors were detected

The script verify_platform which checks the configuration of the Flexible Platform should be run before attempting to install the GSR 9 OMC-R. Discrepancies between the platform and the minimum specification result in errors and/or warnings being generated. It is the responsibility of the user to correct these problems before installing the OMC-R. Ensure that you are logged in as root. Insert the GSR 9 OMC-R DVD in the DVD ROM drive. To validate the flexible platform, execute the following:cd /cdrom/cdrom0/s0/suninstall/Flexible./verify_platformThe following output is displayed:Verifying Platform..Platform Configuration: GUI serverChecking OS version..Installed Operating System: 5.9OS version is OK<output omitted.. >Finished verification of GUI server platformCheck logfile: /var/tmp/verify_platform.<pid>No warnings were detectedNo errors were detectedInstallation of the GSR 9 OMC-R software on a platform that has not been successfully validated by the verify_platform script may result in the failure of the installation and/or incorrect operation of the software.

371

Security Vulnerability

FR 25663

372

Security Vulnerabilities Across the OMC-R

• Insecure Services (rsh,rlogin,rcp,telnet, ftp) replaced with Secure Service equivalents which make use of key-based authentication:

• Secure Shell• The services rsh / rlogin / telnet are replaced with ssh (Secure Shell).

• Secure Copy• The Service rcp is replaced with scp (Secure Copy).

• Secure File Transfer Protocol• The Service ftp is replaced with sftp (Secure File Transfer Protocol).

This feature is being introduced to minimize security vulnerabilities across the OMC-R and other Motorola operations and maintenance products.The GSR9 OMC-R will be based on Solaris 10 Operating System. As part of Secure Services feature in GSR9, the OMC-R shall replace existing Insecure Services (rsh,rlogin,rcp,telnet, ftp) with Secure Service equivalents which make use of key-based authentication:Secure ShellThe services rsh / rlogin / telnet are replaced with ssh (Secure Shell).Secure CopyThe Service rcp is replaced with scp (Secure Copy). Secure File Transfer Protocol The Service ftp is replaced with sftp (Secure File Transfer Protocol).

All existing occurrences of Insecure Services in the OMC-R code and scripts will be replaced with the Secure Service equivalent. Once Secure Services is set up correctly, user operation of the various Motorola O&M products will be seamless and will not change after the introduction of the Secure Services Feature.

373

Customer Impacts

• Customers must take immediate action to prepare for the introduction of the GSR9 secure services feature.

• Bulletin Number: GSM_G_OMCR_085 describes the introduction of the Secure Services feature (FR25663) on Solaris based O&M Products in the GSR9 release.

• Potential impacts to customers, caused by Secure Services such as rsh,rlogin,rcp,telnet and ftp being disabled by default.

• Any customer scripts or third party tools which make use of the insecure services (described above) to access Motorola products such as the OMC-R will not work after upgrade to GSR9, as these insecure services will be disabled by default.

Customer Impacts

Customers must take immediate action to prepare for the introduction of the GSR9 secure services feature.

Bulletin Number: GSM_G_OMCR_085 describes the introduction of the Secure Services feature (FR25663) on Solaris based O&M Products in the GSR9 release, and the potential impacts to customers, caused by Secure Services such as rsh,rlogin,rcp,telnet and ftp being disabled by default.

Any customer scripts or third party tools which make use of the insecure services (described above) to access Motorola products such as the OMC-R will not work after upgrade to GSR9, as these insecure services will be disabled by default.

374

Actions Required

• Customers must update their scripts/tools accordingly before GSR9 upgrade.• OMC-R customers on the GSR8 release (Solaris 9) already have the packages necessary for “ssh” installed with the GSR8 OMC-R software.• Customers may choose to activate “ssh” on their OMC-R Single platform processors to test and resolve any issues with their scripts/tools using ssh, before they upgrade to GSR9.• OMC-R customers on the GSR7 release will not be able to install/activate “ssh” on their OMC-Rs until after they upgrade to GSR 8.• GSR7 customers should plan to implement this bulletin as soon as they have upgraded to GSR8 and before proceeding to GSR9.

• RLOGIN to NE procedure The OMC-R has a facility for users to rlogin directly to the BSC. This is not related to the standard UNIX rlogin and disabling the UNIX rlogin command will not impact this facility. Therefore there is no impact on BSC/BTS/RXCDR.

Actions Required Customers must update their scripts/tools accordingly before GSR9 upgrade. OMC-R customers on the GSR8 release (Solaris 9) already have the packages necessary for “ssh” installed with the GSR8 OMC-R software.Customers may choose to activate “ssh” on their OMC-R Single platform processors to test and resolve any issues with their scripts/tools using ssh, before they upgrade to GSR9.

GSR7 CustomersOMC-R customers on the GSR7 release will not be able to install/activate “ssh”on their OMC-Rs until after they upgrade to GSR 8.These customers should plan to implement this bulletin as soon as they have upgraded to GSR8 and before proceeding to GSR9.

RLOGIN to NE procedureThe OMC-R has a facility for users to rlogin directly to the BSC.This is not related to the standard UNIX rlogin and disabling the UNIX rlogin command will not impact this facility.Therefore there is no impact on BSC/BTS/RXCDR.

375

New login method in GSR9

• As telnet (and other insecure services such as rsh, rlogin) are now disabled by default in GSR9, access to the OMC-R Server or GUI server will be using ssh command.

• The ssh login has the following format:• ssh hostname –l username or ssh username@hostname

• Example 1:• ssh somc142 –l omcadmin

• Example 2:• ssh omcadmin@somc142

New login method in GSR9

As telnet (and other insecure services such as rsh, rlogin) are now disabled by default in GSR9, access to the OMC-R Server or GUI server will be using ssh command.

The ssh login has the following format:

ssh hostname –l username or ssh username@hostname

Example 1:ssh somc142 –l omcadmin

Example 2:ssh omcadmin@somc142

376

Customers with more than one OMC-R

• During the upgrade phase from GSR8 to GSR9, customers may have OMC-Rs on different releases i.e. some on GSR9, and the remaining on GSR8 which are yet to be upgraded to GSR9.

• In this scenario, OMC-R functionality which spans across multiple OMC-Rs such as license audit (FMON) and pcellSync, will not work correctly until all OMC-Rs are at GSR9.

• Solution

• This issue only applies to networks with multiple OMC-Rs.

• Full details on this will be detailed in the GSR9 OMC-R upgrade guide.

Customers with more than one OMC-R

During the upgrade phase from GSR8 to GSR9, customers may have OMC-Rs on different releases i.e. some on GSR9, and the remaining on GSR8 which are yet to be upgraded to GSR9.In this scenario, OMC-R functionality which spans across multiple OMC-Rs such as license audit (FMON) and pcellSync, will not work correctly.

Solution

This issue only applies to networks with multiple OMC-Rs.Full details on this will be detailed in the GSR9 OMC-R upgrade guide.

377

Updating scripts in GSR8

• Customers need to update any scripts/tools so that they replace insecure services with the secure service equivalent:

• On GSR8 OMC-R single platform processors you need to ensure the correct packages are installed, by running the following commands as user root.

1. # pkginfo | egrep ssh

2. # ps -ef | grep sshd

3. # /etc/init.d/sshd start

4. # /etc/rc3.d/S89sshd

Updating scripts in GSR8Customers need to update any scripts/tools so that they replace insecure services with the secure service

equivalent.On GSR8 OMC-R single platform processors you need to ensure the correct packages are installed, by

running the following commands as user root.

• # pkginfo | egrep sshShould see the following packages listed:SUNWsshcuSUNWsshdrSUNWsshduSUNWsshrSUNWsshu2. Confirm that the sshd is running by checking for the sshd process # ps -ef | grep sshd root 536 1 0 Feb 15 ? 0:00 /usr/lib/ssh/sshd Note that there may be more than one instance of the process.3. If above command does not produce any output, then you need to enable ssh daemon by running:# /etc/init.d/sshd start4. Confirm that the ssh process is configured to start when the machine is booted. Check for the following file:# /etc/rc3.d/S89sshd

378

Updating scripts in GSR8 cont’d

5. Ensure password-less ssh connection between OMC-R and remote host:

1. On each machine, as user root, edit /etc/ssh/sshd_config and change the setting for "PermitRootLogin" to "yes". Save the file and run "pkill sshd“

2. As user root on each machine, run "ssh-keygen -t rsa" and hit return for each question to accept the defaults.

3. As user root copy the file /.ssh/id_rsa.pub on each machine to /.ssh/authorized_keys on the other machine. Change permissions on the /.ssh directory to 700 and the /.ssh/authorized_keys file to 600.

4. As user omcadmin on each machine, run "ssh-keygen -t rsa" and hit return for each question to accept the defaults.

5. As user omcadmin copy the file /home/omcadmin/.ssh/id_rsa.pub on each machine to home/omcadmin/.ssh/authorized_keys on the other machine. Change permissions on the /home/omcadmin/.ssh directory to 700 and the /home/omcadmin/.ssh/authorized_keys file to 600.

6. The first time you use ssh to connect each way as each user, you will be asked if you accept the host key. Respond Yes to avoid being prompted again for that user.


5. Ensure password-less ssh connection between OMC-R and remote host:

1. On each machine, as user root, edit /etc/ssh/sshd_config and change the setting for "PermitRootLogin" to "yes". Save the file and run "pkill sshd“

2. As user root on each machine, run "ssh-keygen -t rsa" and hit return for each question to accept the defaults.

3. As user root copy the file /.ssh/id_rsa.pub on each machine to /.ssh/authorized_keys on the other machine. Change permissions on the /.ssh directory to 700 and the /.ssh/authorized_keys file to 600.

4. As user omcadmin on each machine, run "ssh-keygen -t rsa" and hit return for each question to accept the defaults.

5. As user omcadmin copy the file /home/omcadmin/.ssh/id_rsa.pub oneach machine to home/omcadmin/.ssh/authorized_keys on the other machine. Change permissions on the /home/omcadmin/.ssh directory to 700 and the /home/omcadmin/.ssh/authorized_keys file to 600

6. The first time you use ssh to connect each way as each user, you will be asked if you accept the host key. Respond Yes to avoid beingprompted again for that user.

379

Updating scripts in GSR8 cont’d

6. Customers need to update their individual scripts or tools to replace any instances of insecure services (rsh/rlogin/telnet,ftp, rcp) with the secure service equivalent (ssh,sftp,scp)

7. Customers should test their updated scripts/tools by connecting to GSR8 OMC-R using secure service methods.


6. Customers need to update their individual scripts or tools to replace any instances of insecure services (rsh/rlogin/telnet,ftp, rcp) with the secure service equivalent (ssh,sftp,scp)

7. Customers should test their updated scripts/tools by connecting to GSR8 OMC-R using secure service methods.

380

Checking the known_host file

• A problem may arise when logging in for the first time from a remote host, e.g. NHA, DG, then the process will hang because background process is asking user to respond to this initial login prompt

• As a precaution it’s advisable to ensure the host key is in the known_host file in advance to avoid this problem occurring. Thiswould be a recommended inclusion in any setup documentation for tools and adjunct products.

Checking the known_host file

A problem may arise when logging in for the first time from a remote host, e.g. NHA, DG, then the process will hang because background process is asking user to respond to this initial login prompt.

As a precaution it’s advisable to ensure the host key is in the known_host file in advance to avoid this problem occurring. This would be a recommended inclusion in any setup documentation for tools and adjunct products.

381

Sun StorEdge EnterpriseBackup Server (EBS)

382

The EBS three main utilities

• The Enterprise Backup Server GUI

• The nwbackup Utility

• The nwrecover Utility

The 3 EBS main utilities

• The Enterprise Backup Server GUIThis is the administration window for the StorEdge Enterprise Backup Server. It is a Java based application which is accessed using the Mozilla web browser on the OMC-R System Processor. It replaces the nwadmin utility and is used for administering the backup/restore.

• The nwbackup UtilityFor backing up UNIX file systems or part thereof. In particular, the utility is used for marking the file systems required to be backed up and then performing the actual file system backup to the specified labelled tape. It can be invoked manually or can be scheduled.

• The nwrecover UtilityFor restoring UNIX file systems or part thereof. In particular, the utility is used for restoring file systems that were initially backed up on tape media using the nwbackup utility.

383

Configuring the Backup Server Administration GUI

Use the following procedure to configure the Java web-based interface:

• 1. Login to the System Processor as user root.• 2. Remove the /.java directory, if it exists.• 3. Ensure that the DISPLAY is set correctly. • Open a browser window by executing the following:• /usr/sfw/bin/mozilla &• 4. In the browser window, select Edit > Preferences. • Highlight Helper Applications under Navigator, and select New Type.• 5. Add the following information:• MIME Type: application/x-java-jnlp-file• Extension: .jnlp• Open it with: /usr/j2se/jre/javaws/javaws• 6. Ensure that the Open it with: is selected.• 7. Click OK.• 8. Click OK to save out of Preferences.

Configuring the Backup Server Administration GUI

As of Solaris 10, the StorEdge Enterprise Backup Server GUI, nwadmin, is no longer available. Instead, a Java web-based interface has been introduced. Once the OMC-R Backup Server is installed, the StorEdge Enterprise Backup Server GUI can be configured.Use the following procedure to configure the Java web-based interface:1. Login to the System Processor as user root.2. Remove the /.java directory, if it exists.3. Ensure that the DISPLAY is set correctly. Open a browser window by executing the following:/usr/sfw/bin/mozilla &4. In the browser window, select Edit > Preferences. Highlight Helper Applications under Navigator, and select New Type.5. Add the following information:MIME Type: application/x-java-jnlp-fileExtension: .jnlpOpen it with: /usr/j2se/jre/javaws/javaws6. Ensure that the Open it with: is selected.7. Click OK.8. Click OK to save out of Preferences.

384

Launching the Backup Server Administration GUI

Use the following procedure to launch the Backup Server Administration GUI:

• 1. A browser is installed by default on the OMC-R Backup Server and can be run as user root.• 2. Ensure that the DISPLAY is set correctly. Open a browser window by executing the

following command:– /usr/sfw/bin/mozilla &

• 3. Connect to the following URL:– http://<Server>:1000

• Where <Server> is the fully qualified GSM OMC-R hostname.• 4. Click Start button to start the Enterprise Manager.• 5. A login dialog box is displayed. The default username/password is: Administrator• 6. On first login, configuration is required.• 7. Accept the License agreement and click Next on Welcome to the Configuration Window.• 8. Change the administrator password if required. Otherwise, click Next to retain the default.• 9. Click Next on Set Legato License Manager Server Name.• 10. Click Next on Set Database Backup Server window.• 11. Add Backup Server hostname on Add Sun StorEdge EBS Servers, and click Next.• 12. The GUI is displayed.

– Click the Enterprise button, and select the OMC-R Backup Server hostname.– Double-click the entry in the main window – another window, is displayed.

Launching the Backup Server Administration GUI:1. A browser is installed by default on the OMC-R Backup Server and can be run as user root.2. Ensure that the DISPLAY is set correctly. Open a browser window by executing the following command: /usr/sfw/bin/mozilla &3. Connect to the following URL: http://<Server>:1000Where <Server> is the fully qualified GSM OMC-R hostname.4. Click Start button to start the Enterprise Manager.5. A login dialog box is displayed. Default username/password is: Administrator6. On first login, configuration is required.7. Accept License agreement. Click Next on Welcome to the Configuration Window.8. Change the administrator password if required or click Next to retain default.9. Click Next on Set Legato License Manager Server Name.10. Click Next on Set Database Backup Server window.11. Add Backup Server hostname on Add Sun StorEdge EBS Servers, click Next.12. The GUI is displayed. Click the Enterprise button, and select the OMC-R Backup Server hostname. Double-click the entry in the main window – another window, is displayed.

385

3GPP Release 6 Performance Management IRP 2G3GPP Release 6 FM and CM IRP 2G

Feature 27751/27752

386

Overall Description

• These features upgrade 3GPP functionality to Release 6 compliance:

• Fault Management IRP (Integration Reference Point)

• Bulk Configuration Management IRP

• State Management IRP

• Performance Management File (3GPP Release 6 Performance Management IRP 2G)

Overall Description

These features upgrade 3GPP functionality to Release 6 compliance:

Fault Management IRP (Integration Reference Point)

Bulk Configuration Management IRP

State Management IRP

Performance Management File (3GPP Release 6 Performance Management IRP 2G)

387

Integration Reference Points

The following IRPs are required for GSR9:

• Entry Point IRP (Release 6)• Performance Management IRP (Release 6)• Communications Surveillance IRP (Release 6)• Kernel Configuration Management IRP (Release 5 & Release 6)• Bulk Configuration Management IRP (Release 5 & Release 6)• File Transfer IRP (Release 6)• NBI Fault Management (Release 5 and Release 6)

NOTE:The upgrade to the latest NBI Core partner release of GSR9 requires a

clean install.

The following Integration Reference Points are required for GSR9:

•Entry Point IRP (Release 6)•Performance Management IRP (Release 6)•Communications Surveillance IRP (Release 6)•Kernel Configuration Management IRP (Release 5 & Release 6)•Bulk Configuration Management IRP (Release 5 & Release 6)•File Transfer IRP (Release 6)•NBI Fault Management (Release 5 and Release 6)

388

Performance Management (PM) Upgrade and New File Transfer IRP

GSR9 delivers the upgrade of all previously delivered 3GPP PM functionality to release 6 compliance.

It also introduces a New IRP: File Transfer IRP

The Feature upgrade consists of:

• Support the File Transfer IRP which is addressing how files are exchanged through Itf-N as well as certain aspects of file management and maintenance.

• The introduction of the FT IRP does impact the overall architecture. • PM IRP now hands over its completed files to the FT IRP instead of

initiating the FTP to the NMC by itself.• Update PM IRP Agent to use a Release 6 updated NRM. (Updated to

support all new/changed/delete stats being caused by other GSR9 features.)

GSR9 delivers the upgrade of all previously delivered 3GPP PM functionality to release 6 compliance.

It also introduces a new IRP: File Transfer IRP

The Feature upgrade consists of:

•Support the File Transfer IRP which is addressing how files are exchanged through Itf-N as well as certain aspects of file management and maintenance.•The introduction of the FT IRP does impact the overall architecture.•PM IRP now hands over its completed files to the FT IRP instead of initiating the FTP to the NMC by itself.•Update PM IRP Agent to use a Release 6 updated NRM. (Updated to support all new/changed/delete stats being caused by other GSR9 features.)

389

Entry Point (EP) IRP & Communication Surveillance (CS)

3GPP Entry Point (EP) IRP

Entry Point IRP is newly introduced in Motorola GSR9 NBI solution while compliant to 3GPP Release 6 FM and CM specifications.

• Entry Point provides the following:

– It allows NM to discover outline information of IRPs, including the DN of IRPs and the supported IRP Versions and their scope of management (e.g. the set of network resources that it is responsible for) in the managed systems.

– It supports NM to obtain the References of the IRPs of specific IRPVersion by means of the IRPManager inputting the DN of the IRP which supports the IRP Version number it needs.

– Entry Point allows NM to indicate to the managed system the References it will not use again.

• Communication Surveillance (CS) IRP

• The communication between NM and Managed System (NE) shall be monitored, and link breaks between NM and Managed System shall be discovered by NM as early as possible.

3GPP Entry Point (EP) IRP

Entry Point IRP is newly introduced in Motorola GSR9 NBI solution while compliant to 3GPP Release 6 FM and CM specifications.

Entry Point provides the following:•It allows NM to discover outline information of IRPs, including the DN of IRPs and the supported IRP Versions and their scope of management (e.g. the set of network resources that it is responsible for) in the managed systems.•It supports NM to obtain the References of the IRPs of specific IRPVersion by means of the IRPManager inputting the DN of the IRP which supports the IRP Version number it needs.•Entry Point allows NM to indicate to the managed system the References it will not use again.

Communication Surveillance (CS) IRP

•The communication between NM and Managed System (NE) shall be monitored, and link breaks between NM and Managed System shall be discovered by NM as early as possible.

390

3GPP Fault Management & Configuration Management IRP

Configuration Management IRP

• CM is composed of Kernel CM & Bulk CM

– Kernel CM• Configuration Management existed from GSR8 and has had minor

updates for GSR9 • Updates to kernel CM of re-synch to recommend a state change

notification.– Bulk CM is characterised by:

• Bulk (file-oriented) data retrieval (configuration parameters) over Interface-N from single NEs, a collection of NEs or the whole network.

• Bulk (file-oriented, XML) data download of configuration parameters to NEs over Interface-N. The network-wide activation of those parameters through a single operation.

• Fault Management IRP

• The first phase of the CORBA interface development is the interpretation and management of alarms being generated by the OMCR.

• These alarms are picked up by the alarm interface and converted into CORBA objects which can then be passed through the standard CORBA interface to the NMC application.

• Fault Management existed from GSR7 and has had minor updates for GSR9 from GSR8.

3GPP Configuration Management IRPCM is composed of Kernel CM & Bulk CM•Kernel CM

•Configuration Management existed from GSR8 and has had minor updates for GSR9.•Updates to kernel CM of re-synch to recommend a state change notification.

•Bulk CM is characterised by:•Bulk (file-oriented) data retrieval (configuration parameters) over Interface-N from single NEs, a collection of NEs or the whole network.•Bulk (file-oriented, XML) data download of configuration parameters to NEs over Interface-N. The network-wide activation of those parameters through a single operation.

3GPP Fault Management IRP•The first phase of the CORBA interface development is the interpretation and management of alarms being generated by the OMCR.•These alarms are picked up by the alarm interface and converted into CORBA objects which can then be passed through the standard CORBA interface to the NMC application.•Fault Management existed from GSR7 and has had minor updates for GSR9 from GSR8.

gsr9 delta

Documents