ZGO-01-03-001____eMLPP_FG_20101030.pdf

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf

http://slidepdf.com/reader/full/zgo-01-03-001emlppfg20101030pdf 1/37

Operator Logo

ZGO-01-03-001 eMLPP

Feature Guide

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf


ZGO-01-03-001 eMLPP

ZTE Confidential Proprietary © 2010 ZTE CORPORATION. All rights reserved. I

ZGO-01-03-001 eMLPP

Version Date Author Approved By Remarks

V1.00 2010-10-30 Not open to the Third Party

© 2010 ZTE Corporation. All rights reserved.

ZTE CONFIDENTIAL: This document contains proprietary information of ZTE and is not to bedisclosed or used without the prior written permission of ZTE.

Due to update and improvement of ZTE products and technologies, information in this document issubjected to change without notice.

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf


ZGO-01-03-001 eMLPP

ZTE Confidential Proprietary © 2010 ZTE CORPORATION. All rights reserved. II

TABLE OF CONTENTS

1

Feature Property ............................................................................................. 1

2

Overview ......................................................................................................... 1

2.1

Feature Introduction .......................................................................................... 1

2.2

Correlation with Other Features ........................................................................ 2

3

Technical Description .................................................................................... 2

3.1

A Interface Parameters Related to eMLPP ....................................................... 2

3.2

eMLPP Call Setup Flow .................................................................................... 4

3.3

eMLPP Handover Flow ..................................................................................... 7

4 Parameter Configuration and Descriptions .................................................. 8

4.1

Parameter List .................................................................................................. 8

4.2

Parameter Configuration ................................................................................. 10

4.2.1

eMLPP Priority Configuration (ZTE CN) .......................................................... 10

4.2.2

Reserved Channel Configuration .................................................................... 11

4.2.3

Queuing and Preemption Strategy Setting ...................................................... 15

4.2.4

Channel Allocation Strategy Setting ................................................................ 24

5

Engineering Guide and Configuration Principle ......................................... 25

5.1

Application Scenarios ..................................................................................... 25

5.2

Configuration Principle .................................................................................... 25

5.3

Recommendation ........................................................................................... 26

6

Related Counters and Alarms ...................................................................... 27

6.1

Related Counters ............................................................................................ 27

6.2

Related Alarms ............................................................................................... 33

7

Abbreviations ................................................................................................ 33

8 Reference Document .................................................................................... 33

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf


ZGO-01-03-001 eMLPP

ZTE Confidential Proprietary © 2010 ZTE CORPORATION. All rights reserved. III

FIGURES

Figure 3-1 Flow of Handling Channel Acquisition Failure in Local Cell ................................. 6

Figure 3-2 eMLPP Handover Flow ....................................................................................... 7

Figure 4-1 BSC Configuration ............................................................................................ 12

Figure 4-2 Cell Configuration ............................................................................................. 14

Figure 4-3 Module Parameters ........................................................................................... 16

Figure 4-4 Configuration at BSC Level ............................................................................... 17

Figure 4-5 Configuration at BSC Level ............................................................................... 17

Figure 4-6 Cell Switch ...................................................................................................... 18

Figure 4-7 ............................................................................................................................. 18

Figure 4-8 ............................................................................................................................. 19

Figure 4-9 ............................................................................................................................. 19

Figure 4-10 ........................................................................................................................... 20

Figure 4-11 ........................................................................................................................... 20

Figure 4-12 Switch of eMLPP Strategy ............................................................................... 21

Figure 4-13 Selection of Preemption Target ....................................................................... 24

Figure 4-14 Channel Allocation Strategy ............................................................................ 25

TABLES

Table 3-1 PIE definition ........................................................................................................ 2

Table 3-2 Priority BIT Definition ............................................................................................ 3

Table 3-3 Extra information definition ................................................................................... 3

Table 3-4 Octet 3 is coded ................................................................................................... 4

Table 4-1 Parameter List ...................................................................................................... 8

Table 6-1 Counter list ......................................................................................................... 27

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf


ZTE Confidential Proprietary © 2010ZTE Corporation. All rights reserved. 1

Document Title

1 Feature Property

iBSC version: [iBSC V6.20]

BTS version: [applicable for all SDR BTS versions]

Attribute: [optional function]

NEs involved

NE Name Involved or Not Special Requirement

MS √

BTS -

BSC √

MSC √

MGW -

SGSN -

GGSN -

HLR √

Dependency: [None]

Mutual exclusion: [None]

Remarks: None

2 Overview

2.1 Feature Introduction

In the 3GPP protocol, the enhanced Multi-Level Precedence and Preemption service

(eMLPP) is a supplementary service provided by the GSM system. The eMLPP service

involves multiple NEs, such as BSC, MSC, and HLR.

After the service is provisioned, mobile subscribers are differentiated by different priority

levels. The system allocates channel resources by following the principle of “higher

priority, easier network access”. Therefore, based on the priority configuration, the

high-priority MS has obvious advantages in call connection setup ability and call

interruption prevention ability. When the voice service channels are scarce, high-priority

call may preempt the resources of low-priority calls.

Generally, the eMLPP service contains the following three parts:

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

1 Queuing and preemption

When the network is lack of radio channel resource, calls are put in the queue based on

the priority level. Once idle resources are available, high-priority users can access first.

After preemption is enabled, the high-priority user may preempt resources originally

allocated to low-priority calls. The preemption involves forced handover and forced

release.

2 Reserve channels for high-priority users;

Reserve channels for users of specified priority level. The reserved channels will be used

by the high-priority users at the time of assignment and handover.

3 Configure different channel allocation policies based on the priorities of the users.

You can configure different channel allocation policies for users of different priorities.

2.2 Correlation with Other Features

ZGF05-09-006 Co-BCCH: If the handover from sub-cell 2 to sub-cell 1,is emergency

handover, the eMLPP preemption flow is used.

ZGF05-02-005 Directed Retry: As another mode to obtain resources during channel

congestion, it is considered in enhanced eMLPP function.

ZGF05-09-009 Enhancement on Channel Allocation: The reserved channels involved in

the eMLPP and the policy of allocating channels according to priority are the factors that

must be considered in the enhancement on channel allocation. The channel allocation

methods are described in <Enhancement on Channel Allocation Feature Guide>.

3 Technical Description

3.1 A Interface Parameters Related to eMLPP

According to 3GPP 48.008, the MSC carries call priority parameters in A interfacemessages ASSIGNMENT REQUEST and HANDOVER REQUEST. Different operators

may have different parameter setting modes.

Table 3-1 defines the priority (PIE (Priority Information Element.)) segment.

Table 3-1 PIE definition

8 7 6 5 4 3 2 1

Element identifier octet 1

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Length octet 2

Priority octet 3

Table 3-2 lists the definition of priority bits.

Table 3-2 Priority BIT Definition

8 7 6 5 4 3 2 1

spare pci priority level qa pvi octet 3

Priority Level (PL) occupies 4 bits and defines 15 user levels.

6 5 4 3 (bit)

0 0 0 0 spare

0 0 0 1 priority level 1 = highest priority

0 0 1 0 priority level 2 = second highest priority

: : : :

1 1 1 0 priority level 14 = lowest priority

1 1 1 1 priority not used

Other parameters are defined as follows:

Preemption capability indicator (PCI) identifies whether the call can preempt resources of

other calls;

Preemption vulnerability indicator (PVI) identifies whether the resources of the call can be

preempted by other calls;

Queuing allowed indicator (QA) identifies whether this call allow queuing.

The value of these parameters includes 1 (allow) and 0 (prohibit).

According to 3GPP 48.008, for inter BSC handover, the Extra information part in Old BSS

to New BSS Information element of the HANDOVER REQUIRED message sent by

source BSC to MSC carries PREC parameter, which indicates whether recommend

preemption to the target BSC.

Table 3-3 Extra information definition

8 7 6 5 4 3 2 1

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Field Element identifier octet 1

Length octet 2

octet 3

Table 3-4 Octet 3 is coded

8 7 6 5 4 3 2 1

Spare UE-prob

lcs prec octet 3

PREC (Preemption Recommendation): identifies whether source BSC recommends the

handover to preempt other calls .1 means recommend, 0 means not recommend.

3.2 eMLPP Call Setup Flow

When a user initiates a call or serves as a callee, the MSC sends the ASSIGNMENT

REQUEST message with the PIE parameter to the BSC. The following describes the flow

of speech channel allocation by the BSC:

First try to allocate an idle TCH channel in the local cell:

Check the PriorityLevel of MS. If PriorityLevel≤PriThreshold, it means that the service can

occupy the reserved channel. Check the parameter RsvChanFirst to judge whether the

service should occupy the reserved channel or non-reserved channel. When allocating

the reserved channels, check whether the local cell has reserved channels in reference

to parameter EMLPPThs.

When channel acquisition fails, the flow is as follows:

1 Judge whether allow forced handover:

i If ForcedHoInd_0=1, forced handover is allowed. In this case, go to step 2.

ii If ForcedHoInd_0=0, forced handover is allowed. In this case, go to step 4.

2 Judge whether allow forced queue:

i If QueueInd_0=1, queue is allowed. In this case, go to step 3.

ii If QueueInd_0=0, queue is not allowed. In this case, go to step 4. Forcedhandover needs queue at the same time. Forced release does not need queue.

3 Search for forced handover object. The object must have a lower priority level thanthe user implementing forced handover, its PVI flag, channel type, and frequencyband must meet the requirement, and have adjacent cells meeting lowest handoverlevel.

i If the forced handover object is found, trigger handover and go to step 7.

ii If the forced handover object is not found, go to step 4.

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

4 Judge whether the cell parameter configuration allows forced release:

i If PreemptionInd_0=1, forced release is allowed. In this case, go to step 5.

ii If PreemptionInd_0=0, forced release is not allowed. In this case, go to step 6.

5 Search for forced release object. The object must have a lower priority level than theuser implementing forced release, its PVI flag, channel type, and frequency bandmust meet the requirement.

i If the forced release object is found, wait for the system to allocate forciblyreleased channel. The flow ends.

ii If the forced release object is not found, go to step 6.

6 Judge whether the cell parameter configuration allows queue:

i If QueueInd_0=1, queue is allowed. In this case, go to step 7.

ii If QueueInd_0=0, queue is not allowed. Channel acquisition fails and the flowends.

7 Enter the queue to wait for channel allocation.

i If channel is acquired before the timer expires, MS successfully acquires thechannel. In the case, the flow ends.

ii If no channel is acquired before the timer expires, go to step 8.

8 Judge whether the cell parameter configuration allows forced release:

i If PreemptionInd_0=1, forced release is allowed. In this case, go to step 9.

ii If PreemptionInd_0=0, forced release is not allowed. Channel allocation failsand the flow ends.

9 Search for forced release object by using the policy in step 5.

i If the forced release object is found, wait for the channel allocated after beingforcibly released. The flow ends.

ii If the forced release object is not found, MS fails to acquire channel and the flow

ends.

The previous process is shown in figure 3-1.

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Figure 3-1 Flow of Handling Channel Acquisition Failure in Local Cell

Allowforced

handover?

Allow

queuing?

Allowforced

release?

Yes

No

Yes

Yes

Enterthe

queue

Channelallocation

failsduetocellcongestion

Allow

queuing

No

No

Yes

No

Yes

Forced

handoverobject

attempts

handover

Acquire

channelbefore

queuetimer

expires

Yes

Channel

acquisition

succeeds

Allowforced

release?

Yes

Implement

forcedrelease

toacquire

channel

No

Channel

acquisition

fails

No

Yes

Implement

forcedrelease

toacquire

channel

Findforced

release

object?

Findforced

handover

object?

No

Findforced

release

targetNo

Yes

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

3.3 eMLPP Handover Flow

The handover in the BSC includes intra-cell handover, inter-cell handover, inter-BSC

handover out, and inter-BSC handover in.

For the handover of users with high priority, besides system parameter , the handover

causes also decide whether to implement preemption. Classified by handover cause,

handover has two types. One is rescue handover (also called emergency handover),

such as quality handover and level handover. If such type of handover is not performed,

call drop may occur. The other is non-rescue handover, including PBGT handover,

handover from the first sub cell to the second sub cell (the handover from the second sub

cell to the first sub cell serves as a rescue handover). For details, please refer to

ZGF05-09-006 Co-BCCH. BSC performs different measures for handling these two types

of handover. For non-rescue handover, the system does not implement preemption if the

target cell does not have available channels. For rescue handover, if the target cell hasno idle channel, like the preemption in allocation process, the system attempts forced

handover and forced release on target cell based on parameter setting and PIE to

acquire channels.

Intra-cell emergency handover has only one target cell. The preemption process is the

same as that in allocation process. Inter-cell handover has multiple target cells and they

need to be applied for channel attempt one by one. When the system fails to allocate

channels for all internal candidate target cells and no other external candidate cells are

available, the system attempts the preemption to acquire channels.

The inter-cell handover flow has 2 stages:

1 BSC does not start the preemption process but applies for channels in the targetcells one by one. If the channel allocation fails in the target cells, the system doesnot resort to forced handover, forced release and queuing. According to theparameter PriorityLevel , the system decides whether to allocate reserved channels,and selects the channel priority selection strategy by PriorityLevel when BSCdecides to allocate the unreserved channels.

2 If no channel is allocated after the system has tried the inner cells in the top of thecell table and no outer cells are available, the system starts the preemption processand tries the target cell once again. The system tries the preemption and queuing toobtain a channel in the target cell according to the settings (QueueInd_1,

PreemptionInd_1, and ForcedHoInd_1) of the parameters of the target cells, asshown in Figure 2. The processing in the target cell is similar to the preemption flowof the call setup flow mentioned in Section 3.2.

Figure 3-2 shows the inter-cell handover flow.

Figure 3-2 eMLPP Handover Flow

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Inner

targetcell

1

Callinitiating

handover

Inner

targetcell

2Applychannel(preemptionnot

recommended)

ReturnchannelnotavailableApplychannel(preemptionrecommended)

ReturnchannelavailableorProceeding

①

①

①

①

①

①

①

①

In case that outer candidate cells are available during handover, if all target cells before

the outer cells fail to apply for channels during the first resource application, that is,

preemption not recommended, BSC does not attempt to acquire channel through

preemption among inner cells but starts external handover. Based on whether the

handover is a rescue handover, BSC transmits the PREC flag, which indicates whether

preemption is recommended, to target BSC through the “OLD BSC TO NEW BSC” parameter in HANDOVER REQUIRED message. The target BSC performs channel

preemption according to this parameter.

During inter-BSC handover, the target BSC decides whether to perform preemption

according to parameter configuration, PCI flag, and the PREC flag in “OLD BSC TO NEWBSC” information element. The preemption process is the similar to that described

section 3.2. The difference is that different control parameters are used, including

QueueInd_1, PreemptionInd_1, and ForcedHoInd_1.

4 Parameter Configuration andDescriptions

4.1 Parameter List

Table 4-1 Parameter List

No. Parameter Name Configured in

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

1 PriThreshold Figure 5

2 RsvChanFirst Figure 5

3 EMLPPThs Figure 5

4 EMLPPThs Figure 6

5 UseCellEmlppThs Figure 6

6 AssQueEnable Figure 7

7 AssPreEmpt Figure 7

8 HoQueEnable Figure 7

9 HoPreEmpt Figure 7

10 QueueIndAss Figure 8

11 QueueIndHo Figure 8

12 PreemptionIndAss Figure 8

13 PreemptionIndHo Figure 814 ForcedHoIndAss Figure 8

15 ForcedHoIndHo Figure 8

16 QueueInd_0 Figure 9

17 QueueInd_1 Figure 9

18 PreemptionInd_0 Figure 9

19 PreemptionInd_1 Figure 9

20 ForcedHoInd_0 Figure 9

21 ForcedHoInd_1 Figure 9

22 AssPreemptStrategy Figure 10

23 HoPreemptStrategy Figure 10

24 AssForcedHoTry Figure 10

25 HoForcedHoTry Figure 10

26 AssForcedRelTry Figure 10

27 HoForcedRelTry Figure 10

28 AssPreemTimer Figure 10

29 HoPreemTimer Figure 10

30 AssForceRelTimer Figure 10

31 HoForceRelTimer Figure 10

32 AssForceHoInterval Figure 10

33 HoForceHoInterval Figure 10

34 AssForceRelInterval Figure 10

35 HoForceRelInterval Figure 10

36 RmsT11 Figure 11

37 RmsTqHo Figure 11

38 ForceHoWaitEmergServiceIPrio Figure 11

39 ForceRelWaitEmergServiceIPrio Figure 11

40 LowestPriority Figure 11

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

41 Longcallduration Figure 11

42 ForceHoPenalty Figure 11

4.2 Parameter Configuration

4.2.1 eMLPP Priority Configuration (ZTE CN)

Set priority for MS through MSC and HLR. Note that there are 15 RAM priority levels (1 ~

14 + None) at MSC side, which correspond to the previously mentioned 15 priority levels.

At HLR side, however, only 4 priority levels (L1~L4; LA and LB are internally used priority

levels and therefore are excluded here). In this case, the system should select four RABpriority levels from the 15 options to set up corresponding relation with the service

priorities at HLR side, and then set priority levels on HLR for MS. That means, only four

priority levels can be set to users in ZTE system.

4.2.1.1 Configuration at MSC side

Choose Service Data Configuration－> RAB Configuration－>RAN Service Priority

on MSCSERVER and choose the RAM priority (eMLPP priority) corresponding to

services on HLR:

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Configure PVI, PCI, and QA parameters in PIE information element.

In addition, choose Service Data Configuration－> VLR Configuration－>Services

supported by VLR and select Support enhanced multi-level precedence and

pre-emption service to enable the function of priority access.

4.2.1.2 Configuration at HLR side

For mobile phone numbers required for priority access, this service needs to be enabled

through IMSI. The procedures for configuring the parameters in HLR are as follows:

Choose Supplementary Service ->eMLPP and set priorities from 1 to 4. The highest

level of eMLPP is the highest level of this the user. For example, if the highest level of the

user is 2, the default priority can be a level among 2, 3, and 4. Generally, the highest

priority is configured to be the same with the default priority.

4.2.2 Reserved Channel Configuration

The reserved channel is used for users with certain high priorities during allocation and

handover. Currently, only TCH/F channel can be set as reserved channel.

4.2.2.1 Configuration at BSC Level

To configure channel reservation at BSC level, in configuration resource tree, chooseOMC→GERAN Subnetwork→BSC Managed Element→Config Set and double-click

BSC Function. The BSC Function window is displayed at right. Select the Channel

Allocation Control Params tab, as shown in the following figure:

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Figure 4-1 BSC Configuration

Configure the following parameters:

User Priority for EMLPP: indicates the priority threshold for users to occupy reserved

channel. A user can occupy the reserved channel only when its priority level is lower thanthe threshold.

Reserved channel first: indicates whether the system allocates reserved channel or

non-reserved channel for users meeting priority requirement.

EMLPP channel reserved threshold: indicates the proportion of reserved channels in a

cell. If the result of calculation according to the rate is greater than 0 and smaller than 1,

then one channel is reserved.

Full name Reserved Channel First

Abbreviation RsvChanFirst

3GPP name –

3GPP reference –

DescriptionThe selection order of reserved channel and non-reservedchannel

Managed object BSC

Value Range Yes/No

Unit None

Default value Yes

Related functions ZGF05-25-017 eMLPP

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Related parameters –

Related interfaces –

Full name EMLPP channel reserved threshold

Abbreviation EMLPPThs

3GPP name –

3GPP reference –

Description

When eMLPP service is used, the system may set certainreserved channels. If the result of calculation according tothe rate is greater than 0 and smaller than 1, then onechannel is reserved.

Managed object BSC

Value Range 0 ~ 100

Unit %

Default value 0




Full name User Priority for EMLPP

Abbreviation PriThreshold

3GPP name –

3GPP reference –

DescriptionWhen eMLPP service is used, the system may set certainreserved FR channels. This parameter specifies the lowestpriority level to use reserved channel.

Managed object BSC

Value Range 1 ~ 15

Unit None

Default value 2

Related functions ZGF05-25-017 eMLPPRelated parameters –


4.2.2.2 Configuration at Cell Level

The rate of reserved channel can also be configured at cell level.

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

In configuration resource tree, choose OMC→GERAN Subnetwork→BSC Managed

Element→Config Set→BSC Function→Site Config→Site and double-click Cell. The

Cell window is displayed at right. Select the Other Params, as shown in the following

figure:

Figure 4-2 Cell Configuration

Full name Use cell EMLPP Threshold

Abbreviation UseCellEmlppThs

3GPP name –

3GPP reference –

DescriptionThis parameter defines whether to use eMLPPThs. If yes,you shall select cell property, otherwise to select BSCproperty.

Managed object CellValue Range Yes/No

Unit None

Default value No




Full name Reserved rate of EMLPP

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Abbreviation EmlppThs

3GPP name –

3GPP reference –

Description

This parameter defines eMLPP channel reserved time, thatis, the proportion of eMLPP channel in all available channelsin the cell. If the calculation result is greater than 0 andsmaller than 1, then one channel is reserved.

Managed object Cell

Value Range Yes/No

Unit None

Default value No




4.2.3 Queuing and Preemption Strategy Setting

Preemption has two modes: forced handover and forced release. Forced handover

means that channel is acquired through the handover of users with low priority to other

cells. Force release means that channel is acquired through the release of the calls from

users with low priority.

4.2.3.1 Switch of Queuing and Preemption

1. Configuration at Module Level

In the Configuration Resource Tree, right-click OMC→GERAN Subnetwork→BSC

Managed Element→Config Set→BSC Function and choose Set System Control

Parameter →operation control parameters, as shown in the following figure

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Figure 4-3 Module Parameters

As shown in the following figure, you can set whether to support assign/handover queue

and assign/handover preemption. If they are set as No, the eMLPP configurations at BSC

level and cell level are invalid.

2. Configuration at BSC Level

In the version R8.2, the eMLPP switch at BSC level is added. Double-click OMC→

GERAN Subnetwork→BSC Managed Element→Config Set and select BSC Function.

In the displayed BSC Function window at right, select the EMLPP Set tab.

There are three values for queue, forced handover, and forced release. They are:

allowed, not allowed, and According to the Cell, as shown in the following figure:

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Figure 4-4 Configuration at BSC Level

Pay attention to the following points:

1. The value of the functional switch is contained in R_EMLPP table. 0 means disable, 1means enable, and 2 means refer to cell configuration.

2. The settings of BSC-level switch are also shown in the printed result:

Figure 4-5 Configuration at BSC Level

3. Configuration at Cell Level

In configuration resource tree, double-click OMC→ GERAN Subnetwork→ BSC

Managed Element→Config Set→BSC Function→Site Config→Site and select Cell.

In the displayed Cell window at right, select the Service Process Additional Params

tab.

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Figure 4-6 Cell Switch

Full name Queue allowed when assign

Abbreviation QueueInd_0

3GPP name –

3GPP reference –

DescriptionThe parameter decides whether queuing is allowed in theprocess of assignment when there is no channel available inthe cell.

Managed object Cell

Value Range Yes/No

Unit None

Default value No




Figure 4-7

Full name Queue allowed when handover

Abbreviation QueueInd_1

3GPP name –

3GPP reference –

DescriptionThe parameter decides whether queuing is allowed in theprocess of handover when there is no channel available inthe cell.

Managed object Cell

Value Range Yes/No

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Unit None

Default value No




Figure 4-8

Full name Preemption allowed when assign

Abbreviation PreemptionInd_0

3GPP name –

3GPP reference –

Description

It decides whether forced disconnection is allowed duringthe assignment. The priority in the assignment request isvalid and the preemption is valid. Those connections withlow priority can be forcefully disconnected (handover) toallocate their resources to other assignments or handoverrequest with higher priority. Assignment request indicate thecall status.

Managed object Cell

Value Range Yes/No

Unit None

Default value No

Related functions ZGF05-25-017 eMLPPRelated parameters –


Figure 4-9

Full name Preemption allowed when handover

Abbreviation PreemptionInd_1

3GPP name –

3GPP reference –

Description

It decides whether forced disconnection is allowed duringthe handover. The priority in the handover request is validand the preemption is valid. Those connections with lowpriority can be forcefully disconnected (handover) to allocatetheir resources to other assignments or handover requestwith higher priority. Assignment request indicate the callstatus.

Managed object Cell

Value Range Yes/No

Unit None

Default value No

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title




Figure 4-10

Full name When assigned forced handover

Abbreviation ForcedHoInd_0

3GPP name –

3GPP reference –

Description

This parameter indicates whether the low prioritysubscribers can be forcefully handover to other cell, so thathigh priority subscribers can obtain channels. This

parameter represents whether forced handover is allowedduring assignment.

Managed object Cell

Value Range Yes/No

Unit None

Default value No


Related parametersThe Queue allowed when assign (QueueInd_0) parametermust be configured at the same time.


Figure 4-11

Full name When handover forced handover

Abbreviation ForcedHoInd_1

3GPP name –

3GPP reference –

Description

This parameter indicates whether the low prioritysubscribers can be forcefully handover to other cell, so thathigh priority subscribers can obtain channels. This

parameter represents whether forced handover is allowedduring handover.

Managed object Cell

Value Range Yes/No

Unit None

Default value No


Related parametersThe Queue allowed when handover (QueueInd_1)parameter must be configured at the same time.


7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

4.2.3.2

4.2.3.3 Control Switch of eMLPP Strategy

In R8.2, in BSC Function→eMLPP Params, you can respectively configure preemption

polices of assignment and handover for users with different priority levels. They are

represented by the AssPreemptstrategy and HoPreemptstrategy parameters in

R_EMLPP table.

1. For assignment, there are three strategies: 0 indicates forced handover only; 1indicates try forced handover first, and if fails, try forced release; 2 indicates forcedrelease first.

2. For handover, there are three strategies: 0 indicates forced handover only; 1

indicates try forced handover first, and if fails, try forced release; 2 indicates releaseonly.

Figure 4-12 Switch of eMLPP Strategy

In the channel allocation in versions earlier than R8.2, users are classified into high

priority and low priority. They use different channel allocation strategies. In versions later

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

than R8.2, to flexibly configure the channel allocation for more user types, you can set the

priority allocation strategy for users based on the priority.

4.2.3.4 Flow Control Parameters

To flexibly control eMLPP process, R8.2 adds some configuration parameters for each

user priority. The parameters are grouped based on assignment or handover, and stored

in the R_EMLPP table. The flow control parameters are important for the whole eMLPP

process. Any incorrect understanding of the parameters may result in completely different

results. The following gives a detailed description of the parameters:

Max forced handover/release times: indicates the maximum times of force handovers

or forced releases, excluding those fails to find forced handover or release objects.

Preemption duration: indicates the period when forced handover or release can be

attempted. If the period elapses, only queue is allowed, and new forced handover or

forced release is not allowed.

Timer for start forced release: If both forced handover and forced release are allowed,

do forced handover first. If no channel is acquired, attempt forced release after the timer

for start forced release elapse.

Interval for search forced handover/release target: It determines the waiting time of

next search when no forced handover/release target instance is found. The new attempts

after receiving forced handover instance fails to apply for channel or returns to the

original channel, or timeout of timer for waiting for resources after forced handover,

timeout of timer for waiting for resources after forced release, are not restricted by the

condition and can be initiated immediately.

Queue timer: It determines the time of waiting for channel after forced handover or

forced release. If no channel is acquired after waiting for such a period and the maximum

number of allowed attempts is not reached, the system can initiate a new attempt.

Note that O&M personnel shall ensure the correctness of the whole configuration. The

foreground shall ensure that the software run normally. The related restriction relations

are as follows:

1. For the same priority level, queuing period > preemption time. In actual configuration,the difference of the two is about 2 seconds, so that enough time is reserved forchannel release.

2. For the same priority level, start time of forced release < preemption time. In this way,forced release can be performed within the preemption time.

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

4.2.3.5 Selection of Preemption Targets

In R8.2, in addition to the PVI parameter of the target cell, the priority level and

conversation time also need to be considered during the selection of forced

handover/release targets.

Therefore, two parameters for target selection, LowestPriority and LongCallDuration, are

added at BSC side. The following content details the effect of these two parameters on

target selection:

1. LowestPriority is used to decide whether a comparatively low priority user is found.Its value range is 1 ~ 15. That is, if the priority level of the found target is not smallerthan LowestPriority, the system assumes that the target level is low enough andstops the search. Otherwise, the system keeps searching for the lowest priority. Thepurpose is to reduce the number of times of search.

a) If the parameter is set to 15, infer that the lowest priority user must be found.

b) If the parameter is set to 1, infer that even if a user with priority level 1 is found,the system assumes that the priority level is low enough and stops searching.

2. LongCallDuration is used to measure conversation duration. Here it refers to thetotal number of measurement reports of TCHs within the local BSC. During forcedhandover and forced release, users with comparatively long conversation durationare tended to be serve as the target. When the number reported by the measurementis larger than LongCallDuration, it is assumed that the conversation time is longenough to serve as the target of preemption.

a) If the value is set to the maximum number 65535 (period of measurementreport is about 480 ms), it indicates that the user with the longest conversationtime needs to be found.

b) Note that the priority level is more important than call duration.

Additionally, the ForceHoPenalty parameter is also used for forced handover target. It

indicates the penalty time for the handover failure of forced handover object. During

penalty period, the instance cannot serve as the forced handover target, but it can serve

as forced release target.

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Figure 4-13 Selection of Preemption Target

4.2.4 Channel Allocation Strategy Setting

In R8.2, the system sets channel allocation strategies for users at each priority level. The

strategies are stored in the ChanSelectstrategy field of R_BTS. Totally nine values are

available:

0: According to channel select order of MSC, when prefer TCHF and cell congest change

to prefer TCHH

1: Prefer TCHF, when cell congest change to prefer TCHH

2: Prefer TCHH

3: Only TCHF

4: Only TCHH

5: According to channel select order of MSC, not consider whether cell congest

6: According to channel select order of MSC, when prefer TCHF and cell congest,

change to prefer TCHH if AMR-HR supported

7: Prefer TCHF, not consider whether cell congest

8: Prefer TCHF, when cell congest, change to prefer TCHH if AMR-HR supported

In configuration resource tree, choose OMC→GERAN Subnetwork→BSC Managed

Element→Config Set→BSC Function→Site Config→Site and double-click Cell. In the

displayed Cell window at right, select the Other Params tab and set the related

parameters, as shown in the following figure:

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

Figure 4-14 Channel Allocation Strategy

5 Engineering Guide and Configuration

Principle

5.1 Application Scenarios

When there are a small number of VIP users, configure reserved channels of a certain

quantity to ensure that the calls of important users can be established and maintained.

Queuing is an extensively-applied function and can relieve radio resources congestion.

When there are a wide variety of users, the eMLPP function can be used to realize

priority based radio resource allocation. Forced handover has little impact on users oflower priority; forced release has major impact on users of lower priority and therefore

should be applied with care.

5.2 Configuration Principle

This feature does not involve the adjustment of iBSC and BTS hardware configuration.

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

5.3 Recommendation

This feature involves many parameters and switches. Also, many parameters have

corresponding switches in BSC and cell. Therefore, DO CAREFULLY read the chaptersabout parameter configuration before enabling this feature. Ensure that you have

grasped the meanings of the parameters and their relations.

Pay attention to the following issues when enabling this feature:

3. Only if the switch is set to cell level, the eMLPP setting at cell level can take effect.

4. Either forced handover or forced release is set to be allowed, the queue function mustbe set to enabled. Similarly, if the setting is according to the cell, the queue functionmust be set to enabled or according to the cell. The reason is that queue providestime for forced handover and forced release.

5. The setting of allowing forced handover and forced release does not mean that userswith high priority can surely initiate them. The implementation of forced handover,forced release, and queue are determined with the combination of PIE parameter sentby MSC.

Additionally, various factors affect the selection of preemption target in this feature. The

feature may not be smoothly enabled due to any misunderstanding. It is recommended to

carefully read the following process for selecting preemption target instance before

configuring flow control parameters.

The preemption target instance found by iBSC must meet the following requirement:

The channel type, band, and subcell meet the requirement.

For forced handover target, the system determines whether the target cell hasavailable channels in advanced.

The target is not in penalty period, and not selected as preemption target by otherusers. The PVI bit (meaning preemption allowed) is reset and the priority level islower than the preemption initiator.

After the instance meeting the requirement is found, it is compared with LowestPriority

and LongCallDuration. If both parameters meet the requirement, the system stops

searching and use the instance as the preemption target even if subscribers with lowerpriority exists. If either of the two parameters does not meet the requirement, the system

precedes searching. If the found instance has a lower priority level, replace the previous

one with this one. If the found instance has the same priority level with the previous one

but longer conversation time, it is also used to replace the previous one. Similarly, the

system determines whether to continue the search based on LowestPriority and

LongCallDuration. This process goes cyclically till both the parameter requirements are

met. If no instance meeting the requirements is found, the finally got instance serves as

the preemption target after all instances are searched. After the preemption target is

found, the data area is marked to avoid being selected as the forced handover/release

target again.

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

R8.2 involves directed retry. It is recommended to comprehensively consider directed

retry when enabling this feature. When directed retry takes effect, it can be initiated

earlier than the end of queuing (that is, queue timer expires). Therefore, in case directed

retry permits, quits the queue after directed retry start time (rmsT10) and attempts

directed retry.

6 Related Counters and Alarms

6.1 Related Counters

Table 6-1 Counter list

Counter No. What It CountsNE

Granularity

C100430130Number of assign TCH/F release by forcedhandover to forced handover source

cell

C100430131Number of assign TCH/F release by forcedhandover to queuing user

cell

C100430132Number of restore TCH/F release by forcedhandover to DBS

cell

C100430133Number of assign TCH/F release by forced releaseto forced release source

cell

C100430134 Number of assign TCH/F release by forced releaseto queuing user cell

C100430135Number of restore TCH/F release by forced releaseto DBS

cell

C100440130Number of assign TCH/H release by forcedhandover to forced handover source

cell

C100440131Number of assign TCH/H release by forcedhandover to queuing user

cell

C100440132Number of restore TCH/H release by forcedhandover to DBS

cell

C100440133Number of assign TCH/H release by forced release

to forced release source

cell

C100440134Number of assign TCH/H release by forced releaseto queuing user

cell

C100440135Number of restore TCH/H release by forcedrelease to DBS

cell

C100460001Number of general assignment executions for voicechannel

cell

C100460002Number of assignments attempts for voice due toforced release

cell

C100460003Number of assignment executions for voicechannel due to forced release

cell

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

C100460004Number of handover attempts for voice due toforced release

cell

C100460005Number of handover executions for voice channeldue to forced release

cell

C100460006Number of assignments for voice channel due toqueuing

cell

C100460007Number of assignments for execution for voicechannel due to queuing

cell

C100460008Duration of assignment success voice channel dueto queuing

cell

C100460009Number of assignments success for voice channeldue to queuing

cell

C100460010Number of assignments for directed retry attemptsfor voice channel

cell

C100460011 Number of assignments for execution for voicechannel due to directed retry

cell

C100460012Number of general assignments for execution fordata

cell

C100460013Number of assignments attempts for data due toforced release

cell

C100460014Number of assignment executions for data due toforced release

cell

C100460015Number of handover attempts for data due toforced release

cell

C100460016Number of handover executions for data due to

forced release.cell

C100460017Number of assignments attempts for data due toqueuing

cell

C100460018Number of assignments for execution for data dueto queuing

cell

C100460019Total duration of successful assignments for datadue to queuing

cell

C100460020Number of assignments success for data due toqueuing

cell

C100460021Number of assignments attempts for data due todirected retry

cell

C100460022Number of assignment executions for data due todirected retry.

cell

C100460035Number of assignments attempts due to forcedrelease(emergency service)

cell

C100460036Number of assignment executions channel due toforced release(emergency service)

cell

C100460037Number of handover attempts due to forcedrelease(emergency service)

cell

C100460038Number of handover executions channel due toforced release(emergency service)

cell

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

C100460039Number of assignments channel due toqueuing(emergency service)

cell

C100460040Number of assignments for execution channel dueto queuing(emergency service)

cell

C100460041Number of forced handover target notfound(assignment forced handover)

cell

C100460042Number of send forced handover request to lowerPRI user(assignment forced handover)

cell

C100460043Number of recv failure from lower PRI user requestresource for forced handover(assignment forcedhandover)

cell

C100460044Number of lower PRI user handoverfailure(assignment forced handover)

cell

C100460045Number of time out for wait resource(assignmentforced handover)

cell

C100460046Number of forced release target notfound(assignment forced release

cell

C100460047Number of time out for wait resource(assignmentforced release)

cell

C100460048Number of get before grab releasedchannel(assignment forced handover)

cell

C100460049Number of get before grab releasedchannel(assignment forced release)

cell

C100470064Number of SDCCH drops due to eMLPP forcedhandover

cell

C100470065 Number of signaling TCH/F drops due to eMLPPforced handover

cell

C100470066Number of voice TCH/F drops due to eMLPPforced handover

cell

C100470067Number of data TCH/F drops due to eMLPP forcedhandover

cell

C100470068Number of signaling TCH/H drops due to eMLPPforced handover

cell

C100470069Number of voice TCH/H drops due to eMLPPforced handover

cell

C100470070Number of data TCH/H drops due to eMLPP forced

handovercell

C100490001 Number of handover attempts due to direct retry cell

C100490020Number of SDCCH handover during assignmentdue to forced transfer

cell

C100490021Number of SDCCH handover during handover dueto forced transfer

cell

C100490043Number of TCH/F handover during assignment dueto forced transfer

cell

C100490044Number of TCH/F handover attempts duringhandover due to forced transfer

cell

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

C100490066Number of TCH/H handover attempts duringassignment due to forced transfer

cell

C100490067Number of TCH/H handover attempts duringhandover due to forced transfer

cell

C100500011Number of BSC-controlled inter-cell incominghandover attempts

cell

C100500012Number of BSC-controlled inter-cell incominghandover

cell

C100500013Number of BSC-controlled incoming handoverattempts due to forced release

cell

C100500014Number of BSC-controlled incoming handover dueto forced release

cell

C100500015Number of BSC-controlled incoming handoverattempts due to queue

cell

C100500016 Number of BSC-controlled incoming handover dueto queue

cell

C100500017Number of BSC-controlled incoming handoverattempts due to forced handover

cell

C100500018Number of BSC-controlled incoming handover dueto forced handover

cell

C100500019Number of BSC-controlled inter-cell incominghandover success

cell

C100500020BSC-controlled incoming handover time due toqueue

cell

C100500021Number of BSC-controlled incoming handover due

to queuecell

C100500022BSC-controlled incoming handover success timedue to queue

cell

C100500023Number of BSC-controlled incoming handoversuccess due to queue

cell

C100500024Number of MSC-controlled incoming handoverattempts

cell

C100500029 Number of MSC-controlled incoming handover cell

C100500030Number of MSC-controlled incoming handoverattempts due to forced release

cell

C100500031Number of MSC-controlled incoming handover dueto forced release cell

C100500032Number of MSC-controlled incoming handoverattempts due to queue

cell

C100500033Number of MSC-controlled incoming handover dueto queue

cell

C100500034Number of MSC-controlled incoming handoverattempts due to forced release

cell

C100500035Number of MSC-controlled incoming handover dueto forced handover

cell

C100500036Number of MSC-controlled incoming handoversuccess

cell

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

C100500037MSC-controlled incoming handover time due toqueue

cell

C100500038Number of MSC-controlled incoming handover dueto queue

cell

C100500039MSC-controlled incoming handover success timedue to queue

cell

C100500040Number of MSC-controlled incoming handoversuccess due to queue

cell

C100500149B Number of BSC-controlled inter-cell incominghandover attempts due to forcedrelease(emergency service)

cell

C100500150Number of BSC-controlled inter-cell incominghandover(forced release)(emergency service)

cell

C100500151Number of BSC-controlled inter-cell incominghandover attempts due to forcedhandover(emergency service)

cell

C100500152Number of BSC-controlled inter-cell incominghandover(forced handover)(emergency service)

cell

C100500153Number of BSC-controlled inter-cell incominghandover attempts due to queue(emergencyservice)

cell

C100500154Number of BSC-controlled inter-cell incominghandover(queue)(emergency service)

cell

C100500155Number of MSC-controlled incoming handoverattempts due to forced release(emergency service)

cell

C100500156Number of MSC-controlled incominghandover(forced release)(emergency service) cell

C100500157Number of MSC-controlled inter-cell incominghandover attempts due to forcedhandover(emergency service)

cell

C100500158Number of MSC-controlled inter-cell incominghandover(forced handover)(emergency service)

cell

C100500159Number of MSC-controlled incoming handoverattempts due to queue(emergency service)

cell

C100500160Number of MSC-controlled incominghandover(queue)(emergency service)

cell

C100500161 Number of forced handover target notfound(BSC-controlled inter-cell handover due toforced handover)

cell

C100500162Number of send forced handover request to lowerPRI user(BSC-controlled inter-cell handover due toforced handover)

cell

C100500163Number of recv failure from lower PRI user requestresource for forced handover(BSC-controlledinter-cell handover due to forced handover)

cell

C100500164Number of lower PRI user handoverfailure(BSC-controlled inter-cell handover due toforced handover)

cell

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf



Document Title

C100500165Number of high PRI user time out for waitresource(BSC-controlled inter-cell handover due toforced handover)

cell

C100500166Number of forced release target notfound(BSC-controlled inter-cell handover due toforced release)

cell

C100500167Number of high PRI user time out for waitresource(BSC-controlled inter-cell handover due toforced release)

cell

C100500168Number of HO Target not found(MSC-controlledincoming handover due to forced handover)

cell

C100500169Number of send forced handover request to lowerPRI user(MSC-controlled incoming handover dueto forced handover)

cell

C100500170

Number of failure to lower PRI user request

resource for forced handover(MSC-controlledincoming handover due to forced handover)

cell

C100500171Number of lower PRI user handoverfailure(MSC-controlled incoming handover due toforced handover)

cell

C100500172Number of high PRI user time out for waitresource(MSC-controlled incoming handover dueto forced handover)

cell

C100500173Number of forced release target notfound(MSC-controlled incoming handover due toforced release)

cell

C100500174 Number of high PRI user time out for waitresource(MSC-controlled incoming handover dueto forced release)

cell

C100500175Number of get before grab releasedchannel(handover forced handover)

cell

C100500176Number of get before grab releasedchannel(handover forced release)

cell

C100500177Number of handover attempts due to eMLPPforced handover

cell

C100500178Number of handover due to eMLPP forcedhandover

cell

C100500179 Number of handover success due to eMLPP forcedhandover

cell

C100510001 Average length of queue cell

C100510002 Duration of queuing cell

C100510003 Number of queuing cell

C100510004 Duration of queuing success cell

C100510005 Number of queuing success cell

7/23/2019 ZGO-01-03-001____eMLPP_FG_20101030.pdf


Document Title

6.2 Related Alarms

None

7 AbbreviationsAbbreviation Full Name

eMLPP enhanced Multi-Level Precedence and Preemption service

PCI Preemption capability indicator

PIE Priority Information Element

PL Priority Level

PREC Preemption Recommendation

PVI Preemption vulnerability indicator

QA Queuing allowed indicator

TCH Traffic channel

8 Reference Document

[1] 3GPP TS 22.067

3rd Generation Partnership Project;Technical Specification Group Services and System

Aspects;enhanced Multi-Level Precedence and Preemption service (eMLPP) - Stage 1

[2] 3GPP TS 23.067

3rd Generation Partnership Project;Technical Specification Group Core

Network;enhanced Multi-Level Precedence and Preemption service (eMLPP) - Stage 2

[3] 3GPP TS 24.067

3rd Generation Partnership Project;Technical Specification Group Core

Network;enhanced Multi-Level Precedence and Preemption service (eMLPP) - Stage 3

[4] ZXG10 BSS (V6.20) Radio Parameters Reference (Volume I)

[5] ZXG10 BSS (V6.20) Radio Parameters Referce (Volume II)

Documents

ZGO-01-03-001____eMLPP_FG_20101030.pdf