Pre-Emption and Queing

8/12/2019 Pre-Emption and Queing

http://slidepdf.com/reader/full/pre-emption-and-queing 1/39

GSM/EDGE BSS, Rel.

RG20(BSS), Operating

Documentation, Issue 10

Feature description

BSC3910 and BSS20869: Radio Resource

Pre-emption and Queuing

DN9835517

Issue 13-1

Approval Date 2011-04-07

Confidential

Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of

its products and services. We would like to encourage you as our customers and users to join

us in working towards a cleaner, safer environment. Please recycle product packaging and

follow the recommendations for power use and proper disposal of our products and their compo-

nents.

If you should have questions regarding our Environmental Policy or any of the environmental

services we offer, please contact us at Nokia Siemens Networks for any additional information.



2 DN9835517

BSC3910 and BSS20869: Radio Resource Pre-emp-tion and Queuing

Id:0900d8058084fd6b

Confidential

The information in this document is subject to change without notice and describes only the

product defined in the introduction of this documentation. This documentation is intended for the

use of Nokia Siemens Networks customers only for the purposes of the agreement under whichthe document is submitted, and no part of it may be used, reproduced, modified or transmitted

in any form or means without the prior written permission of Nokia Siemens Networks. The

documentation has been prepared to be used by professional and properly trained personnel,

and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes

customer comments as part of the process of continuous development and improvement of the

documentation.

The information or statements given in this documentation concerning the suitability, capacity,

or performance of the mentioned hardware or software products are given "as is" and all liability

arising in connection with such hardware or software products shall be defined conclusively and

finally in a separate agreement between Nokia Siemens Networks and the customer. However,

Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions

contained in the document are adequate and free of material errors and omissions. Nokia

Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which

may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO

EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-

TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-

RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED

TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY

OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION

IN IT.

This documentation and the product it describes are considered protected by copyrights and

other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark

of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respectiveowners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2011. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sources

of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle

this product and only after having carefully read the safety information applicable to this

product.

The safety information is provided in the Safety Information section in the “Legal, Safety

and Environmental Information” part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur ProduktsicherheitVon diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder

andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch

geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-

anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal,

Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-

satzes.





4 DN9835517


Id:0900d8058084fd6b

Confidential

List of figuresFigure 1 Forced release after an unsuccessful forced handover attempt . . . . . . . 16

Figure 2 Time stamp comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 3 Soft call drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18



DN9835517 5


Id:0900d8058084fd6b

Confidential

List of tablesTable 1 Example of subscriber classification . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Table 2 Required software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Table 3 Counters of Traffic Measurement related to Radio Resource Pre-emption

34

Table 4 Counters of Traffic Measurement related to Queuing . . . . . . . . . . . . . . 34

Table 5 Counters of Traffic Measurement related to Market Expansion Toolkit 35



6 DN9835517


Id:0900d8058084fd6b

Confidential



DN9835517 7


Summary of changes

Id:0900d8058085e7ff

Confidential

Summary of changesChanges between document issues are cumulative. Therefore, the latest document

issue contains all changes made to previous issues.

Changes made between issues 13-1 and 13-0

Information on BSS21534: OSC Full Rate with SAIC MS has been added in chapter

Interworking with other features.


Information on BSS21222: Energy optimized TCH allocation and BSS21309: OSC Half

Rate with SAIC MS has been added in chapter Interworking with other features.

Information on BTSplus BTS and Flexi Multiradio BTS has been added in chapter

Requirements.

Changes made between issues 12-2 and 12-1Information on ISHO Acceleration via IUR-G has been added in chapter Interworking

with other features.


Information on InSite BTS has been removed.


Information on pre-emption queuers has been added in section Pre-emption.

Information on Dynamic Frequency and Channel Allocation has been updated in section

Interworking with other features

The name of NetAct Radio Access Configurator has been changed to NetAct Configu-rator.


Overview of Radio Resource Pre-emption and Queuing

Information of chapter Radio Resource Pre-emption and Queuing in Radio Resource

Pre-emption and Queuing System Feature Description has been combined into this

chapter.

Technical Description of Radio Resource Pre-emption and Queuing

Information of chapter Radio Resource Pre-emption and Queuing in Radio Resource

Pre-emption and Queuing System Feature Description has been combined into thischapter.

Functionality of Radio Resource Pre-emption and Queuing

Information of chapter Technical Description of Radio Resource Pre-emption and

Queuing has been combined into this chapter. Section Forced release after an unsuc-

cessful forced handover attempt has been added.

System impact of Radio Resource Pre-emption and Queuing

This chapter has been added. Chapter User interface of Radio Resource Pre-emption

and Queuing has been combined into this chapter.



8 DN9835517


Id:0900d8058085e7ff

Confidential

Summary of changes

Implementing of Radio Resource Pre-emption and Queuing

This chapter has been added.

Information on Market Expansion Toolkit has been added throughout the document. The

counters of Traffic Measurement related to Market Expansion Toolkit have been addedto section Measurement and counters in System impact of Radio Resource Pre-emption

and Queuing .

Two new unsuccessful forced handovers 'There are no resources available in the neigh-

bouring cells' and 'There are no suitable neighbouring cells in the network' have been

added to Functionality of Radio Resource Pre-emption and Queuing .

Section Stored information and statistics counters in Functionality of Radio Resource

Pre-emption and Queuing has been updated to remove too detailed information and the

old data structures.

The counters of Traffic Measurement related to Radio Resource Pre-emption and

Queuing have been updated in section Measurement and counters in System impact of

Radio Resource Pre-emption and Queuing .


Priority level related information has been moved from section Storing forced release

requests to section Storing forced handover requests in chapter Technical description

of Radio Resource Pre-emption and Queuing .



DN9835517 9



Id:0900d8058059120f

Confidential

1 Overview of Radio Resource Pre-emption

and Queuing

Radio Resource Pre-emption and Queuing makes it possible to provide a specific levelof service in case of temporary congestion. Each subscriber can be assigned a specific

priority level. Subscribers with the highest priority level can be guaranteed a high level

of service at all times, while the service level for other subscribers can be lower when

there is congestion in the cell.

Pre-emption

The purpose of the BSC pre-emption procedures (forced release and forced handover)

is to offer a service of a guaranteed level to the subscribers in a temporary cell conges-

tion situation.

In a temporary congestion situation, the priority levels and the pre-emption indicators

may be used to determine whether an assignment or handover request has to be per-formed unconditionally and immediately. This leads to the triggering of the pre-emption

procedure that causes the forced release or forced handover of a lower priority connec-

tion if no free resource is immediately available.

The seizure request that is allowed to cause the forced release or forced handover for

a call in progress can be one of the following:

• mobile-originating call (MOC) set-up

• mobile-terminating call (MTC) set-up

• handover attempt

Pre-emption is BSC-specific that contains specific statistical functions.

Queuing

The purpose of radio resource queuing in the BSC is to increase the number of success-

fully completed calls in a temporary congestion situation in the cell and, in doing so, to

increase radio network efficiency.

Radio resource queuing enables placing a radio channel request to a queue, and when

a suitable radio resource becomes available again, the call set-up can be continued.

Consequently, there is no need to cut off a started transaction caused by temporary

radio channel congestion in the cell.

The queued radio resource is always a traffic channel (TCH), never a stand-alone ded-

icated control channel (SDCCH). The queued seizure request can be one of the fol-

lowing:

• mobile-originating call (MOC) set-up

• mobile-terminating call (MTC) set-up

• handover attempt (all GSM-specified handover types)

Radio resource queuing in the BSC is always a cell-specific procedure that contains

specific priority management and statistical functions.

Market Expansion Toolkit

Market Expansion Toolkit is an enhancement to Pre-emption that allows you to divide

subscribers into classes more effectively. It consists of the following enhancements:

http://general_glossary.pdf/






10 DN9835517


Id:0900d8058059120f

Confidential


• Forced release after an unsuccessful forced handover attempt

Forced release after an unsuccessful forced handover attempt combines the forced

release and forced handover procedures. If a forced handover is not possible, for

example because of congestion in neighbour cells, a forced release is performed to

make room for a higher priority subscriber.

• Pre-emption based subscriber classification

Pre-emption based subscriber classification is done by applying Forced release

after an unsuccessful forced handover attempt only to subscribers with certain

priority levels.

• Subscriber class specific statistics

Traffic channel allocation attempts and successful traffic channel seizures during a

call setup are counted separately for all the subscriber classes. These counters help

you in deciding when to increase the capacity of the network. For example, if the

counters show blocking for priority one subscribers, capacity increase may be

required.

• Fair call duration

Fair call duration makes it possible to use pre-emption on calls that have lasted

longer. This ensures that the shortest call of the cell is not disconnected.

• Soft call drop support in BSC

Soft call drop is an MSC feature which gives the users a warning that their call is

about to be cut off. This means that users have time to end the calls before being

disconnected.

Market Expansion Toolkit requires a valid licence in the BSC.

Benefits of Radio Resource Pre-emption and Queuing

Radio Resource Pre-emption and Queuing enables subscriber segmentation, making it

possible to increase the number of subscribers in the network without increasing the

network capacity. Queuing also improves radio network efficiency, as it increases the

number of successfully completed calls in a temporary congestion situation in the cell.

With Market Expansion Toolkit, you can divide subscribers into classes more effectively

than before. This improves user satisfaction, as you can ensure a high level of service

for high class subscribers while providing a fair resource usage among the lower class

subscribers.

Related topics in Radio Resource Pre-emption and Queuing in BSC

• Technical description of Radio Resource Pre-emption and Queuing

• Functionality of Radio Resource Pre-emption and Queuing

• System impact of Radio Resource Pre-emption and Queuing

• Implementing of Radio Resource Pre-emption and Queuing overview

Other related topics

• Functional Area Descriptions

• Radio Network Performance

• RF Power Control and Handover Algorithm

• Radio Channel Allocation

• Feature Descriptions

• Existing features

• Radio Network Performance • Soft Channel Capacity in BSC

http://dn9814129.pdf/








DN9835517 11



Id:0900d8058059120f

Confidential

• Directed Retry in BSC

• Intelligent Underlay-Overlay

• Dynamic Frequency and Channel Allocation

• Packet Switched Data • HSCSC and 14.4 kbit/s Data Services in BSC

• Macrocellular

• Handover Support for Coverage Enhancements

• Value Added Services

• Wireless Priority Service in BSC

• Trunk Reservation

• Install

• Software

• Licencing in BSC

• Activate

• Value Added Services

• Activating and Testing BSC3910: Pre-emption and BSS20869: Market

Expansion Toolkit

• Reference

• Clear Codes/Cause Codes

• Call Related DX Causes in BSC

• Commands

• MML Commands

• EE - Base Station Controller Parameter Handling

• EQ - Base Transceiver Station Handling in BSC

• Counters/Performance Indicators • Circuit-switched Measurements

• 1 Traffic Measurement

• Parameters

• BSS Radio Network Parameter Dictionary

• PRFILE and FIFILE parameter list










http://x%3Dd%3Do%3Dc/s-000338.pdf



















12 DN9835517


Id:0900d80580591212

Confidential

Technical description of Radio Resource Pre-emptionand Queuing

2 Technical description of Radio Resource Pre-

emption and Queuing

2.1 Queuing

The BSC has a cell-specific queue for every queue type. Three different queue types

are implemented:

• call queue

Used when mobile-originating call (MOC) or mobile-terminating call (MTC)

attempts are queued for.

• handover queue for urgent handovers

Used when an urgent handover attempt is queued for. The initial cause of the

handover determines the urgency. The handover causes treated as non-urgent are:

• uplink/downlink interference

• uplink/downlink quality

• uplink/downlink level

• handover initiated because of a rapid field drop

• MS-BTS distance exceeding cell boundaries

• MS-BTS distance causing a handover from extended range cell to inner cell

• MS-BTS distance causing a handover from inner cell to extended range cell

• forced handover to empty a cell

• handover from super-reuse to regular frequency area because of a bad carrier-

to-interference ratio (C/I)

•

handover initiated to switch theA interface

circuit pool • handover of a fast-moving MS from the lower layer cell to upper layer cell

For more information, see Intelligent Underlay-Overlay under Feature Descriptions

and RF Power Control and Handover Algorithm under Functional Area Descriptions.

• handover queue for non-urgent handovers

Used when a non-urgent handover attempt is queued for. The handover causes

treated as non-urgent are:

• power budget handover

• umbrella handover

• handover of slow-moving MS from the upper layer cell to the lower layer cell

• MSC-controlled traffic reason handover

• BSC-controlled traffic reason handover These three logical queues form one cell-specific physical queue.

The handover attempt can be an internal intra-cell, internal inter-cell, or external han-

dover. However, external handovers are always treated as urgent handovers when the

target BSC has not received the handover cause information from the A interface.

Note that the following handover attempts are not queued:

• handovers from regular to super-reuse frequency area corresponding to the cause

'Good C/I ratio'

• handovers related to Directed Retry or Intelligent Directed Retry

• handovers initiated by the pre-emption procedure











DN9835517 13



Id:0900d80580591212

Confidential

You can handle the queuing parameters using NetAct or the local MMI. With the param-

eters, it is possible to manage queuing on a cell-by-cell basis and to determine the

queuing characteristics. The following parameters are used:

• allowed queue length • queuing time for the call queue type (the same for both MOC and MTC)

• queuing time for the handover queue type (the same for urgent and non urgent han-

dovers)

• priority management

• queue type priority: possibility to prioritise between the three queue types

• MSC informed priority (MS priority): possibility to prioritise between queue

seizure elements

The queue type priority and MSC informed priority can be set on or off.

Queuing possibility

The target cell used for queuing can vary depending on the request type. One queuingtarget cell is possible in the following cases:

• call attempt: the actual cell is used as the queuing target

• internal intra-cell handover: the actual cell is used as the queuing target

• external cell handover (target BSC): the cell identified by the MSC in a HANDOVER

REQUEST message is used as the queuing target

In an internal inter-cell handover, it is possible to use more cells (up to sixteen) as alter-

native target cells in radio resource allocation. The handover candidate cells for the

channel search are chosen from the candidate cell list created by the handover algo-

rithm. From these cells, the BSC searches for a free radio resource in the order of their

superiority over each other. If all the cells in the list are congested, the queuing possibil-

ity in the candidate cells is checked using the same order as in the allocation procedure.

Consequently, in this handover type choices are given to the BSC to increase the

chance of getting the required free radio resource, either immediately or after queuing.

2.2 Pre-emption

Pre-emption is used when the BSC receives an assignment request or a handover

request from the MSC and no suitable channel is available in the cell.

The BSC has two ways to perform call pre-emption: forced release and forced handover.

In both cases, there is a separate queue for calls which are waiting for the target call to

be released or handed over. It depends on the priority of the call which of the queues ischosen (forced handover or forced release).

A maximum of eight seizure requests can be stored at a time for a cell in each pre-

emption queues. In BSC level total amount of simultaneous pre-emption queuers is

3000.

Priority of the request

The priority of the request is received with the request in a special priority element. In

pre-emption handling, the most important information concerning seizure requests is the

Priority information element (PIE). The PIE contains the following information:

• MS priority (PRIO)

• pre-emption capability indicator (PCI)



14 DN9835517


Id:0900d80580591212

Confidential


• pre-emption vulnerability indicator (PVI)

• queuing allowed indicator (QA)

With these indicators, different services can be offered to certain priority levels. Priority

0 is defined as spare and it does not initiate pre-emption procedures.

• PCI=YES, QA=YES, PRIO=0

Does not initiate the pre-emption procedure because the priority level 0 is specified

as spare.

• PCI=YES, QA=YES, PRIO=1

The highest possible priority. Initiates forced release for a vulnerability call in prog-

ress.

• PCI=YES, QA=YES, PRIO=2...PRIO=14

Initiates forced handover for a vulnerability call in progress.

• PVI=YES, QA=no relevance, PRIO=0

Not chosen to be the target of the forced release or forced handover because priority

0 is spare.

• PVI=YES, QA=no relevance, PRIO=2...PRIO=14

The lowest priority is chosen to be the target of the forced release or forced han-

dover. Priority 1 is the highest and 14 the lowest. A call with priority 1 cannot be

overridden by another call.

Forced release

Forced release queue

Forced release queue is the queue for the calls which are waiting for the target call to

be released. They are equipped with the priority level 1.

Storing forced release requests

The seizure request which is allowed to cause a forced release to another call in

progress is stored in the BTS forced release data structure (BFRFIL). The seizure

request is stored, provided that there is free space.

When the seizure request is stored in the BFRFIL, the BSC sends the QUEUING

INDICATION message to the MSC. If Directed Retry is in use, and a seizure request is

waiting for forced release in the BFRFIL, Directed Retry is not initiated. If the seizure

request cannot be stored (that is, the BFRFIL is full), the channel allocation is given a

negative acknowledgement.

When the seizure request is stored in the BFRFIL, the BSC's BTS state data structure

(BSTAFI) is updated with the information on the number of forced release seizure

requests in that cell and time supervision is started. The time limit is a BSC-specific fixedparameter (which means that it cannot be changed by the user).

Successful forced release

If the BSC detects seizure requests in the BFRFIL when a traffic channel (TCH) is

released, the TCH is allocated for the first seizure request, and it is removed from the

BFRFIL. The number of forced release seizure requests in the BFRFIL in that cell is

updated in the BSTAFI.

Time-out for the forced release

The number of TCH requests which are allowed to cause a forced release is updated in

the BSTAFI. An unsuccessful assignment or handover attempt is rejected with the

cause 'No Radio Resource Available'.



DN9835517 15



Id:0900d80580591212

Confidential

Forced handover

Forced handover queue

Forced handover queue is the queue for the calls which are waiting for the target call to

be handed over.

Storing forced handover requests

The seizure request which is allowed to cause a forced handover to another call in

progress is stored in the BTS forced handover data structure (BFHFIL). The seizure

requests are stored to BFHFIL according to the priority levels of subscribers. The

seizure request is stored in the BFHFIL, providing that there is free space. If there is no

free space in the BFHFIL, a request with a lower priority is removed to make room for a

request with a higher priority.

When the seizure request is stored in the BFHFIL, the BSC sends the QUEUING

INDICATION message to the MSC. If Directed Retry is in use and if the seizure request

is waiting for forced handover in the BFHFIL, directed retry is not initiated. If the seizure

request cannot be stored (that is, the BFHFIL is full and it is not possible to remove any

lower priority requests), the channel allocation is given a negative acknowledgement.

When the seizure request is stored in the BFHFIL, the BSC's BTS state data structure

(BSTAFI) is updated with the information on the number of forced handover seizure

requests in that cell and time supervision is started. The time limit is a BSC-specific fixed

parameter.

Successful forced handover

When a TCH is released in the actual cell, the BSC first checks the BFRFIL. If the BSC

does not detect a seizure request in the BFRFIL, it then checks the BFHFIL. If the BSC

detects seizure requests in the BFHFIL, the TCH is allocated for the first seizure

request, and it is removed from the BFHFIL. The number of forced handover seizurerequests in the BFHFIL in that cell is updated in the BSTAFI.

Time-out for forced handover

The number of TCH requests which are allowed to cause a forced handover is updated

in the BSTAFI. An unsuccessful assignment or handover attempt is rejected with the

cause 'No Radio Resource Available'.

2.3 Market Expansion Toolkit

Market Expansion Toolkit introduces five enhancements to Pre-emption.

Of these five, the following are enabled automatically when the Market ExpansionToolkit licence state is set to ON:

• Subscriber class specific statistics

• Fair call duration

• Soft call drop support in BSC

Enabling the following two enchancements requires that the parameter is set to some

other value than to the default value. They can also be disabled by setting the param-

eter forced release priority threshold to the default value ('1').

• Forced release after an unsuccessful forced handover attempt

• Pre-emption based subscriber classification



16 DN9835517


Id:0900d80580591212

Confidential


Forced release after an unsuccessful forced handover attempt

Forced release after an unsuccessful forced handover attempt ensures that a high

priority subscriber is allocated a TCH even if there is congestion in the cell and the

neighbouring cells. If the lower priority subscriber cannot be handed over to another cell,a forced release is started for the lower priority subscriber. Figure Forced release after

an unsuccessful forced handover attempt illustrates the process in a congested

network.

Figure 1 Forced release after an unsuccessful forced handover attempt

Pre-emption based subscriber classification

The subscribers are divided into classes according to their priority levels and the value

of the parameter forced release priority threshold. The priority levels are

defined in the MSC and the parameter value in the BSC. The parameter range is 2 to

14. The value 1 is the default value which disables the pre-emption base classification

in all pre-emption attempts.

Table Example of subscriber classification gives an example of a situation where thethree priority levels have been specified in the MSC/HLR and the value of the forced

release priority threshold parameter in the BSC is 2. The Function column

states what happens in a congestion situation.

Class Priority

level

PCI QA PVI Function

1 1 Y Y N Forced release

Table 1 Example of subscriber classification

A TCH is neededfor a high priorityuser.

Select the pre-emption candidate.

Start forcedhandover.

Start forced releasefor the selectedcandidate.

Allocate the TCHfor the highpriority user.

The cell iscongested.

The neighbour cellsare congested.

The low priorityuser is moved toanother cell.

The low priorityuser is released.



DN9835517 17



Id:0900d80580591212

Confidential

Subscriber class specific statistics

The Market Expansion Toolkit related Traffic Measurement counters are updated

according to the class of the subscriber. There are two counters for each subscriber

class.

For more information on counters related to Market Expansion Toolkit, see System

impact of Radio Resource Pre-emption and Queuing .

Fair call duration

In Fair call duration, the call durations are compared when a pre-emption candidate is

selected. The comparison is made between two or more equal pre-emption candidates.

The candidate with the longest call is then selected for pre-emption. If the call is trans-

ferred from one TCH to another, the existing time stamp is also transferred to the new

TCH. Figure Time stamp comparison illustrates the selection process.

Figure 2 Time stamp comparison

Soft call drop support in BSC

In a soft call drop, the MSC sends a warning tone to the pre-empted user and waits for

a short period before starting the release procedure. Support for soft call drop in the BSC

is implemented by extending the timer that controls pre-emption. This ensures that the

BSC waits long enough for the channel release procedure to be completed. Figure Soft

call drop illustrates how the soft call drop procedure works.

2 2 Y Y N Forced handover

(primary option) orforced release (sec-

ondary option)

3 3-14 N Y Y No pre-emption capa-

bility

Class Priority

level

PCI QA PVI Function

Table 1 Example of subscriber classification (Cont.)

Call 1 time stamp

12:28:24

Call 2 time stamp

12:30:45

Call 3 time stamp

12:27:27

Call 4 time stamp

12:31:05

The TCH containing the longestlasting call is selected for pre-emption.

The duration of the call = NOW - timestamp



18 DN9835517


Id:0900d80580591212

Confidential


Figure 3 Soft call drop

1. The MSC sends an ASSIGNMENT REQUEST message to the BSC for MS 2.

2. The BSC starts the pre-emption procedure for a lower priority class subscriber (MS

1).

The timer that controls pre-emption is set for 15 seconds.

3. The BSC sends a QUEUING INDICATION message to the MSC for MS 2.

4. If handover is not possible for MS 1 and forced release is allowed, the BSC sends a

CLEAR REQUEST message to the MSC for MS 1.

5.

The MSC send a warning tone or message to MS 1 and waits until the time set inthe timer has been exceeded.

The user is not disconnected immediately, but has time to finish the call properly.

6. The MSC releases the call (MS 1).

7. The MSC sends a CLEAR COMMAND message to the BSC for MS 1.

8. The BSC clears the call and gives the released TCH to MS 2.

The BSC also resets the timer.

9. The BSC sends a CLEAR COMPLETE message to the MSC (MS 1).

10. The BSC sends a ASSIGNMENT COMPLETE message to the MSC (MS 2).

ASSIGNMENT REQUEST (MS 2)

The BSC starts pre-emption for MS 1.

BSC MSCMS

QUEUING INDICATION (MS2)

Forced handover is not possible.

Forced release is allowed.

CLEAR REQUEST (MS 1)

The MSC sends a warning to MS 1 and waits a while.

The user (MS 1) has timeto finish the call.

The MSC releases the call (MS 1).

CLEAR COMMAND (MS 1)

The BSC clears the call (MS 1) and gives thereleased channel to MS 2.

CLEAR COMPLETE (MS 1)

ASSIGNMENT COMPLETE (MS 2)





20 DN9835517


Id:0900d80580591215

Confidential

Functionality of Radio Resource Pre-emption andQueuing

The calculated actual queue length in the cell specifies the number of call and handover

attempts that can queue for a TCH release in that cell.

In the BSC, every cell has the same maximum data area (same number of queuing posi-

tions) on which the maximum queue length can have an effect. The data area gives themaximum value to the actual queue length for every cell. The size of the data area can

be changed, but it is fixed in a certain software package.

3.3 Forced release

Forced release possibility checks

When the BSC receives an ASSIGNMENT or a HANDOVER REQUEST message and all

traffic channels (TCHs) are busy, it checks whether the assignment is allowed to cause

a forced release to another call in progress on the cell. The forced release transaction

is allowed, if the 'pre-emption capability' indicator is set on, the MS priority is set to 1,

and the 'queuing allowed' indicator is set on.

In a call attempt which is allowed to cause a forced release, the Priority information

element (PIE) received from the MSC in the ASSIGNMENT REQUEST message is used.

The MSC can prevent the use of the forced release procedure for a call in progress by

setting the pre-emption vulnerability indicator off.

In an internal handover, the original PIE is used. The PIE is stored in the BSC during the

call set-up phase. If the MSC has prevented the forced release in the original call

attempt, the forced release is also denied in all handover attempts during the ongoing

call.

In an external handover, the PIE received from the MSC in the HANDOVER REQUEST

message is used.

In a successful forced release, the BSC sends a pre-emptive TCH request for a new call

or handover attempt. This request causes the forced release for another call in progress

and the new call receives the released TCH. The BSC then initiates channel allocation

signalling.

If no channel has been released within the time limit, the forced release is unsuccessful.

Selection of the candidate for forced release

After the BSC has stored the information of the seizure request to the BTS forced

release data structure (BFRFIL), it selects the candidate to be released. The following

main principles apply to the candidate selection:

• the candidate has the pre-emption vulnerability indicator set on • the call in progress is not an emergency call

• the call with the lowest priority among the calls in progress is selected

The TCH channel rate requirement of the resource request makes the candidate selec-

tion procedure more complicated, especially when the cell contains dual rate resources

and a full rate TCH is requested. In that case, the following two cases are possible:

• the MS of the lowest priority is found among the full rate MSS

• the MS of the lowest priority is found from a half occupied dual rate radio timeslot

(RTSL)

The following rules are applied when the candidate for forced release is selected:

• the MS of the lowest possible priority is allocated





DN9835517 21



Id:0900d80580591215

Confidential

• only one call is allowed to be released for an incoming call

When the BSC has found the best suitable candidate for the release, it starts the

required signalling procedures concerning forced release.

Successful forced release

The successful assignment or handover is reported to the BSC, including the informa-

tion concerning the radio resource allocated to i t. After that, the BSC starts the required

signalling procedures concerning the assignment or handover attempt.

Unsuccessful forced release

When the forced release seizure request is stored to the BFRFIL, time supervision is

started. The time limit is 10 s. If the time supervision expires and no TCHs have been

released, the BSC receives a time-out message. The seizure request is removed from

the BFRFIL.

Statistics counters for forced release

When the BSC receives a seizure request attempt which is allowed to cause a forced

release for another call in progress, statistical counters are updated. Assignment

request attempts and handover request attempts have their own counters.

When a TCH request which is allowed to cause a forced release for another call in

progress is rejected because of lack of released channels, the statistics counters are

updated. Assignment request failures and handover request failures have their own

counters.

When the seizure request that caused a forced release for another call in progress

receives a TCH, a statistics counter is updated.

If TCH allocation is based on the RX level and the assignment request is rejectedbecause of too low an RX level, a specific statistical counter is updated.

The counters are BTS-specific. For more information on the counters, see 1 Traffic Mea-

surement under Reference.

3.4 Forced handover

Forced handover possibility checks

When the BSC receives an ASSIGNMENT or a HANDOVER REQUEST message and all

traffic channels are busy, it first checks from the Priority information element (PIE) of the

seizure request if the assignment or handover is allowed to cause a forced release. If a

forced release is not allowed, the BSC then checks if the seizure request is allowed to

cause a forced handover for another call in progress in the cell. The forced handover

transaction is allowed if the 'pre-emption capability' indicator is set on, the MS priority is

set to 2-14 in the PIE, and the 'queuing allowed' indicator is set on.

In a call attempt which is allowed to cause a forced handover, the priority element

received from the MSC in the ASSIGNMENT REQUEST message is used. The MSC can

prevent the use of the forced handover function for the call in progress by setting the

pre-emption vulnerability indicator off.

In an internal handover, the original PIE is used. The PIE is stored during the call set-up

phase in the BSC. If the MSC has prevented the forced handover in the original call





DN9835517 23



Id:0900d80580591215

Confidential

Unsuccessful forced handover

When the forced handover seizure request is stored to the BFHFIL, time supervision is

started. The time limit is 10 s. If the time supervision expires and no TCHs have been

released, the BSC receives a time-out message. The seizure request is removed fromthe BFHFIL.

In the following unsuccessful forced handover cases, a new candidate is selected for a

forced handover, and a forced handover is started again:

• There are no resources available in the neighbouring cells

• There are no suitable neighbouring cells in the network

Statistics counters for forced handover

When the BSC receives a seizure request attempt which is allowed to cause a forced

handover for another call in progress, statistical counters are updated. Assignment

request attempts and handover request attempts have their own counters.

When a TCH request which is allowed to cause a forced handover for another call in

progress is rejected because of lack of released channels, the statistics counters are

updated. Assignment request failures and handover request failures have their own

counters.

The counters are BTS-specific. For more information on the counters, see 1 Traffic Mea-

surement under Reference.

Forced release after an unsuccessful forced handover attempt

The Market Expansion Toolkit allows to start a forced release after an unsuccessful

forced handover attempt.

A forced release can be started after an unsuccessful forced handover attempt only if

the subscriber belongs to the class 2 in the pre-emption based subscriber classification.

Then the subscriber's MS priority is lower than or equal to the value of the parameter

FRPT. For more information on the classification, see Pre-emption based subscriber

classification.

A forced release can be started if there are no resources available in the neighbouring

cells, or no suitable neighbouring cells exist in the network. A forced release is started

for the same TCH candidate which has already been selected for an forced handover

attempt.

Although the subscriber is able to start a forced release for the existing call, the informa-

tion of the seizure request remains stored in BFHFIL.

• Successful and unsuccessful forced releaseThe successful and unsuccessful forced releases after an unsuccessful forced

handover attempt are explained in Forced release.

• Time-out for a forced release

If the Market Expansion Toolkit is in use, the time limit is 15 s.

Enabling the Market Expansion Toolkit enhancement increases the time limit in all

the pre-emption related cases.

If the time supervision expires, and no TCHs have been released, the BSC receives

a time-out message. The seizure request is removed from the BFHFIL.



24 DN9835517


Id:0900d80580591215

Confidential


• Statistics counters for a forced release

A BTS-specific statistics counter for a forced release after an unsuccessful forced

handover attempt is updated once the BSC receives a forced release after an

unsuccessful forced handover attempt.

For more information on the Market Expansion Toolkit related counters, see Mea-

surements and counters.

3.5 Queuing

Queuing possibility checks

When all TCHs are busy or there are no TCHs of the requested kind available and the

seizure request is not allowed to cause a forced release or a forced handover for another

call in progress, the BSC checks whether the queuing of this assignment or handover is

allowed. The queuing transaction is allowed if the following requirements are met:

• the 'queuing allowed' indicator in the Priority information element (PIE) is set on

• the cell channel configuration contains channels capable of the requested channel

rate

• the SEG-specific queue parameters make queuing possible in the cell

In call attempt queuing, the priority element that has been received from the MSC and

contained in the ASSIGNMENT REQUEST message, contains the 'queuing allowed' indi-

cator. This priority element is used. If the MSC prevents the queuing, the call attempt

cannot be placed in the queue.

In an internal handover, the original PIE is used and stored in the original call set-up in

the BSC. If the MSC has prevented the original call attempt queuing, the queuing is also

denied in all handover attempts during the ongoing call.In external handover queuing, the PIE received from the MSC in the HANDOVER

REQUEST message, contains the 'queuing allowed' indicator. This priority element is

then used. If the MSC prevents queuing, the handover attempt cannot be placed in the

queue.

If this queuing is allowed, the BSC checks that the queue is available, that is, that the

actual queue length is not zero, and the queue type is activated in this cell so that the

time limit value of the queue type is not zero. If queuing is not allowed in the cell in

general, or for this kind of attempt only, the call attempt cannot be placed to the queue.

• successful queue set-up

In a call attempt queuing and an external handover attempt queuing in the target

BSC, if there is no TCH of the requested kind available in the cell and the queue set-

up is successful, the BSC sends a QUEUING INDICATION message to the MSC.

• successful queuing

When the queue element receives a TCH, queuing is successful. In that case, the

BSC starts the required signalling procedure concerning the attempt.





DN9835517 25



Id:0900d80580591215

Confidential

• unsuccessful queuing

In all radio channel request cases, if no TCH of the requested kind is available in the

cell and the queue set-up is not successful, the BSC starts the required clearing or

interruption procedure concerning the attempt.

If the queue set-up has been successful, but the queuing time-out takes place, the

BSC sends a normal negative radio resource allocation acknowledgement to the

MSC.

If the queue set-up has been successful, but the queue element has to be removed

from the queue, the BSC sends a normal negative radio resource allocation

acknowledgement to the MSC.

Queue element

Each queued seizure request, that is, queue element, has queue specifications that fully

identify the queue element and the required radio resource. The queue specifications

are:

• original queuing resource indication: BTS, TRX, channel number

• queue type: call attempt, urgent handover attempt, non-urgent handover attempt

(the sorting of handover attempts to urgent and non-urgent handovers is based on

the actual reason of the handover and indicated in the TCH resource request)

• queue element priority: MS priority, queue type priority

In call attempt queuing, the MS priority definition received from the MSC in the

ASSIGNMENT REQUEST message is used.

In an internal handover, the original MS priority definition above is used and stored

in the call set-up in the BSC.

In external handover queuing, the MS priority definition received from the MSC in

the HANDOVER REQUEST message is used.

If the MS priority is undefined in the MSC, the MS priority value has the lowest

priority in queue management.

• required TCH resource (channel type)

In call attempt queuing, the resource definition received from the MSC in the

ASSIGNMENT REQUEST message is used.

In an inter-BSC handover, the original resource definition above is used and stored

in the call set-up in the BSC.

In external handover queuing, the resource definition received from the MSC in the

HANDOVER REQUEST message is used.

• accepted interference levels

In call attempt queuing, the most recently received interference band definition from

the MSC, contained in the ASSIGNMENT REQUEST message, is used. If there areno interference band requirements, all available TCHs are suitable for this queue

element.

In an inter-BSC handover, the original interference band definition above is used

and stored in the call set-up in the BSC.

In external handover queuing, the most recently received interference band defini-

tion from the MSC, contained in the HANDOVER REQUEST message, is used.

• requested TRX type

Indicates whether the queued resource is requested from the extended area or the

normal area. The same queues are used by MSS of the normal area and the

extended area. When a TCH is released in the normal area, it is assigned immedi-

ately to the first MS of a queue which is queuing for resources of the normal area.



26 DN9835517


Id:0900d80580591215

Confidential


When a radio channel is released in the extended area, it is assigned immediately

to the first MS of a queue which is queuing for resources of the extended area.

In call attempt queuing, the type of the requested TRX is always the same as the

TRX type used for signalling.

In intra-cell and inter-cell handover, the TRX type request from the HANDOVER

REQUEST message is used.

In external handover queuing, the queued TRX type is always E-TRX if the target

cell is extended. The queued TRX type is N-TRX if the target cell is normal.

Prioritisation of the request

In queue management, an important part of the queue element is the priority. There are

two queue priority elements:

• MS priority: possibility to prioritise between queue elements

• queue type priority: possibility to prioritise between the queue types

Queue management with different combinations of the priority elements are the follow-ing:

• queue type priority off, MS priority off

In this most straightforward case of queue management, the priority elements are

not taken into account at all. The seizure request is placed on the queue, providing

that there is free space. If the queue is full, the channel allocation is given a negative

acknowledgement.

• MS priority on, queue type priority off

The seizure request, that is, the queue element, is placed on the queue in a position

that the MS priority entitles.

The MS priorities of the queue elements are checked. If the new queue element has

a higher priority than the previous ones, it is placed on the queue so that it is located just before the lower priority element. Other queue elements are transferred one

position towards the end. In this case, the last queue element may have to be

removed from the queue. This is then informed to the requested instance as a

negative acknowledgement to the radio channel seizure request.

When the seizure request is placed on the queue, the timer service corresponding

to the queue type is attached, and the required BSC file updating is performed. After

that the queuing acknowledgement is returned to the requested instance.

• MS priority off, queue type priority on

The new queue element is placed on the queue in the position that the queue type

priority entitles.

The queue type priorities of the queue elements are checked. If the new queue

element has a higher priority than the previous ones, this new element is placed on

the queue just before the lower priority element. Other queue elements are trans-

ferred one position towards the end. In this case, the last queue element may have

to be removed from the queue. This is then informed to the requested instance as a

negative acknowledgement to the radio channel seizure request.


the queue type is attached and the required BSC file updating is performed. After

that, the queuing acknowledgement is returned to the requested instance.



DN9835517 27



Id:0900d80580591215

Confidential

• MS priority on, queue type priority on

In this case, the queue element priority consists of the MS priority and the queue

type priority.

The new queue element is placed on the queue in the position that the queue

element priority entitles.

The MS priority operates only within one single queue type. For example, a higher

MS priority call attempt is placed after a lower MS priority handover attempt, if the

handover queue type priority is set to be higher than the call queue type priority.

In the queue setting analysis, only the MS priorities corresponding to the same

queue type as the requested one are checked, so that the search is not performed

on the whole cell queue. If the new queue element has a higher MS priority than the

previous ones within the same queue type, the new element is placed on the queue

so that it is located just before the lower MS priority element. Other queue elements

within the same queue type are transferred one position towards the end. In this

case, the last queue element may have to be removed from the queue. This is then

informed to the requested instance as a negative acknowledgement to the radiochannel seizure request.


to the queue type is attached and the required BSC file is updated. After that, the

queue setting command is acknowledged to the main channel call control.

Stored information and statistics counters

When a seizure request is stored to the queue, the BSC stores all the information from

the seizure request to the queue file. The time stamp for the queuing start time is also

stored.

The BSC stores the priority order of the queue element cell specifically according to the

queue element priority. The most important part of the stored data deals with the radiochannel identifiers of the requested instance, the requested channel type, the requested

TRX type, the accepted interference level, and the subindex to the queue file.

When the request is stored in the cell queue, the BSC updates the information on the

number of the queue elements in that cell. The number of requests queuing for either

full rate or half rate TCHs or requests capable of both channel rates depending on the

received channel type and rate in the assignment request.

The channel state files are also updated with queuing information. This information

includes the queued BTS identifier and a subindex to the queue file. The information is

important, because, if, for instance, an MS releases a call or if the BSC sends informa-

tion concerning the rejected handover attempt while queuing, the queue element has to

be found and removed from the queue files.

When a request is placed on the queue, statistics counters are updated. All counters are

BTS-specific queue counters. Call set-ups and handovers have their own counters; the

queuing statistics related to the urgent and non-urgent handovers can also be picked

out using the counters. For more information on the counters, see 1 Traffic Measure-

ment under Reference.



28 DN9835517


Id:0900d80580591215

Confidential


Transaction release during queuing

• queuing MS on SDCCH is released

When the queuing radio channel (source) is a stand-alone dedicated control

channel (SDCCH), the queuing data is stored in the BSC's signalling channel statedata structure (SCHSTA) record corresponding to the SDCCH in question.

If the SDCCH is released during the queuing, the queue element is removed from

the queue. If the queuing SDCCH receives a TCH, the queuing data in the SCHSTA

has to be removed. Similarly, if the queuing time runs out or the queue element is

removed from the queue, the queuing data in the SCHSTA is removed.

• queuing MS on TCH is released

When the queuing radio channel (source) is a TCH, the queuing data is stored in the

BSC's traffic channel status data structure (TCHSTA) record corresponding to the

TCH in question.

If this TCH is released during queuing, the queuing element is removed from the

queue files with the queuing data stored in the TCHSTA.

If the queuing TCH receives a new TCH, the queuing data in the TCHSTA has to be

removed. Similarly, if the queuing time runs out or this queue element is removed

from the queue, the queuing data in the TCHSTA is removed.

Queue search

If the BSC detects queued seizure requests in the cell when the TCH is released, the

cell queue is scanned. The last updated interference level information to be used for the

released TCH can be found in the channel state file record.

When TCH radio resources are deblocked and the BSC detects queued seizure

requests in the cell, the cell queue is scanned. The new available TCH interference band

is initialised for the worst interference band until a real interference updating is received.

The cell queue is also scanned when the idle TCH interference levels are changed and

there are queued seizure requests in the cell. This is done because the queued

elements may have just the kind of interference band requirements that the new updated

TCHs can now offer.

The cell queue is scanned in the queue element priority order until a suitable queue

element is found, that is, when the requested channel type and rate, the requested TRX

type, and the interference level information are the same as those of the new TCH avail-

able. If the TCH access is based on the RX level, the queue element's soft carrier-to-

noise ratio (C/N) threshold is checked. If a queue element was C/N blocked during

channel allocation, the channel is not allocated from that queue element but the next

queue element is scanned until a suitable queue element is found. The starting-point of

the search is the top element of the cell queue order records, because the queue is

always organised so that the highest priority element is the first one in the queue.

The queuing time used is examined and after that the queue record is removed.

Because of this queue removal, the information controlling the queuing order has to be

reorganised and updated in the BQUORD.

The queuing data and the possible BTS data in the queued channel state file record are

removed. The number of queuing requests in that cell is updated in the BSTAFI.

After successful queuing, the BSC starts the required signalling procedures concerning

the queued attempt.











DN9835517 29



Id:0900d80580591215

Confidential

Successful queuing is marked to the statistics counters. The queuing time used is

examined by using the actual time stamp and the stored time stamp to see the queuing

start time. Every queue type has its own counters.

Time-out for queued seizure request

When the seizure request is queued, time supervision is started. The queuing time avail-

able depends on the queue type.

If the time supervision expires, and no suitable TCHs have been released, the BSC

receives a time-out message. The queue element is searched, removed and reor-

ganised in the same way as in the radio channel release.

The number of BTS queue elements in the BSTAFI is updated. The queuing data in

radio channel state files (TCHSTA and SCHSTA) is removed. In unsuccessful queuing,

the BSC starts the required clearing or interruption procedures concerning the queued

attempt.

Unsuccessful queuing, as well as the queuing time used, are marked to the statisticscounters. Call set-ups and handovers have their own counters. The urgent and non-

urgent handovers can also be picked out using the counters. If TCH access is based on

the RX level and call set-up request is rejected because of too low an RX level, a specific

statistical counter is used.

Changing cell queue length

If you change the value of the parameter max queue length, the BSC receives a

parameter update from NetAct or the local MMI. You can, for example, set the new

maximum queue length definition to zero, so that queuing is not possible in that cell. The

actual queue length, that is, the maximum queue length proportioned to the number of

possible queuing positions (all created TRXs in the cell), is recalculated after the param-

eter change.

If there are queuing call or handover attempts not located within the new allowed area,

the BSC removes them immediately from the cell queue and negative acknowledge-

ments for the queued channel seizure requests are forwarded to the requested

instances.

Every created TRX builds up to eight/sixteen (full rate TCH / half rate TCH) queue posi-

tions. The maximum queue length in the cell is 32. When a TRX is deleted, the same

number of possible queue positions is removed. The actual queue length is determined

with the value of the max queue length parameter (in percentage format) given by

the user.

After the TRX deletion procedure, it is checked whether there are queuing call orhandover attempts not located within the new allowed area. If this is the case, the BSC

immediately removes them from the cell queue and negative acknowledgements for the

queued channel seizure requests are forwarded to the requested instances.

MCMU switchover during pre-emption and queuing

The marker and cellular management unit (MCMU) is duplicated. The state of the BSC

in the spare unit can be changed to active in any situation without affecting the active

calls. Calls at set-up phase can break.

The pre-emption and queued transactions are set-up phase connections, and, there-

fore, not updated and maintained in the spare unit. If an MCMU switchover occurs during

pre-emption or queuing, there is no real time pre-emption or queuing data available inthe new working unit. This means that the BSC cannot send an acknowledgement con-



30 DN9835517


Id:0900d80580591215

Confidential


cerning the pre-emption attempt or queuing. The process instances that have requested

pre-emption or queuing services are released autonomously when the time supervision

for the acknowledgement from the BSC expires. The pre-emption call attempts and

queued call attempts are then cleared. The pre-emption handover attempts and queued

handover attempts are interrupted, and calls continue on the original radio channels.



DN9835517 31


System impact of Radio Resource Pre-emption andQueuing

Id:0900d80580853ed3

Confidential

4 System impact of Radio Resource Pre-

emption and Queuing

The system impact of Radio Resource Pre-emption and Queuing is specified in thesections below. Radio Resource Pre-emption and Queuing includes features

BSS02302: Queuing, BSS03910: Queuing and Priority, and BSS20869: Market Expan-

sion Toolkit.

Queuing does not require a license. Queuing and Priority is a product that does not

require a license. Market Expansion Toolkit is a product and requires a valid licence in

the BSC.

4.1 Requirements

Hardware requirements

No requirements

Software requirements

Frequency band support

The BSC supports Radio Resource Pre-emption and Queuing on the following fre-

quency bands:

• GSM 800

• GSM 900

• GSM 1800

• GSM 1900

4.2 Impact on transmission

No impact.

Network element Software release required

BSC Market Expansion Toolkit requires S13 or later.

BTSplus BTS No requirements

Flexi Multiradio BTS No requirements

Flexi EDGE BTS No requirements

UltraSite EDGE BTS No requirements

MetroSite EDGE BTS No requirements

Talk-family BTS No requirements

MSC/HLR Pre-emption and Market Expansion Toolkit require

the Enhanced Multi-Level Precedence and Pre-

emption (eMLPP) service

SGSN No requirements

NetAct OSS4.2 CD Set 1

Table 2 Required software



32 DN9835517


Id:0900d80580853ed3

Confidential


4.3 Impact on BSS performance

OMU signalling

No impact.

TRX signalling

No impact.

Impact on BSC units

No impact.

Impact on BTS units

No impact.

4.4 User interfaceBSC MMI

The following MML command groups and commands are used to handle Radio

Resource Pre-emption and Queuing:

• Base Station Controller Parameter Handling in BSC: EEO, EEQ

• Base Transceiver Station Handling in BSC: EQH

• GSM Measurement Handling: TPE, TPI, TPM, TPS

• Parameter Handling: WOC, WOI

• Licence and Feature Handling: W7M, W7I

For more information on the command groups and MML commands, see MML

commands under Reference.

BTS MMI

Radio Resource Pre-emption and Queuing cannot be managed with BTS MMI.

BSC parameters

Pre-emption

The BSC-specific parameter pre-emption usage in handover defines whether

the pre-emption procedures (forced release and forced handover) are applied in the

case of a handover attempt. The parameter is handled with the EEQ command.

Queuing

The queue characteristics are defined with SEG object class parameters. The parame-

ters are handled with the EQH command.

The following parameters are related to queuing:

• max queue length

The maximum queue length in the cell specifies the number of call attempts and

handover attempts waiting for a traffic channel (TCH) release in the cell. If the value

is set to zero, TCH queuing is not possible in that cell.

• time limit call

The maximum queuing time for call attempts (mobile-originating or mobile-terminat-

ing) in the cell. If the value is set to zero, call attempt queuing is not active in that cell.





























DN9835517 33



Id:0900d80580853ed3

Confidential

• time limit handover

The maximum queuing time for handover attempts (all handover types and

handover reasons) in the cell. If the value is set to zero, handover attempt queuing

is not active in that cell.

• queueing priority call

The specified priority for the call queue type in the cell. Queue type prioritisation

enables different priorities between call attempt and handover attempt queuing.

• queueing priority urgent handover

• queueing priority non-urgent handover

The specified priority for the urgent and non-urgent handover queue type in the cell.

Queue type prioritisation enables different priorities between call attempt and

handover attempt queuing and between non-urgent and urgent handovers queuing.

• MS priority used

Indicates whether the priority data for the message element priority in the

ASSIGNMENT REQUEST and HANDOVER REQUEST messages from the MSC is

taken into account in the queue management of the cell.

• queue priority used

Indicates whether the queue type priority is taken into account in queue manage-

ment in the cell.

For more information on the parameters, see BSS Radio Network Parameter Dictionary

under Reference.

Market Expansion Toolkit

The forced release priority threshold parameter specifies the priority levels

of the subscribers to which Forced release after an unsuccessful forced handover

attempt is applied. The parameter is handled with the EEQ command.

The following licence is related to the Market Expansion Toolkit:

• Market Expansion Toolkit W71

The following MML commands are used for licence and feature handling:

• W7M

• W7I

For activating the Market Expanion Toolkit, see Activating and Testing BSC3910: Pre-

emption and BSS20869: Market Expansion Toolkit under Activate. For more information

on the licences, see Licence Management in BSC under Install.

PRFILE parameters

The following PRFILE parameters are related to Radio Resource Pre-emption:

• PREEMPT_USAGE

• PREEMPT_USAGE_IN_BSC

Pre-emption is activated in the BSC with the PREEMPT_USAGE parameter using the local

MMI. The SEG-specific queue parameters do not have any influence on pre-emption.

For more information on PRFILE parameters, see PRFILE and FIFILE Parameter List

under Reference.

Alarms

No alarms are specifically related to Radio Resource Pre-emption and Queuing.









34 DN9835517


Id:0900d80580853ed3

Confidential


Measurements and counters

The following measurement and counters are related to Radio Resource Pre-emption

and Queuing.

1 Traffic Measurement

Name Number

FORCED RELEASES 001070

FORCED HANDOVERS 001071

Table 3 Counters of Traffic Measurement related to Radio Resource Pre-emption

Name Number

CALL ATTEMPTS IN THE QUEUE 001016

HANDOVER ATTEMPTS IN THE QUEUE 001017

AVE QUEUE LENGTH FOR CHANNEL SEIZURE REQUEST 001018

QUEUE DENOMINATOR 1 001019

AVE QUEUE TIME OF CALL ATTEMPTS 001020


AVE QUEUE TIME OF HO ATTEMPTS 001022


NOT SERVED QUEUED CALL ATTEMPTS 001024

NOT SERVED QUEUED HO ATTEMPTS 001025

QUE ALL ASSIGN REQ ATT 001056

QUE NALL ASSIGN REQ ATT 001057

QUE ALL ASSIGN REQ FAIL 001060

QUE NALL ASSIGN REQ FAIL 001061

QUE ALL HO REQ ATT 001064

QUE NALL HO REQ ATT 001065

QUE ALL HO REQ FAIL 001068

QUE NALL HO REQ FAIL 001069

QUEUED URGENT HANDOVER ATTEMPTS 001142

AVE QUE TIME OF URGENT HO ATTEMPTS 001143

QUE DENOMINATOR 4 001144

AVE QUE TIME OF NON URGENT HO ATTEMPTS 001145

QUE DENOMINATOR 5 001146

QUEUED URG HO ATTS NOT SERVED 001147

Table 4 Counters of Traffic Measurement related to Queuing



DN9835517 35



Id:0900d80580853ed3

Confidential

For more information on the counters, see 1 Traffic Measurement under Reference.

4.5 Impact on Network Switching Subsystem (NSS)

Pre-emption in the BSC is based on priority levels specified in the MSC/HLR. The

Enhanced Multi-Level Precedence and Pre-emption (eMLPP) service allows you to

define different priority levels for calls on the basis of a set of analysed attributes.

4.6 Impact on NetAct products

NetAct Administrator

No impact.

NetAct Monitor

No impact.

NetAct Optimizer

No impact.

NetAct Planner

No impact.

NetAct Configurator NetAct Configurator can be used to configure the radio network parameters related to

Radio Resource Pre-emption and Queuing. For more information, see BSS RNW

Parameters and Implementing Parameter Plans in NetAct Product Documentation. For

a list of the radio network parameters, see BSC parameters.

NetAct Reporter

NetAct reporter can be used to create reports from measurements related to Radio

Resource Pre-emption and Queuing. For a list of the measurements, see Measure-

ments and counters.

NetAct Tracing

No impact.

Name Number

FORCED RELEASE AFTER FORCED HO 001235

CLASS 2 SUBSCRIBER FORCED RELEASE 001236

TCH REQUESTS FOR CALL ATTEMPT CLASS 1 001237

SUCCESSFUL TCH SEIZURES FOR CALL ATTEMPT CLASS 1 001238





Table 5 Counters of Traffic Measurement related to Market Expansion Toolkit



36 DN9835517


Id:0900d80580853ed3

Confidential


4.7 Impact on mobile stations

No impact.

4.8 Impact on interfaces

Impact on radio interface

No impact.

Impact on Abis interface

No impact.

Impact on A interface

Radio Resource Pre-emption and Queuing modifies the following messages:

•CLEAR REQUEST

• QUEUING INDICATION

Impact on Gb interface

No impact.

4.9 Interworking with other features

Directed Retry

If Directed Retry is used simultaneously with queuing, the value of the min time

limit directed retry parameter has to be smaller than the value of the time

limit call parameter.For more information on Directed Retry, see Directed Retry in BSC under Feature

Descriptions.

Trunk Reservation

Pre-emption is applied to those pre-emption capable subscribers that have been

rejected by the trunk reservation algorithm.

By combining Pre-emption and Trunk Reservation, it is possible to define different

service grades to the network.

For more information on the service grades, see Trunk Reservation under Feature

Descriptions.

Soft Channel Capacity

If traffic channel allocation is not possible in a cell because of BSC signalling unit

(BCSU) capacity, pre-emption is applied normally.

For more information on Soft Channel Capacity, see Soft Channel Capacity under

Feature Descriptions.

RXLev Min Access

During TCH allocation, the BSC checks the RX level of the accessing MS. If the RX level

is not high enough, the TCH is not allocated and queuing and pre-emption procedures

are not applied.



DN9835517 37



Id:0900d80580853ed3

Confidential

For more information on RXLev Min Access, see Radio Channel Allocation under Func-

tional Area Descriptions.

Dynamic Frequency and Channel Allocation

Pre-emption is supported on DFCA TRX when feature state of SDCCH and PS Data

Channels on DFCA TRX licence is ON and pre-emption functionality is enabled. Pre-

emption is started using the existing rules except for proper candidate that can be

searched from regular and DFCA TRX.

When the DFCA algorithm prevents the use of DFCA channels because of soft blocking,

only the regular resources can be queued for.

For more information on DFCA, see Dynamic Frequency and Channel Allocation under

Feature Descriptions.

High Speed Circuit Switched Data

Call setup or handover attempts in the queue are preferred to upgrade pending High

Speed Circuit Switched Data (HSCSD) connections in channel allocation algorithm.

Transparent HSCSD connections cannot enter a cell through queueing or pre-emption.

The pre-emption handover is not applied to transparent HSCSD connections.

For more information on HSCSD, see HSCSD and 14.4 kbit/s Data Services in BSC

under Feature Descriptions.

Wireless Priority Service

Radio resource queuing must be in use in the BSC for Wireless Priority Service (WPS)

to operate.

WPS and pre-emption cannot co-exist in the same network. If WPS is used in the

network, pre-emption cannot be used.

For more information on WPS, see Wireless Priority Service in BSC under Feature

Descriptions.

GPRS/EDGE

If the circuit-switched (CS) territory of a cell is congested and additional or default

GPRS/EDGE timeslots are available, robbery allocation is done. Pre-emption is applied

only if robbery allocation is not possible.

For more information on GPRS/EDGE, see BSS10091: EDGE System Feature Descrip-

tion under Feature Descriptions.

Better cell handoversThe pre-emption procedures are not applied to better cell handovers. If a pre-emption

capable subscriber attempts a better cell handover to a congested cell, the pre-emption

procedures are not applied, and the subscriber remains in the source cell.

For more information on better cell handovers, see Call Related DX Causes in BSC

under Reference.

Inter System Handover Acceleration via IUR-G

Queuing is not allowed by BSC when the TCH is requested for Enhanced Relocation

Resource Request.

For more information on Inter System Handover Acceleration via IUR-G, see

BSS21528: ISHO acceleration via Iur-g under Feature Descriptions.



38 DN9835517


Id:0900d80580853ed3

Confidential


Energy optimized TCH allocation

DL RX level measurement for TCH allocation is not considered for a call in queue.

Hence, the allocated radio resource can be either on the BCCH TRX or a non-BCCH

TRX.For more information on Energy optimized TCH allocation, see BSS21222: Energy opti-

mized TCH allocation

Orthogonal subchannel with SAIC MS

Forced handover as well as forced release because of pre-emption is prevented for the

calls where OSC multiplexing handover is ongoing.

For more information on Orthogonal subchannel with SAIC MS, see BSS21309: OSC

Half Rate with SAIC MS and BSS21534: OSC Full Rate with SAIC MS.

http://fd21222.pdf/

http://fd21222.pdf/

http://fd21309.pdf/

http://fd21309.pdf/

http://fd21534.pdf/

http://fd21534.pdf/

http://fd21309.pdf/

http://fd21309.pdf/

http://fd21222.pdf/

http://fd21222.pdf/




Implementing Radio Resource Pre-emption and Queu-ing overview

5 Implementing Radio Resource Pre-emption

and Queuing overview

Steps

Define subscriber priority levels on the MSC.

For more information and detailed instructions, see Enhanced Multi-Level Precedence

and Pre-emption (eMLPP) service inSupplementary Services for Mobile Subscriber and

MI - Home Subscriber Identification Handling in Nokia MSC/HLR Product Documenta-

tion.

You also need to check that support for Enhanced Multi-Level Precedence and Pre-

emption (eMLPP) capable MSS is enabled. For more information, see parameter

EMLPP_CONFIG description in PRFILE Description in M13 in Nokia MSC/HLR Product

Documentation.

2 Activate Pre-emption on the BSC.

For detailed instructions, see Activating and Testing BSC3910: Pre-emption and

BSS20869: Market Expansion Toolkit under Activate.

3 Activate Market Expansion Toolkit on the BSC.

For detailed instructions, see Activating and Testing BSC3910: Pre-emption and

BSS20869: Market Expansion Toolkit under Activate.

Documents

Pre-Emption and Queing