2g data network planning & optimization guidelines

16
2G Data Network Planning & Optimization Guidelines (Document no: VF / NSN / PLNG / Data 1 May, 2011) Version / History : Version Date Created By Reviewed by Approved by Ver. 1 May 2011 Vijendra Singh Tushar Panchal Ajay Jain Distribution list : Vodafone Network PLNG & Quality Managers of all NSN circles Vodafone Network Head of all NSN circles NSN Circle heads & Quality Leads (MS Team)

Upload: manpreet-kaur

Post on 04-Oct-2015

86 views

Category:

Documents


25 download

DESCRIPTION

2g gsm

TRANSCRIPT

  • 2G Data Network Planning & Optimization Guidelines

    (Document no: VF / NSN / PLNG / Data 1 May, 2011)

    Version / History :

    Version Date Created By Reviewed by Approved by

    Ver. 1 May 2011 Vijendra Singh Tushar Panchal Ajay Jain

    Distribution list : Vodafone Network PLNG & Quality Managers of all NSN circles Vodafone Network Head of all NSN circles NSN Circle heads & Quality Leads (MS Team)

  • Scope of Document :

    This Document gives the basic guidelines for 2G Data (GPRS & EDGE) Access network dimensioning

    & optimization along with basic proven tips.

    This Document also includes information about PCU PIUs, its resource, dimensioning &

    optimization.

    This document also provides the information related to the Data KPIs, Formula, Counter, Reports

    which helps to plan & optimize 2G Data Network followed by new NQI calculation for data network.

  • General Guidelines:

    1. GPRS (GENA=Y) and EDGE (EGENA=Y) should be enabled in all the cells.

    2. For the Cells with 1 TRXs configuration, in any case, there should not be more then 1

    dedicated data RTSL require to configure.

    3. The BVCI OPERATIONAL STATE should always be WO_EX.

    4. BCCH TRX should always be defined preferred for GPRS/EDGE channel allocation.

    5. Dedicated Capacity should never be kept Zero in any case as it will make the ongoing

    GPRS/EDGE sessions to be dropped, whenever any voice call will arrive.

    6. The Maximum GPRS Capacity (CMAX) should always be 100%.

    PCU Information:

    Below table gives the capacity in terms of 16Kbps TSL for each type of logical PCUs.

    Following are the capacity of different PCU cards,

    BSC3i 2000 : max. 100 PCU2 (50 physical PCU2 units per BSC, 2 logical PCUs in one PCU2 plug-in unit) - Simple rule is one BCSU of BSC 3i HC can support max 5 physical PCU (10 Logical PCU). So for BSC3i 2000 BSC - total 10 BCSU = 10*10=100 logical PCUs Max capacity supported

    BSC3i 1000 : max. 50 PCU2 (25 physical PCU units per BSC, 2 logical PCUs in one PCU2 plug-in unit) - Simple rule is one BCSU of BSC 3i HC can support max 5 physical PCU (10 Logical PCU). So for BSC3i 1000 BSC - total 5 BCSU = 5*10=50 logical PCUs Max capacity supported

    BSC3i 660 : max. 24 PCU1/PCU2 (12 physical PCU units per BSC, 2 logical PCUs in one PCU1/PCU2 plug-in unit) - Simple rule is one BCSU of BSC 3i Normal can support max 2 physical PCU (4 Logical PCU). So for BSC3i 660 BSC - total 6 BCSU = 6*4=24 logical PCUs Max capacity supported

    BSC2i : max. 16 PCU1/PCU2 (16 physical PCU units per BSC, 1 logical PCU in one PCU1/PCU2 plug-in unit) - Simple rule is one BCSU of BSC 2i can support max 2 physical PCU (2

    Limits per PCU PCU1 PCU-B PCU2-U PCU2-D PCU2-E

    Max RTSLs * 128 256 256 256

    Max 16kbps Abis Ch 256 256 256 256

    Max EDAPs per PCU 16 16 16 16

    Max BTSs 64 64 128 128

    Max SEGs 64 64 64 64

    Max TRXs 128 128 256 256

    Max 64kbps Gb Ch 32 32 32 32

    Logical PCU per PIU 1 2 1 2

    Max PCU PIU per BCSU 2 2 2 5

  • Logical PCU). BSC2i max TRX capacity 512 TRX and 8 BCSU (64 TRX per BCSU) - total 8 BCSU = 8*2 =16 logical/physical PCUs Max capacity supported

    MS capabilities and present Multislot Market Trend : (As of Week 15, 2011) Below are the available MS multislot classes. For e.g. for MS class 10, maximum of 4 TSLs in DL and 2 TSLs in UL can be get allocated however simultaneously total of 5 TSLs can be got allocated (4+2=5)

    Below is the current market trend of available Mobile Handsets, the highest penetration is of MS class 10, followed by other classes. In future the growth of high end Smart handset will lead to higher percentage of Class 32 and above handsets and there the features like EDA and HMC will play a vital role in user perception of Data Throughput.

    Multislot Class Downlink TS Uplink TS Active TS

    1 1 1 2

    2 2 1 3

    3 2 2 3

    4 3 1 4

    5 2 2 4

    6 3 2 4

    7 3 3 4

    8 4 1 5

    9 3 2 5

    10 4 2 5

    11 4 3 5

    12 4 4 5

    30 5 1 6

    31 5 2 6

    32 5 3 6

    33 5 4 6

    34 5 5 6

  • Radio Network Configuration:

    1. Dedicated Capacity (CDED) should be kept MINIMUM 4 TSLs for Top-10 city cells and

    MINIMUM 2 TSLs for RoN cells. Based on requirement, the same can be increased further.

    Voice Busy hour & Data Busy hour can be reviewed.

    2. Single TRX sectors should have at least 1 dedicated TSL.

    3. Dynamic Capacity should be kept MINIMUM 4 TSLs (Packet territory totals 6 TSLs) for TOP-

    10 City cells and MINIMUM 2 TSLs (Packet territory totals 4 TSLs) for RoN cells.

    4. The MINIMUM EDAP size should be 2 x 64 TSLs (8 Abis Sub-TSLs) for RoN and 4 x 64 TSLs (16

    Abis Sub-TSLs) for Top-10 City sites. Based on requirement, the same can be increased

    further.

    5. All the BSCs with PCU2D and above should have CS3 and CS4 enabled in all the cells. The

    same can be enabled wherever EDGE already enabled.

    6. For each Cell, Voice Busy hour & Data Busy hour can be reviewed to increase more Dynamic

    TSLs instead of reserving more Dedicated TSLs.

    7. Reconfiguration of Dedicated Data TSLs to Voice needs to also review. These will release un-

    necessary occupied Radio & PCU Capacity.

    Circle Class 32 Subs Class 10 Subs Combined

    Andhra Pradesh 10% 19% 29%

    Assam 11% 16% 27%

    Bihar 6% 12% 17%

    Chennai 16% 27% 44%

    Delhi 13% 18% 32%

    Gujarat 9% 16% 25%

    Haryana 5% 9% 14%

    Himachal Pradesh 10% 18% 28%

    J&K 7% 13% 20%

    Karnatka 14% 22% 36%

    Kerala 15% 16% 31%

    Kolkata 8% 17% 25%

    Maharashtra 8% 17% 25%

    MP 9% 21% 29%

    Mumbai 23% 33% 56%

    North East 16% 23% 39%

    Orissa 8% 16% 25%

    Punjab 17% 27% 44%

    Rajasthan 4% 9% 13%

    TN 7% 12% 19%

    UP (East) 4% 8% 12%

    UP (West) 3% 7% 10%

    WB 4% 11% 15%

    National 9% 15% 23%

  • PCU Dimensioning (with 80% PCU Capacity):

    Sample calculation created based on March 2011 information for Top 10 Cities & RoN to

    have an idea for PCU capacity requirements considering all PCU_2D PIUs, GbIP & PCU Pooling.

    Circles (or BSCs) with higher TRXs per Cell will have adequate PCU resource utilization.

    Circles (or BSCs) with lower TRXs per Cell need to have higher PCU resource utilization & require to

    have need base approach. Additional PCU resource can be added POST Asymmetrical PCU

    Configuration feature in place.

    ParameterTotal TRX

    (operational)

    Total

    cells

    TRXs per

    Cell

    Sites possible per

    110 TRX BCSU

    Sites possible per

    200 TRX BCSU

    PCU Capacity Available in 110 TRX

    BCSU with 1 x PCU_2D PIU

    PCU Capacity Available in 110 TRX

    BCSU with 1 x PCU_2D PIU

    Required PCU capacity in case

    of 110 TRX BCSU

    Required PCU capacity in case of 200

    TRX BCSU

    No. of Cells

    with 1 TRX

    No. of Cells

    with 2 TRX

    GUJ 79,935 19,848 4.0 9 17 512 1024 310 563 14 2419

    CHN 18,825 5,114 3.7 10 18 512 1024 339 616 16 599

    UPE 86,437 24,260 3.6 10 19 512 1024 350 636 7 5975

    TN 62,509 19,291 3.2 11 21 512 1024 385 700 21 6435

    HAR 23,926 7,490 3.2 11 21 512 1024 390 710 32 2298

    WB 54,316 17,814 3.0 12 22 512 1024 409 743 79 7201

    UPW 51,543 17,136 3.0 12 22 512 1024 414 754 139 6403

    MAH 60,842 20,725 2.9 12 23 512 1024 425 772 905 9420

    KER 34,366 11,835 2.9 13 23 512 1024 429 781 44 5685

    RAJ 48,512 18,321 2.6 14 25 512 1024 471 856 1601 8489

    NE 5,739 2,604 2.2 30 1024 1028 660 1101

    ASM 12,987 6,088 2.1 31 1024 1063 1248 3595

    BHR 34,239 16,479 2.1 32 1024 1091 3594 8278

    KAR 43,883 21,278 2.1 18 32 512 1024 604 1099 7164 7411

    JK 5,696 2,764 2.1 32 1024 1100 334 2148

    ORI 18,380 9,321 2.0 34 1024 1149 1578 6880

    AP 46,040 23,454 2.0 19 34 512 1024 635 1155 8133 8911

    HP 3,673 1,987 1.8 36 1024 1226 487 1281

    MP 20,209 11,533 1.8 38 1024 1294 4090 6645

    ParameterTotal TRX

    (operational)

    Total

    cells

    TRXs per

    Cell

    Sites possible per

    110 TRX BCSU

    Sites possible per

    200 TRX BCSU

    PCU Capacity Available in 110 TRX

    BCSU with 1 x PCU_2D PIU

    PCU Capacity Available in 110 TRX

    BCSU with 1 x PCU_2D PIU

    Required PCU capacity in case

    of 110 TRX BCSU

    Required PCU capacity in case of 200

    TRX BCSU

    GUJ 79,935 19,848 4.0 9 17 512 1024 182 331 14 2419

    CHN 18,825 5,114 3.7 10 18 512 1024 199 362 16 599

    UPE 86,437 24,260 3.6 10 19 512 1024 206 374 7 5975

    TN 62,509 19,291 3.2 11 21 512 1024 226 411 21 6435

    HAR 23,926 7,490 3.2 11 21 512 1024 230 417 32 2298

    WB 54,316 17,814 3.0 12 22 512 1024 241 437 79 7201

    UPW 51,543 17,136 3.0 12 22 512 1024 244 443 139 6403

    MAH 60,842 20,725 2.9 12 23 512 1024 250 454 905 9420

    KER 34,366 11,835 2.9 13 23 512 1024 253 459 44 5685

    RAJ 48,512 18,321 2.6 14 25 512 1024 277 504 1601 8489

    NE 5,739 2,604 2.2 30 1024 605 660 1101

    ASM 12,987 6,088 2.1 31 1024 625 1248 3595

    BHR 34,239 16,479 2.1 32 1024 642 3594 8278

    KAR 43,883 21,278 2.1 18 32 512 1024 356 647 7164 7411

    JK 5,696 2,764 2.1 32 1024 647 334 2148

    ORI 18,380 9,321 2.0 34 1024 676 1578 6880

    AP 46,040 23,454 2.0 19 34 512 1024 374 679 8133 8911

    HP 3,673 1,987 1.8 36 1024 721 487 1281

    MP 20,209 11,533 1.8 38 1024 761 4090 6645

    (At 2 Dedicated + 4 Dynamic (Total 6) & 256 DAP = 34 RTSLs

    (At 2 Dedicated + 2 Dynamic (Total 4) & 128 DAP = 20 RTSLs

  • Gb link Augmentation and Utilization:

    The Gb link should always be monitored for congestion in the BW allocated. The below calculation in the table can be used for augmentation of the Gb link.

    Based on the above calculations we can find out if there is need of BW augmentation at any Gb link.

    ND 284 should also be observed for determining and verifying the data sent/receive through SGSN

    and also for observing if there has been any change in the working state of NSVC.

    MSC

    Name

    BSC

    Name

    24 Hour

    Payload

    Busy Hour

    Payload

    BW req.

    (24H)

    BW req.

    (BH)Cluster

    BW from BSC to

    Cluster(Mb)

    Provisioning

    BW req.

    BW Cluster

    Location to

    Switch (Mb)

    MSS1 BSC1 1606200 130000 0.2905 0.2821 xyz 0.5809 2

    MSS1 BSC2 1404000 155000 0.2539 0.3364 xyz 0.6727 2

    MSS1 BSC3 6700000 500000 1.2117 1.0851 xyz 2.4233 4

    MSS1 BSC4 4300000 320000 0.7776 0.6944 xyz 1.5553 2

    MSS1 BSC5 8400000 540000 1.5191 1.1719 xyz 3.0382 4

    MSS1 BSC6 6500000 420000 1.1755 0.9115 xyz 2.3510 4

    MSS1 BSC7 1300000 850000 0.2351 1.8446 xyz 3.6892 4

    MSS1 BSC8 4800000 280000 0.8681 0.6076 xyz 1.7361 2

    MSS1 BSC9 1900000 150000 0.3436 0.3255 xyz 0.6872 2

    MSS1 BSC10 6200000 540000 1.1212 1.1719 xyz 2.3438 4

    7.7963 8.4310 16.8620

    18

  • Data Network Payload:

    Data Payload should be monitored on daily basis for 24Hr, Data network DBH and Cell DBH level.

    The below table shows the DBH hour detail on network (BSC) level:

    Network Data Busy Hour (DBH): This is the particular 1 hour in a day when there has been maximum generation of Data Payload in the network.

    Cell Data Busy Hour (Cell DBH): This is the particular 1 hour in a day when there has been maximum generation of Data Payload in the cell.

    BSC Date Start_Time Payload(KB) Remark

    BSC01 22/ 02/ 2011 00:00 10838.46

    BSC01 22/ 02/ 2011 01:00 30071.46

    BSC01 22/ 02/ 2011 02:00 35012.05

    BSC01 22/ 02/ 2011 03:00 4416.39

    BSC01 22/ 02/ 2011 04:00 3267.4

    BSC01 22/ 02/ 2011 05:00 35828.53

    BSC01 22/ 02/ 2011 06:00 45694.45

    BSC01 22/ 02/ 2011 07:00 10438.92

    BSC01 22/ 02/ 2011 08:00 6691.61

    BSC01 22/ 02/ 2011 09:00 4758.55

    BSC01 22/ 02/ 2011 10:00 6898.47

    BSC01 22/ 02/ 2011 11:00 2332.97

    BSC01 22/ 02/ 2011 12:00 6194.96

    BSC01 22/ 02/ 2011 13:00 5770.05

    BSC01 22/ 02/ 2011 14:00 7761.09

    BSC01 22/ 02/ 2011 15:00 70764.55 Data Busy Hour

    BSC01 22/ 02/ 2011 16:00 36683.96

    BSC01 22/ 02/ 2011 17:00 1241.57

    BSC01 22/ 02/ 2011 18:00 2372.75

    BSC01 22/ 02/ 2011 19:00 5576.38

    BSC01 22/ 02/ 2011 20:00 6981.88

    BSC01 22/ 02/ 2011 21:00 8894.4

    BSC01 22/ 02/ 2011 22:00 12555.02

    BSC01 22/ 02/ 2011 23:00 58351.11

    419396.98 24Hr Payload

    Cell_1 Cell_2 Cell_3 Cell_4

    BSC01 22/ 02/ 2011 00:00 10838.46 15620.65 21588.02 31550.47

    BSC01 22/ 02/ 2011 01:00 1300.79 13919.39 4927.78 19749.11

    BSC01 22/ 02/ 2011 02:00 10300.72 26682.15 16326.95 57559.45

    BSC01 22/ 02/ 2011 03:00 4169.26 14794.91 49893.29 30598.82 DBH for Cell_3

    BSC01 22/ 02/ 2011 04:00 4313.57 12002.39 2386.86 24414.82

    BSC01 22/ 02/ 2011 05:00 1744.24 28369.72 895.45 13534.13

    BSC01 22/ 02/ 2011 06:00 1004.65 88970.22 30290.85 30191.8 DBH for Cell_2

    BSC01 22/ 02/ 2011 07:00 19353.01 49899.82 13090.86 28899.83

    BSC01 22/ 02/ 2011 08:00 26783.91 31770.78 5060.39 23895.5

    BSC01 22/ 02/ 2011 09:00 53704.54 6878.41 4377.18 12592.49

    BSC01 22/ 02/ 2011 10:00 56494.58 36415.11 5265.25 1929.63 DBH for Cell_1

    BSC01 22/ 02/ 2011 11:00 35327.47 19377.06 18295.13 8900.4

    BSC01 22/ 02/ 2011 12:00 12334.07 21059.39 9207.57 17094.56

    BSC01 22/ 02/ 2011 13:00 17428.05 4821.45 13263.51 20024.83

    BSC01 22/ 02/ 2011 14:00 25725.57 2840.73 45663.5 15102.31

    BSC01 22/ 02/ 2011 15:00 20087.97 1028.46 11416.2 71935.14

    BSC01 22/ 02/ 2011 16:00 30869.2 1032.59 15821.37 38774.48

    BSC01 22/ 02/ 2011 17:00 33302.02 13599.06 13153.28 8480.58

    BSC01 22/ 02/ 2011 18:00 6844.04 45284.52 20657.12 47841.87

    BSC01 22/ 02/ 2011 19:00 12069.63 744.09 1464.9 4234.7

    BSC01 22/ 02/ 2011 20:00 13756.84 15700.05 31456.56 18119.05

    BSC01 22/ 02/ 2011 21:00 4423.08 11393.35 2958.58 4210.8

    BSC01 22/ 02/ 2011 22:00 6744.22 29306.24 7154.88 96111.16 DBH for Cell_4

    BSC01 22/ 02/ 2011 23:00 7651.07 10313.36 16115.21 22691.95

    Payload (KB)BSC Date Start_Time Remark

  • Data Network Performance and Optimisation:

    ND reports 226, 228, 229 should be monitored extensively for best data network performance at

    the Air Interface.

    1. Dedicated Capacity can be decreased, if there is TCH Congestion or High utilization (FR

    Utilization > =80%) at the cells.

    2. Dedicated Capacity can be increased; when the data requirement is high and throughput is

    low given there is very low voice utilization and zero TCH Congestion.

    3. The Counters which should be considered for observing the sharing of data resources is

    tbf_37d and tbf_38d, which indicates Average number of UL TBFs per timeslot and

    Average number of DL TBFs per timeslot respectively. Any value greater than 1.1 in Cell

    DBH shows sharing of Data Resources.

    4. Dynamic capacity can be increased when the data requirement is high and throughput is low

    on the same TRX or after defining 2 TRXs as GTRX , also considering the PCU load capacity.

    5. The counters which should be considered for observing the release of dynamic TSLs due to

    high CS traffic are tbf_19a and tbf_20a, which indicates Share of TBFs released due to high

    CS traffic (UL) and Share of TBFs released due to high CS traffic (DL) respectively.

    6. The counters which should be considered for removing the multislot blocking, when the

    blocking is met regularly, than there is a need either to expand the territory (CS traffic low)

    or TCH capacity (CS traffic high), are tbf_15a and tbf_16a, which indicates the Share of

    rejected allocations due to lack or resources (UL) and Share of rejected allocations due

    to lack or resources (DL) respectively.

    7. ND 280 should be monitored extensively for early anticipation of drop in data throughput.

    8. The counters which should be considered for observing the congestion at the Abis end are :

    c76007 Number of DL TBFs without EDAP resources

    c76008 Number of cases where the required EDAP channel cannot be granted to DL TB

    And accordingly the EDAP TSLs can be incremented.

    9. The increase in EDAP TSLs will depend upon the availability of TSLs on E1 and the PCU

    capacity.

  • 10. Alarm 3273, (E) GPRS TERRITORY FAILURE, should be monitored regularly to detect the

    loading of PCU resources.

    New Data KPIs and NQI weightage: (For NSN MS Networks)

    1. The minimum required EDGE DL throughput is 100kbps for Top10 city cells and 90kbps for

    RoN cells.

    2. The minimum required GPRS DL throughput is 45kbps for all the cells.

    3. A New KPI of MCS coding scheme Utilisation success (DBH) has been added to observe the

    allocation of higher coding schemes, as it directly affects the user throughput and customer

    perception of the network.

    Top 10 City Rest of NWNQI

    WeightageTop 10 City Rest of NW

    EDGE DL Average Thruput per TBF

    (DBH)

    EDGE DL Average Thruput per TBF

    (DBH)2 >=110 Kbps >=90 Kbps

    1.5

    1.5

    2

    3

    Total Weightage for DBH Data KPIs > 10

    EDGE DL Average Thruput per TBF

    (DBH)>=100 Kbps

    EDGE DL Average Thruput per TBF

    (DBH) >=80 Kbps2 >=95% >=90%

    2 >=95% >=90%

    TBF Success Rate (DBH) >=95% TBF Success Rate (DBH) >=93% 2 >=95% >=90%

    2 >=95% >=90%

    3 >=85% >=75%

    Total Weightage for Cell BH Data KPIs > 11

    % of Cel ls

    Meeting

    KPI at Cel l

    Data BH

    GPRS DL Average Thruput per TBF (DBH) >=45 Kbps

    DL Multis lot Ass ignment Success (DBH) >=95%

    Cel ls meeting a l l Data KPI's cri terion

    Data KPI

    (at DBH)

    GPRS DL Average Thruput per TBF (DBH) >=45 Kbps

    TBF Success Rate (DBH) >=95%

    DL Multis lot Ass ignment Success (DBH) >=97%

    MCS Coding scheme Utl ization(MCS7,MCS8,MCS9) >=75%

  • Recommendations for optimizing the Data KPIs are as follows:

    TBF Success Rate KPI Optimization: Definition: Temporary Block Flow (TBF) is a physical connection used by the two Radio Resource entities to support the unidirectional transfer of PDUs on packet data physical channels. The TBF is allocated radio resource on one or more PDCHs and comprises a number of RLC/MAC blocks carrying one or more LLC PDU. TBF Success Rate is when during a data session, TBFs are successfully established on UL and DL. Suggestions for Optimization:

    1. Identify the poor performing Cells for TBF Success Rate (ND226/ND229).

    2. Distinguish the Poor TBF Success Rate: whether UL or DL is poor or it is poor in both

    directions.

    3. Take the detailed report (ND235)

    4. Identify the failure reasons (like poor radio conditions, MS no response, Flush, Suspend)

    after analyzing detailed report and work to resolve the same.

    5. If it is due to poor radio conditions/interference; check radio quality, check C/I. Perform a

    drive test to analyze the cell in more detail.

    6. Check Gb Congestion.

    7. Check Hardware/TRX alarms; Resolve if find any.

    8. Audit for any parameters related discrepancies (like BFG, MCA, MCU, ELA etc.) and define as

    per standard parameters set.

    After all rectification, observe the next days report and if the problem gets repeated, the same process may be followed with due care to find the actual cause. Average GPRS throughput and Average EDGE Throughput Optimization:

    Definition: Throughput is the amount of data uploaded/downloaded per unit of time. Suggestions for Optimization:

    1. Identify the poor performing Cells for Poor GPRS/EDGE Throughput (ND226/ND229).

    2. Distinguish the Poor Throughput cells: whether UL or DL is poor or it is poor in both

    directions.

    3. Take the detailed report showing (Ex. Total TBF Requests, Coding Scheme Utilization)

    4. Identify the cells after analyzing detailed report and follow the below mentioned steps.

    5. Take the configuration dump of the poor cells:

  • a. Check The Dedicated and Dynamic TSLs definition from ND 051 report.

    b. If you find Zero Dedicated or Dynamic TSL, define the same.

    c. If TSLs definition is sufficient as per the guidelines, then check whether the TBF

    requests are high. If requests are high, then we need to define more TSLs in the cell.

    But before defining more TSLs, check whether the Voice Utilization is not high and

    there is no TCH Congestion in the cell.

    d. Check whether there are enough EDAP TSLs defined at the site. If not, more TSLs

    need to be defined.

    6. Check whether it is due to poor radio conditions/interference; check radio quality, check C/I.

    Perform a drive test to analyze the cell in more detail.

    7. Check Gb Congestion.

    8. Check Hardware/TRX alarms; Resolve if find any.

    9. Audit for any parameters related discrepancies and define as per standard parameters set.

    After all rectification, observe the next days report and if the problem gets repeated, the same process may be followed with due care to find the actual cause. Optimization of Downlink Multislot Assignment Success Rate:

    Definition: User timeslot request based on traffic types and MS multi-timeslot capability and the actual timeslot allocated by the system which can also be termed as Downlink Multislot Assignment Success rate. Suggestions for Optimization:

    1. Identify the Bad performing Cells for Poor DL Multislot Assignment.

    2. Take the detailed report (ND226, ND235)

    3. Identify the poor cells after analyzing detailed report and follow the below mentioned steps.

    4. Take the configuration dump of the poor cells:

    a. Check The Dedicated and Dynamic TSLs definition from BSC Configuration data

    b. If you find Zero Dedicated or Dynamic TSLs, define the same.

    c. If TSLs definition is sufficient as per the guidelines, then check whether the TBF

    requests are high. If requests are high, then we need to define more TSLs in the cell.

    But before defining more TSLs, check whether the Voice Utilization is not high and

    there is no TCH Congestion in the cell.

    d. Check the multiplexing thresholds and upgrade/downgrade reports.

    5. Check whether it is due to poor radio conditions/interference; check radio quality, check C/I.

    Perform a drive test to analyze the cell in more detail.

  • 6. Check Gb Congestion.

    7. Check Hardware/TRX alarms; Resolve if find any.

    8. Audit for any parameters related discrepancies and define as per standard parameters set.

    After all rectification, observe the next days report and if the problem gets repeated, the same process may be followed with due care to find the actual cause. Sleeping GPRS Cells:

    Sleeping GPRS cell is defined as Cell where GPRS traffic is disturbed intermittently and will

    require some action (like GENA toggling, NSEI reset, site reset, BCSU/PCU combination change etc) to resume Gb traffic. Below is an example of a sleeping cell where there has been no DL TBF (counter 072005) although UL TBF (counter 072000) is there.

    Sleeping GPRS/EDGE cells are usually caused due to multiple reasons like Abis synchronization problems, BVCI in BL_SYS state, DAP mismatch, loading of BCSU/PCU combination that affect GPRS/EDGE. Alarm 7789 should also be monitored for observing No successful (E) GPRS transactions within the supervision period. It detects the lack of (E) GPRS traffic in UL or DL or both as per the parameters (EGIC, IEPH, SPL) settings. RTT (Round Trip Time)

    The Round Trip Time is the time required for a data packet to travel from a source to a destination

    and for its response to travel back to the source. It is a measure of the current delay on a network.

    Round Trip Time (ms) = (t data response packet received -- t data packet sent)

    For EDGE network the RTT should be around 400ms and for GPRS network it should be around

    600ms.

    Circle_name BSC_Name Site_Name Segment_Name Cell_ID Start_Date NBR_OF_DL_TBF NBR_OF_UL_TBF

    XYZ ABCD1 JJERU001 JJERU0011 2041-31851 3/ 12/ 2011 0 4348

    XYZ ABCD1 JJERU001 JJERU0013 2041-31853 3/ 11/ 2011 0 6597

    XYZ ABCD1 JJERU001 JJERU0011 2041-31851 3/ 13/ 2011 0 1604

    XYZ ABCD1 JJERU001 JJERU0012 2041-31852 3/ 11/ 2011 0 3177

    XYZ ABCD1 UC_KAPU001 UCKAPU0011 2041-17971 3/ 11/ 2011 0 5840

  • Formulas:

    Average UL TBF per timeslot (tbf_37d)

    Use: Indicates how many UL TBFs there are on average per timeslot.

    Sum (ave_ul_tbfs_per_used_tsl) / Sum(aver_tbfs_per_tsl_ul_den) * 100

    Average DL TBF per timeslot (tbf_38d) Use: Indicates how many DL TBFs there are on average per timeslot. Sum(ave_dl_tbfs_per_used_tsl) / Sum(aver_tbfs_per_tsl_dl_den) * 100 UL TBF releases due to CS traffic % (tbf_19a) Use: In GPRS the CS takes priority over the radio interface resources outside the dedicated territory. This KPI indicates the impact of CS traffic on PS (TBF drops) when radio interface capacity (TCH) is not sufficient and CS traffic takes the capacity from PS traffic by force. sum(UL_TBF_rel_due_CSW_traffic) 100* ----------------------------------------------------------------------------% sum(Nbr_of_UL_TBF-UL_TBF_Establishment_Failed-UL_EGPRS_TBF_REL_DUE_NO_RESP) DL TBF releases due to CS traffic % (tbf_20a) Use: In GPRS the CS takes priority over the radio interface resources outside the dedicated territory. This KPI indicates the impact of CS traffic on PS (TBF drops) when the capacity of radio interface (TCH) is not sufficient and CS traffic takes the capacity from PS traffic by force. sum(DL_TBF_rel_due_CSW_traffic) 100 * ---------------------------------------------------------------------------% sum(Nbr_of_DL_TBF-DL_TBF_Establishment_Failed-DL_EGPRS_TBF_REL_DUE_NO_RESP) UL mlslot allocation blocking, S9PS (tbf_15) Use: If the blocking is met regularly, there is a need either to expand the territory (CS traffic low) or TCH capacity (CS traffic high). sum(NO_RADIO_RES_AVA_UL_TBF) 100 * ------------------------------------------------------------------------- %

  • sum(req_1_TSL_UL+req_2_TSL_UL+req_3_TSL_UL +req_4_TSL_UL+ req_5_8_TSL_UL) DL mlslot allocation blocking, S9PS (tbf_16) Use: If the blocking is met regularly, there is a need either to expand the territory (CS traffic low) or TCH capacity (CS traffic high). sum(NO_RADIO_RES_AVA_DL_TBF) 100 * ------------------------------------------------------------------------- % sum(req_1_TSL_DL+req_2_TSL_DL+req_3_TSL_DL +req_4_TSL_DL+ req_5_8_TSL_DL) Network Data Busy Hour (DBH): This is the particular 1 hour in a day when there has been maximum generation of Data Payload in the network. Cell Data Busy Hour (Cell DBH): This is the particular 1 hour in a day when there has been maximum generation of Data Payload in the cell. Formula for calculating the Data Payload from the coding scheme distribution:

    Sum over MCS-n (UL_RLC_BLOCKS_IN_ACK_MODE

    +UL_RLC_BLOCKS_IN_UNACK_MODE +DL_RLC_BLOCKS_IN_ACK_MODE

    +DL_RLC_BLOCKS_IN_UNACK_MODE) * nn / 1024

    Total Data Payload Kbytes

    Sum over MCS-n (DL_RLC_BLOCKS_IN_ACK_MODE

    +DL_RLC_BLOCKS_IN_UNACK_MODE) * nn / 1024DL Payload Kbytes

    Sum over MCS-n (UL_RLC_BLOCKS_IN_ACK_MODE

    +UL_RLC_BLOCKS_IN_UNACK_MODE ) * nn / 1024UL Payload Kbytes

    (sum(RLC_data_blocks_UL_CS1*20 + RLC_data_blocks_UL_CS2*30+

    RLC_data_blocks_DL_CS1*20 + RLC_data_blocks_DL_CS2*30) / 1024Total Data Payload Kbytes

    (sum(RLC_data_blocks_DL_CS1*20 + RLC_data_blocks_DL_CS2*30) / 1024 DL Payload Kbytes

    (sum(RLC_data_blocks_UL_CS1*20 + RLC_data_blocks_UL_CS2*30) / 1024 UL Payload Kbytes

    EDGE Payload

    GPRS Payload

  • MCS coding scheme usage:

    DL MCS Coding scheme Utilization (MCS7, MCS8, MCS9) = NOM / DENOM Where, NOM= (DL_RLC_IN_ACK_MODE_MCS_7 + DL_RLC_IN_ACK_MODE_MCS_8 + DL_RLC_IN_ACK_MODE_MCS_9 + DL_RLC_IN_UNACK_MODE_MCS_7 + DL_RLC_IN_UNACK_MODE_MCS_8 + DL_RLC_IN_UNACK_MODE_MCS_9 + RETRANS_RLC_DL_MCS_7 + RETRANS_RLC_DL_MCS_8 + RETRANS_RLC_DL_MCS_9) DENOM = DL_RLC_IN_ACK_MODE_MCS_1 + DL_RLC_IN_ACK_MODE_MCS_2 + DL_RLC_IN_ACK_MODE_MCS_3 + DL_RLC_IN_ACK_MODE_MCS_4 + DL_RLC_IN_ACK_MODE_MCS_5 + DL_RLC_IN_ACK_MODE_MCS_6 + DL_RLC_IN_ACK_MODE_MCS_7 + DL_RLC_IN_ACK_MODE_MCS_8 + DL_RLC_IN_ACK_MODE_MCS_9 + DL_RLC_IN_UNACK_MODE_MCS_1 + DL_RLC_IN_UNACK_MODE_MCS_2 + DL_RLC_IN_UNACK_MODE_MCS_3 + DL_RLC_IN_UNACK_MODE_MCS_4 + DL_RLC_IN_UNACK_MODE_MCS_5 + DL_RLC_IN_UNACK_MODE_MCS_6 + DL_RLC_IN_UNACK_MODE_MCS_7 + DL_RLC_IN_UNACK_MODE_MCS_8 + DL_RLC_IN_UNACK_MODE_MCS_9 + RETRANS_RLC_DL_MCS_1 + RETRANS_RLC_DL_MCS_2 + RETRANS_RLC_DL_MCS_3 + RETRANS_RLC_DL_MCS_4 +RETRANS_RLC_DL_MCS_5 + RETRANS_RLC_DL_MCS_6 + RETRANS_RLC_DL_MCS_7 + RETRANS_RLC_DL_MCS_8 + RETRANS_RLC_DL_MCS_9

    For EGPRS Payload

    where n can be from 1 to 9 and nn is the multiplier for each Coding

    Scheme,i.e. RLC Data Block payload in bytes.

    nn for each MCS:

    MCS-1 22

    MCS-2 28

    MCS-3 37

    MCS-4 44

    MCS-5 56

    MCS-6 74

    MCS-7 56

    MCS-8 68

    MCS-9 74

    Value