PCU2 COMMNETS OSP APAC Matti Puhto MAY-05

1 (3)

PCU has the responsibility of all packet activities in BSS. The most important task for PCU is to perform RLC protocol between PCU and MS. All user data and all GMM signaling (for example GPRS attach) will use this protocol. This documents tells what kind of enhancements and changes there will be in PCU2, which is the second generation PCU. If you want to implement EQoS features, like admission control, you have to have PCU2 and S11.5 SW in given BSC. PCU2 hardware related changes: Pls note that PCU2 has totally new HW and SW structure on it, compared to PCU1 (which are in used to day). Current understanding is that PCU2 HW will be available on JAN-06, with in EQoS support. So, in other words: Nokias BSS will start to support Guaranteed bit rates beginning of 2006, naturally other elements i.e. MS and HLR and SGSN must support Guaranteed bit rates as well. An other important note: if you happens to have old version of PCU (PCU or PCU-S versions), the connectivity figure will go down when S11.5 is introduced. Technically this means: currently one PCU can handle up to 256 RTSL, but after S11.5 implementation this same PCU card (PCU or PCU-S) can handle anymore only 128 RTSL. This is important to take into account if your network happens to have large configuration cells (or typically large PSW territory in air interface) with old PCU HW. The other connectivity figures for PCU and PCU-S will re main as per today (upto 64 cells, upto 128 TRX which can be what ever mixture between EDGE and GPRS). EDAP planning is important: If you introduce EDGE, MS may have 8-PSK modulation in air interface, if the radio conditions are good enough (in typical case C/I >22dB). This new modulation introduces (RLC) data speed up to 59.2 kbit/s/RTSL (MCS-9). If user happens to have TBF with in MCS-9 this one user may eat upto 4 RTSL which means 4*(1+4) sub time slots in A-bis interface. This requires EDGE capable MS with relevant multiclass capability, and naturally PCU will make the final decision how many RTSL will be allocated to one TBF. Pls note that only GPRS capable MS will need one master channel and one slave from DAP pool. In non-EDGE (=GPRS only) environment one RTSL eats one sub slot from A-bis.

One important planning issue is to make appropriate EDAP pools to the network. PCU has internal 2 pcs of PCU-PCMs. This can not be seen nor touched by outsiders. Channel allocation is done independently by DSP which are having responsibility to reserve needed resources from PCUs internal PCU-PCM and further from A-bis interface. Practice has shown that in certain configurations, we may end up congestion in EDAP. Technically this means that one user (TBF) can not have as good service as C/I permits, since there may be a lack of adequate DAP resources. One component in this kind of unwanted scenario is current internal PCU implementation. In 2nd generation PCU card above mentioned negative impacts has been neutralised: each PCU card will have one SW module to handle both internal PCU-PCM allocation and DSP-load sharing within one

PCU2 COMMNETS OSP APAC Matti Puhto MAY-05

2 (3)

PCU card. This will bring more flexibility to PCU2 environment with in S11.5 SW level (expected availability JAN-06). How well my EDAP planning is done? The share of EDGE and GPRS mobiles If you happens to have statistic on mobiles IMEI you can estimate what will be GPRS mobiles impact to you EDAP planning. This IMEI info can be taken from (Nokias equipments) MSC/VLR or SGSN with relevant Traffica. Pricing of EDGE/GPRS service If your operator has introduced flat fee for packet activities, it will have a big impact to user behavior. Practice has shown that flat fee and some streaming content will increase dramatically network level payload figures. And naturally if you have high EDGE capable mobiles penetration this will put demands for adequate band with in A-bis interface (EDAP planning) as well. Some facts: - one PCU (1st generation) has 16 DSPs - one EDAP pool will served by one or several DSPs - one DSP can handle only one EDAP - one TBF is handled by one DSP and there fore by one EDAP one typical risk scenario: You are running out of master channels in your DSP. This is example: - say 5th DL TBF is created - DSP which handles this transaction is running out of master channels - DSP converts slave channels into master channels (EDAP utilisation (c76004) shows small figures) - Worst scenario: 4th TBF with MCS-9 will be downgraded to MCS-6 in order to find master channels for 5th TBF (counters (c76007 and c76008) will show that some TBF has not been enjoyed as good MCS as C/I permits (MCS-9==>MCS-6) PCU monitoring Keep on track how loaded you PCUs are. Network doctor #229 will give info on that. Number of PSW cells (max 64), number of PSW TRX (128 EDGE/GPRS) and number of RTSL (ava_44) this is naturally changing from hour to hour, the typical value is important (up to 256 RTSL). Pls note changes when implementing S11.5 to old 1st generation PCUs (PCU and PCU-S) 256RTSL==>128RTSL. You can not see PCU load level at the moment nor in S11.5. You will get some hints on PCU load level in two different ways: 1) PCU overload alarm #3164 (from S9 CD4.0 (12.16-0) onwards) Alarm on criteria: PCU makes internal load measurements in 500ms interval. When 5 consecutive samples are above this 95% (fixed) threshold PCU alarm will be set (#3164). Affect to existing TBF under affected PCU: RLC and therefore also application data speed will go down. PCU starts to convert real RLC blocks to empty RLC frames. This kind of activity will take PCU processor load down. Alarm off criteria: when load level is less than 80% for 5 consecutive samples 2) PCU load notification #0125 (from S11.5 onwards)

PCU2 COMMNETS OSP APAC Matti Puhto MAY-05

3 (3)

This is pre-notice that given PCU is busy and it may soon go even to overload, which means that users under this PCU will experience lower data speeds than expected. Notification on conditions: turn notification on in BSC (it is off by the def). When PCU have had 5 samples of PCU load more than 90%. Notification #0125 will be set. Pls note that this threshold is fixed and user can not modify this 90% threshold. Affect to users under this PCU: none Notification off condition: once this amount of seconds has gone without new notifications. Fixed 15 sec plus value of user set parameter of suspend_PCU_load_notification (0...254 sec).