10 rn3154aen10gla0 initial parameter planning

8/10/2019 10 RN3154AEN10GLA0 Initial Parameter Planning

1/42RN3154AEn10GLA0

Initial Parameter Planning

1

Customer confidential1 NSN Siemens Networks RN3154AEN10GLA0

Initial Parameter Planning3GRPESS Module 9


2/42RN3154AEn10GLA0


2


Module 9 Initial parameter planning

Objectives

After this module the participant shall be able to:-

Understand the basic parameter settings required for

network launch


3/42RN3154AEn10GLA0


3


Module contents

Scrambling Code Planning

Neighbour List Planning

Location, Routing and Service Area Planning

UTRAN Registration Area Planning


4/42RN3154AEn10GLA0


4


Module contents






5/42RN3154AEn10GLA0


5


512 Primary scrambling codes are organised into 64 groups of 8

Each Primary scrambling code has 15 Secondary scrambling codes Each Primary & Secondary scrambling code has left and right Alternate scrambling codes

Scrambling code planning refers to assigning the Primary scrambling codes Each cell is assigned 1 Primary scrambling code Scrambling code planning strategies can be defined that maximise the number of neighbours

belonging to the same code group, or that maximise the number of neighbours that belong todifferent code groups

The difference between the two strategies remains unquantified in the field and is likely to depend upon UEimplementation

Scrambling code planning requires co-ordination at international borders Scrambling code planning can be completed independently for each RF carrier Scrambling code planning can be completed using a radio network planning tool or a home made

tool

Scrambling code plan should account for future network expansion

Introduction


6/42RN3154AEn10GLA0


6


Air-Interface BCCH Synchronisation (I)

Step 1 Search for Primary Synchronisation Channel (P-SCH) Same chip sequence within every timeslot of every cell of every operator Chip sequence has length of 256 chips Provides slot synchronisation

CP

2560 Chips 256 Chips

CP CP CP

P-SCH

Step 1 is the same for all scrambling code planning strategies


7/42RN3154AEn10GLA0


7


Air-Interface BCCH Synchronisation (II)

Step 2 Search for Secondary Synchronisation Channel (S-SCH)

Different series of 15 chip sequences for each code group Each chip sequence has a length of 256 chips Select 1 out of 64 => relatively large probability of error Relatively low UE processing requirement relative to step 3 Only necessary to identify 3 consecutive chip sequences to identify code group Provides frame synchronisation and identifies Primary scrambling code group

C s1

2560 Chips 256 Chips

C s2 C s15 C s1

Emphasis is placed on Step 2 if scrambling code plan maximises the number ofneighbours with different scrambling code groups


8/42RN3154AEn10GLA0


8


Air-Interface BCCH Synchronisation (III)

Step 3 Search for CPICH

Identifies Primary scrambling code Select 1 out of 8 => relatively low probability of error Relatively high UE processing requirement relative to step 2 Not necessary to correlate complete 38400 chip frame to identify scrambling code

CPICH

38400 Chips = 10 ms radio frame

Emphasis is placed on Step 3 if scrambling code plan maximises the number of

neighbours with the same code group


9/42RN3154AEn10GLA0


9


Impact of Neighbour List Combining (I)

When a UE is in soft handover then the RNC combines the neighbour listsbelonging to the active set cells

It is necessary that duplicate scrambling codes do not appear within those lists Checks should be made to ensure that cells within potential active sets do not

have different neighbours with the same scrambling code

ActiveRadiolink

ActiveRadiolink

UE in softhandover

Neighbour toactive set cell


Examplescramblingcode clashscenario 1

SC100 SC100


10/42RN3154AEn10GLA0


10


Impact of Neighbour List Combining (II)

Checks should be made to ensure that no cells are neighboured to two or morecells which have neighbour lists including the same scrambling code for differenttarget cells

ActiveRadiolink

UE in softhandover



SC100

SC100Examplescramblingcode clashscenario 2




11


Example Scrambling Code Plan

Area with 12 Node B

Strategy has been tominimise the number ofcode groups used inneighbouring cells

Two code groups enoughup to 15 neighbours

6 7

2 0

1 2

0 2 4

2 3 8

1 0

41 7

1 1

2 5 3

1 8 5

1 9

9

2 2 2 1

1 2 2 6

1 6 1 5

1 4

1 3

2 7

2 9

2 8

3 0

3 1

3 2

3 3

3 4

3 5

IntraFreqNcellScrCode

UE

Serving cell

Cluster of cellsusing 2 code

groups




12


Recommendations

Isolation between cells assigned the same scrambling code should bemaximised isolation between cells assigned the same scrambling code sufficiently great to

ensure that a UE never simultaneously receives the same scrambling code from morethan 1 cell

isolation between cells assigned the same scrambling code sufficiently great toensure that a UE never receives a scrambling code from one cell while expecting toreceive the same scrambling code from second cell

Specific scrambling codes should be excluded from the plan to allow for futurenetwork expansion.

The same scrambling code plan should be assigned to each RF carrier Scrambling code planning should be completed in conjunction with neighbour list

planning Scrambling code audits should be completed in combination with neighbour list

audits Checks should be made to ensure that no cells are neighboured to two or more

cells which have neighbour lists including the same scrambling code for differenttarget cells




13


Module contents








14


Introduction

Neighbour lists: 3G intra-frequency

3G inter-frequency 3G inter-system 2G inter-system

High quality neighbour lists are critical to the performance of the network Neighbour lists are usually refined during pre-launch or post-launch optimisation

Neighbour list planning should be as accurate as possible Impact upon pre-launch optimisation has to be recognised Pre-launch optimisation often limited to specific drive route which may not identify all

neighbours Neighbour list tuning usually achieves the greatest gains during pre-launch

optimisation Optimisation tools based upon RNC logging can also be used to

refine neighbour lists subsequent to launch




15


3G Intra-Frequency Neigbour Lists

Intra-frequency neighbours are used for cell re-selection, soft handover, softerhandover and intra-frequency hard handover

Missing neighbours result in unnecessarily poor signal to noise ratios

Excessive number of neighbours increase the UE measurement time may lead to important neighbours being deleted during soft handover

Intra-frequency neighbour lists are combined for both intra-RNC and inter-RNCsoft handover (assuming inter-RNC soft handover is supported) Intra-frequency neighbour lists are transmitted in SIB11 and dedicated

measurement control messages

CPICH Ec/Io SC100SC200

Drop

CellSelection

Time

Missing neighbours can be identifiedfrom UE log files as a decrease inCPICH Ec/Io until connection dropsand then cell selection allows suddenimprovement

Example SC200 missing fromneighbour list associated with SC100UE movement


16/42




17


Parameters

Intra-Frequency neighbours are defined using the ADJS parameter set Each neighbour has its own set of ADJS parameters

WCELL

ADJS

WBTS

RNC

HOPS 100

32

RTNRTHSDPA

Structure of databuild

RAS05 ADJS parameters

3GPP allows the network to specify amaximum of 32 intra-frequency cells for theUE to measure

Serving cell + 31Intra-frequencyneighbours when notin soft handover

2-3 serving cells +30-29 neighbours insoft handover

Size of SIB11 canlimit the number of

neighbours for cellre-selection

Intra-Frequency Neighbours




18


3G Inter-Frequency Neigbour Lists

Inter-frequency neighbours are used for inter-frequency cell re-selection andinter-frequency handover

The NSN RNC allows a maximum of 48 inter-frequency neighbours to bedefined with a maximum of 32 on any one RF carrier 3GPP specifies that a max. of 32 inter-frequency neighbours can be broadcast in

SIB11

NSN does not support inter-frequency handover from CELL_FACH inter-frequency handover while anchoring an RNC

Excessive neighbours increase the UE measurement time may lead to important neighbours being deleted during soft handover

Inter-frequency neighbours are usually introduced after the network has beenlaunched and so refining them is usually a post launch optimisation task




19


Neighbour List CombiningInter-Frequency Neighbours

When a UE is in intra-RNC soft handover then the neighbour lists belonging toeach of the active set cells are combined

Neighbour lists are not combined for inter-RNC soft handover because the NSNRNC does not support inter-frequency neighbour signalling across the Iur Not all vendors offer neighbour list combining

Neighbour lists are not updated once compressed mode measurements havebegun, i.e. inter-frequency neighbour lists are dependant upon the active setcells when inter-frequency handover is triggered

1. Neighbour cells which are commonto three active set cells

2. Neighbour cells which are commonto two active set cells

3. Neighbour cells which are definedfor only one active set cell

Generating a combined inter-frequency neighbour list

Inter-FrequencyNeighbour List




20


ParametersInter-Frequency Neighbours

Intra-Frequency neighbours are defined using the ADJI parameter set Each neighbour has its own set of ADJI parameters

WCELL

ADJI

WBTS

RNC

HOPI 100

48

RTNRT


RAS05 ADJI parameters

Size of SIB11 can limit the number ofneighbours for cell re-selection




21


3G Inter-System Neigbour Lists

GSM neighbours are used for inter-system cell re-selection and inter-system handover

3GPP specifications allow a maximum of 32 inter-system neighbours to be defined Inter-system neighbours are broadcast in SIB11 for cell re-selection and are transmittedin dedicated measurement control messages for inter-system handover

NSN does not support inter-system handover from CELL_FACH inter-system handover while anchoring an RNC

The NSN RNC instructs the UE to measure all GSM neighbours for RSSI measurementsbut one specific neighbour for BSIC verification

Excessive neighbours increase the UE measurement time may lead to important neighbours being deleted during soft handover

GSM neighbour lists can be based upon existing BSC 2G neighbour lists when sites areco-sited

If an operator has both GSM900 and DCS1800 networks then it is possible to define inter-system neighbours only for the GSM900 layer or only for the DCS1800 layer


22/42




23


ParametersInter-System Neighbours

Intra-Frequency neighbours are defined using the ADJG parameter set Each neighbour has its own set of ADJG parameters

WCELL

ADJG

WBTS

RNC

HOPG 100

32

RTNRT


RAS05 ADJG parameters

Size of SIB11 can limit the number ofneighbours for cell re-selection




24


Maximum Neighbour List Lengths (I)

SIB11 is used to instruct UE which cells to measure in RRC Idle, CELL_FACH and CELL_PCH TS25.331 includes a contradiction made by 3GPP, i.e. SIB11 should be able to accommodate

information regarding 96 cells, but SIB11 cannot exceed 3552 bits and this is insufficient toaccommodate information regarding 96 cells

If a NSN RNC is configured with a cell which is configured with more neighbours than SIB11 canaccommodate then the cell is blocked and an alarm is raised

NSN has issued RNC Technical Note 46 to specify that when Hierarchical Cell Structure is disabled, amaximum of 47 cells should be configured. This is a worst case figure and in general more cells can beincluded

RU10 RNC support activation of SI11bis, which enables transmission of all defined neighbours

M a x i m u m

S i z e o

f S I B 1 1

Adjs Adji

Adjg

Complete set ofneighbours will not fit




25


Maximum Neighbour List Lengths (II)

The size of SIB11 can be estimated from the number of intra-frequency, inter-frequency and inter-system neighbours

The quantity of data associated with each neighbour can vary depending uponwhich information elements are included

AdjsQoffset1 orAdjsQoffset2 included

CPICH transmitpower included

Size of single ADJS

Neither No 48 bits

Either One No 48 or 56 bits (average of 55.2 bits)

Both No 56 or 64 bits (average of 62.1 bits)

Neither Yes average of 54.2 bits

Either One Yes average of 61.1 bits

Both Yes average of 68.0 bits

Example for intra-frequency neighbours




26


Maximum Neighbour List Lengths (III)

Expression can be generated to identify whether or not a particular combination ofneighbours is likely to exceed the capacity of SIB11

)63()6.73()1.61(222 _ 11

3552 _ 11 ADJG ADJI ADJS SizeSIB

bitsSizeSIB

+++

65336 values

Large number of LA per PLMN00 00 and FF FE values arereserved




33


Routing Areas A UE in PS IDLE state does not have to update the PS core of its location when

moving within a RA a RA consists of cells belonging to one or more RNCs that are connected to the

same CN node, i.e. one SGSN The minimum size of a Routing Area is a single cell A RA is always contained within a single LA it is possible for RA and LA to be defined to be equal The mapping between a RA and its associated RNCs is handled by the SGSN The mapping between a RA and its cells is handled by the RNC A RA is identified globally using a Routing Area Identification (RAI) The RAI is a concatenation of the LAI and the Routing Area Code (RAC)

1 Byte => 256 values

Maximum of 256 RA per of LA




34


Paging Channel

fach-PCH-InformationList{{

transportFormatSet commonTransChTFS : {tti tti10 : {

{rlc-Size fdd : {

octetModeRLC-SizeInfoType2 sizeType1 : 4},

numberOfTbSizeList {zero : NULL,one : NULL},

logicalChannelList allSizes : NULL}

},

From SIB 5

Transmission TimeInterval = 10 ms

Transport Block Size =(4 x 8) + 48 = 80 bits(equation from TS 25.331)

Maximum Transport BlockSet Size = 1 * 80 = 80 bits

NSN RAN provides an 8 kbps PCH transport channel on the S-CCPCH 8 kbps is sufficient to include a single paging record per 10 ms

A single cell can thus page 100 UE per second S-CCPCH can be shared with the FACH-c and FACH-u but PCH always has

priority Paging completed over either a Location Area, Routing Area, RNC or Cell Utilisation of paging capacity is maximised when paging is completed over a Cell

URA_PCH RRCstate not currently

supported and sopaging does notoccur over a URA


35/42




36


Strategies (II) Possible to plan 2G and 3G networks using the LAI and RAI

Requires unique 2G and 3G Cell Identities (CI)

Cell Global Identification (CGI) defined by

core network is not able to distinguish between the two networks for pagingpurposes and both 2G and 3G paging appears on both the 2G and 3G networks

less chance of a UE missing a paging message when it is completing inter-system cell re-selection

increased quantity of paging on both systems and a requirement to co-ordinatecell identities. In practice it may be difficult to implement the same location areasfor 2G and 3G as a result of them not having the same coverage areas and notall sites being co-sited

CGI must beunique




37


Strategies (III)

LA and RA boundaries used for the 2G system are likely to be relativelymature and may have already been optimised in terms of their locations

This means that they provide a good starting point for the definition of 3G LAand RA boundaries.

LA and RA boundaries should not run close to and parallel to major roads norrailways otherwise there is a risk of relatively large numbers of updates.

Likewise, boundaries should not traverse dense subscriber areas Cells which are located at a LA or RA boundary and which experience large

numbers of updates should be monitored to evaluate the impact of the updateprocedures.

It is only necessary to decrease the size of a RA area relative to a LA if thereis a large quantity of paging from the PS service domain

LA and RA boundaries should be accounted for during the clusteridentification task associated with pre-launch optimisation

Clusters should be defined such that LA and RA boundaries are crossedduring drive tests. This helps to verify that the update procedures aresuccessful and do not have a significant impact upon services




38


Service Areas

A Service Area (SA) is identified globally using its Service AreaIdentifier (SAI)

The SAI is a concatenation of MCC + MNC + LAC + Service Area Code (SAC)

Service areas are used for emergency service calls The SAC can be configured on a per cell basis with a value equal

to the cell identity (CI). This helps to simplify system design

RAN04 introduces the Service Area Broadcast (SAB) feature whichmakes use of a third S-CCPCH and Service Area Codes for SAB(SACB)

A specific SAC can be assigned to multiple cells within a locationarea whereas a SACB must be unique for each cell within alocation area.


39/42




40


URA_PCH state

RU10 RNC support URA_PCH state transition

The purpose of this state is to decrease the cell update signalingdue to cell reselection, which saves RNC and UE resources

When the UE is in Cell_FACH or Cell_PCH state Location is known by the cell level Cell updates sent by the UE when a cell re-selection occurs

If too many cell updates ( MaxCellReselections ) are received in apredefined time window ( CellReselectionObservingTime ), the UEis ordered to transfer to URA_PCH state in order to reduce cellupdate signalling between the UE and RNC

In URA_PCH state UE sends URA update to RNC after re-selection to new URA area




41


URA planning

The planning of URA involves a balance between paging load and

signalling load Large URA : Paging load increases Small URA : Frequent URA updates, signalling load and also UE power

consumption increases

Multiple URA Ids can be configuredfor each cell Reduces possible ping-pong between

URA areas

Initially URA can be designed RNCwide Simple design, each RNC area with different

URA Id URA can be optimised with counter info


42/42



Module 9 Initial parameter planning

Summary

The initial parameter planning includes configuration ofessential parameters that are required for network launch

Groups of parameters that are dependent on the

network layout

Most parameters are configured as default

10 rn3154aen10gla0 initial parameter planning

Documents