Bss Queing

Radio Resource Pre-Emption andQueuing in BSC

dn9835517Issue 7-0 en

# Nokia CorporationNokia Proprietary and Confidential

1 (44)

2003330Nokia BSC S10.5 ED, Vers. 2, ProductDocumentation

The information in this documentation is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This documentation is intended for theuse of Nokia's customers only for the purposes of the agreement under which the documentationis submitted, and no part of it may be reproduced or transmitted in any form or means without theprior written permission of Nokia. The documentation has been prepared to be used byprofessional and properly trained personnel, and the customer assumes full responsibility whenusing it. Nokia welcomes customer comments as part of the process of continuous developmentand improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, orperformance of the mentioned hardware or software products cannot be considered binding butshall be defined in the agreement made between Nokia and the customer. However, Nokia hasmade all reasonable efforts to ensure that the instructions contained in the documentation areadequate and free of material errors and omissions. Nokia will, if necessary, explain issueswhich may not be covered by the documentation.

Nokia's liability for any errors in the documentation is limited to the documentary correction oferrors. NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL(INCLUDING MONETARY LOSSES), that might arise from the use of this documentation or theinformation in it.

This documentation and the product it describes are considered protected by copyrightaccording to the applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

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

Copyright © Nokia Corporation 2003. All rights reserved.

2 (44) # Nokia CorporationNokia Proprietary and Confidential


Radio Resource Pre-Emption and Queuing in BSC

Contents

Contents 3

List of tables 4

List of figures 5

Summary of changes 7

1 Introduction to Radio Resource Pre-Emption and Queuing in BSC 111.1 Radio Resource Pre-Emption and Queuing overview 12

2 General description of Radio Resource Pre-Emption and Queuing inBSC 13

3 Radio Resource Pre-Emption and Queuing user interface 17

4 Implementation of Radio Resource Pre-Emption and Queuing 194.1 Implementation architecture for pre-emption and queuing 194.2 Pre-emption and queuing functions 204.3 Pre-emption management in RRMPRB 214.4 Queue management 22

5 Implementation details of forced release 255.1 Forced release possibility checks 255.2 Storing forced release requests 265.3 Selection of the candidate for forced release 265.4 Successful and unsuccessful forced release 275.5 Time-out for the forced release 275.6 Statistics counters for forced release 28

6 Implementation details of forced handover 296.1 Forced handover possibility checks 296.2 Storing forced handover requests 306.3 Selection of candidate for forced handover 306.4 Successful and unsuccessful forced handover 326.5 Time-out for forced handover 326.6 Statistics counters for forced handover 33

7 Implementation details of queuing 357.1 Queuing possibility checks 357.2 Queue element 377.3 Prioritisation of request 387.4 Stored information and statistics counters 407.5 Transaction release during queuing 417.6 Queue search 417.7 Time-out for queued seizure request 427.8 Changing BTS queue length 43



3 (44)

Contents

List of tables




List of figures



5 (44)

List of figures

Summary of changes

Summary of changes

Changes between document issues are cumulative. Therefore, the latest documentissue contains all changes made to previous issues.

Changes made between issues 6 and 7

Chapters 4.4. Queue management and 7.8. Changing BTS queue length: Thequeue length has been changed from 24 to 32.

Changes made between issues 6 and 5b

Chapter Implementation details of forced release , section Time-out for the forcedrelease , Chapter Implementation details of forced handover , section Time-out forforced handover and Chapter Implementation details of queuing , section Time-out for queued seizure request : a note was added because of Pronto 1629316.

Chapter Radio Resource Pre-Emption and Queuing user interface : added a newsection Pre-emption to the beginning of the chapter. Renamed the rest of thechapter Queuing .

Chapter Implementation of Radio Resource Pre-Emption and Queuing, sectionPre-emption management in RRMPRB : added a note about denying the use ofpre-emption.

Changes made between issues 5b and 5

The document has been revised throughout to comply with the latestdocumentation standards. No changes have been made in the document due tonew features.

Changes made between issues 5 and 4

Chapter Introduction , section Concepts

Explanation of concepts Directed Retry, Intelligent Directed Retry, MSC and PIEhas been added.

Chapter Radio resource pre-emption and queuing in BSC , section GeneralDescription

General part of pre-emption has been defined.

Chapter Radio Resource Pre-emption and Queuing in BSC , section Handoverqueue for non-urgent handovers

New non-urgent handovers have been added.



7 (44)

Summary of changes

Chapter Implementation , section Pre-emption management in RRMPRB

Added information on choosing between forced release and forced hadover.

Chapter Implementation , section Use of priority element in pre-emption

Added the different services that can be offered to certain priority levels.

Chapter Implementation , section Storing forced release requests

Added more details in the effect of Directed Retry.

Chapter Implementation , section Storing forced handover requests

Added more details in the effect of Directed Retry.

Chapter Implementation , section Selection of candidate for forced handover

Half rate call can be handed over to a free permanent full rate resource.

Chapter Implementation , section Queuing possibility checks

The requirements for the queuing transaction have been further specified: theBTS specific queue parameters make queuing possible in the BTS.

Revisions made between issues 4 and 3

Section General description

The queue type Handover queue has been separated into urgent handovers andnon-urgent handovers.

Section User interface

New queue type priority parameter introduced: "queuePriorityNonUrgentHo".

Section Pre-emption management in RRMPRB

New requirement: The use of pre-emption procedure requires that the MSCsupports the queuing.

Section Forced release possibility checks

New requirement added to the section Forced release check : for a pre-emptingcall, the "queuing allowed" indicator must be set on.

Section Forced handover possibility checks

New requirement added to the section Forced handover check : for a pre-emptingcall, the "queuing allowed" indicator must be set on.




Section Queue element

In queue type: call attempt, urgent handover and non-urgent handover have beenseparated. A new element, Requested TRX type, is explained.

Section Stored information and statistics counters

Urgent handovers and non-urgent handovers have separate statistics.

Section Time-out for queued seizure request

Urgent handovers and non-urgent handovers have separate statistics.



9 (44)

Summary of changes

1 Introduction to Radio Resource Pre-Emption and Queuing in BSC

The purpose of the BSC pre-emption procedures (forced release and forcedhandover) is to offer a service of a guaranteed level to the subscribers in atemporary BTS congestion situation. The purpose of radio resource queuing inthe BSC is to increase the number of successfully completed calls in a temporarycongestion situation in the BTS and thereby to increase radio network efficiency.

In a temporary congestion situation the priority levels and the pre-emptionindicators may be used to determine whether the assignment or handover requesthas to be performed unconditionally and immediately. This leads to triggering ofthe pre-emption procedure which causes the forced release or forced handover ofa lower priority connection if no free resource is immediately available.

The seizure request which is allowed to cause forced release or forced handoverfor a call in progress can be either a call set-up, mobile originating call (MOC)set-up or mobile terminating call (MTC) set-up, or a handover attempt (all GSM-specified handover types).

The pre-emption is an optional BSC-specific feature and it contains specificstatistical functions.

Radio resource queuing enables the setting of the radio channel request to thequeue, and when a suitable radio resource is available again, the interrupted callset-up can be continued. Consequently, there is no need to cut off a startedtransaction owing to a temporary radio channel congestion in the actual BTS.

The queued radio resource is always a TCH, never an SDCCH. The queuedseizure request can be either a call set-up, mobile originating call (MOC) set-upor mobile terminating call (MTC) set-up, or a handover attempt (all GSM-specified handover types).

The queuing contains specific priority management and statistical functions.



11 (44)

Introduction to Radio Resource Pre-Emption and Queuing in BSC

1.1 Radio Resource Pre-Emption and Queuingoverview

The whole topic summary of Radio Resource Pre-Emption and Queuing

. General description of Radio Resource Pre-Emption and Queuing in BSC

. Radio Resource Pre-Emption and Queuing user interface

. Implementation of Radio Resource Pre-Emption and Queuing

. Implementation details of forced release

. Implementation details of forced handover

. Implementation details of queuing




2 General description of Radio ResourcePre-Emption and Queuing in BSC

Pre-emption is an optional BSC-specific feature. Pre-emption is put into use inthe BSC by setting the PREEMPT_USAGE -parameter via the local MMI. TheBTS-specific queue parameters do not have any influence over pre-emptionfeature. A more detailed description of pre-emption is in section "Pre-emptionmanagement in RRMPRB".

Radio resource queuing in the BSC is always a BTS-specific procedure and it is anon-optional feature. The BSC has a specific queue for every BTS and for everyqueue type in each cell.

Three different queue types are implemented:

Call queue

Used when MOC or MTC attempts are queued for.

Handover queue for urgent handovers

Used when an urgent handover attempt is queued for; urgencyis determined by the initial cause of the handover (seeIntelligent Underlay-Overlay and RF Power Control andHandover Algorithm ).

. uplink/downlink interference

. uplink/downlink quality

. uplink/downlink level

. handover initiated due to rapid field drop

. MS-BS distance exceeding cell boundaries

. MS-BS distance causing handover from extendedrange cell to inner cell

. MS-BS distance causing handover from inner cell toextended range cell

. forced handover in order to empty a cell



13 (44)

General description of Radio Resource Pre-Emption and Queuing in BSC

. handover from super-reuse to regular frequency areadue to bad C/I ratio

. handover initiated in order to switch A interface circuitpool

. handover of fast-moving MS from lower layer cell toupper layer cell.

Handover queue for non-urgent

handovers

Used when a non-urgent handover attempt is queued for.Handover causes treated as non-urgent are

. Power Budget handover

. Umbrella handover

. handover of slow-moving MS from upper layer cell tolower layer cell

. MSC controlled traffic reason handover

. BSC controlled traffic reason handover.

These three logical queues are carried out with one BTS-specific physical queue.

The handover attempt can be internal intra-cell, internal inter-cell or external handover. External handovers, however, arealways treated as the urgent ones when the actual handovercause information has not been received by the target BSCfrom the A interface.

Note that the following handover attempts are not queued:

. handovers from regular to super-reuse frequency areacorresponding to the cause "Good C/I ratio",

. handovers related to Directed Retry or IntelligentDirected Retry,

. handovers inititated by the pre-emption procedure.

You can handle the queuing parameters and management viathe OMC and/or local MMI. By means of parameters it ispossible to manage the queuing on a cell by cell basis, as wellas to determine the queuing characteristics. The followingparameters are used:

. allowed queue length

. queuing time of the call queue type which is equal forMOC and MTC




. queuing time of the handover queue type which isequal for urgent and non urgent handovers

. priority management

- queue type priority: possibility to prioritisebetween the queue types

. call queue

. handover queue for urgent handovers

. handover queue for non-urgent handovers.

- MSC informed priority (MS priority): possibilityto prioritise between queue elements.

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



15 (44)

General description of Radio Resource Pre-Emption and Queuing in BSC

3 Radio Resource Pre-Emption andQueuing user interface

Pre-emption

The BSC-specific parameter pre-emption usage in handover(UsageOfPreemtionInHandover) defines if pre-emption procedures, forcedrelease and forced handover, are applied or not in the case of a handover attempt.The parameter can be handled by a specific command of the Base StationController parameter handling MML (PBCHAN) for modifying themiscellaneous BSC parameters (EEQ ).

Queuing

The queue characteristics are defined with the aid of the BTS object classparameters. The parameters can be handled by a specific command of the BaseTransceiver Station parameter Handling MML (PBTHAN) for modifyingqueuing parameters (EQH ).

Parameters can also be handled from the OMC via the Q3.

The following parameters have been defined:

. maximum queue length (maxQueueLength)

Maximum queue length in the actual BTS (in percentage format) specifiesthe number of call attempts and handover attempts waiting for a TCHrelease in the BTS. If the value is set to zero, TCH queuing is not possiblein that BTS.

. time limit for call queuing (timeLimitCall)

The maximum queuing time for call attempts (MOC or MTC) in the actualBTS. If the value is set to zero, call attempt queuing is not active in thatBTS.

. time limit for handover queuing (timeLimitHandover)



17 (44)

Radio Resource Pre-Emption and Queuing user interface

The maximum queuing time for handover attempts (all handover types andhandover reasons) in the actual BTS. If the value is set to zero, handoverattempt queuing is not active in that BTS.

. queue type priority for call attempt queuing (queuingPriorityCall)

Specified priority for the call queue type in the actual BTS. Queue typeprioritisation enables different priorities between call attempt and handoverattempt queuing.

. queue type priority for urgent handover attempt queuing(queuingPriorityHandover)

Specified priority for the urgent handover queue type in the actual BTS.Queue type prioritisation enables different priorities between call attemptand handover attempt queuing as well as between urgent and non-urgenthandovers queuing.

. queue type priority for non-urgent handover attempt queuing(queuePriorityNonUrgentHo)

Specified priority for the non-urgent handover queue type in the actualBTS. Queue type prioritisation enables different priorities between callattempt and handover attempt queuing as well as between non-urgent andurgent handovers queuing.

. MSC-informed priority (MS priority) is taken into account; YES/NO

(msPriorityUsedInQueuing)

Tells whether the priority data for the message element priority in themessages ASSIGNMENT REQUEST and HANDOVER REQUEST istaken into account in the queue management of the BTS.

. queue type priority is taken into account; YES/NO

(queuePriorityUsed)

Tells whether the queue type priority (queuingPriorityCall,queuingPriorityHandover and queuePriorityNonUrgentHo attributes) istaken into account in queue management in the BTS.




4 Implementation of Radio Resource Pre-Emption and Queuing

4.1 Implementation architecture for pre-emption andqueuing

General

Radio resource call control management in the DX 200 BSC (radio channelallocations, releases and queuing) is totally controlled by and performed in theRadio Resource Management Program Block (RRMPRB). The radio resourcequeuing algorithm and pre-emption procedures (forced release and forcedhandover) are realised as a program sub-block which contains severalsubroutines. The program sub-block is controlled by the main RRMPRB radioresource manager. The main RRMPRB handles the message interfaces with otherprogram blocks involved, as well as the data processing in the input transitions.The RRMPRB is located in the Marker and Cellular Management Unit (MCMU).

Main program blocks

In addition to the RRMPRB, the following program blocks are mainly involvedin the radio channel queuing and pre-emption procedures:

. BSC Configuration Updating Program Block (GUPDAT)

The GUPDAT handles the BTS configuration updating procedures to theRRMPRB, for instance, TRX creating/deleting and blocking/deblockingfunctions, and BTS queuing parameter updating.

. Abis Interface Program Block (ABIPRB)

The ABIPRB handles the Abis interface signalling. It requests radiochannels from the RRMPRB, and also releases them. The ABIPRBupdates the idle radio channel interference band information received fromthe BTS to the RRMPRB.



19 (44)

Implementation of Radio Resource Pre-Emption and Queuing

. Handover Attempt Supervisor Program Block (HASPRB)

The HASPRB supervises handover attempts. It sends channel requests tothe RRMPRB, and sometimes also releases them in case of failure. If ahandover attempt is interrupted during queuing, the HASPRB can send anorder to remove the queue to the RRMRPB.

. A Interface Signalling Program Block in BSC (AIVPRB)

The AIVPRB is responsible for interface management between the MSCand the BSC.

4.2 Pre-emption and queuing functions

MCMU switchover during pre-emption and queuing

The Marker and Cellular Management Unit (MCMU) is duplicated. The state ofthe RRMPRB in the spare unit can be changed to active in whichever situationwithout affecting the active calls. Calls at set-up phase can break.

The pre-emption and queued transactions are set-up phase connections, and arenot updated and maintained in the spare unit. If the MCMU switchover occursduring pre-emption or queuing, there is no real time pre-emption or queuing dataavailable in the new working unit, and the RRMPRB cannot send anacknowledgement concerning the pre-emption attempt or queuing. The processinstances (ABIPRB or HASPRB hands) which have requested pre-emption orqueuing services, are released autonomously when the time supervision for theacknowledgement from the RRMPRB expires. The pre-emption call attempts andqueued call attempts are then cleared. The pre-emption handover attempts andqueued handover attempts are interrupted, and calls will continue on the originalradio channels.

Queuing possibility

The target BTS used for queuing can vary depending on the request type. Onequeuing target BTS is possible in the following cases:

. call attempt; the actual BTS is used as the queuing target

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

. external cell handover (target BSC); the BTS identified by the MSC in aHANDOVER REQUEST message is used as the queuing target.




As far as the internal inter-cell handover is concerned, it is possible to use morecells (sixteen at the maximum) as alternative target cells in radio resourceallocation. The handover candidate BTSs for the channel search are chosen fromthe candidate cell list created by the handover algorithm, and are then forwardedto the RRMPRB. From these BTSs, the RRMPRB searches for a free radioresource in order of their superiority over each other. In case all the base stationsin the list are congested, the queuing possiblity in the candidate BTSs is checkedusing the same order as in the allocation procedure.

Consequently, in this handover type choices are given to the RRMPRB in orderto increase the possibility to get the required free radio resource, eitherimmediately or after queuing.

4.3 Pre-emption management in RRMPRB

The pre-emption is used when the BSC receives an assignment request or ahandover request from the MSC and there is no suitable channel available in thecell.

Note

The operator may deny the use of pre-emption in the case of a handover attemptby the BSC-specific parameter pre-emption usage in handover(UsageOfPreemtionInHandover).

The BSC checks the Priority Information Element (PIE ) and, on the basis ofPIE's flags, it may initiate a forced release or forced handover. Only one of thesetwo, forced release or forced handover, is allowed for one subscriber on the basisof the Priority Information Element. In other words, it is not possible to try forcedhandover first, and if the forced handover is unsuccessful, then initiate the forcedrelease as a second choice. If the forced handover is unsuccessful, the new forcedhandover attempt is initiated in case the time supervision has not been expiredand there is suitable vulnerability canditate to be handed over. The use of the pre-emption procedure requires that the MSC supports the queuing.



21 (44)


Use of priority element in pre-emption

In pre-emption handling, the most important information concerning seizurerequests is the Priority Information Element (PIE). The PIE contains the MSpriority information, the pre-emption capability indicator (PCI), the pre-emptionvulnerability indicator (PVI) and the queuing allowed indicator (QA). With theuse of 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-emptionprocedure because the priority level 0 is specified as spare

. PCI=YES, QA=YES, PRIO=1 -> the highest possible priority, initiatesforced release for vulnerability call in progress

. PCI=YES, QA=YES, PRIO=2...PRIO=15 -> initiates forced handover forvulnerability call in progress

. PVI=YES, QA=no relevance, PRIO=0 -> is not chosen to be target of theforced release or forced handover because the priority 0 is spare

. PVI=YES, QA=no relevance, PRIO=1...PRIO=15 -> the lowest priority ischosen to be target of the forced release or forced handover. Priority 1 isthe highest and priority 15 is the lowest.

4.4 Queue management

Queuing is used when the BSC receives an assignment or a handover requestfrom the MSC and all traffic channels are busy or there are no TCHs of therequested kind available. If this seizure request is not allowed to pre-empt anexisting connection, the BSC checks the priority information element and, on thebasis of the "queuing allowed" indicator, it may initiate queuing.

Use of priority element in queuing

In queue handling, one of the most important pieces of information concerningthe queued seizure request is the priority of the queue element. This queueelement priority consists of the MS priority and the queue type priority.

The SEIZURE REQUEST messages to the RRMPRB contain the MS priorityinformation, which is the priority value determined by the MSC. The queue typepriority is a BTS queue parameter that also affects the queuing algorithm functionconsiderably. In general, the handover queue type is set to have a higher prioritythan the call queue type, because handovers deal with already existing callconnections.




BTS queue length specification

Every created TRX builds up eight possible queue positions in the actual BTS. Ifthe TRX contains half rate resources, the queue length is doubled. The maximumqueue length in the BTS is, however, 32. Respectively, every deleted TRXremoves eight/sixteen possible queue positions.

The actual queue length is calculated by using the number of the possible queuingpositions (all created TRXs in the BTS), and the BTS parameter maximum queuelength (maxQueueLength ) given in percentage format. Recalculation isperformed when you change the maximum queue length parameter or when theactive TRX count changes (TRXs are created or deleted).

The calculated actual queue length in the BTS, then, specifies the number of calland handover attempts which can queue for a TCH release in that BTS.

In the BSC every BTS has the same maximum data area (same number ofqueuing positions), on which the maximum queue length can have an effect. Thedata area gives the maximum value to the actual queue length for every BTS. Thesize of the data area can be changed, but it is fixed in a certain software package.



23 (44)


5 Implementation details of forced release

5.1 Forced release possibility checks

Forced release check

When the RRMPRB receives an ASSIGNMENT or a HANDOVER REQUESTmessage and all traffic channels are busy, the RRMPRB checks if the assignmentis allowed to cause a forced release to another call in progress on the BTS. Theforced release transaction is allowed, if the "pre-emption capability" indicator isset 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 PriorityInformation Element received from the MSC in the ASSIGNMENT REQUESTmessage is used. The MSC can prevent the use of the forced release function for acall in progress by setting the pre-emption vulnerability indicator off.

In an internal handover, the original priority information element is used. Thepriority information element is stored in the ABIPRB during the call set-up phase.If the MSC has prevented the forced release in the original call attempt, the forcedrelease is also denied in all handover attempts during the ongoing call.

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

Acknowledgement in successful forced release

In the case of a successful forced release the following steps take place:

. a program block (HASPRB or ABIPRB) sends a pre-emptive TCH requestfor a new call- or handover attempt

. this request causes the forced release for another call in progress and thenew call gets the releaced TCH

. RRMPRB then forwards a positive radio resource allocationacknowledgement to the requesting program block, which initiates channelallocation signalling.



25 (44)

Implementation details of forced release

Acknowledgement in unsuccessful forced release

If no channel has been released within the time limit, the RRMPRB sends anegative radio resource allocation acknowledgement to the requesting programblock.

5.2 Storing forced release requests

The seizure request which is allowed to cause a forced release to another call inprogress is stored in the BTS Forced Release Data Structure (BFRFIL). Theseizure request is stored, providing that there is space left; a maximum of 8seizure requests can be stored at the same time for one BTS. When the seizurerequest is stored in the BFRFIL, the RRMPRB sends the QUEUINGINDICATION message to the service requesting program block. If the DirectedRetry is in use in the BSC, the ABIPRB checks from the QUEING INDICATIONmessage in which queue or data structure the call attempt is stored. If the callattempt is waiting for forced release in the BFRFIL, the Directed Retry will notbe inititated. If the seizure request cannot be stored (the BFRFIL is full), thechannel allocation is given a negative acknowledgement.

When the seizure request is stored in the BFRFIL, the RRMPRB BTS State DataStructure (BSTAFI) is updated with the information on the number of forcedrelease seizure requests in that cell, and time supervision is started. The time limitis a BSC-specific fixed parameter (i.e. it cannot be changed by the operator).

The seizure requests are removed from the BFRFIL in chronological order (firstin, first out).

5.3 Selection of the candidate for forced release

After the RRMPRB has stored the information of the seizure request to theBFRFIL, the RRMPRB selects the candidate to be released. The following mainprinciples 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 lowest priority of the calls in progress is chosen.

The TCH channel rate requirement of the resource request makes the candidateselection procedure more complicated especially when the BTS contains dual rateresources and a full rate TCH is requested. In that case the following three casesare possible:




. the MS of lowest priority is found among the FR mobiles

. the MS of lowest priority is found from a half occupied dual rate RTSL

. the MS of lowest priority is found from a dual rate RTSL, both halves ofwhich are occupied.

The MSs of the first two cases are accepted as candidates but the third case isexceptional when the forced release is requested.

The following rules are followed when the candidate for forced release isselected:

. the MS of lowest possible priority is allocated

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

When the RRMPRB has found the best suitable candidate for release, theRRMPRB sends the information of that channel to the ABIPRB. The ABIPRBstarts the required signalling procedures concerning forced release.

5.4 Successful and unsuccessful forced release

Successful forced release

If the RRMPRB detects seizure requests in the BFRFIL when TCH releases, thefirst seizure request is removed. The number of forced release seizure requests inthe BFRFIL in that cell is updated in the BSTAFI.

The successful assignment or handover is reported to the requesting programblock (ABIPRB or HASPRB), including the data concerning the radio resourceinformation allocated to it. After that, the program block starts the requiredsignalling procedures concerning the actual assignment or handover attempt.

Unsuccessful forced release

If no TCH has been released within the time limit, the TCH service request isrejected due to lack of resources.

5.5 Time-out for the forced release

When the forced release seizure request is stored to the BFRFIL, time supervisionis started. The time limit is a BSC-specific fixed parameter.



27 (44)

Implementation details of forced release

If the time supervision expires and no TCHs have been released, the RRMPRBreceives a time-out message. The seizure request is removed from the BFRFIL.

The number of TCH requests which are allowed to cause a forced release isupdated in the BSTAFI. The unsuccessful assignment or handover attempt isreported to the requesting program block (ABIPRB or HASPRB) as a negativeacknowledgement to the channel seizure request with the cause "no resourceavailable".

Note

If Directed Retry feature is used simultaneously with preemption features forcedrelease and forced handover, the Minimum Time Limit Directed Retry (MIDR)parameter value has to be smaller than the time limit for preemption (fixed value10 s).

5.6 Statistics counters for forced release

When the RRMPRB receives a seizure request attempt which is allowed to causea forced release for another call in progress, the statistical counters are updated.Assignment request attempts and handover request attempts have their ownindividual counter.

When a TCH request which is allowed to cause forced release for another call inprogress is rejected due to lack of released channels, the statistics counters areupdated. Assignment request failures and handover request failures have theirown individual counters.

When the seizure request which caused a forced release for another call inprogress gets a TCH, the statistics counter is updated.

These counters are BTS-specific.




6 Implementation details of forcedhandover

6.1 Forced handover possibility checks

Forced handover check

When the RRMPRB receives an ASSIGNMENT or a HANDOVER REQUESTmessage and all traffic channels are busy, the RRMPRB checks first in thepriority information element of the seizure request if the assignment or handoveris allowed to cause a forced release. If a forced release is not allowed, theRRMPRB checks next if the seizure request is allowed to cause a forcedhandover for another call in progress on the BTS. The forced handovertransaction is allowed, if the "pre-emption capability" indicator is set on, the MSpriority is set to 2 - 15 in the Priority Information Element and the "queuingallowed" indicator is set on.

In a call attempt, which is allowed to cause a forced handover, the priorityelement received from the MSC in the ASSIGNMENT REQUEST message isused. The MSC can prevent the use of the forced handover function for the call inprogress by setting the pre-emption vulnerability indicator off.

In an internal handover, the original Priority Information Element is used. ThePriority Information Element is stored during call set-up phase in the ABIPRB. Ifthe MSC has prevented the forced handover in the original call attempt, theforced release is also denied in all handover attempts during the ongoing call.

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

Acknowledgement in successful forced handover

In the case of a successful forced handover the following steps take place:



29 (44)

Implementation details of forced handover

. a program block (HASPRB or ABIPRB) sends a pre-emptive TCH requestfor a new call- or handover attempt

. this request causes the forced handover for another call in progress and thenew call gets the releaced TCH

. RRMPRB then forwards a positive radio resource allocationacknowledgement to the requesting program block, which initiates channelallocation signalling.

Acknowledgement in unsuccessful forced handover

If no channel has been released within the time limit, the RRMPRB sends anegative radio resource allocation acknowledgement to the requesting programblock.

6.2 Storing forced handover requests

The seizure request which is allowed to cause a forced handover to another call inprogress is stored in the BTS Forced Handover Data Structure (BFHFIL). Theseizure request is stored in the BFHFIL, providing that there is space left, amaximum of 8 seizure requests can be stored at the same time for one BTS. Whenthe seizure request is stored in the BFHFIL, the RRMPRB sends the QUEUINGINDICATION message to the service requesting program block. If the DirectedRetry is in use in the BSC, the ABIPRB checks from the QUEUEINGINDICATION message in which queue or data structure the call attempt is stored.If the call attempt is waiting for forced handover in the BFHFIL, the directed retrywill not be attempted. If the seizure request cannot be stored (i.e. the BFHFIL isfull), the channel allocation is given a negative acknowledgement.

When the seizure request is stored in the BFHFIL, the RRMPRB BTS State DataStructure (BSTAFI) is updated with the information on the number of forcedhandover seizure requests in that cell, and time supervision is started. The timelimit is a BSC-specific fixed parameter.

The seizure requests are removed from the BFHFIL in chronological order (firstin, first out).

6.3 Selection of candidate for forced handover

After the RRMPRB has stored the information of the seizure request to theBFHFIL, the RRMPRB selects the candidate for forced handover. The followingmain principles apply to the candidate selection:




. the candidate has the pre-emption vulnerability indicator set on

. the call in proqress is not an emergency call

. the lowest priority call of the calls in progress is chosen.

The TCH channel rate requirement of the resource request makes the candidateselection procedure more complicated, especially when the BTS contains dualrate resources and a full rate TCH is requested. The following three cases are thenpossible:

. the MS of lowest priority is found among the full rate mobiles

. the MS of lowest priority is found from a half occupied dual rate RTSL

. the MS of lowest priority is found from a dual rate RTSL which also hasthe other half occupied.

The following rules apply in the selection of the candidate for forced handover:

. the MS of lowest possible priority is allocated

. only one forced handover is permitted.

In some circumstances the forced handover can be performed inside the cell thatis maintaining the candidate call - a kind of call packing feature generated by thepre-emption:

. a full rate call can be handed over from a dual rate RTSL to a freepermanent full rate RTSL

. a half rate call can be handed over from a half occupied dual rate RTSL to afree permanent half rate RTSL

. a half rate call can be handed over from a half occupied dual rate RTSL toanother half occupied dual rate RTSL

. if channel rate changes are allowed then full rate call can be handed over toa free half rate resource, and consequently, a half rate call to a freepermanent full rate resource. In these cases the handovers shall beperformed externally, controlled by the MSC if the actual A-interfacecircuit pool does not support the channel rate changes. Note also that theFR call must have HR capabilities before it can be moved to a half ratetraffic channel.

When the RRMPRB has found the best suitable candidate for handover, adecision whether the handover is going to be performed intra-cell or not is made,and the ABIPRB is informed. The ABIPRB starts the required signallingprocedures concerning forced handover.



31 (44)


Negative acknowledgement from RCSPRB

The ABIPRB sends the handover request to the Radio Connection SupervisionProgram Block (RCSPRB). If the RCSPRB rejects the handover attempt, it sendsa negative acknowledgement message to the RRMPRB. The RRMPRB checks ifthe seizure request is still waiting for free resource in the BFHFIL. If the seizurerequest is in the BFHFIL, the RRMPRB selects another candidate for a forcedhandover and gives the information of the new channel to the ABIPRB. If theseizure request is not in the BFHFIL, the forced handover function is ended.

Negative acknowledgement from HASPRB

The HASPRB sends a handover request to the AIVPRB. If the AIVPRB rejects ahandover attempt, the HASPRB informs the RRMPRB by sending a negativeacknowledgement message to the RRMPRB. If the seizure request is still waitingfor free resource in the BFHFIL, the RRMPRB selects another candidate for aforced handover and gives the information of the new channel to the ABIPRB. Ifthe seizure request is not in the BFHFIL, the forced handover function is ended.

6.4 Successful and unsuccessful forced handover

Successful forced handover

When a TCH releases in the actual BTS, the RRMPRB checks first the BFRFIL.If the RRMPRB does not detect a seizure request in the BFRFIL, the RRMPRBchecks the BFHFIL next. If the RRMPRB detects seizure requests in theBFHFIL, the first seizure request is removed. The number of forced handoverseizure request(s) in the BFHFIL in that cell is updated in the BSTAFI.

The successful assignment or handover is reported to the requesting programblock (ABIPRB or HASPRB), including the data concerning the radio resourceinformation allocated to it. After that, the program block starts the requiredsignalling procedures concerning the actual assignment or handover attempt.

Unsuccessful forced handover

If no TCH has been released within the time limit, the TCH service request isrejected due to lack of resources.

6.5 Time-out for forced handover

When the forced handover seizure request is stored to the BFHFIL, timesupervision is started. The time limit is a BSC-specific fixed parameter.




If the time supervision expires and no TCHs have been released, the RRMPRBreceives a time-out message. The seizure request is removed from the BFHFIL.

The number of TCH requests that are allowed to cause a forced handover isupdated in the BSTAFI. Unsuccessful assignments or handover attempts arereported to the requesting program block (ABIPRB or HASPRB) as a negativeacknowledgement to the channel seizure request with the cause "no resourceavailable".

Note

If Directed Retry feature is used simultaneously with preemption features forcedrelease and forced handover, the Minimum Time Limit Directed Retry (MIDR)parameter value has to be smaller than the time limit for preemption (fixed value10 s).

6.6 Statistics counters for forced handover

When the RRMPRB receives a seizure request attempt which is allowed to causea forced handover for another call in progress, the statistics counters are updated.Assignment request attempts and handover request attempts have their ownindividual counters.

When a TCH request which is allowed to cause a forced handover for another callin progress is rejected due to lack of released channels, the statistics counters areupdated. Assignment request failures and handover request failures have theirown individual counters.

When the seizure request which caused a forced release for another call inprogress gets a TCH, the statistics counter is updated.

These counters are BTS-specific.



33 (44)


7 Implementation details of queuing

7.1 Queuing possibility checks

Queuing checks

When all traffic channels are busy or there are no TCHs of the requested kindavailable and the seizure request is not allowed to cause a forced release or aforced handover for another call in progress, the RRMPRB checks if the queuingof this assignment or handover is allowed. The queuing transaction is allowed ifthe following requirements are fulfilled:

. the "queuing allowed" indicator in PIE is set on

. the BTS channel configuration contains channels capable of the requestedchannel rate and

. the BTS specific queue parameters make queuing possible in the BTS.

In call attempt queuing, the priority element that has been received from theMSC, and is given in the ASSIGNMENT REQUEST message, contains the"queuing allowed" indicator. This priority element will then be used. If the MSCprevents the queuing, the call attempt cannot be placed in the queue.

In an internal handover, the above original Priority Information Element is used,and stored in the original call set-up in the ABIPRB. If the MSC has preventedthe original call attempt queuing, the queuing is also denied in all handoverattempts during the ongoing call.

In external handover queuing, the Priority Information Element received from theMSC in the HANDOVER REQUEST message, contains the "queuing allowed"indicator. This priority element will then be used. If the MSC prevents queuing,the handover attempt cannot be placed in the queue.



35 (44)

Implementation details of queuing

Queuing possibility in the BTS

If this transaction queuing is allowed, the RRMPRB checks that the queue isavailable, i.e. that the actual queue length is not zero, and the queue type isactivated in this BTS so that the time limit value of the actual queue type is notzero. If queuing in general, or only for this kind of attempt, is not allowed in theactual BTS, the call attempt cannot be placed to the queue.

Acknowledgement in successful queue set-up

In all radio channel requests, if there is no TCH of the requested kind available inthe BTS, and the queue set-up is successful, the RRMPRB sends queuinginformation to the requested program block.

If the call attempt is queued for, the RRMPRB gives queuing information to theABIPRB, which then sends a queuing indication to the AIVPRB. The AIVPRBthen sends a QUEUING INDICATION message to the MSC.

If the handover attempt is queued for, the RRMPRB gives queuing information tothe HASPRB. In an external handover attempt queuing in the target BSC, theHASPRB sends a queuing indication to the AIVPRB. The AIVPRB then sends aQUEUING INDICATION message to the MSC.

Acknowledgement in successful queuing

In the case of successful queuing, i.e. when the queue element gets a TCH, thenormal positive radio resource allocation acknowledgement is forwarded to therequested program block, which then starts the required signalling procedureconcerning the actual attempt.

Acknowledgement in unsuccessful queuing

In all radio channel request cases, if no TCH of the requested kind is available inthe BTS and the queue set-up is not successful, the RRMPRB sends a normalnegative radio resource allocation acknowledgement to the requested programblock. It then starts the required clearing or interruption procedure concerning theactual attempt.

If the queue set-up has been successful, but the queuing time-out takes place, theRRMPRB sends a normal negative radio resource allocation acknowledgement tothe requested program block.

If the queue set-up has been successful, but the actual queue element has to beremoved from the queue, the RRMPRB sends a normal negative radio resourceallocation acknowledgement to the requested program block.




7.2 Queue element

Each queued seizure request, i.e. queue element, has queue specifications (seebelow), which fully identify the queue element and the required radio resource.

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

. queue type: call attempt, urgent handover attempt, non-urgent handoverattempt; (sorting of handover attempts to urgent and non-urgent handoversis based on the actual reason of the handover and indicated in the TCHresource request received by the RRMPRB)

. queue element priority: MS priority, queue type priority:

In call attempt queuing the MS priority definition received from the MSC,contained in the ASSIGNMENT REQUEST message, is used.

In internal handover the original MS priority definition above is used andstored in the call set-up in the ABIPRB.

In external handover queuing, the MS priority definition received from theMSC, contained in the HANDOVER REQUEST message, is used.

If the MS priority is undefined in the MSC, the MS priority value will havethe lowest priority in queue management.

. required TCH resource (channel type)

In call attempt queuing, the resource definition received from the MSC,contained in the ASSIGNMENT REQUEST message, is used.

In an inter-BSC handover the original resource definition above is usedand stored in the call set-up in the ABIPRB.

In external handover queuing, the resource definition received from theMSC, contained in the HANDOVER REQUEST message, is used.

. accepted interference levels

In call attempt queuing, the most recently received interference banddefinition from the MSC, contained in the ASSIGNMENT REQUESTmessage, is used. If there are no interference band requirements, allavailable TCHs are suitable for this queue element.

In an inter-BSC handover the original interference band definition above isused and stored in the call set-up in the ABIPRB.

In external handover queuing, the most recently received interference banddefinition from the MSC, contained in the HANDOVER REQUESTmessage, is used.

. Requested TRX type:



37 (44)


Indicates if the queued resource is requested from the extended area or thenormal area. The same queues are used by MSs of the normal area and theextended area. When a TCH is released in the normal area it is assignedimmediately to the first MS of a queue which is queuing for resources ofthe normal area. When a radio channel is released in the extended area it isassigned immediately to the first MS of a queue which is queuing forresources of the extended area.

In call attempt queuing the type of the requested TRX is always the sameas the TRX type used for signalling.

In intra- and inter-cell handover the TRX type request from theHANDOVER REQUEST message is used.

In external handover queuing the queued TRX type is always E-TRX if thetarget cell is extended and the queued TRX type is N-TRX if the target cellis normal.

7.3 Prioritisation of request

In queue management, one important specification of the queue element is thepriority. 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 ispresented below.

Queue type priority and MS priority off

In this most straightforward case of queue management, the priority elements arenot taken into account at all. The seizure request is set to queue, providing thatthere is space left. If the queue is full, the channel allocation is given a negativeacknowledgement.

MS priority on, queue type priority off

The seizure request, i.e. the queue element, is set to the queue in a position thatthe MS priority entitles it to.




The MS priorities of the queue elements are checked. If the new queue elementhas a higher priority than the previous ones, it is set to the queue so that it islocated just before the lower priority element. Other queue elements aretransferred one position towards the end. In this case the last queue element mayhave to be removed from the queue, which is then informed to the actualrequested instance as a negative acknowledgement to the radio channel seizurerequest.

When the seizure request is set to the queue, the timer service corresponding tothe queue type is attached, and the required RRMPRB 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 set to queue in the position that the queue type priorityentitles it to.

The queue type priorities of the queue elements are checked. If the new queueelement has a higher priority than the previous ones, this new element is set to thequeue just before the lower priority element. Other queue elements are transferredone position towards the end. In this case the last queue element may have to beremoved from the queue, which is then informed to the actual requested instanceas a negative acknowledgement to the radio channel seizure request.

When the seizure request is set to the queue, the timer service corresponding thequeue type is attached, and the required RRMPRB file updating is performed.After that the queuing acknowledgement is returned to the requested instance.

MS priority and queue type priority on

In this case the queue element priority consists of the MS priority and the queuetype priority.

The new queue element is set to queue in the position that the queue elementpriority entitles it to.

The MS priority operates only inside one single queue type. A higher MS prioritycall attempt, for example, is placed after a lower MS priority handover attempt, ifthe handover queue type priority is set to be higher than the call queue typepriority.

In the queue setting analysis only the MS priorities corresponding to the samequeue type as the requested one are checked, so that the search is not performedon the whole BTS queue. If the new queue element has a higher MS priority thanthe previous ones inside the same queue type, the new element is set to the queueso that it is located just before the lower MS priority element. Other queue



39 (44)


elements inside 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,which is then informed to the actual requested instance as a negativeacknowledgement to the radio channel seizure request.

When the seizure request is set to the queue, the timer service corresponding tothe queue type is attached, and the required RRMPRB file updating is performed.After that the queue setting command is acknowledged to the main channel callcontrol.

7.4 Stored information and statistics counters

When a seizure request is stored to the queue, all necessary information from theseizure request message is stored in the RRMPRB BTS Queue Data Structure(BQUFIL) in a record corresponding to the BTS identifier. The time stamp for thequeuing start time is also stored.

The priority order of the queue elements in the RRMPRB BTS Queue Order DataStructure (BQUORD) is updated according to the queue element priority. Themost important part of the stored data deals with the radio channel identifiers ofthe requested instance, the requested channel type, the requested TRX type, theaccepted interference level, and the subindex to the reserved BQUFIL record.

When the request is stored in the BTS queue, the RRMPRB BTS State DataStructure (BSTAFI) is updated with the information on the number of the queueelements in that cell, i.e. the number of requests queuing for either full rate or halfrate TCHs or requests capable of both channel rates depending on the receivedchannel type and rate in the assignment request.

The channel state files are also updated with information on queuing. Theinformation includes the queued BTS identifier and a subindex to the BQUFIL. Itis of great importance, because if for instance an MS releases a call, or if theHASPRB sends information concerning the rejected handover attempt whilequeuing, the queue element has to be found and removed from the queue files.

When a request is set to the queue, statistics counters are updated. All countersare BTS-specific queue counters. Call set-ups and handovers have their owncounters; the queuing statistics related to the urgent and non-urgent handoverscan also be picked off with the aid of the counters.




7.5 Transaction release during queuing

Queuing MS on SDCCH releases

When the queuing radio channel (source) is an SDCCH, the queuing data isstored in the RRMPRB 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 fromthe queue. If the queuing SDCCH gets a TCH, the queuing data in the SCHSTAhas to be removed. Respectively, if the queuing time runs out, or the queueelement is removed from the queue, the queuing data in the SCHSTA is removed.

Queuing MS on TCH releases

When the queuing radio channel (source) is a TCH, the queuing data is stored inthe RRMPRB Traffic Channel Status Data Structure (TCHSTA) recordcorresponding to the TCH in question.

If this TCH is released during queuing, the queuing element is removed from thequeue files with the help of the queuing data stored in the TCHSTA.

The HASPRB can send a REMOVE FROM QUEUE message to the RRMPRBin interrupted sequences. The queuing element is removed from the queue fileswith the help of the information acquired from the message.

If the queuing TCH gets a new TCH, the queuing data in the TCHSTA has to beremoved. Respectively, if the queuing time runs out, or this queue element isremoved from the queue, the queuing data in the TCHSTA will be removed.

7.6 Queue search

General

If the RRMPRB detects queued seizure requests in the actual BTS when TCHreleases, the BTS queue is scanned. The last updated interference levelinformation to be used for the released TCH can be found in the channel state filerecord.

When TCH radio resources are deblocked, and the RRMPRB detects queuedseizure requests in the actual BTS, the BTS queue is scanned. The new availableTCH interference band is initialised for the worst interference band until a realinterference updating is received.



41 (44)


The BTS queue is also scanned when the idle TCH interference levels arechanged and there are queued seizure requests in the actual BTS. This is donebecause the queued elements may have just the kind of interference bandrequirements that the new updated TCHs can now offer.

Queue search procedure

The BTS queue is scanned in the queue element priority order until a suitablequeue element is found, that is, when the requested channel type and rate, therequested TRX type and the interference level information are the same as thoseof the new TCH available. The starting-point in the search is the top element ofthe BTS queue order records, because the queue is always organised so that thehighest 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 hasto be reorganised and updated in the BQUORD.

The queuing data and the possible BTS data in the queued channel state filerecord are removed. The number of queuing requests in that cell is updated in theBSTAFI.

Successful queuing is reported to the requested program block (the ABIPRB orthe HASPRB), including the data concerning the radio resource informationallocated to it. After that, the program block starts the required signallingprocedures concerning the actual queued attempt.

Successful queuing is marked to the statistics counters. The queuing time used isexamined by using the actual time stamp and the stored time stamp to see thequeuing start time. Every queue type has its own counters.

7.7 Time-out for queued seizure request

When the seizure request is queued, time supervision is started. The queuing timeavailable depends on the queue type.

If the time supervision expires, and no suitable TCHs have been released, theRRMPRB receives a time-out message. The queue element is searched, and thequeue element removed and reorganised in the same way as in the radio channelrelease.




The number of BTS queue elements in the BSTAFI is updated. The queuing datain radio channel state files (the TCHSTA and the SCHSTA) is removed.Unsuccessful queuing is reported to the requested program block (the ABIPRB orthe HASPRB) as a normal negative acknowledgement to the channel seizurerequest. After that the actual signalling process starts the required clearing orinterruption procedures concerning the actual queued attempt.

Unsuccessful queuing, as well as the queuing time used, are marked to thestatistics counters. Call set-ups and handovers have their own counters; the urgentand non-urgent handovers can also be picked off with the aid of the counters.

Note

If the Directed Retry feature is used simultaneously with queuing, the MinimumTime Limit Directed Retry (MIDR) parameter value has to be smaller than theTime Limit Call (TLC).

7.8 Changing BTS queue length

Maximum queue length parameter change by user

If you change the maxQueueLength parameter, the RRMPRB receives a BTSparameter update via the BSC Configuration Updating Program Block(GUPDAT) from the OMC or the local MMI. You may, for example, set the newmaximum queue length definition to zero, so that queuing is not possible in thatBTS. The actual queue length, i.e. the maximum queue length proportioned to thenumber of possible queuing positions (all created TRXs in the BTS), isrecalculated after the parameter change.

If there are queuing calls or handover attempts not located within the newallowed area, the RRMPRB removes them immediately from the BTS queue, andnegative acknowledgements for the queued channel seizure requests areforwarded to the requested instances.

TRX creation or deletion by user

When the BTS configuration is changed, the RRMPRB receives a configurationupdating message from the GUPDAT. Every created TRX builds up eight/sixteen(TCH/F / TCH/H) queue positions. However, the maximum queue length in theBTS is 32. When a TRX is deleted, the same number of possible queue positionsare removed. The actual queue length is determined by means of themaxQueueLength attribute (in percentage format) given by the user.



43 (44)


After the TRX deletion procedure, it is checked whether there are queuing call orhandover attempts not located within the new allowed area. If this is the case, theRRMPRB immediately removes them from the BTS queue, and negativeacknowledgements for the queued channel seizure requests are forwarded to therequested instances.




Bss Queing

Documents

Transcript of Bss Queing