LA-RA Planning Guidelines v1.0

TECHNICAL STUDY 1 (23)

NET SBU C&I Capability DevelopmentGSM Radio Program 20th March, 2007

Location and Routing Area Planning Guidelines

NOKIA C&I Internal Document



1. DOCUMENT HISTORY

DATE VERSION NAME COMMENTS

01/03/2007 v0.1 P. Felices First draft

16/03/2007 V0.2 P. Felices Second draft after comments

20/03/2007 V1.0 P. Felices First Issue

2. TABLE OF CONTENTS

1. Document history............................................................................................................................22. Table of contents.............................................................................................................................23. References......................................................................................................................................34. Abbreviations..................................................................................................................................35. Introduction.....................................................................................................................................46. General Configuration.....................................................................................................................5

6.1 Mobility Management Overview...............................................................................................56.2 Definition of LA and RA............................................................................................................5

6.2.1 Identifiers...........................................................................................................................66.2.2 Core Network Features.....................................................................................................6

7. Signalling Channel Capacity...........................................................................................................67.1 CCCH.......................................................................................................................................6

7.1.1 PCH...................................................................................................................................77.1.2 AGCH................................................................................................................................77.1.3 CCCH Configuration..........................................................................................................77.1.4 CCCH Capacity.................................................................................................................8

7.2 LAPD......................................................................................................................................107.3 SDCCH...................................................................................................................................11

7.3.1 SDCCH Configuration.....................................................................................................127.3.2 SDCCH Capacity.............................................................................................................12

8. Defining Location and routing Areas.............................................................................................138.1 Statistics.................................................................................................................................148.2 Data Processing.....................................................................................................................15

8.2.1 Paging load per cell.........................................................................................................158.2.2 Access grant messages..................................................................................................168.2.3 Estimated number of subscribers....................................................................................168.2.4 Handovers.......................................................................................................................17

8.3 Setting Thresholds..................................................................................................................178.3.1 Paging load.....................................................................................................................178.3.2 Number of data subscribers............................................................................................17

8.4 Creating the Location and Routing Areas...............................................................................188.4.1 Adding sites.....................................................................................................................198.4.2 Visual check....................................................................................................................208.4.3 Monitoring signalling congestion.....................................................................................218.4.4 Site add process without LRAS.......................................................................................21

8.5 Greenfield Networks...............................................................................................................22



3. REFERENCES

[1] 3GPP TS 43.064 “Overall description of GPRS radio interface, Stage 2”

[2] 3GPP TS 44.018 “Mobile radio interface layer 3 specification; Radio Resource Control Protocol”

[3] 3GPP TS 44.060 “General Packet Radio Service (GPRS); Mobile Station – Base Station System (MS-BSS) interface; Radio Link Control and Medium Access Control (RLC/MAC) layer specification”

[4] 3GPP TS 48.058 “Base Station Controller – Base Transceiver Station (BSC-BTS) interface; Layer 3 specification”

[5] Kurner, T and Hecker, A; “Performance of traffic and mobility models for location area code planning”. Proceedings of the 61st IEEE Vehicular Technology Conference, Vol 4, pp 2111-2115, May 2005

[6] Shi Wenjing, “BMCC LAC Study”, Nokia Care Team, October 2003

[7] Wille, Volker, “LA Planning – Solution Description”, Nokia OSP Solutions, September 2004

[8] Waheed, Noman, “Hajj LAC Plan for Mina”, Nokia NWP, August 2002

4. ABBREVIATIONS

3GPP 3rd Generation Partnership ProjectAGCH Access Grant ChannelBCCH Broadcast Control ChannelBCSU Base Station Controller Signalling UnitBSC Base Station ControllerBSS Base Station SystemBTS Base Transceiver StationCBCCH Common BCCH (BSS feature)CCCH Common Control ChannelCS Circuit SwitchedDL DownlinkGPRS General Packet Radio ServiceIMSI International Mobile Subscriber IdentityLA Location AreaLAC Location Area CodeLAI Location Area IdentifierLAPD Link Access Protocol on D ChannelLAU Location Area UpdateLRAS Large Routing Area Support (SGSN feature)MCC Mobile Country CodeMM Mobility ManagementMNC Mobile Network CodeMO Mobile OriginatedMOC Mobile Originated CallMSC Mobile Switching CentreMSS MSC Server SystemMT Mobile Terminated

http://qp1.connecting.nokia.com/QuickPlace/npcommunity/PageLibraryC2256BE20039204C.nsf/7095375AD2A92D38C2256C13004F1EE1/889C4A83922BE130C2256E78002B96C4/?OpenDocument

http://qp1.connecting.nokia.com/QuickPlace/npcommunity/PageLibraryC2256BE20039204C.nsf/7095375AD2A92D38C2256C13004F1EE1/8FCF94C0D23A5280C2256DF5004F0DE1/?OpenDocument



MTC Mobile Terminated CallNCH Notification ChannelPAPU Packet Processing UnitPAGCH Packet Access Grant ChannelPBCCH Packet Broadcast Control ChannelPCCCH Packet Common Control ChannelPCH Paging ChannelPDCH Packet Data ChannelPDTCH Packet Data Traffic ChannelPNCH Packet Notification ChannelPPCH Packet Paging ChannelPRACH Packet Random Access ChannelP-TMSI Packet Temporary Mobile Subscriber IdentityPS Packet SwitchedRA Routing AreaRAC Routing Area CodeRACH Random Access ChannelRAI Routing Area IdentifierRAU Routing Area UpdateRR Radio ResourceSACCH Slow Associated Control ChannelSDCCH Stand-alone Dedicated Control ChannelSG SGSN software versionSGSN Serving GPRS Support NodeSI System InformationSMS Short Message ServiceTBF Temporary Block FlowTCH Traffic ChannelTMSI Temporary Mobile Subscriber IdentityTRX TransceiverUL UplinkVLR Visitor Location Register

5. INTRODUCTION

The purpose of this document is to introduce guidelines for planning Location Areas (LA) and Routing Areas (RA). The variability in signalling traffic means that these guidelines are not prescriptive but serve to highlight areas to consider and provide ideas on producing LA and RA plans. This document does not cover signalling channel optimisation.

LA/RA planning is a non-trivial task and it has historically been easier to assign a Location Area to be equal to all the cells in one BSC, and to make the RA the same as the LA. Nokia will shortly be releasing two high capacity versions of its third generation BSC, the BSC 3i. These versions will be able to control 1000 and 2000 TRXs respectively. The current maximum for the BSC 3i is 660 TRXs.

With these high capacity BSCs, the practice of assigning an LA to a BSC may no longer be valid as the amount of paging load generated by 2000 TRXs worth of traffic may exceed the safe limit before pages are lost.

This document assumes that PBCCH is not in use as is the case with most networks.



6. GENERAL CONFIGURATION

This section summarises the purpose of Mobility Management (MM) and defines the Location and Routing Area.

6.1 Mobility Management Overview

The process of knowing both where a mobile is and what state it is in is known as Mobility Management. The core network, both CS and PS, must know whether a mobile is reachable and where to reach it.

All contact with the network is mobile initiated. If the network wants to communicate with the mobile it must first alert the mobile to this fact by paging it, after which the mobile will start the assignment procedure. The network is divided into Location Areas for voice and Routing Areas for data. All cells must belong to one LA and one RA. When a mobile is camped on a cell it knows which LA and RA it is in and has communicated this to the core network. When either of these areas changes, the mobile must start an update procedure. These update procedures are also initiated after expiry of a periodic timer, for those cases where the mobile has not crossed an LA or RA boundary.

As the network knows in which group of cells the mobile is, it can direct pages to that particular LA or RA and these pages will be broadcast on all cells that belong to those areas. The challenge in LA/RA planning is to increase the paging load to its maximum without causing paging message loss. The larger the LA and RA the fewer Location Area Updates (LAU) and Routing Area Updates (RAU) required as the subscriber is less likely to cross an LA/RA boundary. These updates create a load on the network and require capacity to be provided at both radio and core level.

The larger the LA/RA, the fewer updates due to mobility. However the paging load in that LA/RA will increase. If this becomes too large, paging congestion can occur, leading to lost pages. In this case, Mobile Terminated Calls (MTC) may then be diverted to voicemail or blocked even if the mobile in question is capable of receiving the call. On the other hand, making the LA/RA smaller will ease the paging load but increase the location update load.

6.2 Definition of LA and RA

A Location Area is defined as follows:

The minimum size of an LA is a cell consisting of one BCCH.

The maximum size of an LA is a MSC/VLR. Normally each MSC has one logical VLR even though the VLR may be made up of multiple physical VLR Units. LAs cannot cross MSC boundaries. BSC boundaries are transparent to LAs.

A Location Area Code (LAC) is represented by 16 bits leading to 65536 (range 0 to 65535) possible LACs within a network

A Routing Area is defined as follows:

An RA is a subset of a LA, therefore the absolute maximum size of an RA is the LA which it is located in.

The minimum size of an RA is a cell consisting of one BCCH or PBCCH.



Cells belonging to the same RA must also belong to the same PAPU. Hence RAs cannot cross PAPU borders, although a PAPU can support more than one RA. (This restriction does not apply if the LRAS SGSN feature, described below, is implemented.)

All cells on a PCU must belong to the same PAPU. Cells on the same PCU may belong to different RAs as long as both RAs belong to the same PAPU. (This restriction does not apply if the LRAS SGSN feature, described below, is implemented.)

A Routing Area Code (RAC) is represented by 8 bits leading to 256 (range 0 to 255) possible RACS within a LA.

6.2.1 Identifiers

The actual Location Area is identified through its Location Area Identifier (LAI). This is made up of the Mobile Country Code (MCC), Mobile Network Code (MNC) and Location Area Code:

LAI = MCC + MNC + LAC

As the routing area is a subset of the LA, the Routing Area Identifier (RAI) is composed of the LAI and the RAC:

RAI = LAI + RAC = MCC + MNC + LAC + RAC

6.2.2 Core Network Features

There are some features available at the core network level that can reduce some of the planning restrictions for LAs and RAs:

For CS core, there is a feature with Rel-5 where multiple physical MSC Server Systems (MSS) can be logically grouped into one MSS. This MSS will have one VLR and so counts as one MSS. Although an LA is never going to be of a size spanning more than one physical MSS, this feature allows for certain MSC/MSS boundaries to disappear for LA planning purposes.

For PS core there is a feature called Large Routing Area Support (LRAS) that allows the operator to group individual PAPUs into one large PAPU group. This will remove the restriction of RAs having to be within a physical PAPU as long as they are within the logical PAPU group.

7. SIGNALLING CHANNEL CAPACITY

This section describes each of the signalling channels involved in paging and location updates.

7.1 CCCH

The Common Control Channel (CCCH) is made up of four logical channels:

Paging Channel (PCH)

Access Grant Channel (AGCH)

Random Access Channel (RACH)



Notification Channel (NCH)

Of these we are only interested in the PCH and AGCH. These two channels are downlink only.

7.1.1 PCH

The PCH is used to carry Paging Request messages for mobiles that the network wants to contact. If there is no PCCCH defined then all packet paging is carried out through the PCH and as described in this section. There are three types of Paging Request message:

Paging Request Type 1: This allows two mobiles to be paged with either their TMSI/P-TMSI or IMSI.

Paging Request Type 2: This allows three mobiles to be paged, two with their TMSI/P-TMSI only and the third with either its TMSI/P-TMSI or IMSI.

Paging Request Type 3: This allows four mobiles to be paged with their TMSI/P-TMSI only.

Each paging message is transmitted within one CCCH block. (One CCCH block is spread over 4 bursts and can carry up to 23 octets of data)

7.1.2 AGCH

The AGCH is used to assign radio resources to mobiles. If no PCCCH is defined then all packet assignments are carried out through the AGCH and as described in this section. There are two types of Immediate Assignment message:

Immediate Assignment: This is used to assign an SDCCH, TCH or PDTCH to one mobile.

Immediate Assignment Extended: This is used to assign either an SDCCH or TCH to two mobiles.

The AGCH is also used to send an Immediate Assignment Reject to up to four mobiles in answer to requests for radio resources if none are available. Each Immediate Assignment or Reject message is carried within one CCCH block.

7.1.3 CCCH Configuration

There are two ways in which the CCCH can be multiplexed onto a physical timeslot. With combined SDCCH (Figure 7-1), timeslot 0 of the BCCH carrier is configured to carry the BCCH, three CCCH blocks and four SDCCH channels with their associated SACCH.



Figure 7-1: Combined SDCCH DL multiframe

With non-combined SDCCH (Figure 7-2), timeslot 0 of the BCCH carrier is configured to carry the BCCH and nine CCCH blocks.

Figure 7-2: Non-combined SDCCH DL multiframe

Normally, priority on the CCCH is given to the PCH. However, this can lead to the situation where there is not enough capacity for the AGCH. Various CCCH blocks can be reserved only for the use of the AGCH with the parameter BS_AG_BLKS_RES (SEG: number of blocks for access grant msg (AG)). With combined SDCCH, up to two CCCH blocks can be reserved for AGCH, while with non-combined SDCCH up to seven CCCHs blocks can be reserved.

For example, if we have a non-combined configuration and AG=3, this means that of the nine CCCH blocks, three are reserved for AGCH while the remaining six can be used for either PCH or AGCH.

This parameter has a special value in Nokia BSS software. If no blocks are reserved (AG=0), then the AGCH has priority rather than the PCH. This is to avoid CCCH blocks being reserved for AGCH and then remaining unused while the PCH lacks sufficient capacity. However non-zero values of AG return the priority to PCH in those cases where the CCCH block can be used for either channel.

7.1.4 CCCH Capacity

The capacity of the CCCH can only be given in terms of minimums and maximums. The actual capacity at any given time for each of its constituent channels depends entirely on the signalling traffic mix at that time. (A signalling multiframe length of 235ms is used for these tables although the actual length is 235.416ms)

For combined SDCCH, the maximum PCH capacity per hour is given in Table 7-1 and the minimum AGCH capacity per hour is given in Table 7-2.



Table 7-1: CCCH maximum hourly PCH capacity for combined SDCCHAG PCH

blocksNumber of

mobiles with Pag Req Type 1

Number of mobiles with

Pag Req Type 2


Pag Req Type 3

0 45,957 91,914 137,871 183,828

1 30,638 61,276 91,914 122,552

2 15,319 30,638 45,957 61,276

Table 7-2: CCCH minimum hourly AGCH capacity for combined SDCCHAG AGCH

blocksNumber of Mobiles

with Imm AssNumber of Mobiles with Imm Ass Ext

0 0 0 0

1 15,319 15,319 30,638

2 30,638 30,630 61,276

If TMSI is in use, the initial page is normally using the TMSI while re-pages may use the IMSI. For this reason, an assumption is normally made that each paging message is on average paging three mobiles (equivalent to a Paging Request Type 2 message). Likewise, an average assumption of about 1.5 mobiles per AGCH block is normally used.

For non-combined SDCCH, the maximum PCH capacity per hour is given in Table 7-3 and the minimum AGCH capacity per hour is given in Table 7-4.

Table 7-3: CCCH maximum hourly PCH capacity for non-combined SDCCHAG PCH

blocksNumber of

mobiles with Pag Req Type 1


Pag Req Type 2


Pag Req Type 3

0 137,871 275,742 413,613 551,484

1 122,552 245,104 367,656 490,208

2 107,233 214,466 321,699 428,932

3 91,914 183,828 275,742 367,656

4 76,595 153,190 229,785 306,380

5 61,276 122,552 183,828 245,104

6 45,957 91,914 137,871 183,828

7 30,638 61,276 91,914 122,552



Table 7-4: CCCH minimum hourly AGCH capacity for non-combined SDCCHAG AGCH

blocksNumber of Mobiles

with Imm AssNumber of Mobiles with Imm Ass Ext

0 0 0 0

1 15,319 15,319 30,638

2 30,638 30,630 61,276

3 45,957 45,957 91,914

4 61,276 61,276 122,552

5 76,595 76,595 153,190

6 91,914 91,914 183,828

7 107,233 107,233 214,466

The translation to the number of mobiles needs to be made as the Paging Request messages are composed by the BTS for transmission on the air interface. The BSC sends the BTS each page individually per mobile and this is reflected in the BSS counters.

7.2 LAPD

All the signalling involved in processing calls is carried via the LAPD link to each TRX. This is sometimes known as the TRXSIG. This signalling includes:

Call set-up and termination

Handover and power control messages

Measurement reporting

Resource indications

In addition the BCCH LAPD will also carry all the messages relating to common channel management:

Channel and resource requests

Paging and access grants

Broadcast information (SI messages)

The TRX LAPD link can be configured to be 16 kbits/s, 32 kbits/s or 64 kbits/s, this last size being rarely used. Although most LAPD messages are acknowledged, there can not be more than two unacknowledged messages at any one time. If there are, then all new messages are stored in a buffer until acknowledgement is received for at least one of the



outstanding messages. Bad link quality can also lead to delays in acknowledgements. These factors reduce the maximum safe capacity to well below that defined by the link.

There are recommendations for the LAPD load in terms of number of octets per 30 minute period. These are given in Table 7-5.

Table 7-5: LAPD load recommendations (octets per 30 minutes)LAPD size Safe Limit Overloaded Total capacity

16 kbits/s 1,000,000 1,800,000 3,600,000

32 kbits/s 1,800,000 3,600,000 7,200,000

64 kbits/s 3,500,000 7,000,000 14,400,000

As the LAPD is used for various purposes, the capacity available for paging and access grants will vary according to the amount of signalling traffic on the BCCH TRX. Nokia Product Line recommendations suggest allocating paging a maximum of 60% of LAPD capacity. Each LAPD has to carry the paging for the entire LA and RA, but only the access grants for that particular cell. For the purposes of the calculation we can focus on paging alone.

Each Paging Command message sent from the BSC to the BTS is addressed to one mobile only. The message has a maximum size of 21 octets on the LAPD. The BTS collects these messages and inserts them into an appropriate Paging Request message for transmission on the air interface. (However, Immediate Assignment messages are sent ready for transmission by the BTS and have a size of 29 octets on the LAPD.)

Applying the 60% threshold to the Overloaded column in Table 7-5 will give us the number of paging commands (mobiles) that can be supported for each LAPD size. This is given in Table 7-6.

Table 7-6: Paging Commands per LAPD sizeLAPD size Overload Limit

(Octets per 30 minutes)

Number of Paging

Commands (30 minutes)

Number of Paging

Commands (1 hour)

16 kbits/s 1,800,000 51,428 102,856

32 kbits/s 3,600,000 102,856 205,712

64 kbits/s 7,000,000 200,000 400,000

7.3 SDCCH

The SDCCH is not involved in paging but it is the channel used for Location Area Updates. (Routing Area Updates are performed via a TBF on a PDTCH.) Unlike the PCH and AGCH, the SDCCH is used for various transactions:



Call set-up

Short Message Service (SMS)

Location Area Updates

These transactions are of variable length as they depend on elements other than the BSS.

7.3.1 SDCCH Configuration

The SDCCH can be found in two configurations:

SDCCH/4: This is normally found with a combined BCCH and is illustrated in Figure 7-1. There are four SDCCH channels available

SDCCH/8: This provides eight SDCCH channels (and their associated SACCHs) on one radio timeslot

SDCCH channels can be defined as required subject to a limit of 16 channels per TRX (12 from S11.5 if the TRXSIG is 16 kbits/s).

7.3.2 SDCCH Capacity

As the transactions on the SDCCH are of variable length and the number of SDCCH channels can be varied, the SDCCH capacity required is normally calculated using the Erlang B traffic formula.

An example of an SDCCH requirement calculation is given below. Figures appropriate to your network can be substituted for the assumptions made here.

Table 7-7: Example SDCCH calculationSDCCH Transaction Number per

subscriber per hour

SDCCH hold

time (s)

Total (s)

Periodic location updates 2 3.6 7.2

Mobility location updates 4 3.6 14.4

IMSI attach 0.1 3.6 0.36

IMSI detach 0.1 3 0.3

MTC set-up 1 2.8 2.8

MOC set-up 1 2.8 2.8

MT SMS 1 6.2 6.2

MO SMS 1 6.2 6.2

40.26



Over an hour the average SDCCH hold time for one subscriber is 40.26 seconds. This is equal to 11.18 mErl.

To calculate the required number of SDCCH channels, multiply this traffic figure by the average number of subscribers per cell to obtain the total SDCCH traffic. Then apply Erlang B with 1% blocking. The acceptable blocking is tighter than with voice traffic (normally 2%) due the importance of some of the transactions on the SDCCH.

An example of the number of SDCCHs required for different configurations is given in Table7-8. Traffic per subscriber is assumed to be 25 mErls and TCH blocking is 2%. The calculation requires an iteration:

We take the total number of timeslots available, remove one for the BCCH and calculate the traffic.

This gives us a certain number of SDCCH channels required.

When we remove these timeslots from the total the amount of offered traffic decreases, reducing the number of SDCCH channels required.

The table shows the situation after the final calculation

Table 7-8: Example SDCCH requirementNumber of

TRXNumber of TCHs (FR)

Total traffic (Erl)

Number of subscribers

Total SDCCH

traffic (Erl)

SDCCH channels required

3 21 14.03 561 6.27 13

6 44 34.68 1387 15.50 25

12 89 77.34 3093 34.58 47

8. DEFINING LOCATION AND ROUTING AREAS

There are two main aims in defining Location and Routing Areas:

Maximise the utilisation of the CCCH

Minimise the number of LAUs and RAUs in the network by grouping cells together in the right way

The CCCH is a fixed resource. We can only have either three or nine CCCH blocks assigned per cell. Once those blocks are defined they can be used for nothing else, so it is in our interest to maximise the utilisation of the CCCH. We do this by making the RAs and LAs as large as possible.

On the other hand, the SDCCH can be defined as requirements dictate. If we have too many, we can release those resources. While paging and access grant occupy 100% of the CCCH, on average LAUs only occupy 50% of the SDCCH. (This includes both mobility and periodic LAUs.)



Our primary driver is the utilisation of the CCCH, not the reduction in SDCCH resources. However, once we have decided on the size of our LAs and RAs, we can still minimise the number of LAUs and RAUs by placing the correct cells within them.

The algorithm described in this section will attempt to achieve both aims at the same time. For the pure greenfield network scenario see section 8.5.

(Note: We make various assumptions for figures in this section. Feel free to replace these figures with ones more relevant to your particular network.)

8.1 Statistics

The inputs to the algorithm are configuration information and performance statistics. For each cell that will be included in the algorithm we will need:

The CCCH configuration. This is obtained by the definition of timeslot 0 on the BCCH TRX: MBCCH is non-combined, MBCCHC is combined.

The number of CCCH blocks reserved for AGCH, given by the parameter noOfBlocksForAccessGrant (AG).

The Location and Routing area to which the cell belongs.

The PCU to which the cell belongs (if LRAS is not implemented).

LAPD capacity for the BCCH TRX.

We will also need performance statistics, preferably from the busy hour for each cell. The busy hour is defined here as the hour with the highest number of CS pages. This should be the same hour for every cell in the LA/RA.

CS paging, given by c3000 and c3058 (CS paging via the Gb).

PS paging, given by c3057.

Immediate Assignment messages, given by c3001.

Immediate Assignment Reject messages, given by c3002.

Packet Immediate Assignment messages, given by c72084

Packet Immediate Assignment Reject messages, given by c72087

Number of mobile terminated calls, given by c3012.

Successful handovers to and from each defined adjacency, given by Handover Adjacent Cell Measurement.

CS traffic in Erlangs, given by c2027/c2028.

(c2xxx come from the Resource Availability table, c3xxx from the Resource Access table and c72xxx from the Packet Control Unit table)

If CBCCH is in use, then the counters must be summed across all BTSs in each segment.



8.2 Data Processing

We must now process the data to obtain the information we need for allocating cells to LAs/RAs. The output can take the form of a spreadsheet with a row for each cell containing the following fields:

CS paging load per cell

PS paging load per cell

Total of Immediate Assignment, Immediate Assignment Reject, Packet Immediate Assignment and Packet Immediate Assignment Reject messages

Estimated number of subscribers

Total number of handovers in and out of the cell

Total number of handovers to and from each adjacency

The following sub-sections describe how to obtain this information.

8.2.1 Paging load per cell

Paging is carried out across LAs and RAs. As such, the value of the counter for each cell represents the total number of pages in the particular LA or RA that cell belongs to. Disregarding re-paging attempts, the number of mobile terminated calls in the whole LA must be equal to the number of CS pages in that LA. If we were to remove cells one by one from the LA the reduction in CS paging across the LA would be proportional to the number of mobiles receiving calls in that cell. We can therefore use the number of mobile terminated calls to calculate an approximate value of the number of CS pages that each cell contributes to the total.

Ideally this calculation would use the number of first pages in a LA, but the BSS is transparent to re-paging. If it is possible to obtain the number of first pages per LA from the MSC, then use this value. If the proportion of first pages is known, then reduce the BSS page value to this proportion. Otherwise, use the BSS values.

Calculate the CS paging load as follows:

1. Add all the mobile terminated calls across the LA

2. Calculate the proportion of mobile terminated calls per cell relative to the total

3. Multiply the number of CS pages by this proportion to calculate the number of pages per cell

This is the CS paging load as illustrated in Equation 8-1.



Equation 8-1: CS cell paging load

The situation with PS is more complex. There is no equivalent to the mobile terminated call metric in data. A device may start a transaction to request a download. Here we have a mobile originated call but with a DL TBF. Likewise as traffic size can vary so much between data applications, we cannot use data traffic. One suggestion is to use the MTC proportion as illustrated in Equation 8-2. Note that the area of aggregation is the Routing Area.

Equation 8-2: PS cell paging load

8.2.2 Access grant messages

The total use of the AGCH is given by the number of Immediate Assignment, Immediate Assignment Reject, Packet Immediate Assignment and Packet Immediate Assignment Reject messages.

8.2.3 Estimated number of subscribers

When planning the Routing Area there is a restriction in that the RA can only be served by one PAPU. Depending on the SGSN software, the capacity of a PAPU varies from 40k attached subscribers to 100k attached subscribers. If the packet core is not supplied by Nokia, the operator will have to supply this information. We need to estimate the number of subscribers per cell that will be GPRS-attached so that this can be taken into account during the creation of the RA. If the subscriber limit is reached no more GPRS attachments will be accepted by that PAPU leaving subscribers with no data service.

Different networks run their GPRS subscriptions in different ways. Some provide a subscription to all their users, others to only those that subscribe to data. We can estimate the number of voice subscribers per cell by assuming a certain voice usage per subscriber. This is illustrated in Equation 8-3 with an assumption of 25mErl per subscriber.

Equation 8-3: Number of voice subscribers per cell

We can then reduce this number by the appropriate proportion of data subscribers to total subscribers. If no figures are available then assume all voice subscribers will be GPRS-attached.

(Note: If the operator has purchased the SGSN feature Large Routing Area Support then this restriction is removed and this step can be excluded. There is still a limit on the total number of subscribers that can be supported by the SGSN but as this will be a large figure we do not consider it in this process.)



8.2.4 Handovers

We will be using handover data to build the Location and Routing Areas. The Handover Adjacent Cell measurement will give individual to and from figures for each adjacency defined on the cell.

First add the successful handovers to and from each adjacency. Then add all the figures for all adjacencies. This gives both values we need.

8.3 Setting Thresholds

As we build the LAs and RAs we will check whether certain thresholds have been exceeded. These thresholds are composed of the paging load and the number of data subscribers.

8.3.1 Paging load

The maximum paging load supported by the LA/RA is dependent on the capacity of the signalling channels used. This threshold should be set considering the most constrained cell in the network. There are many ways to calculate this threshold, including on a cell by cell basis so the LA threshold changes as each cell is added.

Here we suggest a simple way that should be sufficient:

1. Take the total of the access grant messages per cell.

2. Find the largest number and use Table 7-4 to find the number of CCCH blocks required for AGCH.

3. Find the least number of CCCH blocks defined. This will be either three or nine CCCH blocks depending on whether combined SDCCH is in use somewhere.

4. Subtract the number of CCCH blocks required for AGCH from the least number of CCCH blocks defined to obtain the maximum number of CCCH blocks for PCH.

5. Use either Table 7-1 or Table 7-3 to find out the number of mobiles that can be paged in one hour. This is the radio interface capacity.

6. Use Table 7-5 to obtain the maximum number of mobiles that can be paged depending on the smallest LAPD link defined.

7. The minimum of these two values sets the paging threshold per LA/RA.

The threshold can be improved by changing the configuration of sites to be planned or even by excluding sites. If the area included both rural and city sites, it is possible to calculate separate thresholds for the city and the rural area and plan each set of LAs and RAs separately. Otherwise with very large networks you will find one or two sites reducing the overall paging threshold.

8.3.2 Number of data subscribers

We must know the maximum number of GPRS-attached subscribers that can be included in a Routing Area. We must also allow a margin to account for variations in subscriber movement. We can take a figure of 90% of maximum subscribers as our safe limit. The subscriber thresholds for Nokia packet core in this case are shown in Table 8-9.



If the LRAS SGSN feature is implemented, then there is no individual PAPU limit but an SGSN-level attached subscriber limit given by the addition of each PAPU’s limit. In this case this threshold can be left out of the process.

Table 8-9: Data subscriber thresholdsSGSN software

levelMaximum number of subscribers per

PAPU

Recommended subscriber threshold

SG4 40,000 *) 36,000

SG5/5.1 65,000 58,500

SG6 100,000 90,000

*) 20,000 if 640k subscriber capacity feature not in use

8.4 Creating the Location and Routing Areas

Each cell’s paging load comes from two sources: the CS paging from the LA and the PS paging from the RA. If there is more than one RA defined in a LA, then the paging load of each cell in that LA will not be equal as each RA’s paging load may be different.

As the smallest unit is the Routing Area we must consider both CS and PS paging load and subscriber thresholds when we start creating the areas. If we reach the paging threshold first, then that LA will only have one RA defined in it. However, if we reach the subscriber threshold first, then the LA may be able to contain a second RA as there is still paging capacity available.

In this process we use handover data to help us decide which cells should be in the same LA or RA. This is based on the theory that subscribers will tend to behave the same way whether they are on a call or not. Reference [5] gives a 94% correlation between the number of incoming handovers to a cell on the LA border and the number of location updates in that cell. Unfortunately the paper does not specify how a cell on an LA border is defined.

Using some live network statistics we have carried out a similar correlation between cells where more than 50% of the incoming handovers are from a different LA and the number of location updates on those cells. The results can be seen in Figure 8-3and the correlation is 87%. By using handover data we can ensure that cells with large numbers of handovers between them are in the same LA/RA and so reduce the amount of LAUs and RAUs required.



R2 = 0.8712

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

0 2000 4000 6000 8000 10000 12000 14000

Number of Handovers

Nu

mb

er

of

Lo

ca

tio

n U

pd

ate

s

Figure 8-3: Correlation between handovers and LAUs

8.4.1 Adding sites

The process for adding sites is an iterative one and is described here. You can take a decision to add either individual cells or the entire site. There is no reason for all cells on a site to belong to the same LA or RA. In this example process we add entire sites.

There may be cells that cover areas like shopping centres or sports facilities. These cells may be located in their own LA/RA, the idea being to remove the paging load from the general area. This allows the overlaying LA/RA to be much larger by removing the load generated by only a few cells. This idea works best if the busy cells are isolated from general traffic, for example by being indoors.

Start with the site with the most handover traffic. The reasoning is that this is the site with the most movement through it and we would like this to be at the centre of our areas. Conversely, you can choose to start with any site you like.

Add all the cells on this site to the RA and LA. Do this by adding the CS and PS paging load and number of subscribers.

Add further sites to the RA/LA by using the algorithm in Figure 8-4. Note that this process is assuming that LRAS is implemented on the SGSN. If this is not the case then the process changes slightly. The changes are described in sub-section 8.4.4.



Figure 8-4: Process for adding sites to RA/LA

8.4.2 Visual check

During and after the process of creating the LAs and RAs it is important to visually check the plan. This can be done with either a planning tool, such as NetAct™ Planner, or another graphical interface tool like Mapinfo. It is necessary to see the plan visually as the process is purely statistical and does not take any geographical features into account.

NoNo

Yes

Yes

Select site with most HOs to/from RA

Add CS and PS paging loads and

subscribers to running totals (*)

Add site to RA as candidate

Start new RA with candidate site

Remove candidate site from RA

LA and RAs complete

Remove candidate site from LA/RA

Paging threshold exceeded

?

Subscriber

threshold exceeded

?

Start new LA

(*) Keep a paging load for each RA:PL1 = LA + RA1PL2 = LA + RA2…When adding totals add the CS load to all the paging loads and the PS load to the paging load for that RA.



We want to avoid:

Having LA or RA boundaries parallel to major roads.

Not having both sides of a river or other water body in the same LA/RA if sites on one side provide coverage to the other side.

Having a LA/RA boundary through a high traffic area such as an airport, city centre or shopping centre.

The plan can be altered manually to avoid situations like this as long as the threshold check is carried out after any changes.

8.4.3 Monitoring signalling congestion

Once a new LA/RA plan has been implemented we must ensure that we are not congesting the signalling channels. There are two counters from the Resource Access table that report deleted paging or access grant messages:

c3005 – Delete Indication Messages Received from the BTS: A delete indication is sent by the BTS every time an Immediate Assignment could not be transmitted due to AGCH congestion

c3038 – Delete Paging Command: This indicates each time a paging command has been deleted due to that paging group’s BTS buffer being full. This normally indicates PCH congestion as the buffers are not being emptied fast enough.

If either of these two counters begin to increase after a new plan, this means the paging and/or assignment load for those cells is exceeding the capacity available. Signalling channel optimisation or a new LA/RA plan may be necessary.

8.4.4 Site add process without LRAS

Large Routing Area Support (LRAS) is an SGSN feature that allows the operator to create a logical PAPU by grouping several physical PAPUs together. Although physically, individual Gbs still connect to individual PAPUs, that PAPU may use the resources of all the other PAPUs in its LRAS logical group.

If LRAS is not implemented, there are a number of restrictions that need to be considered during the RA planning process:

As a Gb is connected to one individual PAPU, all cells served by that Gb (PCU) must also be connected to that PAPU.

An RA may only belong to one PAPU. A PCU may have cells belonging to more than one RA but those RAs will all belong to the same PAPU.

Essentially, if two PCUs are connected to different PAPUs then they must belong to different RAs. We need to take this into account when adding sites in our planning process.

If LRAS is not implemented, when we add a site to the LA/RA, we must also add all the other sites connected to the same PCU and calculate the paging and subscriber loads appropriately. This is the only change to the process described in Figure 8-4 in that we add groups of sites rather than individual sites.



8.5 Greenfield Networks

There may be occasions when the network to be planned is a complete greenfield design with no performance statistics available. The traffic on a network like this is expected to be very low and grow with time. We can design a simple conservative plan for the Location and Routing Areas and wait for performance statistics to become meaningful before following a more precise process.

Firstly, let us roughly calculate whether we can use the rule of allocating one LA and RA per BSC. Figure 8-5 shows an 85% correlation between the traffic and CS paging messages per BSC obtained from some live network data. These data comes from BSCs in a mostly urban and dense urban environment and show an average of 22 paging messages per Erlang of traffic.

R2 = 0.8565

0

200

400

600

800

1000

1200

1400

1600

1800

2000

0 5000 10000 15000 20000 25000 30000 35000 40000 45000

Paging Messages per BSC

Tra

ffic

pe

r B

SC

(E

rla

ng

s)

Figure 8-5: Correlation between paging and traffic

There is no correlation between traffic per BSC and number of TRXs per BSC. There are two reasons for this:

Additional TRXs provide a discrete amount of extra capacity, which may or may not be in use.

Many basic installations comprise 2 TRXs per sector regardless of whether 2 TRXs are required or not.

As such, we will have to calculate a possible maximum paging load per BSC based on the traffic capacity. Table 8-10 shows the number of CS paging messages per BSC type based on an 80% utilisation threshold (current recommendation for expansion).



Table 8-10: Estimated CS paging capacity per BSC typeBSC Type Maximum TRX

CapacityTraffic

Capacity (Erlangs)

80% Traffic Capacity (Erlangs)

Estimated Paging

Messages

2i 512 3,040 2,432 53,504

3i 660 660 3,920 3,136 68,992

3i 1000 1000 5,940 4,752 104,544

3i 2000 2000 11,880 9,504 209,088

From this table and using the tables in section 7, we can see that a majority non-combined SDCCH configuration would be needed in all BSC types, with the possible exception of the BSC 2i. However if the LAPD size is 16 kbits/s in the majority of the BSC, then both the largest capacity BSCs exceed the paging load of the LAPD. If the LAPD is 32 kbits/s then only the BSC 3i 2000 exceeds the LAPD paging capacity.

In reality, we will more likely reach one of the object limits first, probably the TRX limit. In the live network data from above, each BSC had an average TRX connectivity of 60% of the maximum but only 35% of the traffic figure. Using this discrepancy to absorb the PS paging, we can recommend the following:

BSC 2i, BSC 3i 660 and BSC 3i 1000 can have one LA defined

BSC 3i 2000 needs two LAs defined

If we can obtain forecast traffic per cell for our greenfield network then we can use the same general process as described earlier in this section.

Documents

LA-RA Planning Guidelines v1.0