NSN Queuing Detailed Document

Nokia Siemens Networks GSM/EDGE BSS, rel. RG10(BSS), operating documentation, issue 05

Feature description

BSC3910 and BSS20869: Radio Resource Pre-emption and Queuing

DN9835517

Issue 12-2Approval Date 2010-04-12

2 DN9835517Issue 12-2

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

Id:0900d8058072b01e

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 which the 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 respective owners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2010. All rights reserved

f Important Notice on Product Safety Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures.

Non-observance of these conditions and the safety instructions can result in personal injury or in property damage.

Therefore, only trained and qualified personnel may install and maintain the system.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.

Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-zungen und Sachschäden führen.

Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.

DN9835517Issue 12-2

3


Id:0900d8058072b01e

Table of ContentsThis document has 38 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 Overview of Radio Resource Pre-emption and Queuing . . . . . . . . . . . . . 9

2 Technical description of Radio Resource Pre-emption and Queuing . . 122.1 Queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Pre-emption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Market Expansion Toolkit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Functionality of Radio Resource Pre-emption and Queuing . . . . . . . . . 193.1 Pre-emption management in the BSC . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Queue management in the BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Forced release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4 Forced handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5 Queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 System impact of Radio Resource Pre-emption and Queuing . . . . . . . 314.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Impact on transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.3 Impact on BSS performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5 Impact on Network Switching Subsystem (NSS) . . . . . . . . . . . . . . . . . . 354.6 Impact on NetAct products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.7 Impact on mobile stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.8 Impact on interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.9 Interworking with other features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Implementing Radio Resource Pre-emption and Queuing overview . . . 38

4 DN9835517Issue 12-2


Id:0900d8058072b01e

List of FiguresFigure 1 Forced release after an unsuccessful forced handover attempt . . . . . . . 16Figure 2 Time stamp comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figure 3 Soft call drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

DN9835517Issue 12-2

5


Id:0900d8058072b01e

List of TablesTable 1 Example of subscriber classification . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Table 2 Required software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Table 3 Counters of Traffic Measurement related to Radio Resource Pre-emption

34Table 4 Counters of Traffic Measurement related to Queuing . . . . . . . . . . . . . . 34Table 5 Counters of Traffic Measurement related to Market Expansion Toolkit 35

6 DN9835517Issue 12-2


Id:0900d8058072b01e

DN9835517Issue 12-2

7


Summary of changes

Id:0900d8058072ac01

Summary of changesChanges between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues.

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

Changes made between issues 12-1 and 12-0Information on InSite BTS has been removed.

Changes made between issues 12-0 and 11-0Information 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.

Changes made between issues 11-0 and 10-2

Overview of Radio Resource Pre-emption and QueuingInformation 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 QueuingInformation of chapter Radio Resource Pre-emption and Queuing in Radio Resource Pre-emption and Queuing System Feature Description has been combined into this chapter.

Functionality of Radio Resource Pre-emption and QueuingInformation 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 QueuingThis chapter has been added. Chapter User interface of Radio Resource Pre-emption and Queuing has been combined into this chapter.

Implementing of Radio Resource Pre-emption and QueuingThis 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 added to 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.

8 DN9835517Issue 12-2


Id:0900d8058072ac01

Summary of changes

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.

Changes made between issues 10-2 and 10-1Priority 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.

DN9835517Issue 12-2

9


Overview of Radio Resource Pre-emption and Queuing

Id:0900d8058059120f

1 Overview of Radio Resource Pre-emption and QueuingRadio Resource Pre-emption and Queuing makes it possible to provide a specific level of 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-emptionThe 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.

QueuingThe 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 ToolkitMarket Expansion Toolkit is an enhancement to Pre-emption that allows you to divide subscribers into classes more effectively. It consists of the following enhancements:

10 DN9835517Issue 12-2


Id:0900d8058059120f


• Forced release after an unsuccessful forced handover attemptForced 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 classificationPre-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 statisticsTraffic 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 durationFair 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 BSCSoft 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 QueuingRadio 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

DN9835517Issue 12-2

11



Id:0900d8058059120f

• 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

12 DN9835517Issue 12-2


Id:0900d80580591212

Technical description of Radio Resource Pre-emption and Queuing

2 Technical description of Radio Resource Pre-emption and Queuing

2.1 QueuingThe BSC has a cell-specific queue for every queue type. Three different queue types are implemented:

• call queueUsed when mobile-originating call (MOC) or mobile-terminating call (MTC) attempts are queued for.

• handover queue for urgent handoversUsed 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 the A interface circuit pool • handover of a fast-moving MS from the lower layer cell to upper layer cellFor 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 handoversUsed 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

DN9835517Issue 12-2

13


Technical description of Radio Resource Pre-emptionand Queuing

Id:0900d80580591212

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 elementsThe queue type priority and MSC informed priority can be set on or off.

Queuing possibilityThe target cell used for queuing can vary depending on the request type. One queuing target 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-emptionPre-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 is chosen (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 requestThe 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 DN9835517Issue 12-2


Id:0900d80580591212


• 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=0Does not initiate the pre-emption procedure because the priority level 0 is specified as spare.

• PCI=YES, QA=YES, PRIO=1The highest possible priority. Initiates forced release for a vulnerability call in prog-ress.

• PCI=YES, QA=YES, PRIO=2...PRIO=14Initiates forced handover for a vulnerability call in progress.

• PVI=YES, QA=no relevance, PRIO=0Not 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=14The 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 releaseForced 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 fixed parameter (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'.

DN9835517Issue 12-2

15



Id:0900d80580591212

Forced handoverForced 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 seizure requests 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 ToolkitMarket Expansion Toolkit introduces five enhancements to Pre-emption.

Of these five, the following are enabled automatically when the Market Expansion Toolkit 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 DN9835517Issue 12-2


Id:0900d80580591212


Forced release after an unsuccessful forced handover attemptForced 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 classificationThe 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 the three 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.

DN9835517Issue 12-2

17



Id:0900d80580591212

Subscriber class specific statisticsThe 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 durationIn 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 BSCIn 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) or forced 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 1time stamp12:28:24




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

The duration of the call = NOW - timestamp

18 DN9835517Issue 12-2


Id:0900d80580591212


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 in

the 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)

DN9835517Issue 12-2

19


Functionality of Radio Resource Pre-emption andQueuing

Id:0900d80580591215

3 Functionality of Radio Resource Pre-emption and Queuing

3.1 Pre-emption management in the BSCYou can deny the use of pre-emption in the case of a handover attempt with the BSC-specific parameter pre-emption usage in handover.

The BSC checks the Priority information element (PIE) and, on the basis of PIE's flags, it may initiate a forced release or forced handover. If the Market Expansion Toolkit is not in use, only one of these two is allowed for one subscriber. In other words, without the Market Expansion Toolkit, it is not possible to try a forced handover first and then initiate a forced release, if the forced handover is unsuccessful.

If the forced handover is unsuccessful, a new forced handover attempt is initiated if the time supervision has not expired and there is a suitable vulnerability candidate to be handed over. The MSC must support queuing for the pre-emption to work.

Market Expansion Toolkit also allows a forced released after an unsuccessful forced handover attempt.

3.2 Queue management in the BSCQueuing is used when the BSC receives an assignment or a handover request from the MSC, and all traffic channels are busy or there are no traffic channels (TCHs) of the requested kind available. If this seizure request is not allowed to pre-empt an existing connection, the BSC checks the Priority information element (PIE) and, on the basis of the 'queuing allowed' indicator, can initiate queuing.

Use of the priority element in queuingIn queue handling, one of the most important pieces of information concerning the queued seizure request is the priority of the queue element. This queue element priority consists of the mobile station (MS) priority (ms priority used) and the queue type priority (queue priority used).

The SEIZURE REQUEST messages to the BSC contain the MS priority information, which is the priority value determined by the MSC. The queue type priority is a SEG queue parameter that also affects the queuing algorithm function considerably. In general, the handover queue type is set to have a higher priority than the call queue type, because handovers deal with existing call connections.

Cell queue lengthEvery created transceiver (TRX) builds up to eight possible queue positions in the cell. If the TRX contains half rate resources, the queue length is doubled. The maximum queue length in a cell is 32. Every deleted TRX removes eight/sixteen possible queue positions.

The actual queue length is calculated by using the number of the possible queuing posi-tions (all created TRXs in the cell) and the SEG parameter maximum queue length given in percentage format. Recalculation is performed when you change the value of the maximum queue length parameter or when the number of the active TRXs changes (TRXs are created or deleted).

20 DN9835517Issue 12-2


Id:0900d80580591215

Functionality of Radio Resource Pre-emption and Queuing

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 the maximum 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 releaseForced release possibility checksWhen 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 releaseAfter 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

DN9835517Issue 12-2

21



Id:0900d80580591215

• 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 releaseThe successful assignment or handover is reported to the BSC, including the informa-tion concerning the radio resource allocated to it. After that, the BSC starts the required signalling procedures concerning the assignment or handover attempt.

Unsuccessful forced releaseWhen 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 releaseWhen 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 rejected because 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 handoverForced handover possibility checksWhen 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

22 DN9835517Issue 12-2


Id:0900d80580591215


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

In an external handover, the priority element received from the MSC in the HANDOVER REQUEST message is used.

Selection of candidate for forced handoverAfter the BSC has stored the information of the seizure request to the BTS forced handover file (BFHFIL), it selects the candidate for forced handover. 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. The following two cases are then 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 RTSLThe following rules apply in the selection of the candidate for forced handover:

• the MS of the lowest possible priority is allocated • only one forced handover is permitted

In some circumstances, a forced handover can be performed within the cell that main-tains the candidate call - which can be thought of as a kind of call packing feature gen-erated by pre-emption:

• a full rate call can be handed over from a dual rate RTSL to a free permanent full rate RTSL

• a half rate call can be handed over from a half occupied dual rate RTSL to a free permanent half rate RTSL

• a half rate call can be handed over from a half occupied dual rate RTSL to another half occupied dual rate RTSL

• if channel rate changes are allowed, a full rate call can be handed over to a free half rate resourceConsequently, a half rate call can be handed over to a free permanent full rate resource. In these cases, the handovers are performed externally and controlled by the MSC if the A interface circuit pool does not support the channel rate changes. Note that the full rate call must have half rate capabilities before it can be moved to a half rate traffic channel.

When the BSC has found the best suitable candidate for a handover, a decision on whether the handover is going to be performed intra-cell or not is made. The BSC starts the required signalling procedures concerning forced handover.

If the handover attempt is rejected, the BSC checks if the seizure request is still waiting for a free resource in the BFHFIL. If the seizure request is in the BFHFIL, the BSC selects another candidate for a forced handover. If the seizure request is not in the BFHFIL, the forced handover procedure ends.

Successful forced handoverThe BSC starts the required signalling procedures concerning the assignment or handover attempt. The new call receives the related TCH.

DN9835517Issue 12-2

23



Id:0900d80580591215

Unsuccessful forced handoverWhen 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 from the 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 handoverWhen 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 attemptThe 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 releaseIf 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 DN9835517Issue 12-2


Id:0900d80580591215


• Statistics counters for a forced releaseA 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 QueuingQueuing possibility checksWhen 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-upIn 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 queuingWhen the queue element receives a TCH, queuing is successful. In that case, the BSC starts the required signalling procedure concerning the attempt.

DN9835517Issue 12-2

25



Id:0900d80580591215

• unsuccessful queuingIn 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 elementEach 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 priorityIn 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 levelsIn call attempt queuing, the most recently received interference band definition from the MSC, contained in the ASSIGNMENT REQUEST message, is used. If there are no 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 typeIndicates 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 DN9835517Issue 12-2


Id:0900d80580591215


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 requestIn 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 offIn 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 offThe 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 onThe 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.When the seizure request is placed on the queue, the timer service corresponding the queue type is attached and the required BSC file updating is performed. After that, the queuing acknowledgement is returned to the requested instance.

DN9835517Issue 12-2

27



Id:0900d80580591215

• MS priority on, queue type priority onIn 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 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 is updated. After that, the queue setting command is acknowledged to the main channel call control.

Stored information and statistics countersWhen 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 radio channel 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 DN9835517Issue 12-2


Id:0900d80580591215


Transaction release during queuing

• queuing MS on SDCCH is releasedWhen the queuing radio channel (source) is a stand-alone dedicated control channel (SDCCH), the queuing data is stored in the BSC's signalling channel state data 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 releasedWhen 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 searchIf 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.

DN9835517Issue 12-2

29



Id:0900d80580591215

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 requestWhen 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 statistics counters. 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 lengthIf 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 or handover 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 queuingThe 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 in the new working unit. This means that the BSC cannot send an acknowledgement con-

30 DN9835517Issue 12-2


Id:0900d80580591215


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.

DN9835517Issue 12-2

31


System impact of Radio Resource Pre-emption andQueuing

Id:0900d8058072ac4c

4 System impact of Radio Resource Pre-emption and QueuingThe system impact of Radio Resource Pre-emption and Queuing is specified in the sections 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 RequirementsHardware requirementsNo requirements

Software requirements

Frequency band supportThe 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 transmissionNo impact.

Network element Software release required

BSC Market Expansion Toolkit requires S13

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 DN9835517Issue 12-2


Id:0900d8058072ac4c

System impact of Radio Resource Pre-emption and Queuing

4.3 Impact on BSS performanceOMU signallingNo impact.

TRX signallingNo impact.

Impact on BSC unitsNo impact.

Impact on BTS unitsNo impact.

4.4 User interfaceBSC MMIThe 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 MMIRadio Resource Pre-emption and Queuing cannot be managed with BTS MMI.

BSC parametersPre-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 lengthThe 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 callThe 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.

DN9835517Issue 12-2

33



Id:0900d8058072ac4c

• time limit handoverThe 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 callThe 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 handoverThe 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 usedIndicates 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 usedIndicates 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 parametersThe 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.

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

34 DN9835517Issue 12-2


Id:0900d8058072ac4c


Measurements and countersThe 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

DN9835517Issue 12-2

35



Id:0900d8058072ac4c

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 productsNetAct AdministratorNo impact.

NetAct MonitorNo impact.

NetAct OptimizerNo impact.

NetAct PlannerNo impact.

NetAct ConfiguratorNetAct 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 ReporterNetAct 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 TracingNo 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 DN9835517Issue 12-2


Id:0900d8058072ac4c


4.7 Impact on mobile stationsNo impact.

4.8 Impact on interfacesImpact on radio interfaceNo impact.

Impact on Abis interfaceNo impact.

Impact on A interfaceRadio Resource Pre-emption and Queuing modifies the following messages:

• CLEAR REQUEST

• QUEUING INDICATION

Impact on Gb interfaceNo impact.

4.9 Interworking with other featuresDirected RetryIf 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 ReservationPre-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 CapacityIf 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 AccessDuring 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.

DN9835517Issue 12-2

37



Id:0900d8058072ac4c

For more information on RXLev Min Access, see Radio Channel Allocation under Func-tional Area Descriptions.

Dynamic Frequency and Channel AllocationPre-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 DataCall 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 ServiceRadio 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/EDGEIf 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-GQueuing 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 DN9835517Issue 12-2


Id:0900d8058059121b

Implementing Radio Resource Pre-emption and Queu-ing overview

5 Implementing Radio Resource Pre-emption and Queuing overviewSteps

1 Define subscriber priority levels on the MSC.For more information and detailed instructions, see Enhanced Multi-Level Precedence and Pre-emption (eMLPP) service in Supplementary 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.

Date post:	29-Oct-2015
Category:	Documents
Upload:	azam-khan
View:	171 times
Download:	2 times

NSN Queuing Detailed Document

Documents