Contents……

1. enhanced Multi-Level Precedence and Preemption service (eMLPP) implementation in

Core(Rajesh Kunapuri).
2. enhanced Multi-Level Precedence and Preemption service (eMLPP) implementation in
BSC(Raghavender Reddy).
3. LTE PLMN Encoding Change from 24301 to 36413 (Sareddy Bharath Reddy)
 eMLPP Service in BSC

In the 3GPP protocol, the enhanced Multi-Level Precedence and Preemption service (eMLPP) is a
supplementary service provided in the GSM system. The eMLPP service involves multiple NEs, such as
BSC, MSC, and HLR. ZTE's BSC supports all the functions related to eMLPP.

Application Scenario:

When there are a few VIP users, configure reserved channels to ensure that the calls of the VIP users
can be established and maintained.

Queuing is an extensively applied function and can relieve radio resources congestion.
When there are a large number of users, the eMLPP feature can be used to perform priority-based radio
resource allocation. Forced handover affects the users with low priorities and forced release greatly
affects the users with low priorities. Therefore, they should be applied with care

Feature Activation Procedure:

In the configuration resource tree, select Configuration Management > Modify Area > GSM Logical
Configuration > Global Information Configuration > eMLPP Configuration and change as shown below
In the configuration resource tree, select Configuration Management > Modify Area > GSM Logical
Configuration > Cell Information Configuration > GSM Cell Configuration and change as shown below
Result:
When there are a large number of users, the eMLPP feature can be used to perform priority-
based radio resource allocation. Forced handover affects the users with low priorities and
forced release greatly affects the users with low priorities.
 eMLPP Service in USPP and MSC Nodes

Feature Activation Procedure:

In USPP, modify the changes in subscriber profile, Supplementary services >> Other services >> enable
eMLPP and assign the Priority values from LA to 4

Value Macro
1 LA
2 LB
3 0
4 1
5 2
6 3
7 4
Cancel the location update from USPP for the assigned eMLPP subscriber and Register the subscriber
in VMSC, then the eMLPP subscription information will be confirmed in VMSC for the subscriber.

In VMSC, eMLPP information was not updating in VLR, so the eMLPP information cannot be checked,
can be verified through trace of MO call or MT Call of the eMLPP subscriber.

Generally for Emergency services we will provide eMLPP Priority=LA, if we provide LA, the MO
Calls will give High priority to eMLPP subscriber than Non-eMLPP subscribers. MT calls will not give
priority for eMLPP Priority = LA.

For VVIP subscriber, we will provide eMLPP Priority =0, so both MO & MT Calls will give High
priority to eMLPP subscriber than Non-eMLPP subscribers.
Pre emption vulnerability (PVI), Queuing and Pre-emption capability (PCI) parameters need to enable,
disable based on the conditions of the eMLPP subscriber.

So for emergency and VVIP subscribers has to provide PCI=1 , Queuing =1 and PVI=0.

This can be configured in VMSC >> RAB QOS configuration.

ADD
RABPRI:VMSCIDX=0,SRVPRI="LA",NAME="Emergency",RABPRI="PRI2",REEMP="YES",VULN="NO
",QUEUE="YES",OMITAUEN="NO";

ADD
RABPRI:VMSCIDX=0,SRVPRI="0",NAME="VVIP",RABPRI="PRI4",REEMP="YES",VULN="NO",QUEU
E="YES",OMITAUEN="NO";

Now we have to set Non-eMLPP subscriber which we call as Ordinary subscriber.

Ordinary subscriber will have default eMLPP priority=2, so we have to set PVI & PCI values for giving
low priority than eMLPP subscribers.

ADD RABPRI:VMSCIDX=0,SRVPRI="2",NAME="OrdinarySubscriber",
RABPRI="PRI10",REEMP="NO",VULN="YES",QUEUE="YES",OMITAUEN="NO";

Give SYNC in VMSC.

Check the MO & MT Scenarios for the eMLPP subscriber.

Scenario : 1

1) In Cell ID, 2 TCH Radio channels allocated in one sector.

There are three subscribers with PVI , PCI & Queuing parameters for emlpp and Non-Emlpp
Subscriber
Subscriber A is a Emlpp Subscriber and B & D is a Non -Emlpp Subscriber.
Subscriber A are HLR provided Priority = LA and RAB Priority level = 1 is having PVI=0 and PCI
=1,Queuing =1
B & D is a Non-Emlpp subscriber, default priority level =2 and RAB subscriber Priority level = 2
is having PVI=1 , PCI=0 and Queuing=0.

Subscriber B(Non- Emlpp) party connected with another subscriber and TCH channel was busy
Subscriber D(Non-Emlpp) Party connected with another subscriber and TCH channel was busy.

Subscriber A (Emlpp) Party dailed an outgoing call, BSC sending assignment response and the call
connected for Emlpp subscriber.

Scenario: 2
1) In Cell ID, 2 TCH Radio channels allocated in one sector.

There are three subscribers with PVI , PCI & Queuing parameters for emlpp and Non-Emlpp
Subscriber
Subscriber A & C is a Emlpp Subscribers and B is a Non -Emlpp Subscriber.
A & C are HLR provided Priority = LA and RAB Priority level = 1 is having PVI=0 and PCI
=1,Queuing =1
B is a Non-Emlpp subscriber, default priority level =2 and RAB subscriber Priority level = 2 is
having PVI=1 , PCI=0 and Queuing=0.

Subscriber A(Emlpp) party connected with another subscriber and TCH channel was busy
Subscriber B(Non-Emlpp) Party connected with another subscriber and TCH channel was busy.
Subscriber C (Emlpp) Party dailed an outgoing call, Call disconnected or handovered for Non-Emlpp
subscriber B and Subscriber C call successfully connected.

Scenario: 3

In Cell ID, 3TCH Radio channels allocated.

There are four subscribers with PVI , PCI & Queuing parameters for emlpp and Non-Emlpp
Subscriber
Subscriber A & C is a Emlpp Subscribers and B & D is a Non -Emlpp Subscriber.
A,C & E are HLR provided Priority = LA and RAB Priority level = 1 is having PVI=0 and PCI
=1,Queuing =1
B& D is a Non-Emlpp subscriber, default priority level =2 and RAB subscriber Priority level = 2 is
having PVI=1 , PCI=0 and Queuing=0.

Subscriber A(Emlpp) party connected with another subscriber and TCH channel was busy
Subscriber B(Non-Emlpp) Party connected with another subscriber and TCH channel was busy.
Subscriber D(Non-Emlpp) Party connected with another subscriber and TCH channel was busy.

Subscriber C (Emlpp) Party dialed an outgoing call, Call disconnected/Handover to other

neighboring sector or cell ID of either Subscriber B & D(suppose Subscriber B disconnected or
handovered) . Subscriber C connected the call and started the conservation.

Subscriber E (Emlpp) Party received MT call, Subscriber D Call disconnected/Handover to neighbor

sector/Cell ID. Subscriber E connected the call and started the conservation.

Experience Summary:
Understood the parameters in BSC config, RF config and BTS Config for EMLPP service.

RAN nodes also should sync with VMSC config, then appropriate result will come.

Reference Document：
3GPP specification doc TS 23067-710, TS 23107-710
Call flow document 3GPP TR 22.952 V1.0.0 (2003-07)
 LTE PLMN Encoding change from 24301 to 36413 to support IoT

PLMN includes MCC (3digits)+MNC(2 or 3 digits). While negotiation between eNodeB

to MME and UE to MME, different protocols were used for S1AP (3GPP.36.413) and NAS
(3GPP.24.301) negotiations.
By default in our ZTE system we use 24301 from end to end (UE eNodeB MME) in
case both eNodeB and MME are of ZTE.
While other vendors like Ericsson, Huawei, Nokia and Samsung can only support 36413.
Which eventually result negotiation failure in S1AP setup.
In general practice it is suggested to follow 36413 PLMN encoding schema, especially
where MNC consists of 3 digits.
The Encoding scheme of 24301 and 36413 are like below.

According to 3GPP TS 36.413 section 9.2.3.8

IE/Group Name Presence Range IE type and Semantics description

reference
PLMN Identity M OCTET - digits 0 to 9, encoded 0000 to 1001,
STRING (SIZE - 1111 used as filler digit,
(3)) two digits per octet,
- bits 4 to 1 of octet n encoding digit 2n-
1
- bits 8 to 5 of octet n encoding digit 2n

-The PLMN identity consists of 3 digits

from MCC followed by either
-a filler digit plus 2 digits from MNC
(in case of 2 digit MNC) or
-3 digits from MNC (in case of a 3 digit
MNC).

MCC -123
MNC-456

So the encoded send sequence will be Sequence = 214365

According to 3GPP TS 24.301 section 9.9.3.12

8 7 6 5 4 3 2 1

EPS mobile identity IEI octet 1

Length of EPS mobile identity contents octet 2

1 1 1 1 odd/ Type of identity
even octet 3
indic

MCC digit 2 MCC digit 1 octet 4

MNC digit 3 MCC digit 3 octet 5

MNC digit 2 MNC digit 1 octet 6

MME Group ID octet 7

MME Group ID (continued) octet 8

MME Code octet 9

M-TMSI octet 10

M-TMSI (continued) octet 11

M-TMSI (continued) octet 12

M-TMSI (continued) octet 13

MCC -123
MNC-456

So the encoded send sequence will be Sequence = 216354

PLMN encoding change at eNodeB

Go to Configuration Management Radio Parameter  LTE TDD

By default PLMN Encoding method will be set to 24301 Encoding Method[0], For IoT scenarios
it should be changed to 36413 Encoding Method[1]. Same should be set at EPC end as well.

Before:
After:

To Change in all sites, please follow batch process.

Go to Configuration Management Batch Operation  Radio Parameter  LTE TDD and
Change PLMN Encoding Method to 36413[1].

After changing parameter, need to give Synchronize all table to eNodeB. Post restoration of
eNodeB check any S1 alarm exists in network.

Also verify the services at field end.