Download - 3G SWAP Guideline
3G Modernisation/Swap Guidelines
Version 1
Page 2 of 29
document description
Title and version 3G Modernization/Swap Planning Guideline for RANReferenceTarget Group Radio Network PlanningTechnology and SW release
3G
Related Service ItemsService Item numberAuthorDate 31.5.2010Approver Pekka Ranta
CHANGE RECORD
This section provides a history of changes made to this document
VERSION DATE EDITED BY SECTION/S COMMENTS
1.0 14.5.2009 Risto Lamminmäki ALL NSN update
Copyright © Nokia Siemens Networks. This material, including documentation and any related computer programs, is protected by copyright controlled by Nokia Siemens Networks. All rights are reserved. Copying, including reproducing, storing, adapting or translating, any or all of this material requires the prior written consent of Nokia Siemens Networks. This material also contains confidential information which may not be disclosed to others without the prior written consent of Nokia Siemens Networks.
Page 3 of 29
TABLE OF CONTENTS4.4.1 Data Flow for Creation of Adjacencies.......................................................................114.4.2 Consistency Check of Neighbours.............................................................................114.4.3 Deletion of Foreign Objects........................................................................................114.5.1 Data Flow for Creation of the Network.......................................................................134.5.2 Consistency Check of Created WBTSs......................................................................148.3.1 Method - Create double adjacency lists.....................................................................228.3.2 Method - Delete and create adjacencies directly.......................................................228.4.1 Deletion of non-used Adjacencies..............................................................................239.1.1 Handover Performances - Neighbour relations..........................................................25
Page 4 of 29
1. ScopeThe scope of this document is to explain the RAN swap procedure and preparation activities from the network planning point of view updated with RU10/RU20.
Swap (multi vendor swap or modernization) is just replacing old equipments to new equipments. Optimization, which is many times done just after swapping, is a different project and is not described very detailed in this document.
This document supports Flexi modernization cases.
Page 5 of 29
2. IntroductionThis document contains description of the network planning activities during the NSN RAN swap. The document is prepared based on the experiences derived from different RAN swap projects of NSN. The RAN swap mainly consists of three main stages:
• Pre-modernisation activities • Activities during modernisation• Post-modernisation activities
An overview of the main activities is illustrated in the below flow diagram and in the subsequent sections.
Figure 1, Modernization process
Each of these main activities are introduced in their own chapters in this document.
Page 6 of 29
3. Setup Modernize ProjectThere are simultaneous tasks to be done before the actual swap. The following steps are required to prepare plan for the network swap.
3.1 Multivendor integration testsMultivendor integration tests should be performed in the customer’s network. The level of the tests should be decided based on the need for interoperability. If there is also future need for interoperability in customer’s network then target should be that problems will get solved. On the other hand if there is only temporary need for interoperability then it might be enough to check if the functions such as handovers are working or not.
3.2 Swap strategyIf the swap is between two vendors then soft handovers between cells with different vendor are problematic. When cells are having same carrier and soft handover is not possible there is high risk of increased interference and call drops at the border of the cells. Therefore it is highly recommended that during the swap there would be separate carrier for new cells if possible. When it is not possible to use other carrier during the swap it should be taken care that cells are swapped in such clusters that there will not be inter vendor cell borders in critical locations.
Multivendor integration tests
Inter vendor (inter RNC) SHO working
Extra carrier available for swapped cells
Other system (GSM) available and ISHO
working
NoYesSwap using the same
carrier
Swap using another carrier
ISHO at swap border
Inter vendor IFHO working
Yes
YesSHO at swap border
Swap using the same carrier without inter vendor SHO
No
Intra carrier hard handover or drop at swap
border
NoIFHO at
swap border
YesNo
Figure 2, HO strategy for swap
When the case is a modernization of the same vendor, soft handovers are possible and there is no need for extra carrier.
Page 7 of 29
It should also be agreed if any other network modifications are allowed during the swap or if the network is frozen for the swap period. If other modifications are allowed it should be taken care of that how these modifications are included to the swap process in order to avoid data inconsistency.
All the actions causing breaks to service should be scheduled for non-busy time of theday.
Figure 3, Example of a roll-out plan
3.3 Verification of KPI definitions and drive test methodsBefore swap project it has to be defined how the acceptance of the swap project should be done.
• Based on stats from Network (aggregations must be defined)• Based on drive tests
Pre swap KPIs should be collected before any actions have been done. KPI Mapping should be checked before swap project. Triggering points for every vendors can be different so all KPIs are not comparable. These should be taken into account before every swap projects. Note that KPIs are always RAN release specific.
KPI mapping is not always 100%, so there can be differences between KPI results. These should be mentioned before swap and new KPI threshold should be defined based on this information. If KPI criteria’s are not fulfilled, optimization must be done. How to perform optimization after swap should be defined with customer before swap project. More documents about multivendor KPI mapping can be found from reference 11.
It may not be suitable to have same KPIs for all areas for acceptance. If customer is requesting a long list of KPIs to cover all functionalities of the network in detailed level it is recommended to define smaller area which is measured more deeply and if the results are acceptable then other areas do not need to have all KPIs but instead
Week1
Week2
Day1
Week3
Day4Day5
Day3
Day2
Page 8 of 29
use generic system performance KPIs. Drive tests should also be limited in order to reduce the expenses. Measurement routes and methods will be defined for acceptance and additional drive tests will be performed only if there are problems with network performance.
Page 9 of 29
4. Setup Methods and Tools
4.1 Area InformationThe purpose is getting familiar with the city or town. Inputs required from customer regarding the demographic distribution of the areas like commercial area, residential area, industrial areas, and main business centers.
4.2 Create adjacency change procedure3G swap might be complicated in a matter of adjacency handling specially if there are also GSM adjacencies to be updated. Most efficient way to do this is to prepare specific macro or script (Adjacency creation tool, see 4.3) which can retrieve all neighbour relations for requested cell and also create input files with updated adjacency definitions for all the needed OSSs. If it is not possible to use vendor specific input files then Excel can be used and adjacencies are created manually.
Also it should be decided that how adjacencies are handled during the swap. There is more about adjacency handling options in the section 8.3.
4.3 Adjacency creation toolAdjacency handling can be done manually or automatically during a swap:
Manual is very resource demanding and the possibility of mistakes is likely. Automatically adjacency handling by using a tool is the less resource demanding and the possibility of making a mistake is very low, if the tool is configured properly and the input is correct. Pay close attention to one-way neighbours if any defined. An example of a procedure for automatically adjacency handling is shown in Figure 4 and Figure 5.
Figure 4, An example of a procedure for automatic adjacency handling
Part of the adjacency definitions will be to the other vendors’ base stations and there is a need for creation of foreign objects in both OSS systems of old and new vendors’. Since network is under heavy modifications at the areas where vendor borders are located the procedure for adjacency handling is important for successful swap project.
Adjacency PlanOperators DB
MasterPlan
Adjacency ToolAdjacencies to added in NSN
Download Adjacencies OSS
Physical SWAP
Update Swopstatus in swop plan
Produce list of Foreign objects to be deleted NSN &
Vendor 2
Adjacencies to be added in old Vendors
OSS
Outer definition to MSC's
Adjacency PlanOperators DB
MasterPlan
Adjacency ToolAdjacencies to added in NSN
Download Adjacencies OSS
Physical SWAP
Update Swopstatus in swop plan
Produce list of Foreign objects to be deleted NSN &
Vendor 2
Adjacencies to be added in old Vendors
OSS
Outer definition to MSC's
Adjacency PlanOperators DB
Master Plan
Adjacency ToolAdjacencies to added in NSN
Download Adjacencies OSS
Physical swap
Update Swapstatus in swap plan
Produce list of Foreign objects to be deleted NSN &
Vendor 2
Adjacencies to be added in old Vendors
OSS
Outer definition to MSC's
Page 10 of 29
Figure 5, Illustration of the use of foreign cells during the swap
Adjacency creation tool should be able to do the following tasks:
• Import existing pre-swap adjacency definitions for cell to be swapped (also incoming adjacencies from foreign systems)
• Create updated adjacency definitions according to changes that are made for swapped cells ie. updated RAN, carrier, LAC…
• Create import files with updated adjacencies for all the vendors that are involved
Sometimes it is not possible to create these updated import files directly for other vendors’ OSSs but then the format of the adjacency files should be agreed to ease the processing of the adjacencies.
A1
C1
B2F_A1
F_C1
F_B2
F_B2
NSN AreaOld Vendor Area
A2
C1
B2
F_C1
F_B2
NSN Area
Old Vendor AreaF_C1
F_A2
A2
C2
B2
NSN Area
A1 is swapped to A2
C1 is swapped to C2
A1
C1
B2F_A1
F_C1
F_B2
F_B2
NSN AreaOld Vendor Area
A2
C1
B2
F_C1
F_B2
NSN Area
Old Vendor AreaF_C1
F_A2
A2
C2
B2
NSN Area
A1 is swapped to A2
C1 is swapped to C2
A1
C1
B2F_A1
F_C1
F_B2
F_B2
NSN AreaOld Vendor Area
A2
C1
B2
F_C1
F_B2
NSN Area
Old Vendor AreaF_C1
F_A2
A2
C2
B2
NSN Area
A1 is swapped to A2
C1 is swapped to C2
A1
C1
B2F_A1
F_C1
F_B2
F_B2
NSN AreaOld Vendor Area
A2
C1
B2
F_C1
F_B2
NSN Area
Old Vendor AreaF_C1
F_A2
A2
C2
B2
NSN Area
A1 is swapped to A2
C1 is swapped to C2
Page 11 of 29
4.4 Daily Swap Plan Based on the Cluster information available the daily swap plan is prepared by Implementation. Regional Project Managers will provide this information to Network Planning & customer one week prior to the physical swap.
4.4.1 Data Flow for Creation of Adjacencies
Based on the daily swap plan from regions, Intra System (NSN) Adjacency (Neighbouring Cells) data will be given to implementation (OSS) in vendor specific input files. The data can be downloaded to the network from OSS, one day before physical swap if double adjacencies are used. If all swapped adjacencies are to be deleted and created during the swap then adjacencies can not be uploaded to the network forehands but anyway they need to be delivered to Implementation (OSS) one day earlier for verifications.
The Foreign neighbours to be created in the OSS will be given in another vendor’s input file to implementation (OSS) for creating manually in OSS one day before swap. The NSN cells are already created earlier in other vendors OSS. Customer is responsible to modify adjacencies in other vendors OSS using the input files from the scripts or modifying adjacencies manually.
One day before the actual swap all old adjacencies related to swapped cells should be queried from the OSSs. The order of the WBTS swaps has to be known and for each individual swap there should be separate plans for deleting old adjacencies and creating new updated adjacencies. This task should be done with scripts (Adjacency creation tool, see section 4.3) that are able to read the adjacency data, prepare the modifications as specified and create input files for all systems that are involved.
4.4.2 Consistency Check of Neighbours
The log file taken during processing of adjacent cell data to be provided to planning for checking of errors. The OSS dump should be provided also after the successful physical swap for further consistency check and creation of new neighbours.
4.4.3 Deletion of Foreign Objects
After successful physical swap, a list of foreign objects will be provided to implementation from Network Planning for deletion from the network.
4.5 Dataflow and schedule for swapTo allow an easy implementation of all network elements a good interface between the Radio Network Planning group (responsible for the parameter definition), the Network Operations group (responsible for the implementation of the parameters in the network) and the Roll Out Services groups (responsible for installation etc. of equipment on site) needs to be established.
Page 12 of 29
Figure 6, Timeline for network creation
In principle the dataflow between the groups can be simplified as the following illustration shows:
-1 Week
-2 Weeks
Time
Start of the physical swapPost-swap actions
Database provided to implementation Creation of the Network in
RNCs
Dump from OSS downloaded and database transferred to NWP Plan Edit
Database provided to implementation
Page 13 of 29
List of sites to be swapped
OMC export of the old network
WBTS distribution in NSN RNCs
Prepare database for NetAct
import
Import data to NetAct
NSN database
(Plan Editor)
NetAct database
Consistency check for
data
Consistency check
Export processed
data
List of NSN cells to be
added in other vendor’s OSS
Daily swap plan
Adjacency handling tool
Other vendor’s database
Input files with new
neighbours for all OSSs
Actual swap including
adjacency modifications
OMC logfiles for troubleshooting
List of foreign cells that can
be deleted from NSN OSS
Imprt foreign cells to other vendor’s
OSS
Update swap plan
Verification of swapped site
Figure 7, Dataflows for swap project
4.5.1 Data Flow for Creation of the Network
The NSN site database is prepared according to the swap sites information from customer’s OSS dump. Reference WBTSs will be created in the RNCs with recommended set of WBTS parameters from planning, prior to creation of actual WBTSs. The swap WBTSs will be created in the NSN RNCs by a Macro as per the information provided by Planning with reference to the default reference WBTSs.
Page 14 of 29
• The Element IDs will be decided for implementation (RNC)• OSS upload to be done after creation of all WBTSs in the RNCs• Time Frame : It is recommended that all network elements be created in the OSS at
least 2 weeks before the physical swap
4.5.2 Consistency Check of Created WBTSs
After the upload of network data, Implementation (OSS) should provide network dump to planning for consistency check of the created WBTSs, excluding adjacency plan if double adjacencies are not used (see 8.3).
Time Frame: It is recommended to provide OSS dump to Network Planning at least one week before of physical swap.
4.6 Deployment of the base stationActual deployment of the new base station is done following the standard procedures of the customer. Site documentation, hardware tests and measurements are performed as required.
4.7 Other system updatesThere might be other external systems that are using cell parameter info and needs to be updated during the swap. Customer is responsible for these updates but it is good to include all needed actions to swap plan. Here are few examples of other external systems that would require actions during the swap:
• Home Zone Billing –functionality• Area based KPI systems• Customer complaint / Error reporting systems• Business intelligence systems
Updates are performed based on the information of actual swap times in Master plan for swap (see 6.5).
Page 15 of 29
5. Pre-Modernise Performance
5.1 Network Verification 1 (Drive test)Prior to the swap, a network verification drive test will be carried out to evaluate the quality of the existing radio network. The drive test is intended to serve as reference for verification of the performance of the radio network after the swap has been completed.
A test route, covering all relevant WBTSs in the swap area and its border areas, is agreed between customer and NSN. In the drive test NSN will be following the roads defined in the drive test cluster definition by the customer.
5.2 KPI collectionAgree with customer which KPIs should be followed and monitored. Especially when a multi vendor swap is done a proper matching should be found prior to the project start. Benchmarking KPIs are recommended for reporting.
The following KPIs are useful to follow before and after the swap. These could be found from RAN reporting suite system program report:
• Cell Availability• RRC Performance• RAB AMR Performance• RAB UDI Performance • RAB PS Performance• Packet Call Performance• SHO Performance• HSDPA Performance• HSDPA Data Volume• HSDPA Serving Cell Change• HSUPA Performance• HSUPA Serving Cell Change
It has to be checked also that traffic has not reduced post swap and to compare the performance. It needs to be highlighted that comparing the results between vendor’s statistics is difficult due to differences in the way the counters are pegged. The results are presented at cluster and cell level.
Traffic related counters could be:
• RRC Attempts• RRC Non Reg Attempts• RAB RT attempts• RAB NRT attempts• HSDPA selections• Total number of voice drops
Results are compared against pre-swap results with proper mapping as in pre-swap evaluation.
Page 16 of 29
6. Prepare DatabuildsAn approved method for WBTS names and sector number versus direction should be defined ahead of the project. Allocation of SITE IDs, WBTS IDs, WCELL IDs and other IDs and names should follow a predefined system, in order to obtain maximum overview of the network. Having a good overview of the network element IDs and name definitions will also ease the operation of the network.
6.1 Site Visit – Technical Site SurveyTechnical site survey (TSS) needs to be done for each of the sites to be swapped. The purpose of the TSS is to do a site audit and verify the information provided by the customer and to verify that the new equipment could be installed. This task will be performed by Network Implementation. The following site information is checked and recorded during TSS:
• Location (site co-ordinates)• Azimuth • Antenna tilt (Mechanical/Electrical)• Remote electrical tilt systems• Antenna type• Number of antennas• Height of the antennas• Site type (green field, rooftop, etc.) • Feeder type and length.• Power supply• Battery backup system• Site alert systems
Changes for the site configuration can be done if required.
6.2 Radio Network Parameter PlanningIn order to ensure a safe swap with a high quality, the most optimum swap principle will be defined. The main purpose of defining the swap principle is to define whenever CI, LAC or carrier is needed to change during the swap and also how to handle the adjacencies during swap.
In order to ensure an efficient and consistent radio network parameter planning process during a swap, NSN will use NetAct Plan Editor, which is especially designed for mass modification of the network.
Optimized NSN specific default parameter sets for the different networks and environments in the swap area will be defined on basis of the customer’s default parameter sets for the old vendor UTRAN network.
Parameter mapping is not possible for all other vendors. If customer has any specific tuned parameter set for cells or RNCs, these can not be mapped 100% to NSN network. These specific tuned parameters should be known before swap project to avoid negative surprises
The parameter setting for each cell is then generated by the parameter planning application on basis of the default parameter sets and the cell specific settings.
Page 17 of 29
In order to ensure that the swap is performed as smoothly as possible, it is recommended to prepare and download most of the radio parameters to the involved WBTSs and RNCs before the actual hardware is swapped. This is also to make sure that nothing changes during swap. Adjacency relations need to be maintained during the swap.
6.3 Foreign WBTS/BTS – Other vendor cellsIn order to define adjacency relations to the new NSN cells in old vendor RNC and from Swapped NSN cells in NSN RNC to not Swapped old vendor cells before the swap, foreign objects (externals) must be created before the actual swap in the UTRAN system. However foreign objects with same CI and LAC cannot exist at the same time in the UTRAN system.
6.4 Possible strategies for handling of the CI/LAC problemIn order to select the best strategy for handling of CI/LAC in the swap, 4 possible methods are evaluated:
• New CI, same LAC• Same CI, new LAC• Same CI, same LAC• New CI, new LAC
In the case of same CI and new LAC, the geographical LAC area will remain the same but only the numerical value will change. Often this is the easiest solution for swap.
In every case where changes are made it should be taken care of that RAC, URA and SAC values are also updated accordingly as needed. Easy fallback possibility in case the new NSN WBTS does not function properly should be ensured.
6.5 Master planThe master plan is used as the key reference for Network Planning in the swap. The master plan is created based on input from the operator. Information needed is Site name, Sector name, and Direction, System and TRX configuration.
A very important aspect in a swap is to have a common master plan. The master plan can contain all WBTS in the swap area (existing and new WBTS during the swap) and the corresponding configurations (existing and extensions). The master plan can also be used as an input for the adjacency handling. The master plan can also contain the WBTS specific RF parameters that need to be implemented.
All the needed parameters for WBTS commission should be contained in the master plan. A list of mandatory parameters can be collected from the document ‘Commissioning Flexi Multiradio BTS WCDMA DN7039326’ which is part of the document ‘Nokia Siemens Networks WCDMA RAN, Rel. RU20, Operating Documentation, Issue 02’ and can be downloaded from reference 13. There is a simplified example of a master plan in appendix A.
The master plan can also provide information to Logistics, Rollout plan, ET-plan (transmission plan) and the Site creation process in Planed Edit (Access database).
Page 18 of 29
RNC_id WBTS_id Cell_id WBTS_Name Cell_name LAC Sector_id Carrier …
22 123 NameW NameW1 1265 1 10658 …Figure 8, Example of master plan table
Page 19 of 29
7. Prepare Modernize of WBTS
7.1 Network CreationBefore the swap can start the network needs to be created in the RNCs. The Master plan is used as an input to generate the data needed for the creation of all network objects.
The database will be provided to implementation as an Excel sheet using the agreed format.
The cell creation will then start in the RNCs. Creation will be done based on the data provided in the excel sheet and according to the appropriate parameter template depending on the Cell_Type field and mapping of the parameters (see 7.4).
This database will be provided at least 2 weeks prior to the first physical swap
7.2 Consistency checkOnce the cells have been created in the RNCs, a download of all the network elements from OSS will be done. This download will be integrated to the Master Plan using Planed it transfer facility and the data will then be checked and any inconsistency or missing information detected (See Parameters check section for more details).
7.3 Foreign WBTSIn order to define adjacencies out of the swap area, foreign objects need to be defined in OSS. The foreign needed in OSS are found by identifying the adjacencies pointing out of the swap area to the cells of the other vendor.
All cells to be swapped needs to be defined as foreign (the old vendor cells), in order to be able to perform a handover between the two systems during the swap period. Also adjacencies out of the swap area to other non-NSN area need to be defined as foreign neighbours. Foreign can be created automatically when downloading new adjacencies (When an adjacency contains information different from any cell defined in the actual OSS, OSS will automatically create a foreign object for that adjacency relation). The created foreign objects are identified by the CI and LAC (disadvantage). The advantage of this method is that it is fast and requires no extra work.
It is also possible to create all foreign before the download of the adjacencies. The advantage of this method is that it is possible to identify the foreign by a cell name. The disadvantage is that the method requires a lot manual work to type in all the foreign objects.
The principle of foreign definitions and the use of foreign during a swap are shown in the figure in next page.
7.4 Customer Parameter Translation Customer parameter translation process is done from the OSS dump, as they don’t have default parameter settings. All cell specific parameters are derived from the
Page 20 of 29
dump and used for preparing the swap database and also default parameter sets for different types of cells.
Figure 9, Principle of customer parameter translations
Note! Parameter mapping is not possible for all other vendors. If customer has any specific tuned parameter, these can not be mapped 100% to NSN network. These specific tuned parameters should be known before swap project.
7.5 Default RAN Parameter Sets:The RAN default parameter set are including following MO classes (RAS06/RU10)
Recommended RNC parameters to be used in network (RAS06/RU10) could be found from reference 1.
More information about parameters, please see references 2 and 6.
7.6 Check parameter settings in OSSAlthough the parameter transfer is implemented by RNC Engineers according to the default parameters set and cell specific parameters provided by the Network planning group with a Macro (Automated Process), it is recommended to cross-check the "ACTUAL" parameter settings in OSS before the real swap from the OSS after uploading of database from RNCs.
Based on the daily swap plan the right sites can be checked. In case of problems in the created parameters, corrections are needed and can be requested to Implementation before physical swap.
NSN Default
NSN Global
Experience
Old vendor default
NSN Default
definition
Translation Process
NSN Default
NSN Global
Experience
Old vendor default
NSN Default
definition
Translation Process
NSN Default
NSN Global
Experience
Old vendor default
NSN Default
definition
Translation Process
Page 21 of 29
8. Integrate
8.1 Radio Network Parameter ImplementationThe radio network parameters will be implemented in the sites created in the RNCs from a macro application running from the RNC MML with reference to pre defined reference WBTSs. Once the sites are created in RANs OSS upload will be done for updating OSS database. This OSS database will be used for Parameter Planning Application (Plan Editor) for further modifications to the WBTSs and RNCs via OSS. More about Plan Editor can be found from the reference 14.
The radio network parameters will be uploaded to the RNCs via OSS
8.2 Adjacency HandlingAdjacency handling is one of the most critical tasks in a swap. In order to be able to maintain the normal handover traffic and possibility between all cells during a swap an intelligent procedure for defining adjacencies must be defined.
Input to the adjacency-handling tool is the adjacency plan and the master plan. The tool must produce an adjacency list for NSN and one for the old vendor. Adjacencies to NSN can be imported to OSS by using the "Planning File Transfer". Plan Editor is very suitable to generate this planning file. This is a very good argument for that the adjacency handling tool should be a part of Planed it. Since Planed it is based on an Access database, all tables needed to create the adjacencies can be imported to that database.
Outer definitions for MSC are very important if the swap is spread over several MSCs. It is a MSC supplier related item, when outer definitions in MSCs need to be updated. More information about neighbour planning can be read from the reference 4.
8.3 Adjacency handling methodsThere are two main methods for handling adjacencies during the swap: One is to create simultaneously adjacencies to/from old and new cells so that adjacencies do not need to be modified during the actual swap of a site. This method is not suitable for cases where adjacency lists are close to full because every adjacency should be doubled.
Second possibility is to modify adjacencies immediately before and after the actual swap in such a way that all old adjacencies are transferred to new cell as they were before swap. The requirement for this method is well functioning methods for adjacency imports, deletions and creations.
It is also possible to create common updated adjacency plan for all the cells that are to be swapped in near future like next night. The risk of this method is that if one of the swaps failures there is not easy way of doing rollback for the adjacencies of that site.
The first two methods for adjacency handling are discussed deeper in following paragraphs.
Page 22 of 29
8.3.1 Method - Create double adjacency lists
This method is suitable when the adjacency lists in the network are short and can be easily limited to 16 or under adjacencies per system.
During swap you have to create a double handover list. To make such a double entry the maximum allowed neighbours per WBTS is 16 (since the maximum is 32)Since the swap is performed as a one to one swap, the neighbour relations will be doubled during the swap.
The new cells are assigned new LACs and CIs. The neighbours of the old vendor cells will be added to the neighbour list of new NSN cells. After the swap of the old vendor cell the neighbour relations should be deleted in old vendor RNCs but at the same time the new swapped cells should be added as a neighbour to its neighbouring cells. The principle of the neighbour relation swap is shown in Figure10.
Since some cells have more than 16 adjacency relations, all adjacency relations cannot be implemented before the swap, but they will be added and deleted in small blocks. One block will contain the adjacency relations to be added or deleted for e.g. the next 2 days of the swap period. In Rural areas it is normally possible to add all adjacency relations before the swap (Adjacency swap period e.g. 5 days), but in urban areas the maximum of 32 measurement frequencies might be exceeded in some cells (especially in dual band areas). The adjacency relations to be added or deleted in the following swap period are handled by an adjacency tool developed by NSN especially for a swap project.
One solution of adjacency handling during swap is to collect HO stats before swap and take these 16 cells where most of handovers have been done (rest neighbours have to be deleted). So the degradation of quality has been minimized. Rest of (missing) neighbours should be added just after swap.
8.3.2 Method - Delete and create adjacencies directly
If adjacency lists are full or close to full this method should be used. Before each swap all related adjacencies are deleted and new adjacencies are created for the
Old vendor CELL
Old vendor CELLOld vendor
CELL TO swap
NSN CELL New LAC & CI
Figure 10, Neighbor relation swap
Page 23 of 29
new NSN cell as they were for swapped old cell. The advantage of this method is that all the results are final and the risk of errors due to temporary solutions is avoided. This method is also more flexible for the adjacency changes because adjacency exports are performed close to actual swap. The disadvantages are that the downtimes of the sites might be a bit longer due to adjacency updates depending on the performance of the OSSs that are involved. This method also requires good scripts that will generate adjacency input files for all systems.
Create new WBTS
Block old WBTS
Delete old adjacencies
Create updated adjacencies
Activate new WBTS to live network
Verify that new WBTS is working
Delete old WBTS
· Intra frequency· Inter frequency· Inter system· Both directions!
Figure 11, Simplified example of adjacency update procedure
8.4 Adjacency Preparation ProcedureThe procedure for preparing the adjacencies for the next period is resumed in this section.
1. Update Master plan (Last period=Swapped & check that all sites in the next period have the right planned swap date)
2. If needed, update Adjacency table from operators database3. Run adjacency tool4. Make outer lists for MSCs (optional)5. Provide operator with adjacency information for the next period to be created in the
old vendors' OSSs6. Delete all foreign for the sites Swapped the last period in OSS7. Export the ADJACENT_CELL table using Plan Editor8. Import adjacency file to OSS and Upload adjacencies to RNCs
8.4.1 Deletion of non-used Adjacencies
Non-used adjacencies to e.g. old cells that have been swapped, can be easily deleted, by deleting the corresponding foreign objects of the old cells. This will clean up the adjacency plan after the swap. This applies to the method where double adjacencies are used. In other methods there should not be adjacency leftovers.
Note! It is recommended to change the identification of the foreign cells after the swap (e.g. change CI/LAC to Cell name of foreign object). This will make the network it easier to operate in OSS.
Page 24 of 29
8.5 Swap Site VerificationImmediately after the physical swap of the site, drive test shall be performed. A quick drive test is done to verify the implementation of the correct RNP parameters. Additionally this will ensure that handovers between the different cells are being performed, sectors are not swapped, call set-up rate and drop call rate meets the criteria agreed in the swap process. In case of problems, the particular cell or site will be trouble shouted using Reporting Suite Reports.
All the swapped sites are individually checked for problems related to:
• CSSR• SHO • Low coverage• Total cross feeders between the sectors• Partial cross feeders between the sectors
The data for each swap site is recorded as a log file as well as saved as required by customer. The problems are forwarded to the WBTS group for rectification of the problem and verified again once confirmed by the BTS engineer. See also cluster tuning WI, reference 8.
Page 25 of 29
9. Post Modernize
9.1 Radio Network Performance Monitoring during swapThe purpose of this activity is to detect and correct any unintentional hardware or parameter deficiencies at the earliest possible time. In this way any temporary decrease in network quality is minimized.
It is recommended to keep problem record during swap. All the problems encountered will be written down and will be solved with customer as soon as possible.
KPI statistics from the OSS are used during the swap for evaluation of the basic performance of each cell. Some selected KPI's and criteria are defined in order to detect any unexpected hardware problems or wrong parameter settings. KPI statistics can also be used to evaluate the general area performance during the swap. It is recommended to use Benchmarking KPI during the swap. Needs for KPI analysis / Drive test analysis are always contract/project specific.
Official benchmarking KPI can be found from Jump: Reference 12.
In case any of the KPI's degradation, investigations should be started to see that the history of the cell performance was ok. In case performance degeneration is not caused by hardware or parameter problems, but by the network plan, the cell in question is transferred to post-swap optimization process.
During the swap of the network, close monitoring is needed with daily or hourly (depends on the schedule) statistics.
Immediately after swap the following checks needs to be done on all new cells Reporting Suite reports (daily and weekly reporting). More details in reference 15.
• System ProgramRSRAN000
• Service/Session Accessibility Analysis RSRAN073
• Service/Session Retainability Analysis RSRAN079
• Soft Handover Performance RSRAN028
• SHO Adjacencies RSRAN046
• ISHO Adjacencies RSRAN045
• HSPA Overview RSRAN092
9.1.1 Handover Performances - Neighbour relations
For trouble shooting of Handover failures report SHO Adjacencies RSRAN044 RSRAN045 and RSRAN046 of Reporting Suite should be considered (Reference 15). These reports show the neighbouring cells with maximum HO failure. To improve HO performance of the cells the neighbours’ relations should be reviewed. The best
Page 26 of 29
way of finding missing neighbours is from the Drive Test. The report for missing neighbours can also be generated from RS reports.
9.2 Network Verification 2 (Drive test)A second Radio Network Verification will be carried out after the swap has been completed, i.e. at a time, when the network is operational.
Aiming at carrying out the second set of drive tests under similar traffic conditions as before, route, weekday and time of the day for the tests should be similar to those of the first verification.
Measurements and KPI-results for both of the drive tests will be compared and evaluated in a more detailed.
It is recommended that not only site that is on air at the moment of swap is put to the master plan, but also new sites coming during the swap period. New sites can be treated as sites to be swapped and the data (cell parameters and adjacencies) preparation of those sites can be done together with the data preparation for the sites to be swapped.
Page 27 of 29
10. References1 Recommended Parameters for Optimization (RU10)
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/D364619132
2 Radio Network Parameter Dictionary (DN00211177)
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/D419165584
3 UTRAN neighbour planning WI
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/393715157
4 UTRAN Neighbour assessment WI
https://sharenet-ims.inside.nokiasiemensnetworks.com/Download/380115223
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/397937092
5 Utran Consistency Check WI
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/D364148491
6 UTRAN Consistency Check WI
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/D364148491
7 UTRAN Parameter assessment WI
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/380101296
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/400432089
8 UTRAN Cluster Tuning & Acceptance Guideline
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/D368977093
9 UTRAN Performance Analysis WI
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/374963768
10 3G swap project example folder
https://sharenet-ims.inside.nokiasiemensnetworks.com/livelink/livelink?func=ll&objId=414789669&objAction=Browse&viewType=1
11 Multivendor KPI mapping
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/410911135
12 System Program KPIs
http://nop-i.nokiasiemensnetworks.com/reportmanager/htmlset.php?set=426&co=1&m=1&se=1
Page 28 of 29
13 Nokia Siemens Networks WCDMA RAN, Rel. RU20, Operating Documentation, Issue 02
https://www.online.nokia.com/nols/doccenter/dcpageflow/viewDocumentDetails.do?parentObjectId=0b00cc928025f60e
14 NetAct Plan Editor
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/390002169
15 Report Set RSRAN RU20
http://nop-i.nokiasiemensnetworks.com/reportmanager/htmlset.php?set=437&co=1&m=1&se=1
Page 29 of 29
11. Appendices
Appendix A – Simplified example of a master planTable 1, Master plan database fields
Database Field Description
Site Name Site Name (old and new are same)
WBTS id
Old RNC id Old system RNC id (and name if needed)
New RNC id New system RNC id (and name if needed)
WCEL id
TRS IP address
Subnet Mask
BTS IP address
RNC IP address
HSPA Enable /Disable
External equipment IP addresses
Columns for IP-addresses of remote electrical tilt, battery backup unit, location measurement unit, etc…
Transmission type Number of E1s or other specifiications
Transmission setting parameters Columns as needed
Carriers in use
Config
On_air Live status
Planned_swap Date Date
Actual_swap Date Date when confirmed
swapped Yes/No, status changed after succesful swap
Foreigns_removed Yes/No, status changed after database deletions
RF-Parameters Tx powers, handover parameter sets, etc...
…
TRS-Parameters
…
Other Cell-, WBTS-, and Site-specific parameters as needed
… …