HLD LTE Carrier AggregationHLD LTE Carrier Aggregation Document History Version Notes Author(s) Date 0.1 Working version Wim Ockeloen, Marco Meerten 0.8 Released draft version Wim Ockeloen, Marco Meerten, Bert 11 July 2014 Spoelstra, Dennis de Bruin, Rob Hekkens, Taco Amory, Peter Nijland, Jaap Bij. 0.9 Released draft version Wim Ockeloen, Marco Meerten, Bert 24 July 2014 1.0 Final version, updated LTE-CA SW Spoelstra, Dennis Bert Spoelstra, de Kanebi Francis Bruin, Rob 28 July 2014 design Update on PUCCH design, update Hekkens, Taco Amory, Peter Nijland, 1.1 Wim Jaap Ockeloen, Francis Kanebi Bij.Bert Spoelstra, Dennis de 7 August 2014 chapters 5 through 10. Bruin, Rob Hekkens, Taco Amory, Peter Nijland, Jaap Bij. Document Distribution Name Role Bas Hendrikx Program Manager Michel Lenoir Back-up Program Manager Ruud Koeyvoets Manager Access Engineering Hay Ritzen Manager Core Engineering Ralph Thijssen Lead architect Erik Kars Architect core Bogdan Mucuta Architect transmission Freek Mom Architect Classification C2 Page 1 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Matthias Sauder Head of network Carla Massini Manager Network Architecture Erik Slenter Manager Core deployment Jamal Tajaate Manager Access deployment Zoltan Pitman Technical Manager Dennis de Bruin Technical manager Francis Kanebi RAN design engineer Marco Meerten RAN , technical specialist Danny Wesselingh RAN , technical specialist Robert van Muijen RAN , technical specialist Taco Amory Technical architect, core engineering Peter Nijland Technical architect, core engineering Jaap Bij Technical architect, core engineering Raymond Keerssemeeckers Technical architect, core engineering Frank Jansen Technical architect, core engineering Guido Baltus Lead designer, high level design Roger Ruland TCM data Rob Driessen FMC support specialist Dave Boonstra SMC expert Rob Hekkens Ericsson, Technical architect, core engineering Bert Spoelstra Ericsson, Technical architect, RAN engineering Jan Dijkstra Ericsson, test manager Wim Bos Ericsson, MSIP Joris van Eldik Ericsson, project manager Luuk Fiddelers Ericsson, project manager Maurice Sormani Ericsson, deployment manager Grigorios Vourekas Ericsson, technical manager Herman Smeets Ericsson, technical manager Christ van den Bergh Ericsson, technical manager Classification C2 Page 2 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 1. Executive Summary The purpose of this document is to provide the high level design for the LTE Carrier Aggregation roll-out project. The document describes the goals and the scope, the technical solution and the operational impacts. LTE Carrier Aggregation, being one of the major functionalities of the LTE Advanced Rel. 10 portfolio, will further increase the end user data rates. Given the VF-NL spectrum situation, theoretical maximum data rate of 225 Mbps could be realised. With an LTE-CA capable terminal, the customer can make simultaneously make use of LTE800 and LTE1800 spectrum in the downlink. LTE-CA will therefore be deployed on the majority of sites equipped with these 2 frequency bands. First Amsterdam, Rotterdam, Den Haag and Utrecht will be covered, followed by 50 towns by end 2014. The LTE-CA design comprises RAN hardware, RAN Software, Transmission and Core network parts. In order to make LTE-CA work, first the enode-Bs need to be made HW capable followed by a SW feature activation. Meanwhile dependencies with new LTE SW releases (L13B and L14A) will be managed. In the transport network the link capacity need to be upgraded to meet maximum throughput requirements. In the core network the right provisioning needs to take place, In addition there is a dependency with MME SW R14 B roll-out that solves the QoS stickiness issue, which until then limits the speeds to 84 Mbps in case a user makes a location update in 3G. Classification C2 Page 3 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Contents 1. Executive Summary ........................................................................................................ 3 2. Introduction ................................................................................................................... 7 3. Goal & Scope ................................................................................................................. 7 3.1 Goal...................................................................................................................................7 3.2 Scope ............................................................................................................................. 78 3.2.1 In Scope ..................................................................................................................... 78 3.2.2 Out of Scope ..................................................................................................................8 3.3 Dependencies ....................................................................................................................8 3.4 Assumptions ......................................................................................................................9 3.5 Risks..................................................................................................................................9 3.6 Deliverables .......................................................................................................................9 4. Solution Description .....................................................................................................10 4.1 High level solution description and dependencies ............................................................ 10 4.2 Design overview .............................................................................................................. 11 4.3 High Level Designs for making the enode-B LTE-CA HW capable ....................................... 12 4.3.1 Design for RBS reconfiguration .................................................................................... 12 4.3.2 HLD for Dual band DUS deployment [Marco Meerten]................................................... 13 4.3.3 HLD for DUS41 introduction ........................................................................................ 17 4.3.4 HLD for redeployment of DUL20 and DUS31 into Spring roll-out ................................... 17 4.3.5 PUCCH Description [Francis Kanebi] ............................................................................ 17 4.4 High Level Design for carrier aggregation SW functionality [Bert Spoelstra] ................... 2223 4.4.1 LTE Carrier Aggregation Introduction ....................................................................... 2223 4.4.2 Scope ..................................................................................................................... 2728 4.4.3 Feature Description: FAJ 121 3046, Carrier Aggregation ............................................. 28 4.4.4 Use Cases ............................................................................................................... 5358 4.4.5 Test Plan ................................................................................................................. 5358 4.4.6 Network Performance Indicators .............................................................................. 5459 4.4.7 Operational readiness ............................................................................................. 5762 4.5 High level design for increasing the LTE spectrum from 15 to 20 MHz ............................ 5863 4.6 High Level Design Access Transmission upgrade [Dennis de bruin] ............................... 5863 4.6.1 Microwave links ...................................................................................................... 5863 4.6.2 Physical port capacity.............................................................................................. 5863 4.6.3 PTN network capacity .............................................................................................. 5863 4.7 Impact analyses EPC other & IP GW and Core............................................................... 5964 4.7.1 SGSN/MME [Rob Hekkens]: .................................................................................... 5964 Classification C2 Page 4 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.7.2 SGW/PGW [Taco Amory]:......................................................................................... 6065 4.7.3 PCRF [Taco Amory]: ................................................................................................. 6065 4.7.4 HSS/HLR technical solution for providing max bit rates [Jaap Bij] ............................. 6065 4.7.5 MSP [Peter Nijland]: ................................................................................................ 6065 4.7.6 GRX interface [Erik Mattheij]: ................................................................................... 6066 4.7.7 GRX firewall [Frank Jansen] and LAN-taps: ............................................................... 6166 4.7.8 Wireless Security Gateway [Raymond Keerssemeeckers]: ......................................... 6166 4.7.9 End to end testing impact [Michel van Kan] .............................................................. 6166 4.8 High level test set-up design for E2E performance testing ............................................. 6166 4.8.1 Verification of the maximum throughput in ideal radio circumstances ....................... 6166 4.8.2 Live network trial for verification and characterisation of the live network performance 6167 5. Impact on network quality and KPIs ......................................................................... 6267 6. Security .................................................................................................................. 6267 7. Service Layer Impact ............................................................................................... 6267 7.1.1 Billing [Guido Baltus]: ............................................................................................. 6267 8. Process and Guideline impact ................................................................................. 6368 9. Operations .............................................................................................................. 6369 9.1 Network Management System ..................................................................................... 6369 9.2 Operational Support Systems ...................................................................................... 6469 9.3 Performance Management .......................................................................................... 6469 9.3.1 Technology Chain Management & Life Cycle Management ....................................... 6469 9.3.2 ENN performance management ............................................................................... 6570 9.3.3 Capacity Management ............................................................................................ 6570 9.3.4 SLA Monitoring ....................................................................................................... 6570 9.4 Tooling ........................................................................................................................ 6570 9.5 Fault Management ...................................................................................................... 6671 9.5.1 Element Management ............................................................................................. 6671 9.5.2 Service Management............................................................................................... 6671 9.6 Incident Management ................................................................................................. 6671 9.7 Problem Management ................................................................................................. 6671 9.8 Configuration Management ......................................................................................... 6672 9.9 Field Management ...................................................................................................... 6672 9.10 Spare Parts Management ............................................................................................ 6672 10. Implementation................................................................................................... 6772 10.1 Dual-band DUS introduction: ....................................................................................... 6772 10.1.1 Testing in VTC ..................................................................................................... 6772 Classification C2 Page 5 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 10.1.2 Pilot in Live Network ............................................................................................ 6772 10.1.3 Testing in Live Network ........................................................................................ 6772 10.1.4 Deployment in Live Network ................................................................................ 6772 10.2 Testing in VTC for LTE-CA SW introduction .................................................................... 6772 10.2.1 Test Object List (TOL) ........................................................................................... 6873 10.3 Pilot in Live Network .................................................................................................... 6873 10.4 Testing in Live Network ................................................................................................ 7075 10.5 Deployment in Live Network ......................................................................................... 7075 10.6 Deployment in Live Network ......................................................................................... 7075 10.7 Completing Actions ..................................................................................................... 7076 11. Disaster Recovery & 24/90 ................................................................................. 7076 12. Training ............................................................................................................... 7076 13. High Level Project Plan ........................................................................................ 7076 14. Contact Information ............................................................................................ 7076 15. Main Contributors per Document Section ............................................................. 7176 16. Glossary .............................................................................................................. 7177 17. References .......................................................................................................... 7278 18. Appendix............................................................................................................. 7278 Classification C2 Page 6 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 2. Introduction The purpose of this project is to introduce the LTE Carrier Aggregation functionality in the Vodafone NL network. LTE CA is one of the major functionalities of LTE Advanced. With LTE CA is it possible to combine simultaneously use two LTE frequency bands for the end user, which creates an increase in user throughput. End user throughput is used in Marketing campaigns as a differentiator for choosing Vodafone 4G. The LTE-CA functionality will be marketed as 4G+, which provides a theoretical maximum of 225 Mbps. Vodafone wants to be the front runner in providing the 4G+ coverage in the Netherlands. As KPN also announced the roll-out of LTE-CA as well, timelines for Vodafone 4G+ roll-out are ambitiously set. For Vodafone NL this means LTE800 (10 MHz) and LTE1800 (15 followed by 20 MHz) bands can be used simultaneously by the end user. 3. Goal & Scope 3.1 Goal The goal is to introduce LTE-CA in the network in the following areas: Prio 1 (August 2014): Amsterdam Prio 2 (September): Den Haag, Rotterdam and Utrecht Prio 3 (October): Schiphol+ business park Hoofddorp, Leiden (partly), Delft, Maastricht, Eindhoven, ‘s-Hertogenbosch Prio 4 (December): in total 50 towns. The sites for Prio 1,2 and 3 have been identified by site ID and are in scope for the LTE-CA project. A frozen list has been created that is used to define the scope on site level. The frozen list contains 358 sites, but this number can vary slightly in case some sites appear not to be feasible. The sites for Prio 4 are still to be defined and will be added to the frozen list in a later stage. Bandwidth and Speed: • Bandwidth: 2x10MHz (800) + 2x15MHz(1800) followed by 2x20MHz (1800), • Maximum single user / single sector speed within ideal radio circumstances: 225Mbps (in case of 10+20 MHz, otherwise 175 Mbps) • Practical speeds will be less depending on the radio network coverage and load. In average radio conditions end-user speeds of 75-125 Mbps (10+20 MHz) are expected. This has to be verified by live network testing. • TX should be able to deliver at least 225Mbps; The timing for upgrading the transmission network capacity will lag behind the access network roll-out, because of the lead times for transmission capacity upgrades. 3.2 Scope 3.2.1 In Scope Classification C2 Page 7 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation The following activities are in scope of the project: RBS reconfigurations for dual-band support RBS dual band functionality introduction DUS41 introduction Making a re-use plan for the DUL20/DUS31 that are retuned LTE-CA SW feature introductions Transmission upgrades HSS provisioning adaptions to support max bit rate All live LTE800+LTE1800 sites will be made LTE-CA hardware capable. Operational implementation for performance management, configuration management and fault management. Spectrum refarming to provide LTE1800 with 20 MHz. 3.2.2 Out of Scope LTE2600 CA Uplink CA 40 MHz CA and all other CA combinations other then 10+20MHz and 10+15MHz Cross-Carrier Scheduling VoLTE evolved Multimedia Broadcast and Multicast Service deployment (eMBMS), which provides an efficient and low-cost solution to deliver common multi-media content (one to many transmission) Small cells Other LTE-A functionality, such as LTE relaying, 4x4MIMO or beyond Capacity management (Access, Core & Transport) Investigation for dual band introduction for AIR21 or AIR32 with LTE1800 on the active part with respect to 4 branch diversity and single or dual DUS31/41 operation. New configurations beyond spring. New customer SOX (price plans) development (in scope for Marketing) Billing and IT upgrades OSS/RC upgrades 3.3 Dependencies The project has the following dependencies: L13B SW roll-out to enable dual band DUS support L14A SW roll-out to enable LTE-CA with 10+15 MHz MME-SGSN SW upgrade to support max bit rate OSS/RC R14B is officially required to support MME/SGSN R14B. OSS/RC is still to be implemented in the network. Phasing out GSM1800 sites (in order to free up spectrum for LTE1800) Classification C2 Page 8 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 3.4 Assumptions End-2-end testing will be done for the spectrum bandwidth: 2x10MHz (800) + 2x20MHz (1800). With this spectrum the maximum throughput in an unloaded network and under ideal radio circumstances should be 75+150 = 225Mbps; If the available spectrum for LTE1800 is 15 MHz , then the LTE-CA will go live with 10+15 MHz. LTE-CA will be available for all LTE enabled subscribers, including MVNO and roamer subscribers. However a max bitrate limitation differentiation will be used for different subscriber groups. VoLTE not introduced Microwave equipment supporting 8 queues is installed at site locations where LTE-CA will be deployed 3.5 Risks Capacity bottlenecks in the IP RAN transport network will limit the maximum achievable throughput for the end-user. Solving the capacity bottlenecks in the IP RAN transport network is in scope of this document, but it is likely that not all required capacity upgrades will be ready at the launch date of LTE-CA for the particular priority area. Capacity bottlenecks in the Core network will limit the maximum achievable throughput for the end- user. Solving the capacity bottlenecks in the core transport network is not in scope of this project, because the capacity bottlenecks are general capacity bottlenecks in the 3G+4G PS Core network and are related to the data growth in 3G and 4G. Mixed mode operation between LTE1800 and GSM in combination with LTE-CA is a complex configuration. If this configuration is not possible, then a small amount of sites (between 10-20) cannot be realised with LTE-CA. 3.6 Deliverables After the HLD the project should deliver the following concrete deliverables: LLD documents (Updated) process descriptions Implemented tooling where needed Introduction documents Updated RAN parameter files. Updated Access Transmission Rules & Guidelines Handover documentation to network operations (NOC, Field, CM) Test plans and test reports Implemented Change Requests in spring modernization for DUL20/DUS31 redeployment and dual band operation from single DUS. Classification C2 Page 9 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4. Solution Description 4.1 High level solution description and dependencies This paragraph provides an overview of the LTE-CA solution. For the functional introduction the following technical requirements should be fulfilled: The enode-B should be HW capable for LTE-CA: o The site should be equipped with both LTE800 and LTE1800. Radio units of each frequency band should be connected to the same Digital Unit. The DU should be either of type DUS31 or DUS41, the older DUL20 does not support LTE CA and thus needs to be replaced. o In order to control both LTE800 and LTE1800 from DUS, existing sites have to be reconfigured. In most cases this requires the swap of 2 DUL20 for 1 DUS41. For macro sites this also requires redistribution of the radio units over the cabinets. o The DUS41 has to be introduced. o Although not technically required, the DUL20s need to be re-used in new to-be modernised sites. This reduces the CAPEX needed for the combination of LTE-CA and Spring modernization. The enode-B should be SW capable for LTE-CA: o In order to support the make the enode-Bs HW capable (ie. dual-band DUS operation) L13B SW is required on the enode-Bs. The SW upgrade is a dependency to this project. o Next, the make the SW level at the enode-Bs is again to be upgraded to L14A. The SW upgrade is a dependency to this project. o The final step in to enable to optional SW feature LTE carrier aggregation at the enode-Bs The backhaul should be capable for handling the maximum bit rates. In order to upgrade the backhaul capacity or more of the following changes could be required (varies per site): o No change needed (the case with dark fibre connected sites) o Upgrade microwave capacity from 170 to 340 Mbps by using more spectrum o Exchange the type of microwave o Change the microwave path and replace the microwave o Deploy FTTS, either from Eurofiber or KPN leased fibre. o The PTN port capacity should be 1Gbps or more. All 100 Mbps ports needed to be upgraded. Most sites in the 4 largest cities already have a 1GBps interface. Without the backhaul upgrades LTE-CA functionality will still work, but there is a chance the maximum data rates cannot be met. The HSS should support max bit rate settings for the customer groups that have LTE-CA enabled. The SGSN/MME SW release should be upgrade to R14B in order to solve the “QoS Stickiness” present in the current SW release. o QoS stickiness: when the UE performs a Location Area Update (LAU) to 3G it takes over the max bit rate QoS setting from 3G, which is set at 84 Mbps. When the UE returns to LTE this max bit rate value is kept instead of updated with a value from the HSS. In the current LTE implementation the limit of 84 Mbps is not a limitation, but it will be when higher speeds are required. Classification C2 Page 10 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation o Without the SW release update data rates above 84 Mbps can only be established when the user does a network attach at 4G. o To enable a fast SW upgrade to R14B, first only the SW upgrade will be performed and the new SW features that come with R14B will be introduced later. The end-2-end network chain from UE to the internet should be able to support end user data rates up to 225 Mbps. o First an impact analysis will be performed to investigate if any bottlenecks are present in the end-2-end chain. o End-2-end testing should be performed to test the maximum bit rate capability. Various transmission configurations should be tested. o The idea is first to use the enode-B @VTC and connect this to the live EPC. In the VTC ideal radio circumstances can be simulated needed for reaching the maximum throughput o When successful the end to end testing should be performed in the live network on several site locations, connected via several enode-B HW configurations, transmission configurations, Mobile SecGWs and MMEs. 4.2 Design overview The LTE CA design consists of a number of sub designs for the individual parts. The overview of these designs is shown in figure xxx below. Every sub-design will be described in a separate paragraph in this chapter. In order to check if everything works as required end to end testing of the LTE-CA functionality with max bitrate testing will be performed. The test configuration will be described in this chapter and the test cases in the high level test plan, see chapter 10. Classification C2 Page 11 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Schematic overview of LTE-CA design components. Red parts are performed by Vodafone, Blue parts by Ericsson and Grey parts are indicating a dependency project. 4.3 High Level Designs for making the enode-B LTE-CA HW capable 4.3.1 Design for RBS reconfiguration This design will be made by Ericsson. The following site mix applies for roll-out priority 1,2 and 3: roll-out prio 2xMacro outdoor 11 2xMMC 221 MSMM - 2xMMC 75 MSMM - MMC/macro outdoor combi 10 MSMM - 2xMacro outdoor 3 2xMacro indoor 2 MMC/Macro outdoor combi 33 MMC/Macro indoor combi 2 MSMM - MMC/macro indoor combi 1 Grand Total 358 Classification C2 Page 12 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation MS-P212 Swap project for CA prepared Rev B.PDF The scope for this design is documented in the following offer: 4.3.2 HLD for Dual band DUS deployment [Marco Meerten] Dual band operation requires two features to be introduced; both are included in this HLD: 6 Cell Support, in order to operate 6 sectors from a single DUS31/41 Cascadable Radio Units, in order to operate 12RU 4.3.2.1 6 cell support Limitations caused by 6 cell support There are limits wrt to 4 branch diversity, but this is out of scope. Feature description The 6 Cell Support feature offers reduced equipment cost by controlling six cells with one DU in one RBS node. The capacity of the DU can be fully used with six-sector single carrier configurations. One DU can carry the traffic of up to six cells. In dual band scenarios, one single DU can control three sectors in each band. Figure 1Figure 1 shows the operation example. Figure 1 Carrier Mapping Licensing A license is required to operate 6 cell support. If the license is not present, a 6 cell configuration will be accepted from the DU, but only 3 cells can be unlocked. SW dependencies The function of the six cell feature is depending on the SW level: the following is supported: Classification C2 Page 13 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation L13A: 10MHz_800 + 10MHz_1800 L13B: 10MHz_800 + 20MHz _1800 L14A: as L13B. We need L13B as a minimum. PUCCH dimensioning needs to take place. Unlocking of cells can be rejected because of shortage of PUCCH resources. This results in a ResourceConfigurationFailure alarm. Required and available PUCCH resources for a cell depend on the following: Number of cells per node Cell bandwidths Setting of the parameters pdcchCfiMode, noOfPucchCqiUsers, and noOfPucchSrUsers Managed Object structure for Support6Cells The Support6Cells is a system created MO. It is only affecting the license for 6 cells support (so no details description here). 4.3.2.2 Cascadable Radio Units Limitations caused by “cascadable Radio Units” features Impact on traffic: a restart of a RU causes the chained RU to go out of service shortly. There are no other limitations. • MM: SW dependencies: There is a bandwidth limitation on the CPRI interface. In L13A only 20MHz in a cascaded chain can be supported. In L13B up to 40MHz in a chain is supported, so we need L13B. Feature description The Cascadable Radio Units feature enables cascading of two to six Radio Units (RU) per Common Public Radio Interface (CPRI) link. Mixed mode operation One Mixed Mode radio and one single mode radio can be connected in a cascade chain. This configuration allows one standard to use different frequencies, and also to reduce equipment costs and simplify the antenna equipment setup. (DUG gets sync from DUS31/41). As the present sites in the network operate on mixed mode, these sites will remain on mixed mode after reconfiguring for DUS31/41 Dual band. Mixed mode has been introduced, but based on intra sector cascading. This means that cascading takes place within a sector: so from a sector branch A and branch B are cascaded. However, in this dual band scenario, this is not possible any more. We need 2 RU per sector for GSM1800 in order to keep the power balanced for LTE. If a single RU would be used, it can happen that LTE branch A has for instance 60Watt available and branch B 80Watt. By using 2 RU this is avoided. However a new cascading method needs to be introduced: inter sector cascading. This means that in each cascaded chain, two sectors are present (single branch), so the 800 and 1800 RU are in a chain. If a TMA is deployed for 1800MHz, LTE will be the controlling technology for the TMA. In GSM the TMA is filled in as external TMA without any control. So only the radio parameters need to be filled in. This is according the current mixed mode operation instructions. Classification C2 Page 14 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation The following configurations can be expected and must be introduced and verified with testing at VTC: Mixed mode in macro cabinet, see Figure 2Figure 2, for RRU setup see Figure 3Figure 3. Figure 2 Mixed mode GSM/LTE 1800MHz macro config Figure 3 Mixed Mode GSM/LTE 1800 RRU Managed Object structure for class RadioUnitCascading The RadioUnitCascading is a system created MO. It is only affecting the license for cascaded support (so no detailed description here). Digital and Radio Building block. Detailed design must provide the exact DBB and RBB for all used configurations, that is, the 333 batch, quick track and spring config 1 to 8, for all RU, RRU and AIR mixed configurations. An overview must list all the different variants, their DBB and RBB (wiring), including the mixed mode sites. Mixed mode configurations should be designed in a way both 1800 Radios use GSM TRXes. So if a sector uses 2 1800 TRXes each RU (branch) should get 1 GSM TRX in order to balance the power. This way most RF power remains available to LTE. 4.3.2.3 Impact Analysis X2 interface requirements & capacity planning: fewer interfaces are required compared to sites with 2x DU. No interaction of X2 signalling inter-eNB, intra-site location due to IPSEC but now this signalling is kept internal! X2 should go up- and down to SeGw in the inter-eNB case even when it concerns the same site location. Classification C2 Page 15 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Handover procedure between bands changes (other way of X2). o No impact foreseen Sync planning: o MM:Amount of PTP sync sources required in the network becomes half for single DUS dual band sites. There is no further impact. If a DUL20 is disconnected the sync resource is just released. (Source: Dennis de Bruin). • IP Planning o MM:Currently there is one pool of IP-addresses, within this pool there are addresses reserved for DUS 800MHz, 1800MHZ and 2600MHZ. In case of a dualband site, the site should be given an ip address that was currently reserved for the 800MHz DUS. As 1800 is located in the same DUS, there is no other IP address required. The SIU will get one IP connection less, as there is only one connection to the DUS required (which handles both 800 and 1800). (Source: Marc Straat). Security impact. 800 and 1800 have different certificates o IPSec tunnels originate for the DU to the SecGW and every DU has at this moment one IPsec for S1/X2 and one for OAM. Depending on the capabilities of the DU should combining 800 and 1800 not be a problem. Also when working with Certificates, One DU entity can have multiple certificates and are accepted by the SecGW certificate since they use the same root-CA. (Source: Raymond Keerssemeeckers) o SIU: only one DU connected, Script changes may be required o O&M: one O&M connection for both 800 and 1800. • Impact on Maximo and inventory tools. Definition and sector numbering (source Danny Bruinen) Impact is mainly in Phoenix administration. The Digital unit is currently administrated in Phoenix Equipment field per technology. So f.e. for LTE0800 there is one DUL20 or DUS31/41 specified. Not on cell level. With introduction of DUS31/41 this needs to be done on cell level, and we need to define extra columns to administrate what physical DU is present and what port of that DU is used for that specific technology. Current situation: Equipment table Phoenix: LTE0800 DUL20 LTE1800 DUL20 New situation: Equipment table Phoenix: LTE0800 DUS31 Ref: A Port: BAND1 LTE1800 DUS31 Ref: A Port: BAND2 Impact extra columns in Phoenix equipment table: Classification C2 Page 16 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Reference (Physical id) Port (DUS31 has 2 sets of connections for 2 technologies) Impact on Phoenix code (application on Mynetwork Portal). No impact on maximo as this is only LTE related. • Integration procedures for field and CM. Integration procedures need to be updated and handed over to CM. Field needs to receive an updated version of the relevant integration manuals • KPI’s. No impact for seen. • Documents The following documents need to be updated: Installation manuals, Integration manual, RBS 6000 family document updated with dualband config. Impact on OSS-RC and site naming must be determined. Both 800 and 1800 network share the same DUS31/41, so are not separate eNodeB anymore. It must be possible to identify if cell has standalone DU or is shared with the other LTE frequency. 4.3.3 HLD for DUS41 introduction The design will be made by Ericsson. For the scope please see the offer inserted in paragraph 4.3.1 4.3.4 HLD for redeployment of DUL20 and DUS31 into Spring roll-out The design will be made by Ericsson. For the scope please see the offer inserted in paragraph 4.3.1 4.3.5 PUCCH Description [Francis Kanebi] The PUCCH shall be mapped to a control channel resource in the uplink. A control channel resource is defined by a code and two resource blocks, consecutive in time, with hopping at the slot boundary. Depending on presence or absence of uplink timing synchronization, the uplink physical control signaling can differ. In the case of time synchronization being present, the out band control signaling consists of: o Channel status reports, Channel Quality Indicator (CQI) and Rank Indicator(RI) o Hybrid Automatic Repeat Request (HARQ) Acknowledgement/Negative Acknowledgement (ACK/NACK) o Scheduling Request (SR). The CQI informs the scheduler about the current channel conditions as seen by the UE. If MIMO transmission is used, the CQI includes necessary MIMO-related feedback. The HARQ feedback in response to downlink data transmission consists of a single ACK/NAK bit per HARQ process. PUCCH resources for SR and CQI reporting are assigned and can be revoked through RRC signaling. An SR is not necessarily assigned to UEs acquiring synchronization through the RACH (i.e. Classification C2 Page 17 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation synchronized UEs may or may not have a dedicated SR channel). PUCCH resources for SR and CQI are lost when the UE is no longer synchronized. Location of PUCCH resources are on the edge of bandwidth allocated, the reason is to assign the contiguous RBs to single terminal for PUSCH data transmission along with increased frequency diversity experience by control signalling. The information sent on PUCCH uses one RB in each of the two consecutive slots in a subframe and hence called resource block pair (RB –pair). The information sent on PUCCH can be sent in one of the two formats mentioned below: o PUCCH Format 1 for SR and HARQ ACK/NACK o PUCCH Format 2 for CQI and RI The parameters noOfPucchCqiUsers and noOfPucchSrUsers determine the number of resources for CQI and SR per cell. To maximize PUSCH throughput, the number of RB-pairs should not be over-dimensioned. An even number of RB-pairs is preferable, as an odd number will leave one RB-pair unused by both PUCCH and PUSCH. 4.3.5.1 SR & CQI Parameter Limitation When performing the calculation for the parameters noOfPucchCqiUsers and noOfPucchSrUsers the below limitations are considered: o Maximum allowed value of noOfPucchCqiUsers and noOfPucchSrUsers per cell. o Maximum number of RB pair used for PUCCH per DU The below table 1 shows the Maximum allowed value of noOfPucchCqiUsers and noOfPucchSrUsers In the current release L14A noOfPucchCqiUsers and noOfPucchSrUsers are both hard coded to 32 in RBS6401. Classification C2 Page 18 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation The value of maximum noOfPucchSrUsers in the Table assumes default setting of commonSrPeriodicity (the default value 10) and that carrier aggregation is not used. In VF-NL this parameter is set to 5 in most case, except for event sites where is set to 10. If a cell is considered as a primary cell in carrier aggregation, maximum noOfPucchSrUsers must be adjusted, if and only if the cell fulfills the CA criteria as a primary cell. Refer to the appendix for the equation used for Adjustment of Maximum Allowed Value of SR Resources per Cell. 4.3.5.2 Maximum number of RB pair used for PUCCH per DU Table 2 Maximum Number of RB Pair Used for PUCCH per DU For some configuration ,considerations needs to be taken before calculating resource consumption: Combined Cell In case of combined cell, noOfPucchSrUsers and noOfPucchCqiUsers are set on cell level, that is the PUCCH configuration will be the same for all sector carriers. As each sector carrier will require its own PUCCH RB pairs, each sector carrier shall here be viewed as a separate cell. For example a DU configured with three combined cells each with two sector carriers and a DU configured with six cells will use the same amount of RB pairs assuming the same parameter setting and bandwidth. Different bandwidths In a DU configured with cells using different bandwidths, noOfPucchSrUsers and noOfPucchCqiUsers can be set differently per bandwidth. The settings of noOfPucchSrUsers and noOfPucchCqiUsers must be chosen so that the total number of RB pairs used for PUCCH in the DU does not exceed the maximum number of RB pairs. Different number of RX antennas If cells with different number of RX antennas are configured in a DU, the highest number of RX antennas used in a cell should be chosen for the maximum number of RB pairs. Classification C2 Page 19 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.3.5.3 PUCCH Capacity in DU The number of available PUCCH resource that can be simultaneously allocated to a UE is limited by the DU, but this doesn’t limit the setting of noOfPucchCqiUsers and noOfPucchSrUsers. These resources are pooled within a DU, which implies that the number of resource can vary per cell, and the more cells configured decrease the number resource available. In the case of 6 cells the number of SR resources that can be allocated in a DU will decrease as compared to 3 cells. The table 3 below with the equation 1 describes the maximum number of SR and CQI resources that simultaneously can be allocated to UE in a DU. Table 3 Maximum Number of Allocated SR and CQI Resources per DU Equation 1 Adjustment of SR Resources per DU The x, y, z and w in Table 3 indicate that the maximum number of SR resources depends on the number of configured cells ncells. As a number of HARQ resources need to be reserved for each cell configured in the DU, the number of SR resources that can be allocated in a DU will decrease if more cells are configured in a DU. x, y, z and w are calculated by using Equation 1. Where nSR,PUCCH - is the number of subframe with PUCCH, equal to 9 for 1.4 MHz otherwise 10. The number of SR resources per DU given by Table 3 and Equation 1 assumes the default setting of commonSrPeriodicity. In case commonSrPeriodicity is changed, the SR resource per DU calculated by Classification C2 Page 20 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Equation 2 Adjustment of Maximum Number of Allocated SR Resources per DU Where nSR,DU,max - is the maximum number of SR resources per DU in Table 3 after adjustment by w, x, y or z. TSR - is the periodicity for SR in milliseconds, specified by operator parameter commonSrPeriodicity. Default value is 10 ms. Note Be aware when changing this parameter, it only becomes effective after a CELL LOCK / UNLOCK action. Only three settings are possible for parameter “commonSrPeriodicity” commonSrPeriodicity = 10 { 5, 10, 20 } Common SR periodicity, used for all UEs. Unit: 1 ms Dependencies: For 1.4 MHz: Only valid inputs are 10 and 20. Takes effect: Cell lock/unlock In a nutshell the impact of PUCCH on 6 cell will be the number of available resource allocated per DU will decrease and also based on the periodicity value used. As an example using the formula: Z = Min (48,8 * ncells) * nSF,PUCCH Z= 8 * 6 * 10 = 480 2440 - 480 =1960 (The available resouce for SR per DUS 41) In VF-NL the periodicity is set to 5 which is different from the default value used in this formula, in that case Equation 2 will be applied nSR,DU = nSR,DU,max * TSR/10 = 1960 * 0.5 = 980(The available resouce for SR per DUS 41). NB. Based on this, recommended to set the commonSrPeriodicity to 10, to increase the number of resource available per DU. 4.3.5.4 Impact analysis on 6 cells and carrier aggregation 4.3.5.4.1 IMPACT ON 6 CELLS If 6 cells are configured the number of SR resources allocated in a DU decreases, though the available resources also depends on the Common SR periodicity settings as shown in the expample above. Note The number of available PUCCH resource that can be simultaneously allocated to a UE is limited by the DU, but this doesn’t limit the setting of noOfPucchCqiUsers and noOfPucchSrUsers Classification C2 Page 21 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.3.5.4.2 IMPACT ON CARRIER AGGREGATION In the case of carrier aggregation from the formula (Refer to the appendix) number of HARQ resources reserved for carrier aggregation is set to 8 if a cell is considered as a primary cell in carrier aggregation, otherwise 0. This implies that when CA is configured as a primary cell , more resource blocks are allocated for PUCCH on that cell, thus impacts on the maximum noOfPucchSrUsers as mentioned in 4.3.5.1 Applying the formula in the attached appendix regarding the maximum number of noOfPucchSrUsers., the below table shows an overview. CA Max noOfPucchSrUsers commonSrPeriodicity Harq noOfPucchSrUsers 0 160 5 8 120 320 0 320 10 8 240 0 NA 5 8 NA 600 0 600 10 8 520 0 NA 5 8 NA 810 0 810 10 8 730 Table 4 Maximum noOfPucchSrUsers related to LTE-CA. The values for noOfPucchSrUsers based on VF-NL settings (320 & 600 ), while 810 is Ericsson recommended maximum value that can be set per cell. VF-NL recommendation will be to set the parameter commonSrPeriodicity to 10 across the network in order to increase capacity, though this will have an impact on latency. Note Even though is possible to provide each cell with the maximum number of users, the resources are limited by the DU, since a limited resources can be scheduled per subfame. The customer experience during a busy cell could be that they are able to access the cell but would experience delay due to the resouce limitation which could impact on througput. 4.4 High Level Design for carrier aggregation SW functionality [Bert Spoelstra] 4.4.1 LTE Carrier Aggregation Introduction Classification C2 Page 22 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation LTE Advanced offers considerably higher data rates than the initial releases of LTE. The method being proposed to achieve these very high data rates is known as carrier aggregation (CA) or sometimes as channel aggregation. Using LTE Advanced carrier aggregation, it is possible to utilize more than one carrier and in this way increase the overall data rates. Basically Carrier Aggregation (CA) is used to increase the bandwidth by combining several carriers, and thereby increase the peak bitrates. Figure 4: CA aggregates bandwidth of separate carriers The benefit of the Carrier Aggregation feature is that it enables data to be transmitted on two bands simultaneously to a single User Equipment (UE). The main benefits of Carrier Aggregation are: Increased downlink speed across the coverage area More efficient use of scattered spectrum Higher capacity The figure below present a graphic illustration of the drivers for potential LTE-CA deployment in a mobile network, such as the VF-NL network. However for the VF-NL case the TD-LTE argument is not applicable. Figure 5: Graphic illustration of driver for LTE - CA deployment These channels or carriers may be in contiguous elements of the spectrum, or they may be in different bands also known as “Intra-band aggregation, contiguous cells”, “Intra-band aggregation, non-contiguous cells” and “Inter-band aggregation”. For LTE-CA deployment in the VF-NL network only the latter scenario does apply which is the “Inter-band aggregation”. Classification C2 Page 23 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Figure 6: Possible intra- and inter-band CA possibilities The “Inter-band aggregation” form of carrier aggregation uses different bands. It will be of particular use because of the fragmentation of bands - some of which are only 10 MHz wide, like the LTE800 carrier in the VF-NL network. For the UE it requires the use of multiple transceivers within the single item, with the usual impact on cost, performance and power. In addition to this there are also additional complexities resulting from the requirements to reduce intermodulation and cross modulation from the two transceivers. The current standards allow for up to five 20 MHz carriers to be aggregated, although in practice two or three is likely to be the practical limit. These aggregated carriers can be transmitted in parallel to or from the same terminal, thereby enabling a much higher throughput to be obtained. The matrix below shows the expected impacts on terminal complexity, expected usage and concern on interference for the three CA forms as explained above. Table 12: Terminal complexity, usage probability and interference concerns per CA form Key areas which were addressed for further study and possible translation into 3GPP specifications were the following: 1. Peak data rates: downlink - 1 Gbps (8*8); uplink - 500 Mbps (4*4) 2. Spectrum efficiency: 3 times greater than LTE 3. Peak spectrum efficiency: downlink - 30 bps/Hz; uplink - 15 bps/Hz 4. Spectrum use: the ability to support scalable bandwidth use and spectrum aggregation where non- contiguous spectrum needs to be used. 5. Latency: from Idle to Connected in less than 50ms and then shorter than 5ms one way for individual packet transmission. 6. Cell edge user throughput to be twice that of LTE. 7. Average user throughput to be 3 times that of LTE. 8. Mobility: Same as that in LTE 9. Compatibility: LTE Advanced shall be capable of interworking with LTE and 3GPP legacy systems. LTE carrier aggregation used to provide high peak data rates has been introduced in 3GPP Release 10. Classification C2 Page 24 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Figure 7: Roadmap of LTE Carrier Aggregation Later it will allow up to 100 MHz of bandwidth to a user. However in the current Ericsson solution only two downlink CCs (component carrier) and one uplink CC will be supported. The LTE-CA VF-NL solution will use one CC on LTE1800 with a bandwidth of 15MHz or 20MHz, which depends if the GSM1800 spectrum became available to LTE and one CC on LTE800 with a bandwidth of 10MHz. LTE-CA deployment using the LTE2600 carrier is not in scope of this solution. Figure 8: Possible to use CA up to 5 component carriers - 100MHz Besides, LTE carrier aggregation should also be backwards compatible with release 8 and 9 for the support of legacy UEs. The figure below shows two legacy UEs which can co-exist next to a CA capable UE. The CA capable UE will use two CCs in the downlink and one CC in the uplink while the legacy UE will only one CC in downlink and one CC in uplink. The introduction of LTE-CA in the VF-NL network will not affect the functioning of the legacy UEs. Figure 9: Co-existence of CA and non-CA UEs in the same eNodeB In 3GPP specifications only a limited set of possible combinations of frequency bands is currently supported. However for the VF-NL specific scenario all the combinations of LTE800, LTE1800 and even LTE2600 are already supported. Figure 10: 3GPP Releases 8 and 10 carrier support Classification C2 Page 25 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Inter-band CA for B3 (LTE1800): Inter-band CA for B20 (LTE800): Inter-band CA for B7 (LTE2600): 3GPP Release 10 – LTE CA deployment scenarios: In the 3GPP release 10 which is also the supported release in the Ericsson software version L14A not all possible scenarios are supported. Besides it will require different features in the Ericsson eNodeB to cope with these scenarios. Figure 11: LTE-CA deployment - scenario1 F1 and F2 cells are co-located and overlaid, providing nearly the same coverage. Both layers provide sufficient coverage and mobility can be supported on both layers. Aggregation is possible between overlaid F1 and F2 cells. This is a likely scenario in the VF-NL network especially in the urban and suburban areas where both contiguous LTE800 and LTE1800 coverage is available. Figure 12: LTE-CA deployment - scenario 2 F1 and F2 cells are co-located and overlaid, but F2 has smaller coverage due to larger path loss. Only F1 provides sufficient coverage and F2 might be used to improve throughput or enhance capacity. Mobility is performed based on F1 coverage. Aggregation is possible between overlaid F1 and F2 cells. This is a likely scenario in the VF-NL network especially in the rural and LTE cell edge coverage areas (e.g. the edge of a large city) where LTE1800 has whether more down-tilt and / or a larger path loss. Classification C2 Page 26 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Figure 13: LTE-CA deployment - scenario 3 F1 and F2 cells are co-located but F2 antennas are directed to the cell boundaries of F1 so that cell edge throughput is increased or due to specific coverage needs a different sector orientation might be required. F1 provides sufficient coverage but F2 potentially has holes, e.g., due to larger path loss. Aggregation is possible where coverage overlaps. This is a more unlikely scenario in the VF-NL network but expected to be present in the future for a low percentage of the LTE co-located sites. This scenario would require specific features in the LTE RAN and is for now out of scope for this LTE-CA high level design. 3GPP Release 11 – LTE CA deployment scenarios: Figure 14: LTE-CA deployment - scenario 4 F1 provides macro coverage and on F2 Remote Radio Heads (RRHs) are used to improve throughput at hot spots. Mobility is performed based on F1 coverage. Likely scenario is when F1 and F2 are of different bands. Aggregation expected to be possible that between the RRHs on F2 and the underlying F1 macro cells. This scenario is not in scope of this high level design and besides it requires 3GPP release 11 support and this scenario is not deployed as such yet in the VF-NL network. Figure 15: LTE-CA deployment - scenario 5 This scenario is similar to scenario 2, but frequency selective repeaters are deployed so that coverage is extended for one of the carrier frequencies. It is expected that F1 and F2 cells of the same eNodeB can be aggregated where coverage overlaps. This scenario is not in scope of this high level design and besides it requires 3GPP release 11 support and this scenario is not deployed as such yet in the VF-NL network. 4.4.2 Scope 4.4.2.1 In scope Feature introduction o FAJ 121 3046, Carrier Aggregation Network impact analysis due feature introduction o Software & Hardware o Small cells o Capacity Management Access Transport QoS Radio Core Network (briefly) o Mobility o UEs o OSS management system o Operations Classification C2 Page 27 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Configuration Management Performance Management Co-located L800 + L1800 sectors with same orientation DL 2Component Carriers (CCs), UL 1CC MiMo 2*2 CA deployment on a single DU MO / parameter overview High Level Test Plan … 4.4.2.2 Out of scope Feature introductions o FAJ 121 3063, Dynamic SCell Selection for Carrier Aggregation [feature restricted, no FFI] o FAJ 121 3009, Inter-Frequency Load Balancing o FAJ 121 3068, Supplementary Downlink for Carrier Aggregation [feature restricted, no FFI] o FAJ 121 2053, Downlink Frequency-Selective Scheduling o FAJ 121 1799, Uplink Frequency-Selective Scheduling QoS design Naming conventions 4.4.3 Feature Description: FAJ 121 3046, Carrier Aggregation 4.4.3.1 Description The benefits of the Carrier Aggregation feature are Carrier aggregation provides significantly increased peak UE throughput, as it can provide a peak throughput equivalent to a contiguous carrier of the same bandwidth as the aggregate of the individual carriers. Furthermore Carrier Aggregation enables bandwidth aggregation of two FDD carriers Downlink, increases the UE downlink bitrate (but the side effect of this benefit, is the reduction in the number of RRC connected users), increased performance due to improved frequency selectivity and CA will decreases UE downlink latency (i.e. resource utilization per TTI benefits of considering two carriers at scheduling). Carrier aggregation also provides pooling gains across carriers, bringing the effective efficiently of multiple carriers nearly on par with a single carrier having the same bandwidth as the aggregate. Normally there are some load balancing inefficiencies with multiple independent carriers (e.g. two 10 MHz carriers) as compared to a single larger carrier (e.g. one 20MHz carrier). Carrier aggregation can nearly eliminate such inefficiencies. It is possible to configure a UE to aggregate a different number of CCs originating from the same eNodeB and of possibly different bandwidths in the UL and DL. The number of DL CCs that can be configured depends on the DL aggregation capability of the UE. The number of UL CCs that can be configured depends on the UL aggregation capability of the UE. It is not possible to configure a UE with more UL CCs than DL CCs; The Carrier Aggregation feature supports the following characteristics: Carrier Aggregation for FDD Up to two downlink component carriers Statically configured secondary component carrier Single uplink component carrier Same Transmission Mode (TM) on both carriers Dynamic activation or deactivation of secondary component carriers Aggregated cells located on the same Digital Unit (DU) No cross-carrier scheduling Inter-band aggregation Intra- and Inter-LTE Mobility Classification C2 Page 28 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.4.3.1.1 PCELL and SCELL A UE configured for carrier aggregation has one Primary Cell (PCell) and one Secondary Cell (SCell). The PCell is the cell where the UE is connected and has established the Radio Resource Control (RRC) connection, and is operating on the primary frequency. The SCell operates on a secondary frequency and may be configured once the RRC connection is established. Mobility procedures in RRC_Connected mode are always based on the PCELL and never on the SCELL. All aspects of Carrier Aggregation relates only to the UEs in state RRC_CONNECTED. The PCell is always active, while the SCell is dynamically activated or deactivated. When a UE has an activated SCell and the DL channel quality on the SCell is above a certain threshold, DL data can be transmitted over both carriers. The amount of data sent on each carrier is proportional to the bandwidth and the DL channel quality of the carrier. Data splitting onto multiple carriers only occurs if the data to be sent exceeds a certain threshold. If the amount of data sent does not exceed this threshold, the transmission only occurs on the carrier that could potentially send more data given the constraints of carrier bandwidth and DL channel quality on the carrier. Classification C2 Page 29 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Figure 1614: VF-NL LTE-CA (Rel-10) and non-CA (Rel-8) scenarios A Rel-10 UE that supports Carrier Aggregation shall comply with common release 8, 9 and 10 camping & cell selection procedures, as defined in 3GPP 36.304. The required modification in the protocol structure for carrier aggregation is small compared to the Rel-8 protocol structure. Carrier aggregation is not visible at RLC level since the MAC layer allocates data onto cells. The physical layer follows essentially the Rel-8 structure per cell. Figure 1715: Protocol stack for legacy and CA capable UEs The following applies for the DL Primary Component Carrier (DL PCC) UE specific Cannot be de-activated System information monitoring the same as a Rel-8 UE on the DL PCC The cell configured on the DL PCC is the Primary Serving Cell PCell Security and NAS mobility info taken from PCell Only a radio link failure on the DL PCC triggers RRC connection re-establishment The following applies for the One UL Primary Component Carrier (UL PCC) SIB2-linked with DL PCC and thus also UE specific Carries PUCCH Random access limited to UL PCC Random access failure on UL PCC triggers RRC connection re-establishment Classification C2 Page 30 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation The “rest” are Secondary Component Carriers (UL/DL SCC) Can be regarded as “additional resources” Can be de-activated The cell configured on a SCC is a Secondary Serving Cell SCell A SCell for one CA UE occupies almost as much memory as a non-CA UE. 4.4.3.1.2 UE Configuration At attach, reestablishment and incoming handover (inter or intra frequency), the eNodeB will check CA license, CA neighbor cell configuration (i.e. SCell candidate) and UE capability. If all above is fulfilled the UE will be configured with one DL SCell in the same RRC Reconfiguration that is needed for the attach or outgoing handover reconfiguration to complete. Figure 1816: SCELL configuration signaled to the UE RRC connection setup is performed in one cell (PCELL) per Rel-8 where additional component carriers (SCELL) are added afterwards. Figure 1917: Normal Rel-8 RRC set-up followed by CA setup The UE does not read SIB on SCell, but receives all SIB of relevance for SCell by dedicated. Aggregation of carriers is UE-Specific. Reading SIB from additional cells would delay Carrier Aggregation activation after RRC connection establishment. The UE is not required to monitor and maintain updated SIB on SCell. SIB for an SCell remains valid until SCell is removed and is changed by removing and adding SCell with updated SIB. Figure 2018: No SIB reading on SCELL - signalled via RRC messages Classification C2 Page 31 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation The figure below does show the relevant part for configuration of the SCELL which is part of the large RRC Connection Reconfiguration message signaled to the UE in this example at Attach. Figure 2119: S-CELL addition (EARFCN 6300, 100 Radio Blocks, transmission mode 3 [read: MiMo]) In the LTE-CA VF-NL solution a so-called static SCELL configuration will be configured. Overlapping coverage cells are configured as PCell – SCell Pair applicable for both directions from LTE800 towards LTE800 and vice versa. Each cell can only has 1 SCell target candidate. Figure 2220: PCELL – SCELL pair for overlapping coverage cells D1 A static PCELL-SCELL pair is defined for the following overlapping coverage cell combinations: PCELL SCELL LTE800 sector 1 LTE1800 sector 1 LTE1800 sector 1 LTE800 sector 1 LTE800 sector 2 LTE1800 sector 2 LTE1800 sector 2 LTE800 sector 2 LTE800 sector 3 LTE1800 sector 3 LTE1800 sector 3 LTE800 sector 3 Classification C2 Page 32 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.4.3.1.3 UE De-Configuration The UE is implicitly de-configured upon release of the UE. The SCell is always de-configured at incoming handover. The UE is explicitly de-configured if: Handover to a cell where CA is not available or possible (lack of dual band coverage, configuration limitations) Handover to a cell where the UE capability lacks support of the CA band combinations available (harmonics issues etc…) Figure 2321: SCELL de-configuration signaled to the UE 4.4.3.1.4 CA Mobility evaluation There is no change with regards to mobility procedures for a CA UE compared to a legacy non-CA UE. The PCell is determined by Idle-mode reselection priorities. At incoming intra- or inter-frequency handover the target cell becomes the new PCell in case the target cell does support CA. PCell mobility for a LTE-CA capable UE is the same as it is for a Rel-8 legacy UE. The following mobility use cases are possible: Intra Frequency Handover o CA to CA (based on PCELL) o CA to non-CA (based on PCELL) o Non-CA to CA Inter Frequency Handover o CA to CA (based on PCELL) o CA to non-CA (based on PCELL) o Non-CA to CA Inter Frequency Load Balancing o CA to CA (based on PCELL) since IFLB is currently only deployed on co-located sectors. IRAT redirection o CA to UTRAN All these mobility use cases are based on event triggers such as A3, A4, A5, B2, etc. As stated above CA mobility is the same as for Rel-8 legacy UEs and based on the PCELL only. Below the applicable events for the VF-NL network in case of a CA capable UE are summarized: No changes in cell selection / reselection for a CA capable UE Mobility is based on only the PCell coverage for a CA capable UE Event A3 based intra-frequency handovers for a CA capable UE Event A5 based inter-frequency handovers for a CA capable UE Event A4 based inter-frequency load balancing for a CA capable UE due to load balance purposes. Event B2 based inter RAT re-directions for a CA capable UE PCell always changes due to an intra- or inter-frequency (both normal and load based) handover In the new PCell, the old SCell is removed and a new SCell is configured. All of this is done in the same RRCReconfiguration message at the handover itself. Classification C2 Page 33 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Figure 2422: Possible CA mobility scenarios It is important from a performance management point of view to monitor closely the handover success rate both intra- and inter-frequency since the RRC Reconfiguration message becomes bigger due to the additional information at handover related to carrier aggregation and the release and establishment of the old and new SCELLs. The table below shows whether Idle and Dedicated traffic management steering and specific CA functions are based on PCELL or SCELL. Table 23: Traffic Management and CA functions driven by PCELL or SCELL Q1 Since the length of the RRC Reconfiguration message during attach or handover procedure for CA capable UEs is extended, it might affect accessibility and retainability performance indicators. Could it also affect the data interruption time during intra- or inter-frequency handover procedures since the SCELL needs to be set-up in the new cell again? The possible impact on network performance indicators caused by CA capable UEs and activation of feature “FAJ 121 3046, Carrier Aggregation” is difficult to be analyzed during lab verification and needs to be part of the network pilot and roll-out phase. However a possible increase in data interruption time during handover procedures for CA capable UEs can and will be verified during lab verification. Classification C2 Page 34 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.4.3.1.5 Dynamic UE specific SCELL Activation and De-Activation To facilitate UE battery savings, the Carrier Aggregation feature supports dynamic activation and deactivation of the secondary cell. DL transmissions on an SCell are only possible if the secondary cell is activated. If the secondary cell is deactivated, although still configured, no transmissions are possible on that carrier. The UE does not monitor the deactivated component carrier. This results in UE battery saving. For reasons like UE battery consumption, 3GPP has specified a fast MAC level activation/deactivation procedure for SCell (sent on PDSCH). While activated the UE listens to PDCCH channel for both carriers impacting battery life. To take the configured cell into use, the eNodeB will send an Activation/Deactivation MAC CE to the UE, activating the SCell. Upon activation, the UE will start monitoring PDCCH, perform CQI measurements and receive DL transmissions grants. Once the SCell is activated, the eNodeB scheduler will be able to use downlink resources on both the SCell and the PCell which this UE is associated with. The eNodeB monitors the CQI reports for both cells. If the CQI measurements drop below a certain threshold for a SCell, the eNodeB will stop scheduling this UE on that cell. De-configuration of an SCell implicitly also includes deactivation of the SCell, so no separate deactivation command has to be sent. There are triggers for activation and de-activation of the SCELL (read: it does not concern the de-configuration of the SCELL): “Need based” o Allow activation or deactivation of the SCell based on the amount of data available in the Radio Link Control (RLC) buffer. “Coverage based” o Allow deactivation of the SCell based on poor channel (SCELL CQI) quality o Polling when out of SCell coverage Prohibit timer to avoid ping pong Dynamic activation and deactivation ensures that the SCell is only activated when there is DL data demand that could benefit from transmitting on more than just one carrier. Furthermore, the activated secondary cell is only used for DL transmissions if the SCell DL channel quality is above a certain threshold. The SCell is deactivated if the DL data demand drops so much that it can be handled through only one component carrier, or when the DL channel quality of the activated SCell stays below a threshold for a certain time. Allow activation or deactivation of the SCell if the timer is not running, to avoid a Ping-Pong effect. The prohibit timer must be started whenever either activation or deactivation is triggered. No new activation or deactivation can be triggered while the timer is running. If the cell being used as SCell becomes locked, then the eNodeB will trigger deactivate. If the locked SCell becomes unlocked, then the eNodeB will trigger activate (assumption: the UE is still CA configured). Important to understand is that de-activation of the SCELL is not done via de-configuration, since this would require RRC dedicated signalling all the time which would negatively impact processor load and capacity of the eNodeB. Classification C2 Page 35 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation UE specific SCELL Activation Figure 2523: UE Specific SCELL Activation The SCELL once configured is not activated yet. For this a certain conditions need to be fulfilled. Assuming the quality of the channel is considered to be sufficient, it requires that the number of bits in all queues is more than a pre-defined threshold. A hysteresis between activate and deactivate is used. In case the prohibit timer is NOT running the SCELL will be activated and the scheduler is now allowed to schedule data for both carriers. SCell activation is achieved through the transmission of an activation Medium Access Control (MAC) Control Element (CE) with the SCell index bit set to one. The eNodeB sends the Activation MAC CE on a PCell, piggybacked on data. The eNodeB considers the activation successful when a HARQ ACK detection parameter is received after the DL burst that carried the activation MAC CE occurred. Because it is possible to receive a false HARQ ACK detection parameter, the activation MAC CE is repeated multiple times. Once activated, the UE is polled for SCell channel status information. One special scenario is when the SCELL, which is active becomes locked. If the cell being used as SCell becomes locked, then the eNodeB will trigger a deactivate. If the locked SCell becomes unlocked, then the eNodeB will trigger an activate since the UE is still configured. UE specific SCELL Deactivation Figure 2624: UE Specific SCELL Deactivation Once the SCELL is activated, there will be monitoring whether the SCELL can or should be deactivated (read: NOT de-configured) due to poor channel quality, admission control and / or to save UE battery consumption. For example when the SCELL is activated the UE listens to PDCCH channel for both carriers impacting battery life. In case the prohibit timer is NOT running (otherwise a deactivation of the SCELL is NOT possible) and one of the conditions as displayed in Figure 26: UE Specific SCELL DeactivationFigure 22: UE Specific SCELL Deactivation is fulfilled, the SCELL can be deactivated and the scheduler stops scheduling data for both carriers and continues with scheduling on the PCELL carrier only. SCell deactivation is achieved through the transmission of an deactivation Medium Access Control (MAC) Control Classification C2 Page 36 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Element (CE) with the SCell index bit set to zero. The eNodeB sends the deactivation MAC CE on a PCell, piggybacked on data. The eNodeB considers the deactivation successful when a HARQ ACK detection parameter is received after the DL burst that carried the deactivation MAC CE occurred. Because it is possible to receive a false HARQ ACK detection parameter, the deactivation MAC CE is repeated multiple times. The reason to have a prohibit timer for LTE-CA activation and deactivation, which will prevent Ping-Pong activation and deactivation, is to not unnecessary stress the processor load and to cope with fast bursty high traffic load. For this kind of traffic behavior LTE-CA will remain activated, which is good for TCP but also http with a high bandwidth demand. 4.4.3.1.6 Capacity Each carrier aggregation UE with one configured SCell consumes the memory of 2 RRC connected users in the system. If unchecked it would halve the number of RRC connected users in the eNodeB and therefore it is important to check the amount of CA users and to introduce parameters which can limit the number of CA UEs admitted on the eNodeB. When the total load in the eNodeB increases, two thresholds are available to manage the capacity of the eNodeB and to limit the use of carrier aggregation. The first threshold controls the admission or granting of new configurations of SCELLs in the eNodeB. A second thresholds is available to even pre-empt already configured SCELLs of CA capable UEs in case of new incoming RRC connection set-ups of non-CA capable UEs. It is important to understand that Carrier Aggregation works best with a low number of RRC connected users, so deactivation at high traffic load should not impact CA throughput. At high load available system resources need to be shared amongst the RRC connected users and accessibility is considered to be of higher importance over high data throughputs. However also inter-frequency load balancing is expected to be implemented at high capacity demanding site locations. Therefore it is good to optimize settings after LTE-CA has been launched in the VF-NL network to find the optimum balance between capacity, accessibility and throughput. R1 After LTE-CA has been launched in the VF-NL network and a full operational implementation has been completed it is recommended to start an optimization activity, which should aim to find the optimal parameter set in case of high traffic load by means of accessibility, retainability, latency, capacity and throughput. Since LTE-CA consumes more resources, it is expected to work less efficient in high traffic areas creating congestion and performance degradation and thereby affecting main network performance indicators by means of accessibility, throughput, retainability, latency, resource usage, etc. To be able to cope better with these high loaded eNodeBs two new parameters are introduced which will be addressed later on in this document. Classification C2 Page 37 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.4.3.1.7 eNodeB scheduler The current implementation of the Carrier Aggregation feature demands that both carriers, which are aggregated, are connected to the same digital unit. For the bandwidth and throughput needs for LTE-CA deployment in the VF-NL network specific design requirements are provided by Vodafone. Therefore LTE-CA deployment using a DUL20, cannot meet these requirements. Therefore only carrier aggregation using a single DUS31 or DUS41 is in scope of this HLD. D2 A DUL20 cannot meet the design requirements on bandwidth and throughput. Besides this also the current software release L14A on which LTE-CA in the VF-NL will be deployed does not support carrier aggregation on dual-DU configurations. Therefore carrier aggregation should be deployed on a single DUS31 or DUS41 able to support: – 10MHz (LTE800) + 15MHz (LTE1800) – 10MHz (LTE800) + 20MHz (LTE1800) Since carrier aggregation is deployed on a single DUS31 or DUS41 it is good to look at the scheduler inside the eNodeB through an example. Below is one eNodeB with two cells (on the same DU) covering the same geographical area. Cell A has two RRC connected UEs, Cell B has one RRC connected UE. Each cell uses a carrier that is not in the same band as the other carrier (i.e. inter-band). The colour of the UE will be used to map a certain bearer to a cell in the following examples. Note: All QoS metric are per bearer and node, not per bearer and cell. Figure 2725: eNodeB scheduler in case of CA and non-CA capable UEs For a bearer (of a carrier aggregation UE), the scheduler consider the total bitrate when prioritize against non-CA UE bearers. The example shows equal priority for all bearers, which no relative priority scheduling weights are applied to differentiate CA from non-CA users. The eNodeB assigns portions of data, to be sent to a UE, on each DL carrier. This is done using a channel quality based algorithm. If the amount of data is high the new data to be transmitted is split between the carriers according to the channel quality and maximum number of assignable bits. Better channel quality increase assignable bits also known as link adaptation. If the amount of data is low the new data will be sent over one of the carriers (read: no splitting) based on a ranking where bandwidth and channel condition is considered. Classification C2 Page 38 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation UEs with poor channel quality on their SCell will not be assigned any bits. This prevents scheduling for UEs that are out of coverage. Figure 2826: Scheduling of 1 CA and 2 non-CA users by the eNodeB scheduler using equal prioirty 4.4.3.2 Benefits The optional feature “FAJ 121 3046, Carrier Aggregation” provides significantly increased peak UE throughput, as it can provide a peak throughput equivalent to a contiguous carrier of the same bandwidth as the aggregate of the individual carriers to a single UE. Carrier aggregation also provides pooling gains across carriers, bringing the effective efficiently of multiple carriers nearly on par with a single carrier having the same bandwidth as the aggregate. Normally there are some load balancing inefficiencies with multiple independent carriers (e.g., two 10 MHz carriers) as compared to a single larger carrier (e.g., one 20MHz carrier). Feature “FAJ 121 3046, Carrier Aggregation” can nearly eliminate such inefficiencies. The main benefits of the Carrier aggregation are: Enables bandwidth aggregation of two FDD carriers (downlink only) More efficient use of scattered spectrum Increased performance due to improved Frequency selectivity Higher capacity Increased downlink speed across the coverage area Note: The benefit decreases with the number of RRC connected users Decreases UE downlink latency, meaning the resource utilization per TTI benefits of considering two carriers at scheduling. 4.4.3.3 Dependencies This feature has no prerequisite features. This feature also does not affect any other feature but however it does affect the eNodeB scheduler in RAN since it will need to be able to schedule DL data transmission for CA capable UEs on both carriers simultaneously in case the criteria are fulfilled to allow scheduling on both carriers. It is mandatory to have the transmission mode on both carriers set equally. D3 In case Carrier Aggregation is activated between co-located sectors the transmission mode on both sectors need to be configured equally up to the L14A release. In L14B the transmission mode between aggregated carriers can be configured differently (e.g. tm3 & tm4). Classification C2 Page 39 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Before LTE-CA can be deployed on a single DUS31 or DUS41 having 2 * 3 sectors combining LTE1800 (15MHz / 20MHz) and LTE800 (10MHz), which is the most common configuration deployed in the LTE Vodafone network, other feature and hardware introductions are to be introduced prior to activation of feature “FAJ 121 3046, Carrier Aggregation”: “FAJ 121 1821, 6 Cell Support”, required to support 2 * 3 sectors since all cells need to be located on the same DU for CA “FAJ 121 1820, Cascadable Radio Units”, this feature is mandatory for support of CA on special hardware configurations such as special 2 * 3 sectors * 6 RRUS01s Currently only IRAT re-direction is supported from LTE to both UTRAN and GERAN. However once the IRAT handover to UTRAN will be introduced in the Vodafone network it is important to address possible issues or design challenges due to introduction of feature: “FAJ 121 0897, WCDMA IRAT Handover, coverage triggered”, B2 events should be working the same as for legacy Rel-8 UEs but worthwhile to double check during lab verification there is no side effect of this feature for CA capable UEs. Also for feature “FAJ 121 3009, Inter-Frequency Load Balancing” no impact is expected since A4 events should work as usual regardless whether the UE is Rel-8 or Rel-10. However as stated in design recommendation “R 1” it would be good to find the optimal parameter settings to utilize eNodeB capacity for both CA and non-CA users without impacting performance through optimization. Since IFLB is currently only deployed between co-located sectors with a high traffic, any change in the design or deployment guidelines should also consider possible side effects on CA. There are also other features which might be interesting for further study in the near future when the proper software release has been introduced in the VF-NL network and once LTE-CA has been deployed and optimized in the network. “FAJ 121 3075 R1, Carrier Aggregation aware IFLB”, currently IFLB will trigger inter-frequency handover based on A4 events regardless whether the UE is CA or non-CA capable. This feature will provide the opportunity to distinguish between CA and non-CA capable UEs when it comes to inter-frequency load balancing. “FAJ 121 3063, Dynamic SCell Selection for Carrier Aggregation”, currently restricted due to missing FFI (First Field Integration). This feature might become interesting in case sites will be deployed in the network where the orientation between the LTE800 and LTE1800 do differ and a flexible SCELL is demanded instead of a single static SCELL definition. This feature will also introduce a new event A6, will allow several SCELL definitions which can be dynamically be configured or de-configured based on measurement based channel quality measurements. Currently feature “FAJ 121 0869, Maximum Cell Range” is trialed in the Vodafone network. There is restriction when it comes to this feature in combination with feature “FAJ 121 1821, 6 Cell Support”. Up to L14B, the maximum cell range feature can only be used on a digital unit having a maximum of three configured cells. After L14B this restriction will be lifted and both features can be combined at the same digital unit having more than three cells configured. A cross check between the frozen list for LTE-CA deployment (358 eNodeBs) and the pilot eNodeBs for trialing the Maximum Cell Range feature do show an overlap of 4 site locations. Below the details of the affected sites. Table 34: Conflict between LTE-CA deployment and Maximum Cell Range feature trial Classification C2 Page 40 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation It has been agreed that in case of a conflict between this pilot and the deployment of LTE-CA for these specific site locations, performance will be leading. This means that either one of the two might be disabled to maintain or improve the performance of that specific site locations. D4 For potential conflicts with regards to deployment of LTE-CA and usage of the maximum cell range feature, performance of that site location will be leading to determine which one of the two will get priority over the other. This limitation is only applicable up to L14A and will be eliminated once L14B is introduced in the VF-NL network. 4.4.3.4 VF-NL network impact This section will identify mainly the impact on the VF-NL RAN network but will also shortly describe the expected impact on access transport and core network. However a full high level design for access transport, core network and a full operational implementation are beyond the scope of this LTE-CA feature HLD. 4.4.3.4.1 Software L14A IP3 is the minimum recommended software level to deploy LTE-CA in the VF-NL network. Currently the software level is still L12B but a pre-requisite project is running at this stage to upgrade from L12B CP4 to an intermediate L13B level, shortly followed-up by the L14A CP1 or L14A IP6 software package. The decision to go for a later package is two-fold: Usually a later software package does solve issues which might be related to LTE-CA and are also applicable to the VF-NL network IP5 was the minimum mandatory level for the VoLTE project 4.4.3.4.2 Licenses There are two licenses required for successful deployment of the LTE-CA feature assuming that the required licenses for features “FAJ 121 1821, 6 Cell Support” and “FAJ 121 1820, Cascadable Radio Units” are already installed. The first license is required for support of feature “FAJ 121 3046, Carrier Aggregation”. The second license is important to be able to cope with the high data peak rates where LTE-CA is aiming for. Current maximum throughput on the DULs and DUSs are limited to 150Mbps. To be able to support the maximum theoretical throughput of 224 Mbps (30MHz) this license needs to be increased to 300Mbps. Basically there is no additional demand for the uplink since carrier aggregation is neither in scope nor supported in the L14A software release. Furthermore the proper licenses for support of all bandwidths, power requirements for a single DUS need to be implemented prior to installation and activation of the LTE-CA feature. From connected UE license point of view, a LTE-CA user is still counted as one connected UE from connected UE license perspective. Classification C2 Page 41 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation All license related information is gathered and displayed in the table below. LTE-CA features License num ber Feature num ber Com m ent Carrier Aggregation FAJ 121 3046 One required per DUS w here LTE-CA is deployed Carrier Aggregation up to 40 MHz CXC4011476 FAJ 121 3046/1 Out of scope, how ever w ill be the same license Pre-requisite LTE-CA features License num ber Feature num ber Com m ent 6 Cell Support CXC4011317 FAJ 121 1821 Part of dual-band DUS introduction Cascadable Radio Units CXC4011156 FAJ 121 1820 Part of dual-band DUS introduction Capacity License num ber Feature num ber Com m ent ChannelBandw idth=10MHz CXC4010718 FAJ1210668 LTE800, w ill be deployed on the same DUS as LTE1800: - 3 sectors: 3 licenses of LTE800 10MHz ChannelBandw idth=20MHz CXC4010720 FAJ1210670 LTE1800, w ill be deployed on the same DUS as LTE800: - 3 sectors: 3 licenses of LTE1800 20MHz DlBasebandCapacity=1 CXC4010623 FAJ1210544 Needs to be increased from 150 Mbps: > DUS31: to 300 Mbps > DUS41: to 500 Mbps DlPrbCapacity=1 CXC4011039 FAJ1210927 Already Max 65535 UlBasebandCapacity=1 CXC4010624 FAJ1210545 Needs to be increased from 50 Mbps: > DUS31: to 150 Mbps > DUS41: to 250 Mbps UlPrbCapacity=1 CXC4011040 FAJ1210928 Already Max 65535 ConnectedUsers=1 CXC4010608 FAJ1210485 Currently 800 users are licensed w hile the hardw are is capable of handling much more in L14A softw are: > DUS31: 2500 > DUS41: 3000 OutputPow er=40Watt CXC4010625 FAJ1210546 Part of dual-band DUS introduction OutputPow er=60Watt CXC4010626 FAJ1210547 Part of dual-band DUS introduction OutputPow er=80Watt CXC4011161 FAK1010020 Part of dual-band DUS introduction Table 45: License information required for LTE-CA deployment New hardware such as the DUS31 or DUS41 do already come with a set of capacity licenses based on Vodafone global agreements. This capacity license set is sufficient for the DUS41 to fulfil the requirements for the LTE-CA launch in scope of this project. However the standard capacity license set for the DUS31 needs to be enlarged since it is not sufficient to fulfil the requirements. The number of RRC connected users is standard licensed to 1000 for a DUS31 and 1200 for a DUS41 and will not be further increased for this project. A separate capacity management process needs to be set-up to monitor, control, forecast and guarantee enough capacity to meet network performance targets and keep the end-user satisfied. The set-up of such a capacity management process is beyond the scope of this HLD. D5 The standard capacity license set for a DUS41 is sufficient to fulfil the requirements for the LTE-CA launch. However the capacity license set for the DUS31 needs to be enlarged. DUS41: > Downlink capacity: 225 Mbps > Uplink capacity: 75 Mbps > RRC connected users: 1200 DUS31: > Downlink capacity: 150 Mbps will be increased to 225 Mbps > Uplink capacity: 50 Mbps will be increased to 75 Mbps > RRC connected users: 1000 remains the same R2 It is recommended to set-up a capacity management process which ensures a proper monitoring, control and capacity forecast to fulfil the capacity needs of the Vodafone LTE network in time in order to meet network performance targets and to keep end-user satisfaction on a high level. Classification C2 Page 42 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.4.3.4.3 Hardware To deploy LTE-CA digital unit type “DUL20” is not sufficient anymore and cannot fulfill the requirements as stated by Vodafone since it can basically support LTE-CA but only up to a maximum bandwidth of 20MHz and with a limited downlink and uplink capacity. Therefore two new digital unit types, the “DUS31” and “DUS41” are introduced. However next to these two new DUs also dual-band DU support needs to be introduced since carrier aggregation is only supported when both aggregated carriers are connected to the same DU. Both new DU-types will be able to fulfill the LTE-CA deployment requirements. However the “DUS41” will be more powerful by means of capacity, processor power, etc. It will be good in case not already done to define a guideline which will recommend where to deploy a DUS31 or a DUS41. Especially in areas where a high traffic demand is to be expected it is recommended to use the DUS41. The figures below do show the differences in capacity, maximum supported bandwidth, etc. for the three different DU-types which will be deployed in the VF-NL network. Figure 2927: Capacity figure for the DUL20 1 Figure 3028: Capacity figure for the DUS31 1 This figure claims support of 3000 RRC connected users for a DUS31 while the CPI Impact Report for L14A states 2500 Classification C2 Page 43 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 2 Figure 3129: Capacity figure for the DUS41 The most common configuration for LTE-CA deployment to be used will be 2 times 3 sectors connected to the same digital unit. There will be 3 sectors used for LTE800 10MHz and 3 sectors used for LTE1800 15MHZ or 20MHz. Co-located LTE800 and LTE1800 sectors on the same DU having the same orientation will be aggregated via static SCELL definition, which can give a maximum theoretical throughput of 224Mbps. There are several non-mixed mode and mixed mode hardware configurations currently in the VF-NL network. These configurations need to be identified in the dual-band DUS introduction project. This project will need to define the FROM – TO state and is responsible for proper introduction of these TO states in the VF-NL network. Figure 3230: DU with co-located B3 and B20 Radio Units for CA high data peak rates 4.4.3.4.4 Capacity Management Capacity management as such is not fully embedded in the VF-NL organization and is therefore not directly in scope for this HLD. However it is important to understand that LTE-CA will affect capacity of the eNodeB. It is expected to increase processor load since it will need to configure, de-configure, activate and de- activate SCELLs for LTE-CA capable UEs. However the DUS31 and DUS41 will be powerful enough to deal with this possible processor load increase. 2 This figure claims support of 4000 RRC connected users for a DUS41 while the CPI Impact Report for L14A states 3000 Classification C2 Page 44 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Next to processor load, one should also be aware that a LTE-CA user is counted as two non-CA users and will affect the number of RRC connected users. Therefore careful dimensioning and optimization of the parameters to control the number of configured SCELLs and number of CA users is required (see design recommendation “R 1”). Another design question (see design question “Q 2”) to be answered is about the amount of licensed RRC connected users. Currently the limitation is determined by the license (800 users) and not the hardware limit. Even for a DUL20 the hardware limit on L14A software is much higher than the license limit as shown in the previous chapter 4.4.3.4.34.4.7.4.3 HardwareHardware. Two mechanisms are introduced to limit the extra resources consumed by SCELLs on the eNodeB. The first mechanism controls the maximum number of SCELLs allowed to be configured. The second mechanism controls admission on configuration of new SCELLs. These two mechanisms work independently of each other. Param eter Description caPreemptionThreshold Configures the resource consumption margin in percentage, beyond w hich secondary cells must not be configured. caUsageLimit The value configures the number of SCell connections w hich can be in use for carrier aggregation. A secondary cell (SCell) costs in memory the same as a primary cell (PCell) for each UE. Table 56: Main parameters to limit extra resources consumed by SCELLs Parameter caUsageLimit limits the total number of SCELLs configured on the eNodeB regardless of the number of connected UEs. Parameter caPreemptionThreshold is used in formula to determine when the eNodeB stops configuring new SCELLs. This formula is as follows: The eNodeB stops configuring new SCELLs when the “total resource usage” on a DU exceeds: “loadingLimit” * (100 – caPreemptionThreshold) / 100 where the “loadingLimit” is a DU hardware capacity limit which differs for a DUS31 and DUS41 DUS31, “loadingLimit” 2500 DUS41, “loadingLimit” 3000 where “total resource usage” is defined as: # RRC connected UEs + # configured SCELLs The eNodeB stops configuring new SCELLs when the “total resource usage” on a DUS31 exceeds: 2500 * (100 – 50 / 100) = 1250 The eNodeB stops configuring new SCELLs when the “total resource usage” on a DUS41 exceeds: 3500 * (100 – 50 / 100) = 1500 For example, the eNodeB will stop configuring SCELLs if the number of connected UEs is high even though the SCELLs configured are still below caUsageLimit. With proper setting of caPreemptionThreshold, there is a high probability that the licensed connected user number can be reached at high loading without limiting the number of CA users at low loading. D6 The parameters for LTE-CA launch will be based on the Ericsson recommended settings. During pilot and / or roll-out phases of the LTE-CA program or during a separate optimization activity these parameters might be optimized to have a better balance between performance by means of accessibility and retainability and on the other side maximizing capacity and data peak throughputs. caPreemptionThreshold 50% caUsageLimit 300 configured SCELLs Classification C2 Page 45 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation The UL UE peak throughput is reduced by 6% in very good radio condition due to additional DL HARQ bits for the SCell are to be sent through PUSCH. This is the case if the UE is configured with SCell. 4.4.3.4.5 PUCCH dimensioning The PUCCH resource dimensioning needs to be considered. Different settings should be considered depending on the DU-type (read: DUS31 or DUS41), how many cells deployed on the DUS and whether carrier aggregation is applied. PUCCH dimensioning is beyond the scope of this LTE-CA feature HLD. 4.4.3.4.6 Access Transport and Quality of Service The current implementation of the Quality of Service settings within LTE are as such that the user plane traffic for LTE users, independent of any kind of subscriber differentiation (like the GSB concept which is not applicable yet for the LTE VF-NL network), is put into the lowest queue. The impact of this will be that in case of bandwidth shortage on the access transport network, LTE user traffic will be the most impacted. This might lead, when LTE-CA users are active and demanding a high data rate, to a degraded end-user satisfaction or even unwanted LTE-CA behavior resulting in multiple SCELL de-activations. The latter one might even impact negatively network performance indicators. Providing enough access transport bandwidth is the solution to prevent negative impacts on CA and network performance indicators. Another solution is to re-design the end-to-end QoS implementation in the VF-NL network. Both solutions are beyond the scope of this LTE-CA feature HLD. 4.4.3.4.7 OSS-RC There is no impact on OSS-RC 13B currently used in both the Vodafone and the Ericsson Managed Services organizations. Feature “FAJ 121 3046, Carrier Aggregation” is introduced in L13B software and is fully supported by OSS-RC 13B. Only a small modification with regards to carrier aggregation is introduced in L14A, which is support of feature “FAJ 121 3046/1, Carrier Aggregation up to 40 MHz”. This feature has the same license and is neither impacting the Managed Object structure nor the CA parameters. It only has this enhancement compared to L13B that it supports up to 40 MHz DL carrier aggregation across two carriers. 4.4.3.4.8 Mobility There is no change with regards to mobility procedures for a CA UE compared to a legacy non-CA UE. Please refer to chapter 4.4.3.1.44.4.7.1.4 CA Mobility evaluationCA Mobility evaluation for specific details. 4.4.3.4.9 Small cells Currently small cells are deployed on LTE1800 or LTE2600. Carrier Aggregation needs to aggregate in the VF-NL network data from two different carriers deployed at the same digital unit. This not deployed as such for the small cells, currently deployed in the Vodafone shops and the urban outdoor Amsterdam en Rotterdam area. A separate project is required in case carrier aggregation between several digital units and between vendors will be possible in the future. Within 3GPP and on the Ericsson hardware and software roadmaps solutions are foreseen for these special kind of HetNet carrier aggregation scenarios. However all of this is beyond the scope of this HLD. 4.4.3.4.10 HSS The EPC is unaffected and unaware by the use of carrier aggregation. However since we should be able to support data peak rates up to a maximum of 224 Mbps some modifications are required in the HSS. The individual UE-AMBR settings need to be whether deleted or set to a minimum setting of 224 Mbps in order to be not limiting. Furthermore the IMSI refers to a so-called “EsmIndividualDefaultContextId” and is provisioned with one default internet APN such as live.vodafone.com. The APN itself is also connected to one or several “HSS-EsmContextIds”. Classification C2 Page 46 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Below an example of LTE-CA applicable attributes in the HSS for a specific IMSI, APN and HSS- EsmContextId. IMSI: HSS-EsmImsi: 204045220001851 HSS-EsmUserProfileId: HSS_epsprofile_1 HSS-EsmMmeAddress: hnsgsn-mme1.epc.vfvtc.nl.epc.vfvtc.nl HSS-EsmMsisdn: 31652700402 HSS-EsmIndividualContextIdList: 35 HSS-EsmIndividualContextIdList: 15 HSS-EsmIndividualDefaultContextId: 35 APN Detaileddesign.nl HSS-EsmContextId: 81 HSS-EsmContextId: 82 HSS-EsmApnId: 8 HSS-EsmApnId: 8 HSS-EsmQosProfileQci: 7 HSS-EsmQosProfileQci: 7 HSS-EsmQosProfileArp: 1 HSS-EsmQosProfileArp: 1 HSS-EsmAmbrMaxUl: 51024000 HSS-EsmAmbrMaxUl: 26214400 HSS-EsmAmbrMaxDl: 102048000 HSS-EsmAmbrMaxDl: 104857600 4.4.3.4.11 EPC The EPC as such is already able to support this peak data rate. Only one limitation exists in the current MME software release. This limitation applies in the case a LTE-CA capable device would make an inter- RAT cell reselection from UTRAN to LTE. In that scenario a CA capable UE would not be able anymore to achieve these peak data rates of 224 Mbps and will be limited to a maximum peak data rate of 84 Mbps. This “QoS stickiness” limitation will be solved in MME software release “SGSN-MME R14B”. However the maximum throughput supported also in “SGSN-MME R14B” will be limited to a maximum of 256 Mbps, which is not a problem for the current scope but might become an issue when Vodafone wants to deploy LTE-CA++ which could do carrier aggregation over three carriers. Another issue caused by the QoS stickiness issue is, despite only silver users are provisioned in HSS, also gold and bronze users are present in LTE. Bronze and silver users are put into the same queue currently in the access transport network which is the lowest queue and thus not able to affect 3G user and control traffic streams. However in the case where a gold user performs a LTE-CA peak download, it might affect 3G user and control plane traffic. This applies in the scenarios the access transport cannot provide enough bandwidth. Since data traffic of this gold user is put in the same queue as some 3G control traffic and thus in a higher queue as 3G user traffic it might impact data throughput related KPIs and users on the 3G network. Q2 The presence of gold users in LTE, despite the fact that these are not provisioned as such in HSS, might affect the 3G control and 3G user traffic streams in case of peak LTE-CA throughputs with not enough access transport bandwidth. This might affect end-users doing data on 3G and also it might impact network performance indicators which are transport or throughput related. Therefore the severity of this impact needs to be verified during the 2014 MME software upgrade project. Classification C2 Page 47 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.4.3.4.12 Performance Management The migration from two separate DUS’s to a single DUS covered by the dual-band DUS introduction project will impact network performance the most. All KPIs where split over two different eNodeBs where after the migration everything is just still available on a single DUS. It will impact all formulas which do include the number of eNodeBs since this number will decrease by each site location where LTE-CA is going to be exploit. For the LTE-CA feature specifically new counters will be introduced able to monitor the amount of configured, activated cells. A possible change could be expected with regards to throughput KPIs and latency KPIs. With regards to throughput KPIs a shift is expected from LTE1800 to LTE800 in the case the number LTE-CA capable UEs will increase in the Vodafone LTE network AND demand the high data peak rates. In this scenario the eNodeB will schedule data on the SCELL, which is believed to be often the LTE800 cell since the UE is when coverage overlaps in Idle Mode on the LTE1800 cell since it has a higher priority. In case of high traffic load this might be more in balance again due to feature IFLB. The latency KPI might improve in the case of the presence of LTE-CA capable UEs demanding a high data peak rate since the data can be scheduled much fast over two carriers where previously it had to be scheduled all on the same single carrier. The number of RRC connected users might increase rapidly when the number of LTE-CA capable UEs with a high data demand grows in the network. This might trigger IFLB much earlier but might also impact retainability, accessibility KPIs. As described earlier in this HLD there is a mechanism which controls and tries to avoid these congestion scenarios but it might be necessary to tweak the parameters to find the optimal setting for the Vodafone LTE network. Another possible impact on NRR and NAR might be caused by the extension of the RRC Reconfiguration message which will contain for a LTE-CA capable UE more information elements which might affect handover success rates. The total throughput in the LTE network might grow as well even when the number of LTE-CA capable UEs remain low since all users will be provisioned in HSS as such that they are able to reach peak data rates of 224 Mbps where the majority of the LTE users today is limited to a maximum throughput of 50Mbps for the downlink and 25 Mbps for the uplink. However the QoS stickiness issue might limit again this possible data increase since it is believed that a lot of UEs will move between LTE and the legacy RATs 2G and 3G which will result in a maximum throughput limitation of 84Mbps for the downlink. Mobility is not affected by the introduction of LTE-CA since all the triggers which do exist today and are used specifically for the Vodafone NL network do also apply for LTE-CA capable UEs. For LTE-CA capable UEs it will be possible to observe increased UE peak rates. It is believed the number of LTE-CA capable UEs present in the Vodafone NL network is low and even if it starts to increase it should also demand high data peak rates otherwise it could still be scheduled on 1 carrier only despite a SCELL is configured for that particular UE. For legacy UEs there is not much impact to be expected since it should act and function as it did before LTE-CA activation in the network. However the UL UE peak throughput might be reduced due to additional DL HARQ bits for the SCell are to be sent through PUSCH. This is the case if the UE is configured with a SCell but it might also affect the total available throughput for the uplink in case the share of active LTE-CA capable UEs starts to increase in the network. Capacity management is beyond the scope of this HLD but it becomes more important to have such a process in place independent of the launch of LTE-CA since it is believed that the share of LTE-CA capable UEs will be very low at launch of LTE-CA. Currently there are three know types of commercial devices coming to the market, which are two from Huawei: B4000 and R226 and one from Samsung: S5 Galaxy. Classification C2 Page 48 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.4.3.4.13 Configuration Management The dual-band DUS introduction project will impact configuration management the most. For this LTE-CA feature introduction it will mainly impact eNodeB scripting, LTE consistency checking and license management. New managed objects and parameters are introduced and also MO structures do change like the EUTRANCELLRELATION MO. License and feature activation for LTE-CA needs to be embedded in the script used at integration, new recommended parameters need to be added to the leading parameter file and as such being part of the daily consistency checks. New capacity and new feature licenses need to be order for every eNodeB where LTE-CA is going to be deployed. Finally there should be a process which keeps track of the eNodeBs where LTE-CA has been deployed in case of eNodeB modifications, swaps, etc. Manual configuration of the SCELL will be performed by configuration management according to the way as described in decision “D 1”. Besides the creation of the Eutran neighboring relation (MO: EUtranCellRelation) also parameter “sCellCandidate” needs to be set to “ALLOWED”. However before the SCELL configuration set-up takes effect a CELL LOCK / CELL UNLOCK action is required. This lock / unlock operation impacts the LTE availability of those particular eNodeBs where carrier aggregation needs to be deployed for commercial launch. There are other parameters which according to customer product information do require a Node restart when changed. Please refer to 4.4.3.64.4.7.6 ParametersParameters for more details about which exact parameters do require this node restart when changed. 4.4.3.4.14 User Equipment UEs should support at east 3GPP release 10 and should be a category 6 device, otherwise they cannot support LTE-CA. In case there is no LTE-CA support in an eNodeB, the UE will act as a category 4 UE. The UE must support CA for at least two downlink component carriers as stated in 3GPP release 10. Table 67: UE categories including their maximum DL and UL speeds 3GPP specification TS 36.101 indicates which bandwidths a UE supports for a specific band- combinations. The UE will indicate which band-combinations it supports by Information Element (IE) “supportedBandwidthCombinationSet” in the UE capability message. 3GPP release 10 supports a single uplink TA (Timing Advance) value for all component carriers. Therefore radios for different carriers should be at the same location to avoid different propagation delays. 3GPP Release 11 supports Carrier Aggregation with multiple uplink Timing Advances and other enhancements to support non-collocated cells. Classification C2 Page 49 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation There is a specific FGI bit range for release 10 UEs. There are three specific FGI bits related to LTE-CA, which are FGI bits 111, 112 and 113. CA : Measurement reporting trigger 111 UE supports carrier aggregation Event A6 CA : SCell addition within the UE supports carrier aggregation and 112 Handover to EUTRA procedure the Handover to EUTRA procedure Trigger type 0 SRS (periodic SRS) transmission on X Serving Cells UE supports carrier aggregation in 113 X = number of supported component UL carriers in a given band combination Figure 3331: Release 10 LTE-CA specific FGI bits Figure 3432: RRC EUTRA Capability message for Category 4 UE Figure 3533: RRC EUTRA Capability message for Category 6 UE 4.4.3.4.15 VoLTE Since VoLTE is voice over data it is important that this will not trigger a SCELL activation. Due to the data threshold this will not occur for a stand-alone VoLTE call. If there are data bearers parallel with VoLTE calls, the SCell could be activated. In the case where the SCELL is activated for a VoLTE call with one or more data bearers, the VoLTE data packets will be scheduled on the carrier with the best radio conditions, which could be either the PCell or the SCell. Scheduling on SCell will not impact the voice quality. If service triggered mobility is used to change the IFHO thresholds, CA will continue to be possible, as long as carrier aggregation is possible for the UE and network with the new combination of PCell and SCell. Classification C2 Page 50 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.4.3.5 Managed Object structure LTE-CA introduction does affect existing MO “EUtranCellRelation” and does also introduces two new MOs “CarrierAggregationFunction” and “CarrierAggregation”. The latter one is required for licensing and feature activation. In MO “EUtranCellRelation” the SCELL parameter can be set to “ALLOWED” to indicate that carrier aggregation is allowed between these two EUtranCells. Keep in mind the maximum of one SCELL per EUtranCell and that both EUtranCells need to belong to the same digital unit. Figure 3634: LTE-CA Managed Object structure 4.4.3.6 Parameters In total 9 new parameters are introduced with feature “FAJ 121 3046, Carrier Aggregation”. Basically these can be split into three groups: 1. SCELL configuration 2. CA capacity related 3. CA activation/deactivation thresholds The table below does provide the overview of these groups, parameters per group with their belonging description, ranges and recommended parameter setting. Group Parameter Description Parameter Range Unit Recommended setting Takes effect SCell candidate status. The value indicates w hether the cell indicated may be 0 NOT_ALLOWED: The cell indicated must not be used as SCell SCELL Configuration sCellCandidate used as SCell for UE using this cell as their PCell. 1 ALLOWED: The cell indicated may be used as SCell - Refer to decision "D1" Lock / Unlock 2 AUTO: Same as NOT_ALLOWED. Configures the resource consumption margin in percentage, beyond w hich caPreemptionThreshold 0 - 100% 1% 50 Node restart SCells shall not be configured. Capacity The value configures the number of SCell connections w hich can be in use caUsageLimit for carrier aggregation. A secondary cell (SCell) costs in memory the same 0 - 65535 1 SCELL 300 Node restart as a primary cell (PCell) for each UE. If the minimum time needed to transmit all bits in all priority queues of a UE is higher than this threshold, then activation of one or more SCells is considered. Minimum time needed to transmit all bits is calculated as the number of bits in sCellActDeactDataThres 0 - 5000 0.1 ms 100 Lock / Unlock all priority queues, divided by the number of bits that can be transmitted in one TTI by all active serving cells prior to activation decision assuming the UE is given all resources in those cells. Dependencies: sCellActDeactDataThresHyst <= sCellActDeactDataThres If the minimum time needed to transmit all bits in all priority queues of a UE is low er than sCellActDeactDataThres minus sCellActDeactDataThresHyst, sCellActDeactDataThresHyst then deactivation of one component carrier is considered. 0 - 5000 0.1 ms 90 Lock / Unlock Dependencies: sCellActDeactDataThresHyst <= sCellActDeactDataThres SCELL Activation / Deactivation Activation/deactivation prohibit timer. No new activation/deactivation of an sCellActDeactProhibitTimer 0 - 5000 1 ms 200 Lock / Unlock SCell is allow ed w hile this timer is running. No data is scheduled on SCell if w ideband SINR is low er than this threshold. sCellScheduleSinrThres If the SINR persists in staying below the threshold, the SCell w ill eventually -200 - 300 0.1 dB 0 Lock / Unlock become deactivated. Controls the length of time that elapses until a UE is considered once again for SCell configuration after the eNB w as not able to configure this UE w ith a w aitForCaOpportunity suitable Scell. -1 - 60000 1 ms 10000 Ongoing connection "-1" means w ait forever. Duration for w aitForBetterSCellRep. Controls the length of time a UE w ill search for SCell(s) on a particular frequency or set of frequencies w hen it is w aitForBetterSCellRep not in good SCell coverage. -1 - 32000 1 ms 1000 Ongoing connection "-1" means w ait forever. Figure 3735: Recommended LTE-CA parameter settings Classification C2 Page 51 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Only one sCellCandidate is possible with feature “FAJ 121 3046, Carrier Aggregation per PCELL. To avoid SCELL relations to be removed by ANR, it is recommended to set for those EUtranCellRelations parameter “isRemoveAllowed” to FALSE. 4.4.3.7 Counters & Events Feature “FAJ 121 3046, Carrier Aggregation” does also introduce new events and counters which can be used for in-depth analysis and definition of performance indicators. The overview below does provide an overview of these new events and new counters specifically for LTE-CA analysis and performance monitoring. Counter Description Unit Condition Number of supported SCells, for UE using this cell as their PCell This measurement provides the number of UEs capable of dow nlink carrier aggregation, counted per the number of [0] Number of UE that are not carrier aggregation capable at all (i.e. PCell only) component carriers (PCell and SCells). pmCaCapableDlSum [1] Number of UE that are capable of PCell plus one SCell [2] Number of UE that are capable of PCell plus tw o SCells [3] Number of UE that are capable of PCell plus three SCells [4] Number of UE that are capable of PCell plus four SCells The number of carrier aggregation capable UE measurement samples. The counter is stepped for each carrier aggregation capable pmCaCapableDlSamp UE measurement sample. Number of configured SCells for UE using this cell as their PCell This measurement provides the number of UEs configured for dow nlink carrier aggregation, out of the number of carrier [0] Number of carrier aggregation capable UE that are not configured w ith any SCell aggregation capable UEs, counted per the number of pmCaConfiguredDlSum [1] Number of carrier aggregation capable UE that are configured w ith one SCell component carriers (PCell and SCells) configured in each UE. [2] Number of carrier aggregation capable UE that are configured w ith tw o SCells [3] Number of carrier aggregation capable UE that are configured w ith three SCells [4] Number of carrier aggregation capable UE that are configured w ith four SCells The number of carrier aggregation configured UE measurement samples. The counter is stepped for each carrier aggregation pmCaConfiguredDlSamp configured UE measurement sample. Number of activated SCell, for UE using this cell as their PCell Stepped in each TTI for UEs using this cell as a PCell and w hich are configured w ith at least one SCell [0] Number of carrier aggregation configured UE that have no activated SCells pmCaActivatedDlSum [1] Number of carrier aggregation configured UE that have one activated SCell [2] Number of carrier aggregation configured UE that have tw o activated SCells [3] Number of carrier aggregation configured UE that have three activated SCells [4] Number of carrier aggregation configured UE that have four activated SCells Mean number of UE that have data scheduled on dow nlink, counted by the number of component Stepped in each TTI for UEs using this cell as a PCell and carriers simultaneously scheduled. UE is considered scheduled for carrier aggregation if the w hich are activated w ith at least one secondary component eNodeB has sent a PDCCH assignment indicating a PDSCH assignment. carrier SCell pmCaScheduledDlSum [0] Number of carrier aggregation activated UE that have one scheduled cell [1] Number of carrier aggregation activated UE that have tw o simultaneously scheduled cells [2] Number of carrier aggregation activated UE that have three simultaneously scheduled cells [3] Number of carrier aggregation activated UE that have four simultaneously scheduled cells [4] Number of carrier aggregation activated UE that have five simultaneously scheduled cells The total successfully transferred data volume on MAC level in the dow nlink for secondary cell kilobit (1 000 bits) The counter is incremented w hen a dow nlink transmission is pmRadioThpVolDlSCell traffic (i.e. the UE has another cell as its primary component carrier (PCell)). acknow ledged on HARQ level (only stepped for SCell traffic) This counter includes possible padding bits. The total successfully transferred data volume on MAC level in the dow nlink. kilobit (1 000 bits) The counter is incremented w hen a dow nlink transmission is pmRadioThpVolDl This counter includes possible padding bits. acknow ledged on HARQ level. Table 78: LTE-CA counter overview Classification C2 Page 52 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation pm EventNam e Event Type Event Param eter Nam e Event Description and Trigger The total number of times a dow nlink HARQ feedback w as not received from a UE for EVENT_PARAM_PER_SCELL_MAC_DTX_DL_QPSK a Transport Block w here QPSK and DTX are considered to be the reason. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. The total number of occasions w hen an uplink grant w as meant for HARQ transmission in the uplink direction w ith 16QAM, w here DTX is considered the reason EVENT_PARAM_PER_SCELL_MAC_DTX_DL_16QAM for no reception of HARQ in uplink in the eNB. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. The total number of occasions w hen an uplink grant w as meant for HARQ transmission in the uplink direction w ith 64QAM w here DTX is considered the reason EVENT_PARAM_PER_SCELL_MAC_DTX_DL_64QAM for no reception of HARQ in uplink in the eNB. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. The total number of unsuccessful HARQ transmissions in the dow nlink direction using EVENT_PARAM_SCELL_HARQ_DL_NACK_QPSK a QPSK modulation. Failure is based on the HARQ NACK from the UE. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. The total number of unsuccessful HARQ transmissions in the dow nlink direction using EVENT_PARAM_SCELL_HARQ_DL_NACK_16QAM a 16QAM modulation. Failure is based on the HARQ NACK from the UE. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. The total number of unsuccessful HARQ transmissions in the dow nlink direction using EVENT_PARAM_SCELL_HARQ_DL_NACK_64QAM a 64QAM modulation. Failure is based on the HARQ NACK from the UE. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. The total number of successful HARQ transmissions in the dow nlink direction using a EVENT_PARAM_SCELL_HARQ_DL_ACK_QPSK QPSK modulation. Successful is based on the HARQ ACK from the UE. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. The total number of successful HARQ transmissions in the dow nlink direction using a EVENT_PARAM_SCELL_HARQ_DL_ACK_16QAM 16QAM modulation. Successful is based on the HARQ ACK from the UE. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. The total number of successful HARQ transmissions in the dow nlink direction using a EVENT_PARAM_SCELL_HARQ_DL_ACK_64QAM 64QAM modulation.Successful is based on the HARQ ACK from the UE. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. INTERNAL_PER_CELL_TRAFFIC_REPORT Cell Aggregated time for the dow nlink delay measure in the MAC layer. One sample per MAC SDU. The time for each sample is betw een reception of a packet RLC PDU until EVENT_PARAM_PER_SCELL_DL_MAC_DELAY the packet is received by the UE or HARQ failure on this MAC SDU. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. The total successfully transferred data volume on MAC level in the dow nlink. EVENT_PARAM_SCELL_RADIOTHP_VOL_DL This counter includes possible padding bits. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. The total amount of physical resources used for transmission in the dow nlink. Both EVENT_PARAM_SCELL_RADIOTHP_RES_DL successful and unsuccessful transmissions are counted. Only the SCELL traffic is included, i.e. the UE has another cell as its PCell. The sum of the contributions from each UE in the cell of the number of ms w here EVENT_PARAM_PER_SCELL_SCHED_ACTIVITY_UE_DL SRB/DRB data has been scheduled in the DL for SCELL traffic, i.e. the UE has another cell as its PCell. EVENT_PARAM_GLOBAL_SCELL_ID Identity of the cell used as SCell, defined in MOM (eNB ID (20 bits) + Cell ID (8 bits) ) Number of DL assignments transmitted to UEs that use this cell as a secondary cell, EVENT_PARAM_PER_CELL_DL_ASSIGNMENT_CONF_SCELL for w hich the reception is confirmed by detecting a corresponding ACK or NACK for any transport block. Number of DL assignments transmitted to UEs that use this cell as the primary cell and EVENT_PARAM_PER_CELL_DL_ASSIGNMENT_CONF_PCELL do not have any bearer mapped to QCI 1, for w hich the reception is confirmed by detecting a corresponding ACK or NACK for any transport block. Number of DL assignments transmitted to Ues that use this cell as the primary cell and EVENT_PARAM_PER_CELL_DL_ASSIGNMENT_TX_PCELL do not have any bearer mapped to QCI 1. EVENT_PARAM_PER_CELL_DL_ASSIGNMENT_TX_SCELL Number of DL assignments transmitted to UEs that use this cell as a secondary cell. Number of DL assignments transmitted to UEs that use this cell as the primary cell and EVENT_PARAM_PER_CELL_DL_ASSIGNMENT_UNKNOWN_PCELL do not have any bearer mapped to QCI 1, for w hich the reception is unknow n. Number of DL assignments transmitted to UEs that use this cell as a secondary cell, EVENT_PARAM_PER_CELL_DL_ASSIGNMENT_UNKNOWN_SCELL for w hich the reception is unknow n. EVENT_PARAM_SCELL_CONFIG_RESULT result code for SCell configuration attempt EVENT_PARAM_SCELL_SELECTION_METHOD method used to select SCell Table 89: LTE-CA Event overview 4.4.4 Use Cases The following use cases can be identified for a LTE-CA capable UE: LTE-CA activated UE doing a MO / MT CSFB call LTE-CA configuration of a SCELL at attach, handover, re-establishment LTE-CA de-configuration of a SCELL due to release, switch to RRC_Idle Mode, handover, re- direction or SCELL lock LTE-CA activation and de-activation due to quality, load, or throughput LTE-CA Ping-Pong prevention for activation or deactivation when the timer is running LTE-CA mobility for intra-frequency, inter-frequency LTE handover, inter-RAT session continuity to WCDMA and inter-RAT cell reselection from WCDMA to LTE VoLTE call scenario for LTE-CA activated UE including also SRVCC handover 4.4.5 Test Plan A low level test-plan is delivered as a separate deliverable. This HLD will only provide the high level test groups to be covered in the low level test-plan, which are: Regression Configuration Functionality Mobility Throughput Negative Testing Load Counters & Events Classification C2 Page 53 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.4.6 Network Performance Indicators With the introduction of Carrier Aggregation (CA), there is some impact on some existing metrics. User throughput is measured on PDCP while cell throughput is observed on MAC level. Figure 3836: Aggregation of throughput on PDCP / MAC level PDCP counters (pmPdcpVol – service level) do reflect the situation for the group of UEs using a cell as PCell, which would look like for Cell A and Cell B as follows: o Cell A = A1 + A2 + A3 o Cell B = B1 + B2 + B3 MAC counters do reflect the situation in a cell regardless if scheduled UEs do use the cell as a PCell or as a SCell, which should look like for Cell A and Cell B as follows: pmRadioThpVol (cell level ) o Cell A = A1 + A2 + B1 o Cell B = A3 + B2 + B3 pmRadioThpVolSCell (cell level ) o Cell A = B1 o Cell B = A3 As described in 4.4.3.4.124.4.7.4.12 Performance ManagementPerformance Management depending on the amount of LTE-CA capable, configured and activated UEs, the throughput and latency KPIs can different output after LTE-CA enabling as the case before it was active. These KPIs can be calculated as follows: Equation 1: Throughput KPI formulas Classification C2 Page 54 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Equation 2: Latency KPI formulas As presented in 4.4.3.74.4.7.7 Counters & EventsCounters & Events a whole of new LTE-CA specific counters is introduced. These counters can be used to create new performance indicators which might be introduced in the performance management reports and tooling. Below an example is being displayed about how the output of the LTE-CA specific counters can show the distribution on a cell level of UEs that do have a SCELL configured but where the amount of active SCELLs is relatively low. The latter part might indicate that there is a low amount of data to be scheduled on the SCELLs configured. Figure 3937: Example of a possible LTE-CA UE distribution based on counter data 4.4.6.1 New LTE-CA specific performance indicators Based on the new counter set introduced for LTE-CA specifically the following performance indicators have been defined: [CA_CapableUE_pen1_Scell_%] = (100*pmCaCapableDlSum_1 / (pmCaCapableDlSum_0+pmCaCapableDlSum_1+pmCaCapableDlSum_2+pmCaCapableDlSum_3+pmCaCapableDlSum_4) [CA_CapableUE_pen2_Scell_%] = (100*pmCaCapableDlSum_2 / (pmCaCapableDlSum_0+pmCaCapableDlSum_1+pmCaCapableDlSum_2+pmCaCapableDlSum_3+pmCaCapableDlSum_4) [CA_CapableUE_pen3_Scell_%] = (100*pmCaCapableDlSum_3 / (pmCaCapableDlSum_0+pmCaCapableDlSum_1+pmCaCapableDlSum_2+pmCaCapableDlSum_3+pmCaCapableDlSum_4) [CA_CapableUE_pen4_Scell_%] = (100*pmCaCapableDlSum_4 / (pmCaCapableDlSum_0+pmCaCapableDlSum_1+pmCaCapableDlSum_2+pmCaCapableDlSum_3+pmCaCapableDlSum_4) [Num_CA_CapableUE_0_Scell_ROP] = pmCaCapableDlSum_0/(ROP * 12) [Num_CA_CapableUE_1_Scell_ROP] = pmCaCapableDlSum_1/(ROP * 12) [Num_CA_CapableUE_2_Scell_ROP] = pmCaCapableDlSum_2/(ROP * 12) [Num_CA_CapableUE_3_Scell_ROP] = pmCaCapableDlSum_3/(ROP * 12) [Num_CA_CapableUE_4_Scell_ROP] = pmCaCapableDlSum_4/(ROP * 12) Classification C2 Page 55 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation [CA_ConfiguredUE_1_Scell_%] = (100*pmCaConfiguredDlSum_1 / (pmCaConfiguredDlSum_0+pmCaConfiguredDlSum_1+pmCaConfiguredDlSum_2+pmCaConfiguredDlSum_3+pmCaConfiguredDlSum_4) [CA_ConfiguredUE_2_Scell_%] = (100*pmCaConfiguredDlSum_2 / (pmCaConfiguredDlSum_0+pmCaConfiguredDlSum_1+pmCaConfiguredDlSum_2+pmCaConfiguredDlSum_3+pmCaConfiguredDlSum_4) [CA_ConfiguredUE_3_Scell_%] = (100*pmCaConfiguredDlSum_3 / (pmCaConfiguredDlSum_0+pmCaConfiguredDlSum_1+pmCaConfiguredDlSum_2+pmCaConfiguredDlSum_3+pmCaConfiguredDlSum_4) [CA_ConfiguredUE_4_Scell_%] = (100*pmCaConfiguredDlSum_4 / (pmCaConfiguredDlSum_0+pmCaConfiguredDlSum_1+pmCaConfiguredDlSum_2+pmCaConfiguredDlSum_3+pmCaConfiguredDlSum_4) [Num_CA_ConfiguredUE_0_Scell_ROP] = pmCaConfiguredDlSum_0/(ROP * 12) [Num_CA_ConfiguredUE_0_Scell_ROP] = pmCaConfiguredDlSum_1/(ROP * 12) [Num_CA_ConfiguredUE_0_Scell_ROP] = pmCaConfiguredDlSum_2/(ROP * 12) [Num_CA_ConfiguredUE_0_Scell_ROP] = pmCaConfiguredDlSum_3/(ROP * 12) [Num_CA_ConfiguredUE_0_Scell_ROP] = pmCaConfiguredDlSum_4/(ROP * 12) Since feature “FAJ 121 3046, Carrier Aggregation” does only support 1 static SCELL configuration per PCELL it is unlikely to see stepping of those counters for UEs having more than one SCELL per PCELL. Also in the case of introduction of feature “FAJ 121 3063, Dynamic SCell Selection for Carrier Aggregation” it is unlikely to see these counters being stepped since the UE will still use only one SCELL at a time but it might be more dynamically assigned based on measurements and more than a single static SCELL configuration will be possible. A change is expected to be observed when carrier aggregation will be done over more than two component carriers. For Vodafone NL specifically it might be applicable when carrier aggregation done over LTE800, LTE1800 and LTE2600. [CA_ActivatedUE_0_Scell_%] = (100*pmCaActivatedDlSum_0 / (pmCaActivatedDlSum_0+pmCaActivatedDlSum_1+pmCaActivatedDlSum_2+pmCaActivatedDlSum_3+pmCaActivatedDlSum_4) [CA_ActivatedUE_1_Scell_%] = (100*pmCaActivatedDlSum_1 / (pmCaActivatedDlSum_0+pmCaActivatedDlSum_1+pmCaActivatedDlSum_2+pmCaActivatedDlSum_3+pmCaActivatedDlSum_4) [CA_ActivatedUE_2_Scell_%] = (100*pmCaActivatedDlSum_2 / (pmCaActivatedDlSum_0+pmCaActivatedDlSum_1+pmCaActivatedDlSum_2+pmCaActivatedDlSum_3+pmCaActivatedDlSum_4) [CA_ActivatedUE_3_Scell_%] = (100*pmCaActivatedDlSum_3 / (pmCaActivatedDlSum_0+pmCaActivatedDlSum_1+pmCaActivatedDlSum_2+pmCaActivatedDlSum_3+pmCaActivatedDlSum_4) [CA_ActivatedUE_4_Scell_%] = (100*pmCaActivatedDlSum_4 / (pmCaActivatedDlSum_0+pmCaActivatedDlSum_1+pmCaActivatedDlSum_2+pmCaActivatedDlSum_3+pmCaActivatedDlSum_4) [Num_CA_ActivatedUE_0_Scell_ROP] = pmCaActivatedDlSum_0/(ROP *60*1000) [Num_CA_ActivatedUE_1_Scell_ROP] = pmCaActivatedDlSum_1/(ROP *60*1000) [Num_CA_ActivatedUE_2_Scell_ROP] = pmCaActivatedDlSum_2/(ROP *60*1000) [Num_CA_ActivatedUE_3_Scell_ROP] = pmCaActivatedDlSum_3/(ROP *60*1000) [Num_CA_ActivatedUE_4_Scell_ROP] = pmCaActivatedDlSum_4/(ROP *60*1000) Since feature “FAJ 121 3046, Carrier Aggregation” does only support 1 static SCELL configuration per PCELL it is unlikely to see stepping of those counters for UEs having more than one SCELL per PCELL. Also in the case of introduction of feature “FAJ 121 3063, Dynamic SCell Selection for Carrier Aggregation” it is unlikely to see these counters being stepped since the UE will still use only one SCELL at a time but it might be more dynamically assigned based on measurements and more than a single static SCELL configuration will be possible. A change is expected to be observed when carrier aggregation will be done over more than two component carriers. For Vodafone NL specifically it might be applicable when carrier aggregation done over LTE800, LTE1800 and LTE2600. [CA_ScheduledUE_1_Cell_%] = (100*pmCaScheduledDlSum_0 / (pmCaScheduledDlSum_0+pmCaScheduledDlSum_1+pmCaScheduledDlSum_2+pmCaScheduledDlSum_3+pmCaScheduledDlSum_4) [CA_ScheduledUE_2_Cell_%] = (100*pmCaScheduledDlSum_1 / (pmCaScheduledDlSum_0+pmCaScheduledDlSum_1+pmCaScheduledDlSum_2+pmCaScheduledDlSum_3+pmCaScheduledDlSum_4) [CA_ScheduledUE_3_Cell_%] = (100*pmCaScheduledDlSum_2 / (pmCaScheduledDlSum_0+pmCaScheduledDlSum_1+pmCaScheduledDlSum_2+pmCaScheduledDlSum_3+pmCaScheduledDlSum_4) [CA_ScheduledUE_4_Cell_%] = (100*pmCaScheduledDlSum_3 / (pmCaScheduledDlSum_0+pmCaScheduledDlSum_1+pmCaScheduledDlSum_2+pmCaScheduledDlSum_3+pmCaScheduledDlSum_4) Classification C2 Page 56 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation [CA_ScheduledUE_5_Cell_%] = (100*pmCaScheduledDlSum_4 / (pmCaScheduledDlSum_0+pmCaScheduledDlSum_1+pmCaScheduledDlSum_2+pmCaScheduledDlSum_3+pmCaScheduledDlSum_4) [Num_CA_ScheduledUE_1_Cell_ROP] = pmCaScheduledDlSum_0/(ROP *60*1000) [Num_CA_ScheduledUE_2_Cell_ROP] = pmCaScheduledDlSum_1/(ROP *60*1000) [Num_CA_ScheduledUE_3_Cell_ROP] = pmCaScheduledDlSum_2/(ROP *60*1000) [Num_CA_ScheduledUE_4_Cell_ROP] = pmCaScheduledDlSum_3/(ROP *60*1000) [Num_CA_ScheduledUE_5_Cell_ROP] = pmCaScheduledDlSum_4/(ROP *60*1000) Since feature “FAJ 121 3046, Carrier Aggregation” does only support 1 static SCELL configuration per PCELL it is unlikely to see stepping of those counters for UEs having more than one SCELL per PCELL. Also in the case of introduction of feature “FAJ 121 3063, Dynamic SCell Selection for Carrier Aggregation” it is unlikely to see these counters being stepped since the UE will still use only one SCELL at a time but it might be more dynamically assigned based on measurements and more than a single static SCELL configuration will be possible. A change is expected to be observed when carrier aggregation will be done over more than two component carriers. For Vodafone NL specifically it might be applicable when carrier aggregation done over LTE800, LTE1800 and LTE2600. [SCell Data Volume Ratio%] = (pmRadioThpVolDlSCell / pmRadioThpVolDl) 4.4.7 Operational readiness Starting with the disclaimer that this HLD does not cover the complete design or impact analysis for operational readiness or a full operation introduction of LTE-CA. The RAN impacts due to introduction of LTE-CA related to performance and configuration management are covered in chapters 4.4.3.4.124.4.7.4.12 Performance ManagementPerformance Management and 4.4.3.4.134.4.7.4.13 Configuration ManagementConfiguration Management. RAN impact with regards to fault management are not directly foreseen specifically for introduction of feature “FAJ 121 3046, Carrier Aggregation”. When it comes to dual-band DUS introduction there is also operational impact also on fault management since 6- cell are deployed on a single DUS31 or DUS41. It is important for operational readiness and implementation to implement the topics as addressed in the impact analysis chapters for configuration and performance management. After pilot and roll-out also time is required to learn about the exact network impact and if any optimization activities are required to optimize the set of recommended parameters as suggested in this HLD. The network impact is to be expected low at launch of LTE-CA due to the low penetration of LTE-CA devices in the Vodafone NL network. However when this penetration starts to grow also the impact will become more visible and a better understanding of those possible impacts and which optimization activities might be required to control, eliminate and / or optimize these effects. Furthermore, next to the low LTE-CA capable UE penetration the expected impact is low when LTE-CA is launched since there is no impact on network or UE behavior for the big chunk of all legacy 3GPP release 8 LTE non-CA capable devices. Classification C2 Page 57 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.5 High level design for increasing the LTE spectrum from 15 to 20 MHz Steps to take: 1. Remove GSM1800 in border areas 2. Move LTE1800 center frequency to the middle of the LTE1800 band 3. Development deployment policy mixed operation LTE1800 on 15MHz + GSM1800 on 5 MHZ versus LTE1800 on 20 MHz 4. Migrate traffic from GSM1800 to GSM900 5. Implementation of LTE1800 in 20 MHz where possible Further details to be provided. 4.6 High Level Design Access Transmission upgrade [Dennis de bruin] The increased capacity demands on the access transmission by the implementation of LTE-A can be split into separated parts: microwave links, connection to the PTN network and the PTN network itself. 4.6.1 Microwave links The planned capacity for the microwave links should be able to handle the peak capacity demands. Furthermore, one is to prevent the amount of overbooking as much as possible. This gives rise to two additions to the existing Rules & Guidelines: Capacity should match the demands, thus microwave links handling sites that have LTE800 and LTE1800 are to be planned using 56 MHz bandwidth with the highest possible modulation, preferably on 256QAM. The amount of hops per site is to be minimized for all locations, but this urgency increases along with the increased capacity demands per site. This is not to handle the peak, but to ensure that the average throughput for each end user is not affect too much due to overbooking. Both items are to be altered in the Rules & Guidelines and valid from that moment on. 4.6.2 Physical port capacity The physical port capacity, specifically between the microwave links and the PTN equipment, is quite often only capable of handling 100 Mb/s (FE interfaces). In order to ensure that the actual peak rate of LTE-A is handled properly, these are to be altered into 1 Gb/s (GE interfaces). The reason for the limited capacity was to avoid large useless expenses, since the PTN equipment is planned to be exchanged for ATN equipment shortly, and then the increase in capacity per port would be handled much easier. However, since the roll out of LTE-A is advancing faster, the existing PTN equipment is to be adjusted. 4.6.3 PTN network capacity The PTN network is limited in capacity at two different items: dark fiber rings and managed fiber connections. 4.6.3.1 Dark fiber rings capacity The dark fiber rings, connecting the FttS locations have a capacity of 1 Gb/s. Therefore the choice has been made, since the peak capacity demand can easily be handled, to not to upgrade this part of the network. Classification C2 Page 58 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation As mentioned earlier, the exchange of the existing PTN equipment by ATN equipment, will increase the capacity tenfold: 10 Gb/s for the rings. Since this will be done relatively shortly, the expectation is that the current capacity will be sufficient. 4.6.3.2 Managed fiber capacity The current managed fiber (KPN) capacity for all sites that have any LTE equipment is 200 Mb/s. As this is nearly sufficient for locations where carrier aggregation is taking place, the decision has been made not to upgrade the capacity at this moment. When one or more sites require a capacity upgrade, this will be done as fast as possible to ensure the proper capacity matching the demand of the end users. 4.7 Impact analyses EPC other & IP GW and Core In this paragraph in impact of LTE-CA deployment is describe on the EPC and IP Core nodes and related interfaces. Besides the Max bit rate provisioning and SGSN SW release upgrade (see paragraph 4.7.1) Capacity dimensioning is the common denominator in the core network when it comes to LTE-CA deployment. The higher end-user data rates will further increase the capacity demand in the EPC, while the capacity for a number of nodes is already reaching its limits. Not having the capacity available will impact the end user data rates and the maximum throughput that can be reached with LTE-CA. Below the impact per node and/or interface is described: 4.7.1 SGSN/MME [Rob Hekkens]: The impact on SGSN/MME is related to QoS Stickiness. The so called “QoS stickiness” issue was introduced after the LTE launch. QoS stickiness means that if a 4G subscriber is camped on the 2G or 3G network and move to 4G, the subscriber sticks to the QoS settings he got on the 2G/3G network. There is no QoS modification in place. In this case the 4G subscriber won’t get the LTE experiences e.g. low max bit rate. As a temporary work around Vodafone aligned the provisioned HLR and HSS max bit rate values. The temporary work around is sufficient for downlink speeds up to 84 Mbps. Higher speeds are kept by the SGSN due to the QoS policymap. The SGSN policymap limits also the uplink speed to 8 Mbps. This can’t be modified. To avoid poor end user experiences on the uplink data, the policing function is disabled in the PGW. Theoretically end users can get a higher uplink speed compare to the provisioned value. LTE advance makes it possible to have peak rates up till 225 Mbps. In the current SGSN-MME release 12A, the high peak rates are only possible when the subscriber directly attach to LTE. In case of mobility scenario’s e.g. bad LTE coverage or CSFB the subscriber performance a TAU and the speed is restricted to 84 Mbps as earlier described. To avoid this behaviour a new SGSN-MME release is required. From SGSN-MME R13B and onwards the MME performs a QoS modification before the TAU procedure is completed. This is done only if there is no PGW-initiated bearer QoS modification. During the QoS modification procedure the HSS profile values are used which give the proper max bitrate values to the end user. The VF-Global guidelines describe that SGSN-MME 14B is selected as VF preferred release. It’s recommended to introduce this release in order to give the VF-NL subscribers the best user experiences. Classification C2 Page 59 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 4.7.2 SGW/PGW [Taco Amory]: Risk on SGW/PGW capacity. SGW/PGW reach 80% limit by mid September based on extrapolation growth. Current hardware is replaced Q2/Q3 FY2015. LTE-Advanced maximum speed limitation in current PGW software release (StarOSR14.0). Limitation is depending on load, amount of ruledefs in the rulebase. No information is on max throughput for StarOS R14 is available. Limitation is solved in next software releases. StarOS R15 is implemented Q2/Q3 FY2015. Speeds are measured with 540 Bytes packet size. VF-NL has currently around 40 ruledef configured in a rulebase. 4.7.3 PCRF [Taco Amory]: PCRF capacity risk:. With the introduction of CTE and fast 4G rollout, the TPS (transactions per second) is growing rapidly. Around Augustus we are losing redundancy due to TPS increase. With the current data bundles and the introduction of LTE-Advanced, the TPS will increase much faster. PCRF needs to be expanded. 4.7.3.1 GA interface The Ga interfaces resides between the GGSN and EMM. The impact of LTE-CA is that a single user can create multiple CDR partials per second (up to 6 per second). Both on the GGSN site and on the MME site the object owners Taco Amory and Guido Baltus stated that they don’t expect any issue with this. 4.7.4 HSS/HLR technical solution for providing max bit rates [Jaap Bij] With the current software releases on the HSS, CSDB & Linux HLR's the following max bitrates are possible: Linux HLR’s – 256 MBps CSDB HLR-FE – 256 MBps HSS – 4000 MBps For this no upgrades are needed. 4.7.5 MSP [Peter Nijland]: Risk MSP capacity is insufficient to meet traffic growth. Interface MSP capacity with core expected to be insufficient. At this moment the link capacity between the Loadbalancer and the MSP is one 10G fiber. The overall MSP capacity of the MSP is designed at 5 Gbps. It is expected the LTE-A additional peak throughput on top on the 4G traffic growth will exceed the link- and MSP capacity. An extra 10G fiber is needed (no free 10G Loadbalancer ports) and several ASM300 blades. Also MSP TCP buffers sizes need be tweaked. 4.7.6 GRX interface [Erik Mattheij]: Classification C2 Page 60 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation The GRX interface has sufficient capacity. No impact foreseen by LTE-CA enabling. 4.7.7 GRX firewall [Frank Jansen] and LAN-taps: The GRX Firewall is facing capacity bottlenecks due to the organic growth of traffic. To absorb this growth expansions are required, which also has an impact of the LAN tap dimensioning that needs to move to 10Gbps interface instead of 1GBps interface. The LTE-CA functionality enabling does not have an impact on the GRX firewall 4.7.8 Wireless Security Gateway [Raymond Keerssemeeckers]: WSG interface capacity has a limit of 20Gbps Each SAMI blade, to which 500 enode-B’s can be connected, has a throughput limit of 2Gbps. In case SAMI blade capacity becomes a bottlenecks, more SAMI blades are needed with less enode-Bs connected per blade. Current load per SAMI blade is 5%, so there is room for growth The LTE-CA enode-B configuration has an impact on the traffic load per enode-B, because with LTE-CA both LTE800 and LTE1800 will be connected to the same logical enode-B. 800 and 1800 now have different certificates. IPSec tunnels originate for the DU to the SecGW and every DU has at this moment one IPsec for S1/X2 and one for OAM. Combining 800 and 1800 will mean that only 1 certificate is needed. Even when working with multiple Certificates, One DU entity can have multiple certificates and are accepted by the SecGW certificate since they use the same root-CA. No impact. 4.7.9 End to end testing impact [Michel van Kan] The measurement protocol has impact on the results: Will the tests be performed by a single TCP download, or multiple TCP downloads? Which protocol is used: FTP and/or HTTP? FTP server capacity, buffer settings etc (to support max bit rate) The detailed measurement protocol is to be determined. 4.8 High level test set-up design for E2E performance testing The goal of the end to end performance testing is to verify: 1. Verification of the maximum throughput in ideal radio circumstances 2. Live network trial for verification and characterisation of the live network performance 4.8.1 Verification of the maximum throughput in ideal radio circumstances First an initial test will be performed to verify if the theoretical speeds can be reached in ideal radio environments. A enode-B located at VTC will be connected to the live EPC. Throughput testing will be performed in ideal radio conditions. If the expected throughput cannot be reached then a follow-up activity will be defined in which a multi- disciplinary team will perform an in-depth investigation to find the bottlenecks. In addition the throughput will be measured with variable radio conditions in order to determine the relation between maximum throughput and a non-ideal radio environment. 4.8.2 Live network trial for verification and characterisation of the live network performance Live network testing will be performed to verify the LTE-CA performance. Classification C2 Page 61 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Goals are: Get a picture of practical speeds that can be realized. LTE-CA functional performance verification Verification performance of non LTE-CA users Verification of counter based PIs 5. Impact on network quality and KPIs COVERED IN HLD, please refer to 4.4.3.4.12 Performance ManagementPerformance Management and 4.4.6 Network Performance Indicators. 6. Security In this chapter the impact on the following sub areas is described: Fraud & Theft; No Impact Lawful intercept; The terminal is logically connected to the primary cell, which is the same cell as if the terminal would not use LTE-CA. So for tracking of customers by cell ID there will not be any impact. Physical security; No impact Information security. No impact 7. Service Layer Impact There is an impact with billing and provisioning. This will be handled in a separate IT project, which will be driven by the business side of Vodafone. The technical impact on the billing is briefly described below. Within the separate IT project this will be described in more detail. 7.1.1 Billing [Guido Baltus]: The higher end user data rats provided by LTE-CA will also lead to a higher frequency of partial CDRs going via the GGSN via the EMM to Gemini. (later Unify) Currently the EMM has a capacity bottleneck due to the organic growth of data traffic. This will be solved outside the LTE-CA project Current settings: gemini live APN postpaid egcdr threshold interval 900 15 minutes for ipcm egcdr threshold volume total 1073741824 1Gb with 3Gb in EMM memory leads to max 4Gb, which is the CDR field limit. unify live apn egcdr threshold interval 22200 6.2 hours egcdr threshold volume downlink 5000000 4.8Mb exceptions: - Vlive apn Gemini (IPCM): 15 minuten, 1Gb - Vlive apn prepaid: 15 minuten, geen volume limit 4.8Mbyte/sec with LTE+ (220Mbit/s) or LTE (42Mbit/s) would result in ~6 or ~1 partial CDR/second. Classification C2 Page 62 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation As EMM already has problems with 1 partial per 15 minutes for the Gemini live APN subscriber base (assuming there are not that many subs at the moment that use more than one Gb per 15 minutes, so closure is time based), we would definitely run into problems with this setting in November (Unify migration). We need to set this to a sensible value. It has to be said that the Unify EMM config can probably handle more CDRs than now, as the Unify processing is not that complex. But it is difficult to say how many more. 8. Process and Guideline impact The impact on processes and guidelines is described below: Impact Dual band DUS configuration: (pre) integration of sites must be adapted Integration procedures for field and CM. There is no impact to the Cell Naming Convention, Maximo and inventory tools, since the LTE-CA definition is based on the PCell. CGI impact, because CGI is made up of enode-B and cell ID. With 6 cells the Cell-IDs defined in the network for LTE1800 should be changed so that become unique for the site. SIU: only one DU connected, Script changes may be required. Wiring and config for site with both LTE800 and 1800 need to be changed. Sync planning: Amount of PTP sync sources required in the network becomes half for single DUS dual band sites, this could delay sync server investment! Planning impact of rollout sites results in less pts sync (server) requirement. Transmission department can recalculate their needs. LTE-CA enabling process: The enabling of LTE-CA on sites with multiple LTE frequency bands will always be performed by a project. Therefore no site modification type needs to be determined. A guideline will be made describing when and how the LTE-CA SW feature. LTE-CA parameter optimization and capacity expansion planning: Parameter optimizations to the LTE-CA cell configurations will not be included in this project. Capacity expansion planning will be included in a separate activity outside this project that covers LTE capacity management in general. 9. Operations 9.1 Network Management System There is no OSS impact for the deployment of LTE RAN L14A roll-out and the SW features roll-out in this project. Classification C2 Page 63 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation The LTE-CA program has a dependency with the MME/SGSN SW upgrade to R14B. MME/SGSN 14B has a dependency with OSS14B. The roll-out of OSS14B is here on the critical path. In order to reduce the lead time for the MME/SGSN R14B roll-out alternative OSS solutions need to be evaluated. Options are to try out if the current OSS SW (R13 B) can be used instead, although this is not officially supported by Ericsson. Another option could be to temporarily use the VTC OSS, which will be earlier put on R14B than the live OSS. See also paragraph 4.4.3.4.7 in the HLD section. 9.2 Operational Support Systems There are no SAS requirements for the roll-out of LTE-CA. RAN and Core engineering teams have the strong wish to upgrade the LTE test site (site 707 located at switch building Arnhem) to be upgraded with LTE-CA capability. This site is included to the frozen list of LTE-CA site roll-out. Currently a 24/7 E2E measurement system is installed in switch building Arnhem based on TEMS with RTUs. When TEMS RTU’s with LTE-CA support become available, the existing RTU should be upgraded to a version that does LTE-CA. This will enable 24/7 live network speed testing in ideal radio circumstances. VF group has made a vendor selection for a new E2E LTE measurement tool. VF-NL will follow the group selection. Out of scope: periodic drive testing to verify LTE-CA performance in mobility 9.3 Performance Management 9.3.1 Technology Chain Management & Life Cycle Management The TCM requirements are as follows: Other services may not be impacted in a negative way by the project (e.g. voice on 3G) TEMS system should be able to measure LTE-A quality, especially it should be able to measure the high speeds which LTE-A offers (probes and content server!). Ookla server provided by Vodafone Netherlands should be able to handle the high speeds. o Discuss with Ookla how to set-up parameters and speed gauge o Determine whether to upgrade to 10Gbps interfaces Counter KPIs for LTE-A volume and quality (NAR, NRR, NIR) should be provided and reported. Which counter KPIs need to be reported can be decided later when it's clear which counters are available for LTE-A (during clarification sessions?). Decision is made jointly by TCM, Engineering and PM. E/// PM should be able to manage the performance of LTE-A. Classification C2 Page 64 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 9.3.2 ENN performance management Covered in HLD, please refer to 4.4.3.4.12 Performance ManagementPERFORMANCE MANAGEMENT. 9.3.3 Capacity Management Covered IN HLD, please refer to 4.4.3.4.4 Capacity ManagementCapacity Management. 9.3.4 SLA Monitoring Not applicable. 9.4 Tooling Tool Impact Asset tool: generally Maximo, in Tool should be able to administrate the LTE-CA HW future One Inventory configuration. Impact on Cell Naming Convention, definition and sector numbering. (i.e. Single DUS with 2 LTE frequencies and 6 cells for all possible HW combinations). Radio Planning tool: generally ATOL No impact IP planning (IP admin) Impact, LTE-CA will have a different IP configuration Transmission tools Impact related to planning of higher speeds and increased spectrum. Tooling adjusted required (activity ongoing) Configuration tools Impact tbd Cell provisioning tool Impact tbd Measurement tools TEMSi – upgrade for LTE-CA support (Michel to specify) TEMS Automatic will not be upgraded, as TEMS automatic is planned to be phased out. VF-Group reporting is currently limited to the KPI reporting tools reporting of the amount of LTE-CA enabled sites. No requirements for VF-Europe KPI reporting are present today. When new VF-Europe LTE-CA specific KPIS are requested, they will be implemented in due time. (out of project scope) LTE-CA coverage plot generation The tools for plot generation should be adjusted that LTE-CA coverage plots can be made. This means that the combined LTE 800+1800 coverage is shown for which both frequency bands are transmitted from the same site. Classification C2 Page 65 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 9.5 Fault Management The impact is limited to the introduction of the new RBS HW configurations. Changes element management regarding the LTE-CA Hardware configuration will be communicated with Marius Pintican, teamleader back office. 9.5.1 Element Management The impact is limited to the introduction of the new RBS HW configurations. Changes element management regarding the LTE-CA Hardware configuration will be communicated with Marius Pintican, teamleader back office. 9.5.2 Service Management The non-functional requirements from SMC-BO are limited to: Providing of LTE-CA capable handsets with test SIMs to the SMC-BO team Providing project and design information to the SMC-BO and DNOC BO _RAN teams. 9.6 Incident Management Not applicable 9.7 Problem Management Not applicable 9.8 Configuration Management Covered IN HLD, please refer to 4.4.3.4.13 Configuration ManagementConfiguration Management. 9.9 Field Management Field Management (Field Service) must be updated with the new configurations plus their integration documents. See input in chapter 3.4. 9.10 Spare Parts Management The DUS41 is the only new hardware type that will be introduced. Spare Parts management introduction will be managened by ENN (Frans Cöp) Classification C2 Page 66 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 10. Implementation 10.1 Dual-band DUS introduction: 10.1.1 Testing in VTC In order to test this configuration the current VTC RBS setup must be adapted to the dual band situation for all relevant radio config. That is: RU800 + RU1800, RU800 + RRU1800, AIR800 + RRU1800, AIR800 + RRU1800 in both normal and mixed mode operation. 10.1.1.1 Test Object List (TOL) Shall include negative testing, to understand restarting and failure of RU. Shall include functional testing. TOL to be defined. 10.1.2 Pilot in Live Network List tests included in the pilot. Testing needs to be on pilot sites for all radio configurations. 10.1.3 Testing in Live Network After successful pilot site, no further live network testing is required 10.1.4 Deployment in Live Network For live network deployment (so site rollout) as separate HLD is made 10.2 Testing in VTC for LTE-CA SW introduction The high level test plan is covered already in this HLD. The low level test plan is delivered as a separate deliverable in an Excel format. This low level test plan is used for test execution at VTC. On a time-box approach test execution is started where the main focus will be at the start on regression testing, configuration, functionality, mobility testing and throughput. Less priority is given to negative testing, counter and event verification and load testing. For successful test execution at VTC a special test set-up is required, which is listed below: o DUS31, single sector LTE800 + LTE1800, CA configured o DUS41, two sector LTE800 + LTE1800, CA configured o DUL20, one sector for mobility scenario between CA and non-CA o WCDMA sector to verify inter-RAT mobility and CSFB to WCDMA o GERAN sector to verify inter-RAT mobility and CSFB to GERAN (less priority) o TEMS-I with legacy UE and one more additional legacy UE for load testing o Two LTE-CA devices to perform functionality, mobility and load testing o All eNodeBs on latest L14A IP6 software level o 4 SIMs, two provisioned for LTE-CA peak throughputs o Shielded room with all the proper signals patched to the shielded room and connected to handover box o FTP sever o iPerf server o Wireshark plus laptop to trace S1AP signaling o IMSIs should be un-ciphered to be able to decode S1 messaging Classification C2 Page 67 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation For verification of the test results we will use wireshark tracing, eNodeB layer 3 tracing and if possible in- depth baseband tracing to check for activation and deactivation of LTE-CA and actual scheduling over more than one component carrier. Throughput will be verified with NetPerSec since we cannot use any TEMS-I system for LTE-CA analysis since there is not the proper TEMS software (needs TEMS 16) available and no UE is currently supported by ASCOM to work in combination with TEMS 16 software. Only legacy behavior can be verified by using TEMS 15 plus a Sony UE to check for layer 3 messaging and throughput verification on different levels such as layer 1, RLC, etc. 10.2.1 Test Object List (TOL) COVERED IN HLD, please refer to 4.4.54.4.9 Test PlanTest Plan Low level test plan is delivered as a separate excel TOL (low level) 10.3 Pilot in Live Network The approach for verification of lab test results cannot be used in the live network since baseband tracing is too demanding to be performed in the live network. No wireshark tracing is available since the IMSIs will be ciphered anyhow and a lot of different user traffic flows will be captured. Basic layer 3 tracing on the involved eNodeBs is possible but also in this case it is a challenge to capture the particular IMSI used for pilot verification. Therefore a more basic approach is required and suggested since neither TEMS-Automatic nor TEMS- Investigation software in combination with a LTE-CA capable UE is available for pilot verification. It is important during pilot verification to ensure that legacy users having non-CA capable UEs do work as before. This can be done through counter verification as well as static and mobility drive testing between CA-CA, nonCA-CA, CA-nonCA cells using TEMS-Investigation, which allows us to check on a detailed level layer 3 message level and also other aspects as number of radio blocks used, MCS, throughput on several levels. For regression testing of legacy non-CA UE behavior the following tests are recommended to be executed: Static throughput test – lock on LTE1800 / lock on LTE800 important to have attach to 4G to avoid QoS stickiness issue and possible limitation of maximum throughput of 84Mbps Intra- (both LTE800 and LTE1800) and Inter-Frequency (LTE1800 to LTE800) LTE handovers for CA-CA, nonCA-CA, CA-nonCA mobility scenarios Inter-RAT cell reselection from LTE to UTRAN and vice versa Session continuity from LTE to WCDMA CSFB MO and MT call For verification of LTE-CA static and mobility live network verification the following test are recommended to be executed: Static throughput test – lock on LTE1800 / lock on LTE800 important to have attach to 4G to avoid QoS stickiness issue and possible limitation of maximum throughput of 84Mbps. Reason to lock first on LTE800 and the second time on LTE1800 is to verify that LTE-CA functions for both scenarios in the case where the LTE800 is the PCELL and the case where LTE1800 is the PCELL. Parallel throughput test of a LTE-CA and a non-CA LTE capable UE to check that both can co-exist next to each other and the data throughput of the LTE-CA capable UE is significantly higher than the non-CA capable UE. Start in best possible RF conditions with the LTE-CA high peak rate download and slightly move towards the edge of the LTE coverage. It is recommended to have whether a popcorn site or an area where no intra- or inter-frequency handover is triggered. Classification C2 Page 68 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Intra- (both LTE800 and LTE1800) and Inter-Frequency (LTE1800 to LTE800) LTE handovers for CA-CA, nonCA-CA, CA-nonCA mobility scenarios Inter-RAT cell reselection from LTE to UTRAN and vice versa. After this inter-RAT reselection the maximum throughput is limited to 84Mbps due to the QoS stickiness issue Session continuity from LTE to WCDMA CSFB MO and MT call The set of performance indicators as specified in chapter 4.4.64.4.10 Network Performance Indicators can be used to verify the use of SCELLs, activation of SCELLs and actual scheduling of data on more than one component carrier. It is important to run the legacy and LTE-CA throughput verifications close after each other in order to observe a clear gain in peak throughput in the case where LTE-CA is used. Since it concerns the live network it might happen that even LTE-CA throughput is still significantly higher than the throughput of a non-CA capable UE but is still below the throughput limitation of 84Mbps due to other traffic load or because the throughput of both carrier aggregated does not cross the total of 84Mbps. Another fact is that there are not many LTE-CA commercial devices available yet and may have an affect due to unknown issues on live network verification results. It is recommended to do the LTE-CA live network verification with more than one single LTE-CA capable UE, preferably of several brands and for sure with a different chipset. At this moment there are three possible terminals which are LTE-CA capable and could be used for LTE-CA live network verification: Huawei B4000 Huawei R226 (currently not performing well on LTE1800) Samsung S5 (currently not commercial available yet and multiple software updates to be expected) Since we do not have TEMS-I available we should check mainly with PIs through counters, manual observation and end-user experience of the test engineer and finally throughput graphs with a NetPerSec like application. Of course for legacy UEs TEMS-I can be used for more in-depth analysis and the general PIs used for current LTE network monitoring can indicate any change in network behavior, such as handover success rates, NAR, NRR, throughput, etc. A more sophisticated way to analyze LTE-CA is through eNodeB tracing. As stated earlier this cannot be done by baseband traces since they are too demanding for a live network. However normal layer 3 eNodeB or UE traces might be considered. However it is recommended to use those only in case of trouble shooting since a lot of traffic is expected in the eNodeB trace and not much experience is available with regards to the UE tracing. The following deliverables of a live network verification are proposed: Throughput graphs for static measurements for LTE800, LTE1800, LTE800 + LTE1800, LTE800 + LTE1800 CA Throughput graphs as function of RF conditions when moving out of LTE coverage for non-CA and CA capable UE Simultaneous throughput graph of static and as function of RF condition for a non-CA and CA capable UE LTE-CA specific PI report Normal LTE network PI report (e.g. throughput, NAR, NRR, handover success rate, RRC Connection set-up success rates, etc.) TEMS log-files for Legacy UEs eNodeB traces (only in case of trouble shooting) UE traces (only in case of trouble shooting) Finally one could distinguish between fast mobility and slow mobility by means of a drive test versus a walk test, for example to verify LTE-CA performance when moving deep indoors. Classification C2 Page 69 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation 10.4 Testing in Live Network This is covered in the 10.3 10.5 Deployment in Live Network The deployment strategy is to roll-out LTE-CA as described in paragraph 3.1 Further enabling of LTE-CA on live sites LTE800+LTE1800 not yet in scope of this project will either be included into this project by a change request and will be done an in a follow-up project. New sites having both LTE800 and LTE1800 present will by default be configured as LTE-CA site. 10.6 Deployment in Live Network The deployment strategy is to roll-out LTE-CA as described in paragraph 3.1 Further enabling of LTE-CA on live sites LTE800+LTE1800 not yet in scope of this project will either be included into this project by a change request and will be done an in a follow-up project. New sites having both LTE800 and LTE1800 present will by default be configured as LTE-CA site. 10.7 Completing Actions Describe all actions that must be taken after deployment in the network. 11. Disaster Recovery & 24/90 Not applicable. 12. Training Training is required by field operations and NOC. However, explaining documents might be enough. 13. High Level Project Plan Construct high level project plan based on information above (fill Project initiation Document template (PID)). 14. Contact Information List here all the teams that contributed to the HLD through requirements, designs or other inputs. Department / Team Activity Contact Classification C2 Page 70 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation Access Engineering HLD creation for RAN and Wim Ockeloen, Marco Access TX Meerten, Dennis de Bruin, Francis Kanebi, Bert Spoelstra Network Architecture Requirements input Ralph Thijssen, Bogdan Mucuta Core Engineering Impact analysis core Hay Ritzen, Rob Hekkens 15. Main Contributors per Document Section Section Main Contributor 4.3.2 HLD for Dual band DUS deployment [Marco Marco Meerten Meerten] 4.4 High Level Design for carrier aggregation SW Bert Spoelstra functionality [Bert Spoelstra] 4.6 High Level Design Access Transmission Dennis de Bruin upgrade [Dennis de bruin] 4.7.4 HSS/HLR technical solution for providing Jaap Bij max bit rates [Jaap Bij] 4.7 Impact analyses EPC other & IP GW and Core Rob Hekkens, Taco Amory, Peter Nijland, 16. Glossary 2G 2nd Generation (cellular systems) NAS Non Access Stratum 3G 3rd Generation (cellular systems) OSS-RC Operations Support System - Radio and Core 3GPP 3rd Generation Partnership Project PCC Primary Control Channel ACK Acknowledgement PDCCH Physical Downlink Control Channel AM Acknowledged Mode PDN Packet Data Network AMBR Aggregated Maximum Bit Rate PDN-GW PDN Gateway AMR Adaptive Multi Rate codec PDSCH Physical Downlink Shared Channel APN Access Point Name PLMN Public Land Mobile Network ATM Asynchronous Transfer Mode PS Packet Switched CA Carrier Aggregation PSHO Packet Switched Handover CN Core Network PSTN Public Switched Telephone Network CQI Channel Quality Indicator PUCCH Physical Uplink Control Channel CS Circuit Switched QCI Quality of Service Class Indicator DL Downlink QoS Quality of Service DRX Discontinuous Reception RAB Radio Access Bearer DSCP DiffServ Code Point RAN Radio Access Network DTMF Dual Tone Multi Frequency RAT Radio Access Technology DTX Discontinuous Transmission RAU Routing Area Update Classification C2 Page 71 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014 HLD LTE Carrier Aggregation DU Digital Unit RB Radio Bearer DUL Digital Unit LTE RLC Radio Link Control DUS Digital Unit Multi-standard RNC Radio Network Controller eNB EUTRAN NodeB RRC Radio Resource Control EPC Evolved Packet Core RRU Remote Radio Unit EPS Evolved Packet System RRUS Remote Radio Unit Multi-standard E-RAB EUTRAN Radio Access Bearer RTCP RTP Control Protocol EUTRAN Evolved UTRAN RTP Real-time Transport Protocol FDD Frequency Division Domain RTT Round Trip Time GBR Guaranteed Bit Rate RU Radio Unit GERAN GSM EDGE Radio Access Network RUS Radio Unit Multi-standard GGSN Gateway GPRS Support Node SCC Secondary Control Channel GPRS General Packet Radio Service SCTP Stream Control Transmission Protocol GSM Global System for Mobile SGSN Serving GPRS Support Node GSMA GSM Association S-GW Serving-GW GTP GPRS Tunneling Protocol SIB System Information Broadcast GW Gateway SMS Short Message Service HARQ Hybrid Automatic Repeat Request SMS-C SMS Centre HLR Home Location Register SMS-SC SMS Service Centre HO Hand Over SRB Signaling Radio Bearer HPLMN Home PLMN TA Tracking Area HSPA High Speed Packet Access TAU Tracking Area Update HSS Home Subscriber Service TCP Transmission Control Protocol HTTP Hyper Text Transfer Protocol TDM Time Division Multiplexing IFLB Inter-Frequency Load Balancing THP Traffic Handling Priority IMSI International Mobile Subscriber Identifier TM Transmission Mode IP Internet Protocol TTI Transmission Time Interval IPv4 Internet Protocol version 4 TTI Transmission Time Interval IPv6 Internet Protocol version 6 UDP User Datagram Protocol IRAT Inter Radio Access Technology UE User Equipment LTE Long Term Evolution UL Uplink MAC Medium Access Control UM Unacknowledged Mode MAP Mobile Application Part UMTS Universal Mobile Telecommunication System MBR Maximum Bit Rate USB Universal Serial Bus MGW Media Gateway UTRAN UMTS Terrestrial Radio Access Network MiMo Multiple input Multiple output ViLTE Conversational video service over LTE MME Mobility Management Entity VLR Visitor Location Register MO Mobile Originating VoIP Voice over IP MSC Mobile Services Switching Centre VoLTE Voice over LTE MSC-S MSC-Server WCDMA Wideband Code Division Multiple Access MSISDN Mobile Station Integrated Services Digital Network Number Wi-Fi Wireless Fidelity MT Mobile Terminating WLAN Wireless Local Access Network NACK Negative Acknowledgement 17. References If applicable, include references to sources used to create this document. 18. Appendix HLD Project Delivery PUCCH Checklist.docx FORMULARS.docx Classification C2 Page 72 of 72 Template v3 Commercial in Confidence – Copyright Vodafone 2014