B9 Status at MR1 Ed4 QD11

8/23/2019 B9 Status at MR1 Ed4 QD11

http://slidepdf.com/reader/full/b9-status-at-mr1-ed4-qd11 1/121

All rights reserved © 2005, Evolium

Release B9B9 MR1 ed4 + QD#11 Status

27/06/06



B9 MR1 ed4+QD#11 status – 27/06/06 All rights reserved © 2005, Evolium

Agenda

Context of B9 SYS-DR5

Delivery content

QoS feedback

Remaining Features & Configuration where feedback is welcomed

Main Remaining IssuesB9 Introduction

Warning towards RSC

Appendixes

IOT Status

PS Alerters definition Features & configuration tested on field




Context of B9 SYS-DR5

Main conditions to run General Availability Decision review are reached Acceptance and pilot phases completed for the two FO’s, Orange and Vimpelcom.

Green light for rollout granted for the two FO’s with MR1 ed4 (QD8 and QD11)

Already widely deployed in FO’s , but additionally also with numerous early

adopters (more than 600 BSS’s in B9)

Rollout finished in Vimpelcom (Nino).

Rollout ongoing in Orange France 315 BSS’s on a total of 321 are in B9

Numerous early adopters have already started or finalized roll-out

All emergency issues coming from FO’s and early adopters are followed and

managed in daily UO meeting with NPI, ARO(PCS), C-TAC, and concernedPrograms

Main issues are solved ; remaining are planned in next maintenance edition

Alcatel management decision taken to run General Availability Decision

Review




Delivery Content – BSSSAW01B Ed04_QD11




Documentation

BSS Software List - 3BK 13016 0991 TQZZA Available

Restriction List - 3BK 13016 0993 TQZZA

Ed02 available

Operator Hints - 3BK 13016 0994 TQZZA

Ed01 available

Migration Software and Upgrade RL and OH - 3BK 13016 0995 TQZZA

Ed02 available

Counters and Indicators Status - 3BK 13091 0142 TQZZA

Ed01 available

Annex to the delivery note (technical dossier) - 3BK 13016 0992 TQZZA

Available




QoS Feedback




Content

B9 QOS CS

Main Results

Main Improvements

Remaining Issues

B9 QOS PS

Main Improvements

Remaining Issues

QOS expected variation due to new B9 algorithms

Conclusion

Annexes




B9 QOS

CS




QOS Circuit – B9MR1Ed4QD11Radio Link Establishment - Results

Customer

SDCCH Congestion Rate SDCCH Assignment Failure

B8 B9 B8 B9

Orange France

(LeMans-Evolium)

0.31%

(0.02 - 0.87)

0.73%

(0.3 – 1.73)

2.87%

(2.33 – 3.53)

3.2%

(2.78 – 3.88)

Orange France(LeMans-G2)

Unreliable 0.94%(0.06 – 4.89)

8.73%(5.78 – 8.80)

9.29%(7.43 – 9.16)

Tmobile

(3BSCs)SL,W,WDS

2.03%

2.06%

0.10%

3.85%

1.92%

0.36%

4.52%

3.81%

3.59%

3.88%

5.18%

5.13%

SFR

(Evolium)

0.06% 0.08% 2.4% 2.67%

SFR

(G2)

0.05% 0.05% 5.44% 5.67%

VIP (QD8)(PreP) 1.7% 0.79% 1.81% 2.19%

VIP (QD8)(Nino) 0.48% 0.71% 2.43% 3.4%

StableUnder Investigation

(Burst on some cells)

Delta B8-B9 Figures must not be taken as reference

(Not frozen networks on most of the pilots due to several B9 patches on a long period)




QOS Circuit – B9MR1Ed4QD11Call Establishment - Results

Customer

SDCCH Drop Rate RTCH AssignUnsuccess rate

Call Setup Success Rate

B8 B9 B8 B9 B8 B9

Orange France

(LeMans)

(evolium)

0.40% 0.43% <0

(FR counter B8MR5)

0.48% (unreliable)(FR counter B8MR5)

99.09%

Orange France(LeMans)

(G2)

1.05% 1.04% <0(FR counter B8MR5)

0.83% (unreliable)(FR counter B8MR5)

98.14%

Tmobile

(3BSCs)SL,W,WDS

0.33%

0.26%

0.47%

0.40%

0.3%

0.51%

0.35%

0.21%

0.23%

0.11%

0.2%

0.27%

99.31%

99.54%

99.31%

99.5%

99.50%

99.22%

SFR

(Evolium)

0.27% 0.32% 0.68% 0.51% 99.05% 99.17%

SFR

(G2)

0.39% 0.52% 0.65% 0.46% 98.97% 99.02%

VIP (QD8)(PreP) 0.41% 0.4% 0.52% 0.23% 99.01% 99.37%

VIP(QD8)(Nino) 0.7% 0.77% 0.64% 0.51% 97.56% 98.72%

Stable /Improved

Stable






QOS Circuit – B9MR1Ed4QD11Radio Congestion - Results

Customer

RTCH Congestion Rate Incoming Inter BSCCongestion Rate

Incoming Intra BSCCongestion Rate

B8 B9 B8 B9 B8 B9

Orange France

(LeMans)

(evolium)

0.01% 0.03% 0.85% 0.99% 1.12% 1.08%

Orange France

(LeMans)

(G2)

0.11% 0.22% 5.29% 3.25% 0.72% 1.42%

Tmobile

(3BSCs)SL,W,WDS

0.13%

0%

0.01%

0.01%

0%

0%

(unreliable)

1.61%

1.06%

0.48%

0.02%

0.28%

0.99%

0.24%

0.12%

1.31%

0.23%

0.41%

SFR(Evolium)

0.05% 0.06% 0.36% 0.51% 1.89% 1.95%

SFR

(G2)

0.06% 0.1% 0.36% 0.44% 1.51% 2.46%

VIP (QD8)(PreP) 0.17% 0.01% 4.79% 0.88% 5.54% 0.68%

VIP (QD8)(Nino) 0.89% 0.63% 14.67% 11.63% 11.11% 8.83%

Stability or Low increaseRelated to new

Radio RessourceAllocation Algorihm






QOS Circuit- B9MR1Ed4QD11Call Drop rate – Results

Customer Call Drop Rate Call Drop Rate - other networks

B8 B9 Customers B8 B9

Orange France

(LeMans)

(evolium)

0.81% 0.95% Voxtel 0.9% 0.96%

Orange France

(LeMans)(G2)

1.78% 2.25% Orange Romania 0.41% 0.39%

Orange France West 1.01% 1.03% Jersey 0.7% 0.75%

Tmobile

(3BSCs)

SL,W,WDS

0.89%

0.70%

0.97%

unreliable

0.84%

1.04%

SFR

(Evo, G2)

0.77%

1.21%

1.01%

1.40%

VIP (QD8)(PreP) 0.63% 0.49%

VIP (QD8)(Nino) 1.35% 1.3%

Stable on some networks, slight degradationobserved on others

NO CUSTOMER COMPLAINT.

=> Indicator very sensible to traffic profile; Onnetworks where this delta is observed, theobservation time between B8 and last B9QD11 is 3months later and the networks are no more in theequivalent configuration.

=> Recommendation: Specific monitoring to be doneby RSC/RNE for next B8-B9 migrations

QOS Ci i B9MR1Ed4QD11




QOS Circuit- B9MR1Ed4QD11Call Drop Rate

Orange Romania (B8-B9QD11)

Orange France Ouest (B8-B9QD11)

Call drop

0

20000

40000

60000

80000

100000

120000

140000

0 4 / 2 4

/ 2 0 0

6

0 4 / 2 6

/ 2 0 0

6

0 4 / 2 8

/ 2 0 0 6

0 4 / 3 0

/ 2 0 0

6

0 5 / 0 2

/ 2 0 0

6

0 5 / 0 4

/ 2 0 0

6

0 5 / 0 6

/ 2 0 0

6

0 5 / 0 8

/ 2 0 0

6

0 5 / 1 0

/ 2 0 0

6

0 5 / 1 2

/ 2 0 0

6

0 5 / 1 4

/ 2 0 0

6

0 5 / 1 6

/ 2 0 0

6

0 5 / 1 8

/ 2 0 0

6

0 5 / 2 0

/ 2 0 0 6

0 5 / 2 2

/ 2 0 0

6

0 5 / 2 4

/ 2 0 0 6

0 5 / 2 6

/ 2 0 0

6

0 5 / 3 0

/ 2 0 0 6

0

0,2

0,4

0,6

0,8

1

1,2

1,4 Preemption

Drop - BSS

RTCDrop BSS

InternDrop - HO

Drop - Radio

% RTCH drop

B8

B8 B9

B9

B8-> B9QD11 Migration

B8 Reference




B9 QOS Main Improvements - GSM

The B9 main improvments can be summarized belowCall Setup Success Rate increased when CS is favoured

Orange Romania

See Graph =>

Vimpelcom (QD8)

Multiband RFD improvment

Call success

0

5000

10000

15000

20000

25000

30000

0 5 / 0 7 / 2 0

0 6

0 5 / 0 8 / 2 0

0 6

0 5 / 0 9 / 2 0

0 6

0 5 / 1 0 / 2 0

0 6

0 5 / 1 1 / 2 0

0 6

0 5 / 1 2 / 2 0

0 6

0 5 / 1 3 / 2 0

0 6

0 5 / 1 4 / 2 0

0 6

0 5 / 1 5 / 2 0

0 6

0 5 / 1 6 / 2 0

0 6

0 5 / 1 7 / 2 0

0 6

0 5 / 1 8 / 2 0

0 6

0 5 / 1 9 / 2 0

0 6

0 5 / 2 0 / 2 0

0 6

0 5 / 2 1 / 2 0

0 6

0 5 / 2 2 / 2 0

0 6

0 5 / 2 3 / 2 0

0 6

0 5 / 2 4 / 2 0

0 6

0 5 / 2 5 / 2 0

0 6

0 5 / 2 6 / 2 0

0 6

0 5 / 2 7 / 2 0

0 6

0 5 / 2 8 / 2 0

0 6

0 5 / 2 9 / 2 0

0 6

0 5 / 3 0 / 2 0

0 6

0 5 / 3 1 / 2 0

0 6

0 6 / 0 1 / 2 0

0 6

0 6 / 0 2 / 2 0

0 6

0 6 / 0 3 / 2 0

0 6

0 6 / 0 4 / 2 0

0 6

97,5

98

98,5

99

99,5

100

Call drop

Assign Unsucc

SDCCH drop

% Call success

% Call setup

B8-> B9 Migration

Higher

Values




B9 QOS Remaining Issues - GSM

SDCCH Assignement Failure

Very low variation

Ressources Management

Radio congestion (no impact end users for Congestion on HO)

Parameter tuning can reduce the radio congestion (tested in QD10 in ERA)

Under observation

Call drop rate

To be monitored in the next migrations with equivalent configurations beforeand after migrations




B9 QOS

PS




B9 QOS

PSMain Improvements




B9 QOS Main Improvements - PS

PS Improvements brought by New features

Abis Dynamic and Statistical Multiplexing features have beensuccessfully applied on global network

Orange France network offers MCS9 with ABIS dimensioning equivalent to

B8 class 2 (MCS5) without any congestionExtended UL TBF Mode (Main results from end user field tests)

NACC/PSI (Main results from end user field tests)

8-PSK en UL

Abi D i O F f t t t




Abis Dynamic – Orange France feature testsExtraAbisTS reduction

B8 B9 Iso B8 MaxMCS=9

Extra Abis

TS reduction

(Mainly on BSC2)

MAX_PDCH

=12

In B8, BSC

with about 80%

of cells in class 2

In B8, BSC

with about 80%

of cells in class 4

Dynamic AbisBenefit1:

Same transmissionressources

as in B8 ANDhigher codingschemes usage

Dynamic AbisBenefit2:

lower transmissionressources

than in B8 ANDSame coding

schemes usage

BSC1

BSC2

B9 Abis DimensioningEquivallent to B8 class 2

Allows MCS9 usage w/o limitation

On 80% of the

cells of BSC2, the

extraAbisTS have

Been divided by 3

Abis Dynamic Coding scheme Usage




Abis Dynamic – Coding scheme UsageOrange France – West Region Roll-out

DL EGPRS useful RLC traffic

0

50000000

100000000

150000000

200000000

250000000

300000000

0 4 / 2 4 / 2 0 0

6

0 4 / 2 6 / 2 0 0

6

0 4 / 2 8 / 2 0 0

6

0 4 / 3 0 / 2 0 0

6

0 5 / 0 2 / 2 0 0

6

0 5 / 0 4 / 2 0 0

6

0 5 / 0 6 / 2 0 0

6

0 5 / 0 8 / 2 0 0

6

0 5 / 1 0 / 2 0 0

6

0 5 / 1 2 / 2 0 0

6

0 5 / 1 4 / 2 0 0

6

0 5 / 1 6 / 2 0 0

6

0 5 / 1 8 / 2 0 0

6

0 5 / 2 0 / 2 0 0

6

0 5 / 2 2 / 2 0 0

6

0 5 / 2 4 / 2 0 0

6

0 5 / 2 6 / 2 0 0

6

0 5 / 3 0 / 2 0 0

6

0

10

20

30

40

50

60

70

80

MCS9 usef

MCS8 usef

MCS7 usef

MCS6 usef

MCS5 usef

MCS4 usef

MCS3 usef

MCS2 usef

MCS1 usef

%ioMCSxusef

%io8PSKusef

UL EGPRS useful RLC traffic

0

10000000

20000000

30000000

40000000

50000000

60000000

70000000

80000000

90000000

0 4 / 2 4 / 2 0 0

6

0 4 / 2 6 / 2 0 0

6

0 4 / 2 8 / 2 0 0

6

0 4 / 3 0 / 2 0 0

6

0 5 / 0 2 / 2 0 0

6

0 5 / 0 4 / 2 0 0

6

0 5 / 0 6 / 2 0 0 6

0 5 / 0 8 / 2 0 0

6

0 5 / 1 0 / 2 0 0 6

0 5 / 1 2 / 2 0 0

6

0 5 / 1 4 / 2 0 0 6

0 5 / 1 6 / 2 0 0

6

0 5 / 1 8 / 2 0 0 6

0 5 / 2 0 / 2 0 0

6

0 5 / 2 2 / 2 0 0 6

0 5 / 2 4 / 2 0 0

6

0 5 / 2 6 / 2 0 0 6

0 5 / 3 0 / 2 0 0 6

0

510

15

20

25

30

35

40

MCS9 usef

MCS8 usef

MCS7 usef

MCS6 usef

MCS5 usef

MCS4 usef

MCS3 usef

MCS2 usef

MCS1 usef

%io MCSx usef

%io 8PSKusef

Migration

Period

Migration

Period

GPRS UL useful RLC traffic

0

20000000

40000000

60000000

80000000

100000000

120000000

140000000

160000000

180000000

0 4 / 2 4 / 2 0 0 6

0 4 / 2 6 / 2 0 0 6

0 4 / 2 8 / 2 0 0 6

0 4 / 3 0 / 2 0 0

6

0 5 / 0 2 / 2 0 0 6

0 5 / 0 4 / 2 0 0 6

0 5 / 0 6 / 2 0 0 6

0 5 / 0 8 / 2 0 0

6

0 5 / 1 0 / 2 0 0 6

0 5 / 1 2 / 2 0 0 6

0 5 / 1 4 / 2 0 0 6

0 5 / 1 6 / 2 0 0 6

0 5 / 1 8 / 2 0 0

6

0 5 / 2 0 / 2 0 0 6

0 5 / 2 2 / 2 0 0 6

0 5 / 2 4 / 2 0 0 6

0 5 / 2 6 / 2 0 0

6

0 5 / 3 0 / 2 0 0 6

64

6566

67

68

69

70

71

CS4 usef

CS3 usef

CS2 usef

CS1 usef

%io CSxusef

GPRS DL useful RLC traffic

0

50000000

100000000

150000000

200000000

250000000

300000000

350000000

400000000

0 4 / 2 4 / 2 0 0

6

0 4 / 2 6 / 2 0 0

6

0 4 / 2 8 / 2 0 0

6

0 4 / 3 0 / 2 0 0

6

0 5 / 0 2 / 2 0 0

6

0 5 / 0 4 / 2 0 0

6

0 5 / 0 6 / 2 0 0

6

0 5 / 0 8 / 2 0 0

6

0 5 / 1 0 / 2 0 0

6

0 5 / 1 2 / 2 0 0

6

0 5 / 1 4 / 2 0 0

6

0 5 / 1 6 / 2 0 0

6

0 5 / 1 8 / 2 0 0

6

0 5 / 2 0 / 2 0 0

6

0 5 / 2 2 / 2 0 0

6

0 5 / 2 4 / 2 0 0

6

0 5 / 2 6 / 2 0 0

6

0 5 / 3 0 / 2 0 0

6

0

10

20

30

40

50

60

70

80

CS4 usef

CS3 usef

CS2 usef

CS1 usef

%io CSxusef

Migration

Period

Migration

Period

8PSK Usage

n o en per ormances




FTP

downlinkFTP

uplink

B8B9

139

65

132

270

20

40

60

80

100

120

140

B8

B9

FTP throughputs (measured in real network conditions)

Radio conditions : around -75 dBm

Normal load (no specific action taken)

MS class 10 (4+2)

Class 5 (MaxMCS=9) in B8

Stability of DL throughput

High Increase of uplinkthroughput

8PSK in uplink Throughputs in

kbit/s

n - o-en per ormances Vimpelcom pre-pilot : non-regression performancetests

J

n o en per ormances




n - o-en per ormancesOrange France : commitments on performances(static tests)

GPRS CS3/CS4

Ping (ms) 56o 1460o 56o 1460oCommitments 650 2000 1110 3150

Avg 648 1787 1043 2672

Min 621 1672 761 2444

Max 1042 2664 1312 2905

GPRS CS3/CS4

FTP (kb/s by TS) 200KB 500KB 1000KB 200KB 500KB 1000KB

Commitments 17,0 17,5 17,5 17,0 17,5 17,5

Avg 17,55 18,05 18,23 17,73 19,04 17,93Min 12,08 16,38 17,08 14,72 17,48 17,24

Max 18,06 18,28 18,36 18,12 19,20 18,04

EDGE MCS9

Ping (ms) 56o 1460o 56o 1460o

Commitments 600 1680 1080 2440

Avg 610 1670 994 2157

Min 570 1633 711 1802

Max 661 1683 1092 2263

EDGE MCS9

FTP (kb/s by TS) 200KB 500KB 1000KB 200KB 500KB 1000KB

Commitments 37,0 42,5 45,0 37,0 42,5 44,0

Avg 37,79 44,52 47,18 44,14 50,92 49,30

Min 26,08 26,2 32,48 27,64 36,96 38,08

Max 42,14 48,9 51,36 45,68 51,96 50,48

Measurement results

Measurement results

Delay 0s Delay 30s

DL UL

Measurement results

Measurement results

Delay 0s Delay 30s

DL UL

In Orange France,commitments have beentaken on absolute valuesonly, not on non-regressioncompared to B8

Conclusions:

All targets have beenreached

Very Good results withFTP UL EDGE > 50kbit/s(far above target)

J

B9 N f t t t




B9 New features tests Extended UL TBF mode

Orange France Up to 62% gain on ping !

For EDGE ping 1460B, thanks to a gain onTBF establishment+high MCS maintained

EDGE ping 56B : 316ms

HTTP gain : 33%

(reference page download time :down from 13,4sec to 8,9sec)

Statistical non-regression has beenchecked on pilot area

GO for network wide activation

T-Mobile Germany 50% gain on short EDGE ping

31% gain on HTTP reference page

610

316

1670

643

0

200

400600

800

1000

1200

1400

1600

1800

disabled enabled disabled enabled

Ping 56 bytes Ping 1460 bytes

Impact of Extended UL TBF on EDGE Ping measurements

J

B9 N f t t t




B9 New features tests NACC and PSI Status

Drive tests around one site with 3 P-GSM

and 3 DCS cells, to assess feature gain onFTP transfers, in both UL and DL

Mean FTP transfer not relevant : too many

fluctuations Post-processing on Ethereal

traces to get duration of TCP interruption

Orange France

50% gain on TCP outage in DL(from 3,3 sec to 1,6sec, with both featuresactivated)

Statistical non-regression has been

checked on pilot area

GO for network wide activation

T-Mobile Germany

Test performed successfully

3,29

2,51

1,93

1,62

0,00

0,50

1,001,50

2,00

2,50

3,00

3,50

Ref NACC PSI NACC&PSI

TCP outage per reselection, in FTP DL Transfer

(avg in seconds, on 50% best samples)

J

B9 N f t t t




B9 New features tests 8PSK, IR and resegmentation in UL

Orange France Field tests performed in various radio conditions, to

evaluate UL performances

Parameter set1 (IR activated / Resegmentat°deactivated) is the most efficient

8PSK + IR : +120% on RLC throughputcompared to B8, in bad radio conditions

B9default:IR and resegment.both deactivated

SET1:IR

SET2:Resegm.

SET3:IR+Resegm.

33

89 88 87 89

0

10

20

30

40

50

60

70

80

90

100

B8 B9 def SET1 SET2 SET3

UL RLC/MAC throughput - Good conditions

28

47

6255

43

0

10

20

30

40

50

60

70

80

90

100


UL RLC/MAC throughput - Medium / Bad conditions

29

76 77 76 76

0

10

20

30

40

50

60

70

80

90

100


UL RLC/MAC throughput - Mobility




B9 QOS

PSIssues




B9 QOS Remaining Issues - GPRS

Some GPRS KPIs remain below B8

DL TBF establishment success rate

– Delta is usually not high and the end user impact should be low thanks toimprovements brought by new B9 features

UL TBF establishment success rate

– Delta is mainly linked to sleeping cells or highly degraded cells

– A end user impact can be foreseen; analysis on going mainly on SFRnetwork

….

Some other GPRS QOS indicators variations can be observed and

are linked to new B9 algorithms => See next slides

B9 QOS Remaining Issues GPRS




B9 QOS Remaining Issues - GPRSSleeping GPRS cells

Alerters (see annexes) have been defined to detect

sleeping GPRS cells and Degraded UL TBF establishment cells

Degraded DL TBF establishment cells

Feedbacks from Networks in B9MR1Ed4QD11:

Orange France IDF

same number of sleeping Cells in B9 compare to B8MR5 (15 days analysed on 579 cells : 3sleeping cells seen)

To be completed with last migrated BSCs Orange Romania (2BSCs):

no sleeping cells since the migration (2 weeks)

Jersey (4BSCs) : few occurrences (3 weeks of QD11)

Sleeping cells cause BSS : 2 cells (Workaround : reinit GPRS)

Radio Failure cause : 2 cells (2 different Workarounds : reinit GPRS, lock/unlock BTS)

Full sleeping (no UL Requests) : 1 cell (Workaround : reinit GPRS)

SFR (4BSCs): B8 : average of 2 cells per week (reference seen on less than 2 weeks)

B9 : average of 3 cells per week (reference on 3 weeks) (mainly G2 BTS)

Tmobile (3BSCs):

B9 : 1 or 2 cells per week in average (mainly G2 BTS)




B9 QOS

PS - QOSNormal Variations




B9 QOS Normal Variations - GPRS

Some GPRS QOS indicators variations can be observedand are linked to new B9 algorithmsReallocation variations

Increase of CS1 usage in DL

RetransmissionDecrease of average Allocated SPDCH

Increased usage of soft preemption (P417 counter)

See Annexes for more details

B9 QOS Normal Variations GPRS




DL, variations linked to new B9 alogorithms (common to both pilots) Decrease of DL T4 requests

High Increase of DL T2 success rate

High decrease of DL T4 success rate, due to failures during the preparationphase

UL, variations linked to new B9 algorithms (common to both pilots) Increase of UL T1 requests

Decrease of UL T2 & T4 requests

High increase of UL T2 success rate

High decrease of UL T4 success rate, due to failures during the preparation

phase=>Normal behaviour linked to B9 algorithms enhancement => better

Radio ressource management (see explanations in Annex1)

B9 QOS Normal Variations - GPRSUL/DL Reallocation Variations (1/3)

–




– DL Realloc Variations : some RNOReports

DL resource realloc T4

05000

10000150002000025000

3000035000400004500050000

1 0 / 0 3 / 2 0 0 5

1 0 / 0 5 / 2 0 0 5

1 0 / 0 7 / 2 0 0 5

1 0 / 0 9 / 2 0 0 5

1 0 / 1 1 / 2 0 0 5

1 0 / 1 3 / 2 0 0 5

1 0 / 1 5 / 2 0 0 5

1 0 / 1 7 / 2 0 0 5

1 0 / 1 9 / 2 0 0 5

1 0 / 2 1 / 2 0 0 5

1 0 / 2 3 / 2 0 0 5

1 0 / 2 5 / 2 0 0 5

1 0 / 2 7 / 2 0 0 5

1 0 / 2 9 / 2 0 0 5

1 0 / 3 1 / 2 0 0 5

1 1 / 0 2 / 2 0 0 5

1 1 / 0 4 / 2 0 0 5

1 1 / 0 6 / 2 0 0 5

1 1 / 0 8 / 2 0 0 5

1 1 / 1 0 / 2 0 0 5

1 1 / 1 2 / 2 0 0 5

1 1 / 1 4 / 2 0 0 5

1 1 / 1 6 / 2 0 0 5

1 1 / 1 8 / 2 0 0 5

1 1 / 2 0 / 2 0 0 5

1 1 / 2 2 / 2 0 0 5

1 1 / 2 4 / 2 0 0 5

1 1 / 2 6 / 2 0 0 5

1 1 / 2 8 / 2 0 0 5

01020304050

60708090100

External stop

Radio fail

BSS fail

Prep fail

Success

%Success

B8 B9

DL resource realloc T2

0

200000

400000

600000

800000

1000000

1200000

1400000

1 0 / 0 3 / 2 0 0 5

1 0 / 0 5 / 2 0 0 5

1 0 / 0 7 / 2 0 0 5

1 0 / 0 9 / 2 0 0 5

1 0 / 1 1 / 2 0 0 5

1 0 / 1 3 / 2 0 0 5

1 0 / 1 5 / 2 0 0 5

1 0 / 1 7 / 2 0 0 5

1 0 / 1 9 / 2 0 0 5

1 0 / 2 1 / 2 0 0 5

1 0 / 2 3 / 2 0 0 5

1 0 / 2 5 / 2 0 0 5

1 0 / 2 7 / 2 0 0 5

1 0 / 2 9 / 2 0 0 5

1 0 / 3 1 / 2 0 0 5

1 1 / 0 2 / 2 0 0 5

1 1 / 0 4 / 2 0 0 5

1 1 / 0 6 / 2 0 0 5

1 1 / 0 8 / 2 0 0 5

1 1 / 1 0 / 2 0 0 5

1 1 / 1 2 / 2 0 0 5

1 1 / 1 4 / 2 0 0 5

1 1 / 1 6 / 2 0 0 5

1 1 / 1 8 / 2 0 0 5

1 1 / 2 0 / 2 0 0 5

1 1 / 2 2 / 2 0 0 5

1 1 / 2 4 / 2 0 0 5

1 1 / 2 6 / 2 0 0 5

1 1 / 2 8 / 2 0 0 5

0

20

4060

80

100

120

External stop

Radio fail

BSS fail

Prep fail

Success

% Success

DL Ressources Realloc T1

DL Ressources Realloc T2 DL Ressources Realloc T4

DL Ressources Realloc T3

–




– UL Realloc Variations : some RNOReports

UL resource realloc T1

0

100

200

300

400

500

600

700

1 0 / 0 3 / 2 0 0 5

1 0 / 0 5 / 2 0 0

5

1 0 / 0 7 / 2 0 0

5

1 0 / 0 9 / 2 0 0

5

1 0 / 1 1 / 2 0 0

5

1 0 / 1 3 / 2 0 0 5

1 0 / 1 5 / 2 0 0

5

1 0 / 1 7 / 2 0 0

5

1 0 / 1 9 / 2 0 0

5

1 0 / 2 1 / 2 0 0

5

1 0 / 2 3 / 2 0 0

5

1 0 / 2 5 / 2 0 0

5

1 0 / 2 7 / 2 0 0

5

1 0 / 2 9 / 2 0 0

5

1 0 / 3 1 / 2 0 0

5

1 1 / 0 2 / 2 0 0

5

1 1 / 0 4 / 2 0 0

5

1 1 / 0 6 / 2 0 0

5

1 1 / 0 8 / 2 0 0

5

1 1 / 1 0 / 2 0 0 5

1 1 / 1 2 / 2 0 0

5

1 1 / 1 4 / 2 0 0

5

1 1 / 1 6 / 2 0 0

5

1 1 / 1 8 / 2 0 0

5

1 1 / 2 0 / 2 0 0 5

1 1 / 2 2 / 2 0 0

5

1 1 / 2 4 / 2 0 0

5

1 1 / 2 6 / 2 0 0

5

1 1 / 2 8 / 2 0 0

5

0

2040

60

80100120

140

160180

External stop

Radio fail

BSS fail

Prep fail

Success

% Success


0

200000

400000

600000

800000

1000000

1200000

1 0 / 0 3 / 2 0 0 5

1 0 / 0 5 / 2 0 0 5

1 0 / 0 7 / 2 0 0 5

1 0 / 0 9 / 2 0 0 5

1 0 / 1 1 / 2 0 0 5

1 0 / 1 3 / 2 0 0 5

1 0 / 1 5 / 2 0 0 5

1 0 / 1 7 / 2 0 0 5

1 0 / 1 9 / 2 0 0 5

1 0 / 2 1 / 2 0 0 5

1 0 / 2 3 / 2 0 0 5

1 0 / 2 5 / 2 0 0 5

1 0 / 2 7 / 2 0 0 5

1 0 / 2 9 / 2 0 0 5

1 0 / 3 1 / 2 0 0 5

1 1 / 0 2 / 2 0 0 5

1 1 / 0 4 / 2 0 0 5

1 1 / 0 6 / 2 0 0 5

1 1 / 0 8 / 2 0 0 5

1 1 / 1 0 / 2 0 0 5

1 1 / 1 2 / 2 0 0 5

1 1 / 1 4 / 2 0 0 5

1 1 / 1 6 / 2 0 0 5

1 1 / 1 8 / 2 0 0 5

1 1 / 2 0 / 2 0 0 5

1 1 / 2 2 / 2 0 0 5

1 1 / 2 4 / 2 0 0 5

1 1 / 2 6 / 2 0 0 5

1 1 / 2 8 / 2 0 0 5

0

20

40

60

80

100

120

External stop

Radio fail

BSS fail

Prep fail

Success

% Success


0

10000

20000

30000

40000

50000

60000

70000

80000

1 0 / 0 3 / 2 0 0 5

1 0 / 0 5 / 2 0 0 5

1 0 / 0 7 / 2 0 0 5

1 0 / 0 9 / 2 0 0 5

1 0 / 1 1 / 2 0 0 5

1 0 / 1 3 / 2 0 0 5

1 0 / 1 5 / 2 0 0 5

1 0 / 1 7 / 2 0 0 5

1 0 / 1 9 / 2 0 0 5

1 0 / 2 1 / 2 0 0 5

1 0 / 2 3 / 2 0 0 5

1 0 / 2 5 / 2 0 0 5

1 0 / 2 7 / 2 0 0 5

1 0 / 2 9 / 2 0 0 5

1 0 / 3 1 / 2 0 0 5

1 1 / 0 2 / 2 0 0 5

1 1 / 0 4 / 2 0 0 5

1 1 / 0 6 / 2 0 0 5

1 1 / 0 8 / 2 0 0 5

1 1 / 1 0 / 2 0 0 5

1 1 / 1 2 / 2 0 0 5

1 1 / 1 4 / 2 0 0 5

1 1 / 1 6 / 2 0 0 5

1 1 / 1 8 / 2 0 0 5

1 1 / 2 0 / 2 0 0 5

1 1 / 2 2 / 2 0 0 5

1 1 / 2 4 / 2 0 0 5

1 1 / 2 6 / 2 0 0 5

1 1 / 2 8 / 2 0 0 5

0102030405060708090100

External stop

Radio fail

BSS fail

Prep fail

Success

% Success


0

5000100001500020000250003000035000400004500050000

1 0 / 0 3 / 2 0 0 5

1 0 / 0 5 / 2 0 0 5

1 0 / 0 7 / 2 0 0 5

1 0 / 0 9 / 2 0 0 5

1 0 / 1 1 / 2 0 0 5

1 0 / 1 3 / 2 0 0 5

1 0 / 1 5 / 2 0 0 5

1 0 / 1 7 / 2 0 0 5

1 0 / 1 9 / 2 0 0 5

1 0 / 2 1 / 2 0 0 5

1 0 / 2 3 / 2 0 0 5

1 0 / 2 5 / 2 0 0 5

1 0 / 2 7 / 2 0 0 5

1 0 / 2 9 / 2 0 0 5

1 0 / 3 1 / 2 0 0 5

1 1 / 0 2 / 2 0 0 5

1 1 / 0 4 / 2 0 0 5

1 1 / 0 6 / 2 0 0 5

1 1 / 0 8 / 2 0 0 5

1 1 / 1 0 / 2 0 0 5

1 1 / 1 2 / 2 0 0 5

1 1 / 1 4 / 2 0 0 5

1 1 / 1 6 / 2 0 0 5

1 1 / 1 8 / 2 0 0 5

1 1 / 2 0 / 2 0 0 5

1 1 / 2 2 / 2 0 0 5

1 1 / 2 4 / 2 0 0 5

1 1 / 2 6 / 2 0 0 5

1 1 / 2 8 / 2 0 0 5

0

102030405060708090100

External stop

Radio fail

BSS fail

Prep fail

Success

%Success

UL Ressources Realloc T1 UL Ressources Realloc T3

UL Ressources Realloc T2 UL Ressources Realloc T4

B9 QOS Normal Variations – GPRS




B9 QOS Normal Variations – GPRSCoding scheme usage – CS1



0

10000000

20000000

30000000

40000000

50000000

60000000

70000000

80000000

1 0 / 3 1 / 2 0 0

5

1 1 / 0 2 / 2 0 0

5

1 1 / 0 4 / 2 0 0

5

1 1 / 0 6 / 2 0 0

5

1 1 / 0 8 / 2 0 0

5

1 1 / 1 0 / 2 0 0

5

1 1 / 1 2 / 2 0 0

5

1 1 / 1 4 / 2 0 0

5

1 1 / 1 6 / 2 0 0

5

1 1 / 1 8 / 2 0 0

5

1 1 / 2 0 / 2 0 0

5

1 1 / 2 2 / 2 0 0

5

1 1 / 2 4 / 2 0 0

5

1 1 / 2 6 / 2 0 0

5

1 1 / 2 8 / 2 0 0

5

1 1 / 3 0 / 2 0 0

5

1 2 / 0 2 / 2 0 0

5

1 2 / 0 4 / 2 0 0

5

1 2 / 0 6 / 2 0 0

5

1 2 / 0 8 / 2 0 0

5

1 2 / 1 0 / 2 0 0

5

1 2 / 1 2 / 2 0 0

5

1 2 / 1 4 / 2 0 0

5

1 2 / 1 6 / 2 0 0

5

0

10

20

30

40

50

60

70

80

90

100

CS4 usef

CS3 usef

CS2 usef

CS1 usef

%io CSx usef

See explanation in Annex2

B8 B9





B9 QOS Normal Variations – GPRSRetransmission

Increase of retransmission rate in UL EGPRS=>explained by the usage of 8PSK in UL :

=>In B9, higher MCS are introduced in UL. As these MCS are more sensitiveto radio conditions, their usage implies higher retransmission rate. It isconsidered by Alcatel as normal behaviour

In DL, when there is an increase of retransmission rate compared toB8

It is also be linked the increase of usage on high coding schemes

There are 2 possible reasons for this increase

– in B8, there were High Ater Usage or

– The migration in B9 is not iso B8

– When « Max_MCS » > « MCS allowed in B8 according to the class of the cell »

In B9 with Dynamic Abis, higher coding schemes used. As a consequence,an increase of retransmission can be oberved





B9 QOS Normal Variations – GPRSDecrease of average Allocated SPDCH

In B8: the BSC computes the limit of TS that could be allocated to the MFS

(MAX_SPDCH_DYN)

These TS are not necessarily allocated to the MFS

In B9: The BSC computes the TS needed by itself for CS, by the MFS for PS, and allocatesactually these TS to the MFS (MAX_SPDCH_LIMIT)

Conclusion in a real network

Most cells have low PS traffic (on average), which leads to lower MAX_SPDCH_LIMIT inB9 than MAX_PDCH_DYN in B8 (see case 0 and 1)

In case PS traffic increases, the MAX_SPDCH_LIMIT would be equal or even higher toMAX_SPDCH_DYN (see case 2, 4 and 6)

=> More explanations are available in Annex3

B9 QOS Normal Variations – GPRS(1/3)




B9 QOS Normal Variations – GPRS(1/3)Increased usage of soft preemption : P417

In B8, the value of MaxSpdchDyn is reassessed for each TCallocation in the cell, but does not necessarily triggers a preemption:

a preemption will only be triggered if the CS zone of the cell enters in conflictwith the RTSs currently used by the established TBFs.

In B9, the value of MaxSpdchLimit is also reassessed for each TCHallocation in the cell. If it is decreased, this will always trigger apreemption (at the next RR-Allocation-Indication message sendingtowards the MFS).

At any time, the targeted number of allocated PDCHs in the cell is equal toMaxSpdchLimit, so if MaxSpdchLimit is decreased, that will imply somePDCH preemptions (=> P417 is incremented, even if no TBF is present on

the PDCH).





B9 QOS Normal Variations GPRS(2/3)Increased usage of soft preemption : P417

Result

In case of successive CS call establishments / CS call releases, evenif the average number of CS calls in the cell is constant, P417 will be

much higher in B9 than in B8 (this is what was seen in Orange).

In case of PS+CS congestion in the cell (i.e. in case the PS zone is inconflict with the CS zone), then the B8 and B9 counters should havenearer values.

=> no end user impact





B9 QOS Normal Variations GPRS(3/3)Increased usage of soft preemption : P417

Example:

In B8 : values between 0 and 200 on the full BSC

In B9 : values between 8000 and 25000 on the full BSC

PDCH Preemption

84 106 171 114 159 4 9 109 181 195 24496 23754 10116 8192 214930

5000

10000

15000

20000

25000

30000

0 2 / 2 7 / 2 0 0 6

0 2 / 2 8 / 2 0 0 6

0 3 / 0 1 / 2 0 0 6

0 3 / 0 2 / 2 0 0 6

0 3 / 0 3 / 2 0 0 6

0 3 / 0 4 / 2 0 0 6

0 3 / 0 5 / 2 0 0 6

0 3 / 0 6 / 2 0 0 6

0 3 / 0 7 / 2 0 0 6

0 3 / 0 8 / 2 0 0 6

0 3 / 0 9 / 2 0 0 6

0 3 / 1 0 / 2 0 0 6

0 3 / 1 1 / 2 0 0 6

0 3 / 1 2 / 2 0 0 6

0 3 / 1 3 / 2 0 0 6

Soft preempted

B9 QOS




B9 QOS

PS - Conclusion

Q S PS l i (1/2)




QoS PS conclusion (1/2)

High improvements brought by new features

Several algorithms were impacted by the introductionof these new features=> the QOS follow-up is impacted by these modifications with

significant variations on several QOS indicators

Normal variations

Unexpected variations

These improvements compensate the degradation of somePS QOS indicators (mainly TBF establishment success rateunder investigation in TD) not directly perceived by end

user.These improvements are obviously more significative onnetworks with Edge and CS3/CS4 activated (where thebenefit of dynamic Abis is the most obvious)

Q S PS l i (2/2)




QoS PS conclusion (2/2)

The end user and new features tests are very importantto show the non-regression and improvements of B9

=> you can ask us some example of test sheets doneon other networks

=> thank you to provide us the feedbacks on the testsyou will do




Remaining FEATURES

& CONFIGURATIONS

where feedback is welcomed

B9 f t t t d i A t ONLY




B9 features tested in Acceptance ONLY

Telecom

NC2 improvement: Cell ranking with load criteria (without QoS) – mobiles badbehaviour to activate the feature on field

O&M Improvements Remote Inventory from the OMC-R for MFS

Enhanced Remote Inventory export interface

Customisation of radio parameter default values Counters on electromagneticemission (EME)

Better integration of IMT

Export ASCII file interface for GB interface V490 Introduction (for OMC)

Activation follow-up, end of the activation

Inform NPI when these

features will be used on

networks

f O f ( / )




B9 features NOT specifically tested (1/2)

Telecom Load based 3G handover filtering

ANC eVOlution for size reduction and TMA supply

Support of Extended UL TBF mode, NACC and Packet (P) SI Statuson G2 BTS

O&M Improvements MFS alarm flow reduction

Activation follow-up, end of the activation

Keeping adjacencies on inter-OMC move BTS

RNO/NPA Direct connection of RNO to the OMC-R

Move BSS data between two NPA servers

RNO optimisation of tree building filling for non RNO objects

Features where no need for feedback requested to pronounce GADR



networks

B9 f t NOT ifi ll t t d (2/2)




B9 features NOT specifically tested (2/2)

GSM

Unbalanced TRX Output Power

Features for which feedback from first user to be obtained

Inform NPI when this

feature will be used on

networks

B8 f t i t t




B8 features non regression status

Features tested by customers Dynamic SDCCH allocation TBF establishment time improvement CS-3 / CS-4 EDGE Warnings on QoS indicators variation Display of indicator reliability (from PM reporting) Multi-Objects evolution charts

QoS at Busy Hour Support of Centralised backup for X-Large OMC-R - legato Citrix support / RNO WAN GCH Congestion Control: GPRS & EDGE (implicit) GPRS redirection - lab only Full intra-RA LLC PDU re-routing - lab only GCH resource anticipation - fast access - lab only

Network Controlled cell reselection (NC2) in Packet Transfer Mode - lab only

Features to be tested GPRS/EDGE with Abis/Ater over satellite links 3G search deactivation in PTM Tool Chain 10500 Cells (availability date to be confirmed) – planned by VIP



networks

B7 f t i t t




B7 features non regression status

Features tested by customers Adaptative Multirate Codec (AMR) in HR mode

Adaptative Multirate Codec (AMR) in FR mode

GSM to UMTS cell re-selection

Multiple GPU per BSC

Interoperability with UMTS

GSM to UMTS cell re-selection

GPRS to UMTS cell re-selection triggered by MS

Radio Measurement Statistics (RMS)

Extensive Logical Configuration update (MLU)

Tandem free operation (TFO) – lab only

Coordination of CS and GPRS services via Gs interface – lab only



networks

HW configuration NOT tested during FO’s & early




g g yadopters

BTS

Edge+ HP TRA (including 2nd Abis)

Mix M4M/M5M with EDGE

MFS

DS10 RC23 30 GPU

DS10 RC40 30 GPU

OMC

X Large

New New HW (V490) 6000 cells

HW for which feedback from first user will be interesting


configurations will be

used on networks




MAIN REMAINING ISSUES on MR1 ED4 QD11

Main remaining FRs(U0) not yet corrected (1/6)





3BKA45FBR184547 - SDCCH assignment failure degradation after Migration to B9

Reported by CLARO and seen on other networks too

Operational Impact : decreased CS accessibility

Work-around: under study (one track is to change T3111value – approval fromCLARO on-going to perform the modification on 2 cells)

Correction : under investigation

3BKA45FBR183007 - Sleeping GPRS G2 DRFU Cells

Reported by T-MOBILE and SFR

Operational Impact : no PS on that cell

Preventive work-around: none

Corrective work-around: Re-Init GPRS at cell level

Correction : 1 case corrected in GPU (QD#13) ; 1 other case under investigation






3BKA45FBR187032- Since B9 introduction, UL TBF establishmentsuccess rate decrease on whole BSS

Reported by SFR

Operational Impact : decreased PS accessibility

Work-around: none

Correction : under investigation ; 1 correction already identified ; other corrections under study, via trace collection campaigns in SFR and TLO ; target= QD#13

3BKA45FBR188213 – DL TBF establishment success rate degradation inB9 MR1 ed5

Reported by VIP Operational Impact : decreased PS accessibility

Work-around: none







3BKA45FBR184632 - Problems with FTP and Ping application for SIEMENS S75 MS Reported by T-MOBILE

Operational Impact : in certain conditions, in EDGE, ping duration are increasedand ftp throughputs decreased

Work-around: none

Correction : corrected in GPU for QD#13

3BKA45FBR186206 – CS2/CS4:First 1000 Byte Ping needs more than 5sec in case that Extended UL TBF Mode and LLC PDU Re-routingfeatures are enabled

Reported by T-MOBILE

Operational Impact : long ping durations in GPRS when the 2 optional featuresare enabled (Extended UL TBF Mode and LLC PDU Re-routing)

Work-around: none

Correction : corrected in GPU for QD#13






3BKA45FBR188097 – Unix Patch installation failure during B8/B9 MFS A9135

Migration Reported by Orange France

Operational Impact : if, during migration method application, the check of Unix shell type isNOK on stand-by machine, then Unix patch installation should not be performed -Security level of the MFS is equivalent to the B8 one

Work-around: change the global shell of root from csh to ksh on both stations


3BKA45FBR186666 – GPRS blocked on 2 cells = 100% failure cause Radiocongestion, followed by GPU auto-reset upon Cell Re-Init

Reported by KSA

Operational Impact : DLS inconsistency due to the EGSM_RR_ALLOC_STRATEGY

change from 0 to 1. During this change, the data model should also change but it does not – It impacts networks having a mix of PGSM+G1 frequency bands

Work-around: Cell Deletion/Re-Creation (all TRXs of the cell are re-created with the newData Model)

Correction : corrected by OMC add-on for QD#13






3BKA20FBR182557 – In case of firewall allowing only the floating IP address, theSNMP exchange protocol cannot be established between the MFS and the OMC-R

Reported by SFR

Operational Impact : The OMC-R never receives responses from the MFS on SNMPbecause the request from the OMC-R for the activation of SNMP on MFS active station isdone through the floating IP address ( the only one known by the OMC-R ), but the

response from the MFS is done with the fixed IP address Work-around: None (or deactivate the firewall)

Correction : Under study for B10

3BKA20FBR180896 & 182449 – The dataPatch file needs to be systematicallyapplied manually at the end of B8 to B9 MFS migration

Reported by SFR & ORO

Operational Impact : GPRS degradation on associated BSSs in B9

Work-around: Manual download of dataPatch file after “Validate the New MFS Software”step is completed

Correction: MR4






3BKA45FBR189463 - In case of Abis ring and BBH in at least one cell, if the Abis1 fails, there is no more call possible on TRX that are in BBHmode

Reported by True Move

Operational Impact : in case of Abis ring and BBH in at least one cell, if the Abis1 fails, there is no more call possible on TRX that are in BBH mode because

they become in dummy configuration Work-around: Reset all TREs that are concerned

Correction : corrected in BTS in MR4 and in MR1 to be decided

Already corrected in QD#12 (1/3)





3BKA20FBR187631 - No GPRS call after B8-B9 Migration for certain E-GSM cellconfigurations

Reported by KSA

Operational Impact : after B8->B9 Migration or after Cell Creation in B9, no PS is possibleon E-GSM cells configured with Hopping TRX and EGSM_RR_ALLOC_STRATEGY = 0

Preventive work-around: configure the cell with NH, or setEGSM_RR_ALLOC_STRATEGY = 1 but with the side effect that Phase 1 MS will fail to

connect G1 TRX Corrective work-around: same as preventive one

3BKA20FBR185991- GPRS is not allowed by the OMC-R on hopping P-GSMTRX within E-GSM Cells in case EGSM_RR_ALLOC_STRATEGY = 0

Reported by KSA

Operational Impact : not possible to modify such cell configurations nor to create them – Itconcerns networks having a mix of PGSM+G1 frequency bands

Palliative work-around: migrate to B9 with EGSM_RR_ALLOC_STRATEGY=1 but Phase 1MS will hardly work






3BKA20FBR185729 – OMC-R/NMC re-synchronisation functionality does not

work Reported by SFR

Operational Impact : OMC-R/NMC re-synchronisation functionality does not work


Corrective work-around: none

3BKA20FBR187787 - After alarm acknowledgment from NMC, several field of thealarm are disappearing in AS

3BKA20FBR187788 - Answer to the NMC action Retrieve Current Alarms Datadoes not contain the alarm acknowledgment information

3BKA20FBR187789 - After resynchronisation from AS, several fields of the alarmare disappearing in AS

Reported by SFR Operational Impact : functionality “ Alarm Acknowledgment Propagation Between OMC-R

and NMC” cannot be used


Corrective work-around: none






3BKA20FBR186647 - B9 GPRS Cells Misaligned even after Re-synchronisation and Re-initialize GPRS

Reported by KSA

Operational Impact : loss of O&M supervision, no possibility to recover GPRSactivity on misaligned cells

Preventive action: none

Corrective action: none

Maintenance releases




Maintenance releases

MR1 ed4

QD12: delivered – under validation in KSA (new BSC SW, GOM patch, OMCpatches to correct Temip issues)

QD13: in preparation only to solve blocking remaining issues for customershaving started with MR1ed4 ( MFS patch to correct TMO issues and OMCadd-on to correct E-GSM issue of KSA)

QDn: not planned today

MR1ed6

Target: end of June 06

Normal MR1 maintenance release, integrating all corrections of MR1 ed4QD13 + OMC evolution to support MX MFS.

MR4 Target: end September 06

Mainly new equipments (Mx, Twin) + 2G-2G HO, PS on extended cell andQoS features




Networks STATUS

B9 Introduction – Status w625




B9 Introduction – Status w625

Area Country Customer Current releaseNb BSC inB9

Total nbof BSC

AMEI KSA Ettihad Etisalat Mobily B9 MR1 ed4 QD# 12 2 15

AMEI Pakistan Paktel B9 MR1 ed4 8 8

APAC Thailand TAO / True Move B9 MR1 ed4 QD# 10+ 156 156

E&LAM Brazil CLARO B9 MR1 ed4 QD# 10+ 124 124

E&LAM France Orange B9 MR1 ed4 QD# 11 315 321E&LAM France SFR/CEGETEL B9 MR1 ed4 QD# 12 4 239

E&LAM Germany T_Mobile B9 MR1 ed4 QD# 11 4 211

E&LAM Jersey Jersey Telecom B9 MR1 ed4 QD# 11 4 4

E&LAM Moldavia Voxtel B9 MR1 ed4 QD# 11 9 9

E&LAM Poland ERA B9 MR1 ed4 QD# 10+ 17 17

E&LAM Romania Orange B9 MR1 ed4 QD# 11 102 119

E&LAM Russia

Vimplecom (Nizhny

Novgorod) B9 MR1 ed4 QD# 08 21 21

TOTAL 766 1244

Networks already in B9 766 BSS’s on overall 3733 base installed= 20%

ntro uct onCustomer interested in B9




Customer interested in B9

B9 MR1corresponds tothe lastavailableedition

Area Country Customer Next release When Comments

AMEI Cameroon SCM / Mobilis /Orange B9 MR1 July 06 Edge deployment

AMEI Egypt Mobinil B9 MR1 Q2 06

AMEI Ivory Coast Orange Ivoiris B9 M1 ed4 QD# 11 July 06

AMEI Kenya Kencell / celltel B9 MR1 ed4 QD11 June 06 Edge deployment done in August 06 AMEI Madagascar SMM / Antaris Orange B9 MR1 Q2 06 Edge deployment

AMEI Mali Orange B9 MR1 July 06 Edge deployment

AMEI Pakistan Mobilink B9 Q4 06

AMEI Qatar Qtel B9 MR1 ed4 QD11 June 06

AMEI South Africa Vodacom B9 MR1 ed6? Q3 06 Edge deployment + MFS Evol

AMEI Sudan Areeba B9

Potential FO for Twin in B8,

commitment to deliver twin in Q 3'07

AMEI Tanzania Celtel Tanzania B9 MR1 July 06 then B9 MR4 for twin

AMEI Tunisia Orascom B9 MR4 Q1 07 BSC Evolution (and MBO evol)

AMEI Vietnam VMS & Vinaphone B9 MR1 Q4 06 Viettel on ly 2007CHINA China B9 MR4 Q2/Q2 07 Mx

APAC Brunei DST B9 2007 contractual commitment

APAC Indonesia Indosat B9 2006

B7 upgrade is not clear due to

equipment relocation

APAC Malaysia

CELCOM 013 (formerly

TCSB) B9 Q3 06

APAC Philippines Digitel B9 Q3 06

APAC Vietnam VMS B9 MR1 ed6 August 06 MFS Evolution

E&LAM Armenia Vivacell B9 MR1 October 06

E&LAM Austria Telering B9 MR1 Q3/Q4 06E&LAM Bulgaria MOBILTEL B9 MR1 July 06 not clear

E&LAM El Salvador Personal B9 MR1 July 06

E&LAM Italy WIND B9 MR1 Q3 06

E&LAM Caraibes Orange B9 MR1 September 06

E&LAM Netherlands Orange B9 MR1 Q3/Q4 06

E&LAM Paraguay Hola / Vox B9 MR1 Q3 06

E&LAM Portugal TMN B9 MR1 Q3 06

E&LAM Ukrainia UMC B9 MR1 Q3 06




Specific Warnings towards RSC

Specific Warnings towards RSC (1/4)





Remaining problems are all included in the Restriction List http://webqaf.cit.alcatel.fr/delivery/frames/release_b9.html

RSC can extract the critical ones compared to their customers networks

Main remaining issues with B9 MR1 ed4 are listed in the presentation

Methods including Restriction are specific for each MR use the one delivered with the B9 MR1 ed4 software on delivery server

do not use the last version available under DIAMS which refer only to the lastSW release

Be careful, sometimes restrictions can’t be included in the method: read thetable at the end of the SW migration & RL documents that precise the methodsimpacted by the restriction

Some B9 and non-regression features have not been testedon field see technical presentation for the complete list

need RSC feedback as soon as one of these features is activated on field






Sanity Checks mandatory before MFS migration Sanity checks to be launched twice on each B8 MFS : one week minimum

BEFORE the migration to let time to correct potential issues and just before themigration to ensure the migration

MFS Patch installation Be careful, the dataPatch file needs to be systematically applied manually at the

end of B8 to B9 MFS migration

Unix patch installation Be careful, if the patch installation fails, don’t try a new attempt.

EGSM feature

Networks having EGSM_RR_ALLOC_STRATEGY=0 in B9 & hopping willencounter problems in a mix of PGSM+G1 frequency bands or in G1 band only

Issues linked to FR 3BKA20FBR187631 (BSC) & 3BKA20FBR185991 (OMC)

QD#12 is mandatory to avoid these problems






Incorrect behaviour of script remove_db.pl used to remove aBSSIM database and described in the OMC-R TSG FR from Orange France 3BKA45FBR189073 – Side effect of the script is that

other bssim db are removed – A discover is then mandatory on non-suitableremoved BSS

A correction is brought as an OMC add-on in QD13

In case of sleeping cells, install alerters if customer is aware of them and agrees A re-init GPRS can be launched automatically thanks to O&M automatic scripts

Go for B9 MR1 ed4 QD#11 + GOM patch of QD#12

The GOM patch has to be also installed to avoid MFS crash Note that this patch has not been tested by Orange Skill Center – Up to each

Orange network to decide if this patch can be installed anyway






Some GPRS QOS indicators variations can be observed andare linked to new B9 algorithms Reallocation variations


Retransmission

Decrease of average Allocated SPDCH

Increased usage of soft pre-emption (P417 counter)

The end user and new features tests are very important toshow the non-regression and improvements of B9 => you can ask PCS some example of test sheets done on other networks

=> thank you to provide to PCS the feedbacks on the tests you will do

RNE Resources need to be reinforced in order to be able toperform the field tests, to analyse the results, to analyse theQOS variations, prepare and present them to the customer



All rights reserved © 2005, Evolium

ANNEXES

June 2006

IOT status with Alcatel BSS B9 (1/4)




IOT status with Alcatel BSS B9 ( )

Gb interface Alcatel BSS B9 – Ericsson SGSN R5.5 Customer : Orange

No issue

Gb interface Alcatel BSS B9 – Ericsson SGSN R6 Customer : Orange

No issue

Gb interface BSS B9 – Nortel SGSN GPRS06 Customer : Claro Orange with B9MR0

T-Mobile with B9 MR2

No issue

Gb interface BSS B9 – Nortel SGSN SG5 (GPRS07) Customer : Claro

No issueGb interface BSS B9 – Nokia SGSN SG5 Customer : Orange NL

No issue





IOT status with Alcatel BSS B9

A interface BSS B9 – Ericsson MSC R11

Customer : Orange/Claro

No issue on tests performed. All tests not performed due to E1 issues, a RAhas been written

A interface BSS B9 MR2 – MSC Siemens CS3.0

Customer : T-Mobile

No issue






3G2G UTRAN Nokia RAN04 – BSS B9

Customer : Orange

Joint statement, if agreed by Nokia

3G2G UTRAN Nortel UA4.1 – BSS B9

Customer : Orange

No issue






Other tests made on site at customers’ A ZTE MSC BSS B9

Customer : Paktel

OK (waiting for confirmation from the RSC)

Gb ZTE SGSN BSS B9 Customer : Paktel

OK (waiting for confirmation from the RSC)

Alerters definition – Sleeping GPRS cells




e te s de t o S eep g G S ce s

Sleeping GPRS cells alerter raised when (the number of UL TBF estab success = 0) AND

(the number of UL TBF requests > X) AND

(the number of DL TBF estab requests =0)

QoS alerter Scope: ENDTIME>@DAY, "9:00" && ENDTIME<=@DAY,

"23:00"Critical Predicate: (P30a + P30b + P30c==0) && (P62a+P62b+P62c-P438c >X) && (P91a+P91b+P91c+P91d+P91e+P91f==0 )Major Predicate:Warning Predicate:Clearance Predicate: (P30a + P30b + P30c>0) ||(P91a+P91b+P91c+P91d+P91e+P91f >0 )Table: GPRS: CELL

Stability (mins): 60

X : this value can be adapted. The recommended value is « 20 »

When the alerter is raised, it is recommended to check the QOS status of thecell with RNO

Alerters definition – UL Degraded GPRScells




cells

Unefficiency UL TBF establishment alerter raised when [ (The number of UL TBF requests >50) AND

(The UL TBF success rate < 20%) ]

Definition

Warning Predicate: ((P62A+P62B+P62C) > 50) &&((P30A+P30B+P30C) / (P62A+P62B+P62C)) < 0.2))

Clearance Predicate: ((P30A+P30B+P30C) / (P62A+P62B+P62C)) >0.5))

Table: GPRS: CELL

Stability (mins): 120 (restriction in B9 , the value « 60 » will beconsidered)

Alerters definition – DL Degraded GPRScells




cells

Unefficiency DL TBF establishment alerter raised when

[(The number of DL TBF requests >50) AND

(The DL TBF success rate < 20%)]

DefinitionWarning Predicate: ((P91A+P91B+P91C+P91D+P91E+P91F)>50)&& ((P90A+P90B+P90C+P90D+P90E+P90F) /(P91A+P91B+P91C+P91d+P91E+P91F)) < 0.2)

Clearance Predicate: ((P90A+P90A+P90C+P90D+P90E+P90F) /(P91A+P91B+P91C+P91D+P91E+P91F) > 0.5)

Table: GPRS: CELLStability (mins): 120 (restriction in B9, the value « 60 » will beconsidered)

B9 features tested in Acceptance AND on Field (1/2)




p ( )

Telecom features Support of Incremental Redundancy in uplink

Network Assisted Cell Change (NACC)

Packet (P)SI Status

A-bis dynamic allocation

Statistical GCH multiplexing

Extended Uplink TBF Mode Autonomous packet resource allocation (implicit)

Improvements to Ater resource management

Enhanced E-GSM band handling

RMS Improvement

Counter improvement for Release B9: New GPRS counters

Counters to improve TBF drops computation

BSC Alarm flow reduction (implicit)

Improved 2G to 3G cell reselectionSI2quater scheduling





p ( )

O&M Improvements

Synchronization of PRC with SC modifications Wait Traffic Clear period at PRC activation

Detailed logs of PRC activation (implicit)

Call origin in "Usage State On Demand“ (implicit)

OMC-R view manager (implicit)

Refinement of X.25 alarms (discrimination between network and applicative alarms) & X25 alarmreduction

Alarm acknowledgement propagation between OMC and NMC (implicit) – FR A20/187787- FR

A20/187788 - FR A20/187789 corrected QD#12 V490 Introduction(for NPA) – T2 granted from Orange

Functional Access Domain editor

Command Mode enhancements (more commands)

Supervision of process, memory, disk (MFS)

Visibility of GPRS problems

USOD : more telecom info on GSM + GPRS TS

TRE/TCU mapping improvement (implicit) TRX/RSL mapping improvement (implicit)

Automatic O&M procedures

Security improvements for IP Network Elements (MFS) – FR A45/180222 & 180224 & 180225 & 180309to be corrected in B10





p ( )

O&M Improvements (cont)

OMC security: Missing /usr and /var part Security improvements for O&M systems (LDAP, …)

Desktop introduction in BSSUSM

Customer Documentation about HMI changes

X-Large capacity to 6000 cells with new hardware

MFS alarm flow reduction

Alerters Improvements (TMO)

RNO/NPA Improvement Cell Post-it

Spreadsheet facilities

Column and row sorting in spreadsheet

Spreadsheet snapshot

Abort Quick diag operation (implicit)

Use relative dates in Cell zone (implicit)

RNO support of MNC and MCC as filters

LASER

Laser topology reports

Remote inventory database in Laser

Back up time extended up to 120 days

Access via HTML

HW configuration tested during FO’s & early adopters




BSC G2 Type 2 to 6

BTS TRE G3 (including 2nd Abis)

TRA G4 (including 2nd Abis)

M4M

G2 BTS

TC TC G2

TC G2.5 (Compact, with MT120)

MFS

AS800

DS10 RC23 & RC40

OMC

Small new HW (v880)

Large old HW (E450)

Large old HW (E4500)

X large new HW (v880)

RNO Large and X-large

NPA Large and X-large

Laser

B9 QOS




PS - Annexes

Annexes




Annex1 : Reallocation Variations

Annex2 : increase of CS1 usage

Annex3 : Allocated SPDCH

Annex4 : Speech Codec Variation

Annex5 : How to decrease CS congestion in B9 network

Annex6 : Alerters

Annex7 : FR content

Annex8 : B9MR1Ed4QD10 BSS Correction and restriction list

Annex9 :Decrease of TBF release due to NC0 reselection

Annex1: Reallocation Variations




Increase of T1 requestsDecrease of T4 requests

Decrease of T4 success rate

Increase of DL T2 requests, decrease of UL T2 requests, increase of T2 success rate

Decrease of T3 success rate (only one pilot)

Annex1: Increase of T1 requests




Due to M-EGCH Statistical-Multiplexing in B9, addition of a new rule

to trigger T1 reallocations (T1 reallocation triggered if the Max-MCSof a TBF can no longer be supported).

The period of the BSC preemptions (triggered in B8 through Load-Indication message, triggered in B9 through message RR-Allocation-Indication) passed from 15 seconds in B8 to 10 seconds in B9.

Reason:

With the introduction of RAE-4, all the MaxSpdchLimit RTSs are allocated to the MFS (whereas in B8 only the RTSs supporting some TBFs wereallocated to the MFS).

So keeping a period of 15s for the PDCH preemptions in B9 could haveincreased CS blocking rate in the cells.

Therefore, the periodicity of RR-Allocation-Indication sending wasdecreased from 15s to 10s (compared to the periodicity of Load-Ind sending in B8 which was the equivalent message) in order not to degrade thereactivity of RTS sharing between CS and PS traffic.

Presented to Orange France

Annex1: Decrease of UL and DL T4 requests




In B8, with the “immediate UL” feature, an incoming GPRS TBF isestablished on the already-established PDCHs of a TRX, even if those PDCHs support DL EGPRS TBFs

the incoming GPRS TBF becomes candidate for T4 reallocation.

In B9, thanks to M-EGCH Statistical Multiplexing, an incoming GPRS

TBF is established on the other PDCHs of the TRX if it is possible the incoming GPRS TBF does not become candidate for T4reallocation (except if all the PDCHs of the TRX support DL EGPRSTBFs).


Annex1: Decrease of UL and DL T4 successrate due to failures during the prep phase




rate, due to failures during the prep phase

This is linked to the previous slide: A T4 request is only generated when the situation is alreadycongested, i.e. when there are some DL EGPRS TBFs on all thePDCHs of the established TRXs

a T4 reallocation is more likely to fail than in B8.


nnex : ncrease o reques s, ecrease oUL T2 requests, High increase of UL and DL T2t (1/4)




success rate (1/4)

Due to M-EGCH Statistical Multiplexing, P403b/P404b counter definition has changed between B8 and B9 (cf. MFS PM counter catalogue).

The definition of a “TBF candidate for T2 reallocation” is different.

So comparing B8 and B9 values is not relevant for T2 counters.

Some reasons explaining the counter variations are (among others):

In B9, T2 reallocation can replace T3 reallocation during the whole TBF life (but in B8, only during the phase where the TBF is sub-optimal in number of RTSs).

As a general rule, fewer constraints on Abis/Ater in B9 (due to dynamic Abis Allocation and M-EGCH Statistical-Multiplexing)

more possibilities for T2 TBF reallocations to succeed.

The number of T2 reallocations will be fully optimized in B9-MR3 (CR A20/160643V2).


nnex : ncrease o reques s, ecrease oUL T2 requests, High increase of UL and DL T2t (2/4)




success rate (2/4)

Example illustrating some differences between B8 and B9 for T2

reallocation:

In B8, if the existing TBF is optimal in number of RTSs in the direction of the

bias then, if it is possible, the concurrent TBF will be established in front of

it. There is no T2 reallocation of the existing TBF in this case because the

T3-reallocation criteria saying that the number of RTSs in the direction of

the bias shall be increased cannot be fulfilled.

In B9, in the same situation, it will be checked if a significant throughput

gain can be offered to the MS in the direction of the bias. The gain targeted

is the same as for a T3 reallocation: MIN_THROUGHPUT_GAIN.

If so, a T2 TBF reallocation will be triggered (contrary to B8).

If not, if it is possible, the concurrent TBF will be established in front of the

existing one (as in B8).

Another example is provided in the next slides


nnex : n ance ransm ss on resourcemanagement in RRM (3/4)E l 1 B8 b h i




Example 1 – B8 behaviour

Max_SPDCH_Dyn = 8, but only 1 PDCH

(PDCH 0) is allocated to the MFS. UL TBF establishment for MSa, EGPRS,

(4+1)

If new PDCHs are established before arrivalof DL LLC PDU (PDCH anticipation):

PDCHs 1-3 are established,

T2 reallocation,

UL establishment on PDCH 2 and DLestablishment on PDCH 0-3.

If DL LLC PDU arrives before new PDCHs

are established: DL establishment on PDCH 0,

MSa becomes candidate to T3reallocation.

When the new PDCHs are established,MSa is allocated on PDCH 0-3 after T3reallocation.

0 1 2 3

D

L

U

L

4 5 6 7

MSa

MSa

0

D

L

U

L

4 5 6 71 2 3

MSa MSa MSa MSa

0 1 2 3

D

L

U

L

4 5 6 7

MSa

MSa

MSa

0

D

L

UL

4 5 6 71 2 3

MSa MSa MSa MSa


nnex : n ance ransm ss on resourcemanagement in RRM (4/4)E l 1 B9 b h i




Example 1 – B9 behaviour

Max_SPDCH_Limit = 8,

With “Autonomous Packet Resourceallocation“ feature, PDCH0-7 are allocated tothe MFS, but the TRX is not established (noM-EGCH link).

UL establishment for MSa, EGPRS, (4+1):

1 GCH is established(N_GCH_For_Estab),

UL TBF for MSa is established on PDCH2,

4 GCHs are established (to reachTarget_Nb_GCH=5).

When DL LLC PDU arrives:

PDCH 0-3 is a possible candidate, DL TBF for MSa is established on PDCH

0-3,

Target_Nb_GCH = 18,

If it is possible, 13 new GCHs areestablished to reach Target_Nb_GCH.

Contrary to B8, there is no T2

reallocation in this case in B9

MSa

0 1 2 3 4 5 6 7

D

L

U

L

MSa

0 1 2 3 4 5 6 7

D

L

U

L

MSaMSaMSaMSa


Annex1: High decrease of UL and DL T3 success ratedue to failures during the preparation phase,V i ti f th b f T3 t (1/2)




Variations of the number of T3 requests (1/2)

In B9, all the TBFs can be candidate for T3 reallocation, even if theyhave already an optimal number of RTSs.In B8, only the TBFs sub-optimal in number of RTSs are candidatefor T3 reallocation.

Lower success rate in B9 than in B8.

Variations of the number of T3 requests (1):

In B8, in a given cell, up to 5 T3 TBF requests are systematically played ineach direction every second (N_MAX_PERIODIC_REALLOC = 5).

In B9, in a given cell, up to 20 T3 TBF requests are played in each directionevery second (N_MAX_PERIODIC_REALLOC_T3 = 20), but the process isstopped as soon as the first T3 TBF request succeeds.

This can explain variations of the number of T3 requestsbetween B8 and B9.


Annex1: High decrease of UL and DL T3 success ratedue to failures during the preparation phase,V i ti f th b f T3 t (2/2)




Variations of the number of T3 requests (2/2)

Variations of the number of T3 requests (2):

Examples:

- 5 (successful or unsuccessful) T3 TBF requests per second in B8 versus 1successful T3 TBF request per second in B9.

- 5 (successful or unsuccessful) T3 TBF requests per second in B8 versus 20unsuccessful T3 TBF requests per second in B9.

Whether there will be fewer or more T3 requests in B9 than in B8 depends onmany factors (PS traffic load in the cell, “PS traffic burstiness“, number of RTSs available for PS traffic in the cell, ...).

In B9, TBFs are more likely to have an optimal allocation than in B8 (because fewer constraints on Abis/Ater in B9 due to dynamic Abis Allocationand M-EGCH Statistical-Multiplexing).

Both in B8 and B9, the number of T3 TBF requests is only incremented incase of sub-optimal TBF allocation (B8: sub-optimal in number of RTSs, B9:sub-optimal according to “throughput ratio”).

But in B9, this number of sub-optimal TBFs is lower.

This can explain a decrease of the number of T3 requests.


Annexes









Annex6 : Alerters

Annex7 : FR content



Annex2 :Increased CS1 usage rate in B9 (1/4)




Increased CS1 usage rate in B9 (1/4)


Explained by two reasons:

DL TBF drops delayed in bad radio conditions, due to RLC/MAC

parameter modifications.The defence mechanism linked to TBF_CS_DL is more often triggeredand it can explain why the CS1 usage rate is increased in B9 release.

Use of Max_CS=CS1 in DL, when Established_Nb_GCH=1


0

1000000

2000000

3000000

4000000

5000000

6000000

0 2 / 2 1 / 2 0 0 6

0 2 / 2 2 / 2 0 0 6

0 2 / 2 3 / 2 0 0 6

0 2 / 2 4 / 2 0 0 6

0 2 / 2 5 / 2 0 0 6

0 2 / 2 6 / 2 0 0 6

0 2 / 2 7 / 2 0 0 6

0 2 / 2 8 / 2 0 0 6

0 3 / 0 1 / 2 0 0 6

0 3 / 0 2 / 2 0 0 6

0 3 / 0 3 / 2 0 0 6

0 3 / 0 4 / 2 0 0 6

0 3 / 0 5 / 2 0 0 6

0 3 / 0 6 / 2 0 0 6

0 3 / 0 7 / 2 0 0 6

0 3 / 0 8 / 2 0 0 6

0 3 / 0 9 / 2 0 0 6

0 3 / 1 0 / 2 0 0 6

0 3 / 1 1 / 2 0 0 6

0 3 / 1 2 / 2 0 0 6

0 3 / 1 3 / 2 0 0 6

CS4 usef

CS3 usef

CS2 usef

CS1 usef

B8 B9






A) DL TBF drops delayed in bad radio conditions, due to

RLC/MAC parameter modifications:

RLC/MAC parameter modifications:

Default value of N3105_LIMIT changed from 16 to 20

Default value of EGPRS_N3105_LIMIT changed from 16 to 20

Default value of N_stagnating_Window_DL_LIMIT changed 10 from to 32

Creation of a new parameter : MIN_RLF_TIME_DL

Definition : Minimum time before detecting a radio link failure of a DL TBF, triggeredby N3105 or NstagnatingWindowDL

Default value : 4 seconds

These parameters have been modified due to :

Introduction of statistical multiplexing and dynamic Abis features

Radio link failure detection at RLC layer must take into account possible lack of transmission resource, thus reducing the radio throughput

Introduction of the GPRS QoS feature (MAC scheduling modifications)






B) Number of established GCH in the M-EGCH link equal to 1

The maximum allowed (M)CS of a best-effort TBF (TBF_Max_allowed_(M)CS) is computedaccording to:

- the GPRS capability of the TRX (HW capability and EN_EGPRS value)

- the direction of the TBF (DL or UL)

- the Max_GPRS_(M)CS parameter value.

- the number of established GCHs in the M-EGCH link

(*) The maximum allowed (M)CS of an (E)GPRS DL TBF established on a TRX having an M-EGCH

link containing 1 GCH is set to (M)CS1 (and not (M)CS2). Indeed, it shall be guaranteed that the

MFS-BTS signalling messages will always be possible to be sent in the M-EGCH link in DL

UL TBF DL TBF

1 CS2 CS1*

>= 2 CS4 CS4

1 MCS2 MCS1*

2 MCS5 MCS5

3 MCS6 MCS6

4 MCS7 MCS7>= 5 MCS9 MCS9

G P R

E

G P R S

Max allowed (M)CS of the TBF according to

the number of GCHs of the M-EGCH linkNumber of established GCHs in

the M-EGCH link






B) Number of established GCH in the M-EGCH link equal to 1This situation can happen in the following cases:

Heavy GCH congestion, due to under-dimensioning on terrestrial

interfaces (Abis and/or Ater)

Short transitory phase, during the M-EGCH link establishment phase

Target_Nb_GCH computed to 1, in case only one PDCH is active on

the TRX, and Max_(E)GPRS=(M)CS2.This happens mainly for GMM/SM traffic (for which only one RTS is used).

In that specific case, the DL blocks are sent in CS1 instead of CS2, which is

deemed acceptable as throughput optimisation is not required. It can even beconsidered as an advantage, as CS1 is more robust than CS2.

Annexes









Annex6 : Alerters Annex7 : FR content



nnex : oca e Autonomous Packet Resource Allocation (RAE4)algorithm




Reminder in B8: The BSC evaluates the number of timeslots that the MFS could use

to carry PS traffic (Max_SPDCH_Dyn),

The MFS does not know which timeslots are usable for PS traffic,

To serve a new TBF, the MFS needs to request new timeslots to the

BSC.

“Event-triggered” mechanism

Max_SPDCH_Dyn = 8

TS allocated to BSC

TS allocated to MFS

algorithm

nnex : oca e Autonomous Packet Resource Allocation (RAE4)algorithm




In B9, new needs appear linked to AbisDynamic and

StatMux, QoS management (with RealTime PFC), andfaster TBF establishment

New algorithm : Autonomous Packet ResourceAllocation

The BSC evaluates a number of timeslots that the MFS can use tocarry PS traffic (Max_SPDCH_Limit),

Periodical exchange of messages between the BSC and the MFS:

BSC to MFS: list of RTS that the MFS can use,

MFS to BSC: acknowledgement of allocated / de-allocated RTS.

The MFS knows which timeslots can be used to serve a new TBF. “Periodical” mechanism

Max_SPDCH_Limit = 8

TS allocated to BSC

TS allocated to MFS

algorithm

Annex3: Allocated SPDCH (3/10)Impact of RAE4 on allocated SPDCH counters




Counter number

Name Definition

P414 CUMULATED_MAX_PDCH_DYN_SECONDS

This counter integrates over time the value of MAX_SPDCH_DYN during the whole granularityperiod.

Counter number

Name Definition

P414bis CUMULATED_TIME_ALLOCATED_ SPDCH

This counter integrates over time the values of theallocated SPDCH during the whole granularity

period.

nnex : ocateImpact of RAE4 on GPRS_MAX_PDCH_Dyn_avg(KPI)




In B8 :GPRS_MAX_PDCH_Dyn_avg = [ P414 / observation period ]

Average value of MAX_SPDCH_Dyn (available SPDCH to MFS)

In B9 :

GPRS_MAX_PDCH_Dyn_avg = [ P414bis / observation period ]

Average value of MAX_SPDCH_Limit (allocated SPDCH to MFS)

(KPI)

Annex3: Allocated SPDCH (5/10) Allocated SPDCH in B8 and B9 (hourly evolution)




Compared hourly evolution (B8/B9) of PDCH allocation counters

(Average on 224 cells with typical 2TRX configuration : NB_TS=14, MIN_PDCH=2, MAX_PDCH=9)

2

3

4

5

6

7

8

9

10

0 : 0 0

1 : 0 0

2 : 0 0

3 : 0 0

4 : 0 0

5 : 0 0

6 : 0 0

7 : 0 0

8 : 0 0

9 : 0 0

1 0 : 0 0

1 1 : 0 0

1 2 : 0 0

1 3 : 0 0

1 4 : 0 0

1 5 : 0 0

1 6 : 0 0

1 7 : 0 0

1 8 : 0 0

1 9 : 0 0

2 0 : 0 0

2 1 : 0 0

2 2 : 0 0

2 3 : 0 0

P414

P414bis

Annex3: Allocated SPDCH (6/10)Examples of MAX_SPDCH_LIMIT Calculation (1/4)




Free TS (12) are split equallybetween CS and PS (6 and 6)

6 TS are kept for circuit,

so 8 are allocated to packet traffic(6+2 due to MIN_PDCH)

Case 0: No CS & No PS traffic

MIN_PDCH 2

MAX_PDCH 9

MAX_PDCH_HIGH_LOAD 2

HIGH_TRAFFIC_LOAD_GPRS 85

THR_MARGIN_PRIO_CS 15

NB_TS 14

Parameters

B S T T T T T T

T T T T T T T T

AV_USED_CS_TS 0

AV_USED_PS_TS 0

MAX_SPDCH_DYN (B8) 9

MAX_SPDCH_LIMIT (B9) 8

Example :Parameters for a cellwith 2 TRX

nnex : ocateExamples of MAX_SPDCH_LIMIT Calculation(2/4)





5 TS are kept for circuit,so 9 are allocated to PS traffic

Case 2: No CS & Medium PS traffic

AV_USED_CS_TS 0

AV_USED_PS_TS 4

MAX_SPDCH_DYN (B8) 9MAX_SPDCH_LIMIT (B9) 9


4 more TS are kept for circuit,so 6 are allocated to PS traffic

Case 1: Medium CS & No PS traffic

B S T T T T T T

T T T T T T T T

AV_USED_CS_TS 4

AV_USED_PS_TS 0



B S T T T T T T

T T T T T T T T

(2/4)





Free TS (3) are split equally between CSand PS (1.5 and 1.5)

But we must keep a margin of 2 TS for CSdue to HIGH_TRAFFIC_LOAD_GPRS, so

8 remain allocated for PS

Case 4: Medium CS & High PS traffic

B S T T T T T T

T T T T T T T T

AV_USED_CS_TS 4

AV_USED_PS_TS 7




3 TS more are kept for circuit,so 7 are allocated to packet traffic

Case 3: Medium CS & PS traffic

B S T T T T T T

T T T T T T T T

AV_USED_CS_TS 4

AV_USED_PS_TS 4



(3/4)





Case 5: High CS & Medium PS trafficFree TS (3) are split equally betweenCS and PS (1.5 and 1.5)

We must keep a margin of 2 TS for CSdue to HIGH_TRAFFIC_LOAD_GPRS,so 5 TS remain allocated for PS

Case 6: High CS & High PS traffic

We must keep a margin of 2 TS for CSdue to HIGH_TRAFFIC_LOAD_GPRS,

so 5 TS remain allocated for PS

B S T T T T T T

T T T T T T T T

B S T T T T T T

T T T T T T T T

AV_USED_CS_TS 7

AV_USED_PS_TS 7



AV_USED_CS_TS 7

AV_USED_PS_TS 4



(4/4)

Annex3: Allocated SPDCH (10/10)Conclusion




In B8: the BSC computes the limit of TS that could be allocated to the MFS

(MAX_SPDCH_DYN)

These TS are not necessarily allocated to the MFS

In B9: The BSC computes the TS needed by itself for CS, by the MFS for PS, and allocates

actually these TS to the MFS (MAX_SPDCH_LIMIT)

Conclusion in a real network Most cells have low PS traffic (on average), which leads to lower MAX_SPDCH_LIMIT in

B9 than MAX_PDCH_DYN in B8 (see case 0 and 1) In case PS traffic increases, the MAX_SPDCH_LIMIT would be equal or even higher to

MAX_SPDCH_DYN (see case 2, 4 and 6)

Annexes












Annex4: Speech codec variation




Speech Coder Counters variation – Explanation The analysis hasshow the following change in the implementation of the counter:

In B8, we counted as: Data call: MC701E;

Speech: – Support FR AMR or HR AMR: MC701D

– Only support FR&HR&EFR: MC701C

– Only support FR&HR: MC701B

– Only support FR: MC701A

– Other: Not counted;

In B9 Data call: MC701E;

Speech: – Support FR AMR or HR AMR: M701D

– Only support FR&HR&EFR: M701C

– Only support FR&HR: M701B

– Only support FR: MC701A

– Other: MC701A;=> accepted in B9, the description in BCC will be updated accordingly The "other" including:

Only support HR;

Only support EFR&HR;

Only support FR&EFR;

Only support EFR.

Annexes












Annex 5 : How to decrease CS congestion inB9 network




In case of congested networks, an increase of CS congestion can be

observed in B9 Linked to new radio resource allocation in B9

Some parameter tuning can decrease the CS congestion

HIGH_TRAFFIC_LOAD_GPRS is the main parameter to be decreased:

“Load threshold used to determine a certain margin of radio timeslots reserved for CStraffic between two sending of the BSCGP RR Allocation Indication messages. Thethreshold is expressed in percentage of the radio timeslots available in the cell”

1st step: apply the BTP recommended default value: – 70 for a cell with 1, 2 or 3 TRX

– 80 for a cell with more than 3 TRX

=> Check the GPRS QOS which can be degraded by the modification

2nd step: In case of still CS degradation compare to B8:

– Decrease again the parameter HIGH_TRAFFIC_LOAD_GPRS

– Check that MAX_PDCH_HIGH_LOAD is different from 0 (To minimize the impact inGPRS traffic.)

3rd step: Check activation of traffic management features (HR, Directed Retry, traffic HO,fast traffic HO, dyn SDCCH…)

Annexes











Annex6: (1/3) Alerters definition – Sleeping GPRS cells




Sleeping GPRS cells alerter raised when

(the number of UL TBF estab success = 0) AND

(the number of UL TBF requests > X) AND

(the number of DL TBF estab requests =0)

QoS alerter Scope: ENDTIME>@DAY, "9:00" && ENDTIME<=@DAY,"23:00"

Critical Predicate: (P30a + P30b + P30c==0) && (P62a+P62b+P62c-P438c >X) && (P91a+P91b+P91c+P91d+P91e+P91f==0 )Major Predicate:Warning Predicate:Clearance Predicate: (P30a + P30b + P30c>0) ||(P91a+P91b+P91c+P91d+P91e+P91f >0 )Table: GPRS: CELLStability (mins): 60

X : this value can be adapted. The recommended value is « 20 »

When the alerter is raised, it is recommended to check the QOS status of thecell with RNO

Alerters definition – UL Degraded GPRScells




cells

Unefficiency UL TBF establishment alerter raised when [ (The number of UL TBF requests >50) AND

(The UL TBF success rate < 20%) ]

Definition

Warning Predicate: ((P62A+P62B+P62C) > 50) &&((P30A+P30B+P30C) / (P62A+P62B+P62C)) < 0.2))

Clearance Predicate: ((P30A+P30B+P30C) / (P62A+P62B+P62C)) >0.5))

Table: GPRS: CELL

Stability (mins): 120 (restriction in B9 , the value « 60 » will beconsidered)

Alerters definition – DL Degraded GPRScells




cells

Unefficiency DL TBF establishment alerter raised when

[(The number of DL TBF requests >50) AND

(The DL TBF success rate < 20%)]

Definition

Warning Predicate: ((P91A+P91B+P91C+P91D+P91E+P91F)>50)&& ((P90A+P90B+P90C+P90D+P90E+P90F) /(P91A+P91B+P91C+P91d+P91E+P91F)) < 0.2)

Clearance Predicate: ((P90A+P90A+P90C+P90D+P90E+P90F) /(P91A+P91B+P91C+P91D+P91E+P91F) > 0.5)

Table: GPRS: CELLStability (mins): 120 (restriction in B9, the value « 60 » will beconsidered)

Annexes









Annex6 : AlertersAnnex7 : FR content


Annex7: QOS Variation After Migration=>FR




The following information is needed in a QOS FR

Seen by the customer ?

Value of the degradation compare to B8.

Is it common to all cells (check alc_multi_xxx RNO report) ?

If not, What is the rate of cells impacted with the level of degradation. - - For theimpacted cells give some feature/configuration information (if you can find it) (CS3/4activated ? edge activated ? BTS type... all other information which could help theinvestigation...)

Is it common to all BSC with the same level of degradation ?

If not what could be some differences between each BSC (parameter tuning, featureactivated) (this point is to help TD by some track if you can find any)

have you seen a workaround ? (for example do you notice that a GPU reset has an

impact on the QOS degradation...)

All these information can then be correlated with other networks and could help theanalysis

Annexes











nnex : ecrease o num er o rese ec ons n:Impact of B9 on P396b and P434c




p

P396b : Number of UL TBF releases requested by RRM to RLC uponreceipt of the Flush message.

P434c : Number of UL TBF releases due to NC0 cell reselections

In B9, the algorithm in RLC to detect abnormal UL TBF release is lessstrict than in B8, i.e. more time is given to conclude that the MS is

actually lost. Therefore, in case of cell reselection, it is more likely that the FLUSH

message will be received before the TBF is released

P396b higher than in B8, P434c lower than in B8

No impact on end-user :

No influence on the TBF establishment in the new cell

In B9 as in B8, trigger to reroute remaining LLC-PDUs (DL case) is theFlush message


B9 Status at MR1 Ed4 QD11

Documents

Transcript of B9 Status at MR1 Ed4 QD11