Gsm/Edge Bss, Rel. RG30(BSS), Operating Documentation, Issue 04

GSM/EDGE BSS, Rel.
RG30(BSS), Operating
Documentation, Issue 04
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.
BSC3910 and BSS20869: Radio Resource Pre-emp-
tion and Queuing
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 2011. All rights reserved
f Important Notice on Product Safety

This 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 Produktsicherheit

Von 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.
2 Id:0900d8058084fd6b DN9835517
Confidential
tion and Queuing
Table of contents
This document has 39 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 . . 12

2.1 Queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Pre-emption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Market Expansion Toolkit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Functionality of Radio Resource Pre-emption and Queuing . . . . . . . . . 19

3.1 Pre-emption management in the BSC . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Queue management in the BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Forced release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Forced handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5 Queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 System impact of Radio Resource Pre-emption and Queuing . . . . . . . 31

4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Impact on transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Impact on BSS performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Impact on Network Switching Subsystem (NSS) . . . . . . . . . . . . . . . . . . 35
4.6 Impact on NetAct products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7 Impact on mobile stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.8 Impact on interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.9 Interworking with other features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5 Implementing Radio Resource Pre-emption and Queuing overview . . . 39
DN9835517 Id:0900d8058084fd6b 3
Confidential
tion and Queuing
List of figures
Figure 1 Forced release after an unsuccessful forced handover attempt . . . . . . . 16
Figure 2 Time stamp comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 3 Soft call drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Id:0900d8058084fd6b DN9835517
Confidential
tion and Queuing
List of tables
Table 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
DN9835517 Id:0900d8058084fd6b 5
Confidential
tion and Queuing
6 Id:0900d8058084fd6b DN9835517
Confidential
BSC3910 and BSS20869: Radio Resource Pre-emp- Summary of changes
tion and Queuing
Summary of changes
Changes 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.

Information 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 this
chapter.
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.
DN9835517 Id:0900d8058085e7ff 7
Confidential
Summary of changes BSC3910 and BSS20869: Radio Resource Pre-emp-
tion and Queuing
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 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.
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.
8 Id:0900d8058085e7ff DN9835517
Confidential
BSC3910 and BSS20869: Radio Resource Pre-emp- Overview of Radio Resource Pre-emption and Queuing
tion and Queuing
1 Overview of Radio Resource Pre-emption

and Queuing
Radio 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-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:
DN9835517 Id:0900d8058059120f 9
Confidential
Overview of Radio Resource Pre-emption and Queuing BSC3910 and BSS20869: Radio Resource Pre-emp-
tion and Queuing
• 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
10 Id:0900d8058059120f DN9835517
Confidential
BSC3910 and BSS20869: Radio Resource Pre-emp- Overview of Radio Resource Pre-emption and Queuing
tion and Queuing
• 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
DN9835517 Id:0900d8058059120f 11
Confidential
Technical description of Radio Resource Pre-emption BSC3910 and BSS20869: Radio Resource Pre-emp-
and Queuing tion and 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 the A 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
12 Id:0900d80580591212 DN9835517
Confidential
BSC3910 and BSS20869: Radio Resource Pre-emp- Technical description of Radio Resource Pre-emption
tion and Queuing and Queuing
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 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-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 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 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)
DN9835517 Id:0900d80580591212 13
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 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'.
14 Id:0900d80580591212 DN9835517
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 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 Toolkit

Market 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
DN9835517 Id:0900d80580591212 15
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.
A TCH is needed
for a high priority
user.
The cell is
congested.
Select the pre-

emption candidate.
The low priority

user is moved to
another cell. Allocate the TCH
Start forced for the high
handover. priority user.
The neighbour cells

are congested.
Start forced release

The low priority
for the selected
user is released.
candidate.
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 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 PCI QA PVI Function

level
1 1 Y Y N Forced release
Table 1 Example of subscriber classification
16 Id:0900d80580591212 DN9835517
Confidential
Class Priority PCI QA PVI Function

level
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
Table 1 Example of subscriber classification (Cont.)
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.
time stamp The duration of the call = NOW - timestamp

Call 1
12:28:24
time stamp
Call 2
12:30:45
time stamp The TCH containing the longest

Call 3
12:27:27 lasting call is selected for pre-emption.
time stamp
Call 4
12:31:05
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.
DN9835517 Id:0900d80580591212 17
Confidential
MS BSC MSC
ASSIGNMENT REQUEST (MS 2)
The BSC starts pre-emption for MS 1.
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 time

to finish the call.
The MSC releases the call (MS 1).
CLEAR COMMAND (MS 1)
The BSC clears the call (MS 1) and gives the

released channel to MS 2.
CLEAR COMPLETE (MS 1)
ASSIGNMENT COMPLETE (MS 2)
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).
18 Id:0900d80580591212 DN9835517
Confidential
BSC3910 and BSS20869: Radio Resource Pre-emp- Functionality of Radio Resource Pre-emption and
tion and Queuing Queuing
3 Functionality of Radio Resource Pre-emption

and Queuing
3.1 Pre-emption management in the BSC

You 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 BSC

Queuing 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 queuing

In 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 length

Every 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).
DN9835517 Id:0900d80580591215 19
Confidential
Functionality of Radio Resource Pre-emption and BSC3910 and BSS20869: Radio Resource Pre-emp-
Queuing tion 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 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
20 Id:0900d80580591215 DN9835517
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 it. 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 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 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 Id:0900d80580591215 21
Confidential
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 handover

After 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 RTSL
The 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 resource
Consequently, 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 handover

The BSC starts the required signalling procedures concerning the assignment or
handover attempt. The new call receives the related TCH.
22 Id:0900d80580591215 DN9835517
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 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 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 release
The 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.
DN9835517 Id:0900d80580591215 23
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.
24 Id:0900d80580591215 DN9835517
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 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 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.
DN9835517 Id:0900d80580591215 25
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.
26 Id:0900d80580591215 DN9835517
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 radio
channel 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 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.
DN9835517 Id:0900d80580591215 27
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 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 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.
28 Id:0900d80580591215 DN9835517
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 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 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 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 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 in
the new working unit. This means that the BSC cannot send an acknowledgement con-
DN9835517 Id:0900d80580591215 29
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.
30 Id:0900d80580591215 DN9835517
Confidential
BSC3910 and BSS20869: Radio Resource Pre-emp- System impact of Radio Resource Pre-emption and
4 System impact of Radio Resource Pre-

emption and Queuing
The 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 Requirements
Hardware requirements
No requirements
Software requirements
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
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.
DN9835517 Id:0900d80580853ed3 31
Confidential
System impact of Radio Resource Pre-emption and BSC3910 and BSS20869: Radio Resource Pre-emp-
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 interface

BSC 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.
32 Id:0900d80580853ed3 DN9835517
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.
DN9835517 Id:0900d80580853ed3 33
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
34 Id:0900d80580853ed3 DN9835517
Confidential
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
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.
DN9835517 Id:0900d80580853ed3 35
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.
36 Id:0900d80580853ed3 DN9835517
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 handovers

The 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.
DN9835517 Id:0900d80580853ed3 37
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.
38 Id:0900d80580853ed3 DN9835517
Confidential
BSC3910 and BSS20869: Radio Resource Pre-emp- Implementing Radio Resource Pre-emption and Queu-
tion and Queuing ing overview
5 Implementing Radio Resource Pre-emption

and Queuing overview
Steps
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.
DN9835517 Id:0900d8058059121b 39
Confidential

Язык

Добро пожаловать в Scribd!

Gsm/Edge Bss, Rel. RG30(BSS), Operating Documentation, Issue 04

Загружено:

Сведения о документе

Описание:

Дата загрузки

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Описание:

Авторское право:

Доступные форматы

Gsm/Edge Bss, Rel. RG30(BSS), Operating Documentation, Issue 04

Оригинальное название:

Загружено:

Описание:

Авторское право:

Доступные форматы

Похожие издания

GSM/EDGE BSS, Rel.

BSC3910 and BSS20869: Radio Resource

f Important Notice on Product Safety

The same text in German:

f Wichtiger Hinweis zur Produktsicherheit

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

2 Technical description of Radio Resource Pre-emption and Queuing . . 12

3 Functionality of Radio Resource Pre-emption and Queuing . . . . . . . . . 19

4 System impact of Radio Resource Pre-emption and Queuing . . . . . . . 31

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

Changes made between issues 13-1 and 13-0

Changes made between issues 13-0 and 12-2

Changes made between issues 12-2 and 12-1

Changes made between issues 12-1 and 12-0

Changes made between issues 12-0 and 11-0

Changes made between issues 11-0 and 10-2

Overview of Radio Resource Pre-emption and Queuing

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

Changes made between issues 10-2 and 10-1

1 Overview of Radio Resource Pre-emption

Market Expansion Toolkit

• Forced release after an unsuccessful forced handover attempt

Benefits of Radio Resource Pre-emption and Queuing

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

Other related topics

• Directed Retry in BSC

2 Technical description of Radio Resource Pre-

Priority of the request

• pre-emption vulnerability indicator (PVI)

2.3 Market Expansion Toolkit

Forced release after an unsuccessful forced handover attempt

Select the pre-

The low priority

The neighbour cells

Start forced release

Figure 1 Forced release after an unsuccessful forced handover attempt

Pre-emption based subscriber classification

Class Priority PCI QA PVI Function

Table 1 Example of subscriber classification

Class Priority PCI QA PVI Function

Table 1 Example of subscriber classification (Cont.)

Subscriber class specific statistics

Fair call duration

time stamp The duration of the call = NOW - timestamp

time stamp The TCH containing the longest

Figure 2 Time stamp comparison

Soft call drop support in BSC

ASSIGNMENT REQUEST (MS 2)

The BSC starts pre-emption for MS 1.

QUEUING INDICATION (MS2)

Forced handover is not possible.

Forced release is allowed.