RAN Sharing - HQoS Guidelines - Ver. 3.1

Product Version Confidentiality Level
RAN17.0 INTERNAL
Huawei Technologies Co., Ltd. Product Name Pages
UMTS Professional Services

95
Solution
UMTS RAN Sharing Technology

Application Guide(RAN17.0)
Inventory Solutions Dept
Prepared
renliang 00116371 Date 2014-7-21
by:
Reviewed
Xu Xiaoze 56296 Date 2014-8-10
by:
Approved
Fang Xiang 00160457 Date 2014-8-15
by:
Huawei Technologies Co., Ltd.

All Rights Reserved
UMTS RAN Sharing Technology Application Guide(RAN15.0) INTERNAL
Revision Record
Date Revision Change Description Author ID

Version
2009-12-01 1.0 Updated this document based on RAN10.0 and Xu Xiaoze 00059296
RAN11.0.
2010-12-07 2.0 Added the MOCN enhancement feature introduced Xu Xiaoze 00059296
in RAN13.0.
2012-04-13 2.1 Updated the contents related to the feature solution Ji Di 00127658
and service design in RAN13.0.
2012-05-30 2.2 Based on review opinion, achieve the final Ji Di 00127658
document
2012-07-06 2.3 Updated the contents related to description of Ji Di 00127658
MOCN Cell Demarcation feature in RAN14.0.
2012-07-28 2.4 Based on review opinion, achieve the final Ji Di 00127658
document
2013-05-17 3.0 Updated the contents related to the feature solution Lu Weifeng 61540
and service design in RAN15.0.
2014-7-21 3.1 Add MOCN Mobility Management renliang 00116371
Add MOCN Independent Iub Transmission
Resource Allocation
Error! Unknown document property

2017-8-11 Page 2 of 94
name.
Contents
1 About This Document .................................................................................................................. 6

1.1 Purpose ............................................................................................................................................................. 6
1.2 Applicable Versions and Scope ........................................................................................................................ 6
1.3 Intended Audience ............................................................................................................................................ 6
1.4 Dependencies ................................................................................................................................................... 6
2 RAN Sharing Information Collection ....................................................................................... 8

2.1 Operator Requirements .................................................................................................................................... 8
2.2 Necessary Information ..................................................................................................................................... 8
3 RAN Sharing Features................................................................................................................ 10

3.1 Overview of RAN Sharing ............................................................................................................................. 11
3.1.1 System Information Broadcasting ......................................................................................................... 13
3.1.2 Initial NAS Message Routing ............................................................................................................... 13
3.1.3 Requirements of RAN Sharing on the CN ............................................................................................ 13
3.1.4 Operator CBS Deployment ................................................................................................................... 13
3.1.5 Operator Dedicated Features ................................................................................................................. 13
3.1.6 RAN Sharing Mobility Management .................................................................................................... 15
3.1.7 Operator Identities and Types ............................................................................................................... 18
3.1.8 Long-Term Evolution of HSPA+ .......................................................................................................... 19
3.2 MOCN Overview ........................................................................................................................................... 19
3.2.1 CN Node Selection ............................................................................................................................... 21
3.2.2 Requirements of MOCN on the CN ...................................................................................................... 24
3.2.3 Difference Between Supporting UEs and Non-Supporting UEs ........................................................... 25
3.2.4 System Information Broadcasting ......................................................................................................... 26
3.2.5 Initial NAS Message Routing ............................................................................................................... 26
3.2.6 Operator CBS Deployment ................................................................................................................... 29
3.2.7 Operator Shared Features ...................................................................................................................... 29
3.2.8 Operator Types ...................................................................................................................................... 29
3.2.9 CS/PS Coordination .............................................................................................................................. 29
3.2.10 Routing Roaming UEs in Proportion .................................................................................................. 30
3.2.11 MOCN Cell Resource Demarcation .................................................................................................... 31
3.2.12 MOCN Mobility Management ............................................................................................................ 31
3.2.13 Long-Term Evolution of HSPA+ ........................................................................................................ 40

2017-8-11 Page 3 of 94
name.
3.2.14 MOCN Independent CE Resource Allocation..................................................................................... 41

3.2.15 MOCN Independent Iub Transmission Resource Allocation .............................................................. 42
4 RAN Sharing Service Design ................................................................................................... 45

4.1 Design Overview ............................................................................................................................................ 45
4.2 Typical Networking Modes of RAN Sharing ................................................................................................. 45
4.2.1 Coexistence of Shared and Non-Shared RNCs Under Full Coverage ................................................... 45
4.2.2 Coexistence of the Shared RNC and 2G Network ................................................................................ 47
4.2.3 Coexistence of Full and Partial Coverage for Different Operators ....................................................... 48
4.2.4 Coexistence of Iu Flex and RAN Sharing ............................................................................................. 49
4.2.5 Coexistence of Multiple Operators ....................................................................................................... 50
4.3 Interface Design ............................................................................................................................................. 50
4.3.1 Iu Interface ............................................................................................................................................ 50
4.3.2 Iu-BC Interface ..................................................................................................................................... 51
4.3.3 Iub Interface .......................................................................................................................................... 52
4.3.4 Iur Interface ........................................................................................................................................... 56
4.4 OM Design ..................................................................................................................................................... 57
4.5 License Management Design ......................................................................................................................... 58
4.6 Resource Capacity Design ............................................................................................................................. 60
4.7 Carrier Allocation in Typical BTS Hardware Configuration .......................................................................... 61
4.7.1 BTS3812E/BTS3812AE ....................................................................................................................... 61
4.7.2 DBS3800 ............................................................................................................................................... 62
4.7.3 BTS3900/BTS3900A ............................................................................................................................ 62
4.7.4 DBS3900 ............................................................................................................................................... 63
4.8 Typical Configuration Parameters .................................................................................................................. 63
4.8.1 Activating RAN Sharing ....................................................................................................................... 63
4.8.2 Adding Operators .................................................................................................................................. 64
4.8.3 Setting Interface Parameters ................................................................................................................. 64
4.8.4 Configuring Cells .................................................................................................................................. 64
4.9 Acceptance Solution ....................................................................................................................................... 65
4.10 Impact on Network KPIs .............................................................................................................................. 65
5 MOCN Service Design ............................................................................................................... 66

5.1 Design Overview ............................................................................................................................................ 66
5.2 Typical Networking Modes of MOCN ........................................................................................................... 66
5.2.1 Full MOCN ........................................................................................................................................... 66
5.2.2 Coexistence of MOCN Cells and Private Cells .................................................................................... 67
5.2.3 Coexistence of the MOCN RNC and Dedicated RNC .......................................................................... 68
5.2.4 Coexistence of the MOCN RNC and 2G Network ............................................................................... 68
5.2.5 Coexistence of Iu Flex and MOCN ....................................................................................................... 70
5.2.6 Coexistence of Multiple Operators ....................................................................................................... 70
5.2.7 MOCN Cell Resource Demarcation ...................................................................................................... 71
5.3 Interface Design ............................................................................................................................................. 71

2017-8-11 Page 4 of 94
name.
5.3.1 Iu Interface ............................................................................................................................................ 71

5.3.2 Iub Interface .......................................................................................................................................... 72
5.3.3 Iur Interface ........................................................................................................................................... 75
5.4 OM Design ..................................................................................................................................................... 76
5.5 License Management Design ......................................................................................................................... 77
5.6 Resource Capacity Design ............................................................................................................................. 77
5.7 Operator Management Design........................................................................................................................ 79
5.7.1 Operator Type ....................................................................................................................................... 79
5.7.2 Operator Group ..................................................................................................................................... 80
5.8 Load Balancing Design .................................................................................................................................. 80
5.8.1 Load Balancing in RAN10.0 to RAN12.0 ............................................................................................ 80
5.8.2 Load Sharing for Routing Roaming UEs in Proportion in RAN13.0 .................................................... 80
5.9 Cell Parameter Design .................................................................................................................................... 82
5.10 Typical Configuration Parameters ................................................................................................................ 82
5.10.1 Activating MOCN ............................................................................................................................... 82
5.10.2 Adding Operators ................................................................................................................................ 83
5.10.3 Adding CN Nodes ............................................................................................................................... 83
5.10.4 Adding NodeBs ................................................................................................................................... 84
5.10.5 Adding Cells........................................................................................................................................ 84
5.10.6 Adding the Roaming Relationship and Roaming Capacity Proportion ............................................... 85
5.10.7 MOCN Cell Resource Demarcation .................................................................................................... 85
5.11 Acceptance Solution ..................................................................................................................................... 86
5.12 Impact on Network KPIs .............................................................................................................................. 86
6 Design of Feature Combination Policies ................................................................................ 87

6.1 Design Overview ............................................................................................................................................ 87
6.2 Design of Feature Combination Policies ........................................................................................................ 87
6.2.1 Iu Flex + RAN Sharing ......................................................................................................................... 88
6.2.2 Iu Flex + MOCN ................................................................................................................................... 88
6.3 Design of Shared NodeB Types ..................................................................................................................... 88
7 RAN Sharing Product Specifications ...................................................................................... 90

7.1 Product Specifications .................................................................................................................................... 90
7.1.1 RAN Sharing-Related Specifications(RAN17.0) ................................................................................. 90
7.1.2 Other Product Specifications................................................................................................................. 90
8 Commercial Applications of RAN Sharing ........................................................................... 92

9 Appendix ...................................................................................................................................... 93
9.1 Scripts for Commercial Offices ...................................................................................................................... 93
9.1.1 RAN Sharing ......................................................................................................................................... 93
9.1.2 MOCN .................................................................................................................................................. 93
10 Abbreviations and Acronyms ................................................................................................. 94

2017-8-11 Page 5 of 94
name.
1 About This Document
1.1 Purpose
This document provides guidelines for Huawei service delivery personnel in delivering
Universal Mobile Telecommunications System (UMTS) Radio Access Network (RAN)
sharing services. It describes the principles and designs of the RAN Sharing feature. This
document is for internal use only.
1.2 Applicable Versions and Scope

The RAN Sharing feature described in this document is applicable to the construction,
reconstruction, swap, and expansion of RAN10.0 to RAN17.0.
1.3 Intended Audience

This document is intended for:
Personnel who are familiar with UMTS RAN products and other network elements (NEs)
connected to RAN equipment
Personnel who have two or more years of experience in UMTS RAN equipment
deployment or maintenance
Personnel who ever participated in commercial deployment of RAN equipment
1.4 Dependencies
Applicable RAN Versions
This document is developed in compliance with RAN10.0 to RAN17.0.

2017-8-11 Page 6 of 94
name.
Applicable Network Topologies

This document is applicable to all current network topologies, including Asynchronous
Transfer Mode (ATM), IP, dual stack, and hybrid IP.
Applicable Network Construction Scenarios

This document is applicable to the RAN construction, reconstruction, swap, and expansion.
Information Accuracy
Collect relevant information before RAN design and maintain full contact with operators
during services delivery to ensure information accuracy.
If the collected information is changed, locate the cause of the change and update the design
output promptly.

2017-8-11 Page 7 of 94
name.
2 RAN Sharing Information Collection
At the beginning of RAN Sharing delivery, delivery personnel must learn operators'
requirements through full communication and collect necessary information.
If the RAN Sharing feature is included in the network design service package, collect the
necessary information according to network design documents.
2.1 Operator Requirements

Learn operators' expectations from RAN Sharing, for example, carrier sharing among
operators, transmission resources sharing over the Iub interface, and routing UEs in
proportion.
2.2 Necessary Information

Information Description
Operator Collect information about multiple operators and common operators
information sharing the RAN.
License Collect the licenses for the radio network controller (RNC) and
information NodeBs of the primary operator, especially the license items related
to RAN sharing.
RNC and NodeB Collect the information about sharing between all RNCs and NodeBs.
sharing
information
CN information If the Multi-Operator Core Network (MOCN) feature is enabled,
check whether the CN of multiple operators supports the MOCN
feature and the Direct Transfer message retransmission over the Iu
interface.
Northbound Collect the method of interconnection with the northbound interface.
interface
Routing roaming Collect the proportion of roaming UEs routed to RAN sharing
UEs in proportion operators.

2017-8-11 Page 8 of 94
name.

2017-8-11 Page 9 of 94
name.
3 RAN Sharing Features
Operators have invested a lot of money in obtaining 3G licenses and building 3G networks
and now are struggling under a heavy financial burden. If they are willing to cooperate for a
3G network and share network infrastructures, they may be rewarded with less investment,
faster network construction, and shorter time to market. In addition, operators are merged and
restructured to survive or grow rapidly in the context of financial crisis and booming mobile
Internet. Under these circumstances, the UMTS network sharing solution witnesses a growth
in global application in recent years.
In addition to the market and technological background of the network sharing, this document
also describes the main network sharing applications. The UMTS RAN sharing solution is
classified into the RAN Sharing solution and the MOCN solution. In the RAN Sharing
solution, operators have their own spectrum resources; in the MOCN solution, operators share
spectrum resources. This document describes the principles, impacts on hardware and
software, and deployment scenarios of the two solutions. The combination of RAN sharing
and MOCN emerges as hybrid sharing, in which exclusive use and sharing of spectrum
resources coexist.
Hybrid Sharing is an application of the MOCN private cells.
In RAN Sharing, each operator uses independent carriers, RNCs and NodeBs are shared
physically, and a RAN is divided into multiple logical RANs. In this way, multiple operators
can use different frequencies to provide coverage for UEs in one area. RAN Sharing is
independent from the CN and UEs but only requires operators to upgrade RAN equipment.
RAN Sharing allows operators to deploy features independently in the shared RAN and to
implement cell-level independent operation and maintenance (OM). In this way, it helps
reduce the cost on network construction and separate services from network OM, ensuring
that RAN sharing operators use different operating strategies.
In MOCN scenarios, all operators use common carrier resources so that all RAN equipment,
such as the RNC and NodeB, are fully shared. MOCN requires cooperation from the CN and
UEs. UEs of release 6 and later versions (that is, supporting UEs) support the MOCN. UEs
earlier than release 6 do not support MOCN. However, Huawei MOCN supports UEs earlier
than release 6, assigns the UEs to correct CNs, and achieves the load balancing among
roaming UEs.

2017-8-11 Page 10 of 94
name.
3.1 Overview of RAN Sharing

Huawei RAN Sharing solution:
Supports the sharing between a maximum of four operators.
Currently, the sharing between only two or three operators is available. Huawei RAN
Sharing solution, however, allows four operators to share a RAN.
Leaves the CN and UEs unchanged.
Huawei RAN Sharing is independent from the CN and UEs.
Permits cell-level feature deployment by operator.
On one radio network, operators who prefer high-speed services can deploy High Speed
Downlink Packet Access (HSDPA) services and operators who prefer mobile TV can
deploy Multimedia Broadcast and Multicast Services (MBMSs). The two categories of
services do not interfere with each other. Even if the operators deploy the same services
on one radio network, they can configure different parameters for the services to suit
differentiated operation requirements.
Supports independent cell-level performance management (PM), fault management (FM),
and configuration management (CM).
Huawei RAN Sharing supports independent cell-level performance statistics, FM, and
parameter settings of operators.
Achieves flexible configurations of shared and private NodeBs.
To meet diversified operating requirements, RAN Sharing enables operators to deploy
private NodeBs under a shared RNC, as shown in Figure 3-1.
Figure 3-1 Private NodeBs in RAN Sharing
Operator A Operator B
CN CN
shared RNC
A dedicated RAN sharing RAN sharing

NodeB NodeB NodeB
As shown in Figure 3-1, the dedicated NodeB indicates the private NodeB of operator A.
Like that on the traditional network, all UEs under the private NodeB access only to the
CN of operator A. All cells under the private NodeB broadcast only the Public Land
Mobile Network (PLMN) of operator A. UEs under the private NodeB can be handed
over to the cells of operator A in the shared NodeB. If dedicated NodeB need to be added
or changed frequency, firstly, logic cell should be deployed in RNC, then M2000
distribute license. Otherwise, equipment will alarm.
Provides flexible Iub transmission sharing ( Including IP or ATM transmission).
In Huawei RAN Sharing solution, Iub transmission resources can be provided for
operators in exclusive and shared manners. The following transmission resource
management modes are available:

2017-8-11 Page 11 of 94
name.
Full sharing
In full sharing mode, admission control and flow control are shared, maximizing the
usage of transmission resources.
Full independence
In full independence mode, both admission control and flow control are independent.
Transmission resources of operators are for exclusive use of operators and do not
interfere with each other. Different logical ports are configured for operators. The
operators perform independent admission control and flow control and configure
different Virtual Local Area Networks (VLANs) based on the logical ports.
Partial independence
In partial independence mode, admission control is independent but flow control is
shared, meeting the independence requirements and improving resource usage.
Operators share a logical port and use transmission resources by configuring the
admission bandwidth ratio.
Iub transmission sharing is recommended to increase resources usage.
Implements differentiated quality of service (QoS) configuration.
Operators configure different QoS policies, such as Allocation Pretention Priority (ARP),
Traffic Class (TC), and Traffic Handling Priority (THP), and map the policies to different
scheduling priority indicator (SPI) weights and guaranteed bit rates (GBRs). In this way,
the differentiated QoS requirements of operators are met. Operators implement UE
admission control, flow control, and scheduling according to the relevant mapping.
Figure 3-2 Differentiated QoS configuration of RAN Sharing
Supports the long-term evolution of Evolved High-Speed Packet Access (HSPA+).

Huawei RAN Sharing supports the long-term evolution of HSPA+ technologies.

2017-8-11 Page 12 of 94
name.
3.1.1 System Information Broadcasting

Each cell pertains to a unique PLMN identity. The PLMN identity is broadcast in the master
information block of each cell. For system information broadcasting, there is no essential
difference between the shared RNC and non-shared RNC except that the shared RNC
supports multiple PLMNs.
3.1.2 Initial NAS Message Routing

From the initial Non-Access Stratum (NAS) message, the RNC identifies the operator's node
by the PLMN identity and the CN domain. The Iu Flex means that multiple Serving GPRS
Support Nodes (SGSNs) or Mobile Switching Center (MSC) servers of one operator connect
to an RNC.
If Iu Flex is not used, there is only one CN node for the operator in each domain. Therefore,
the initial NAS message is directly routed to this CN node according to the CN domain.
If Iu Flex is used, the NAS Node Selection Function (NNSF) procedure is performed to select
a specific CN node of the operator.
Regardless of whether RAN Sharing is adopted, a CN node such as MSC server and SGSN belongs to
only one operator.
3.1.3 Requirements of RAN Sharing on the CN

RAN Sharing requires that operators have their own CNs.
3.1.4 Operator CBS Deployment

In RAN Sharing, each operator deploys its own Cell Broadcast Service (CBS).
One cell corresponds to one CBS Service Area (SA) and the operator broadcasts messages in
its own CBS SA.
3.1.5 Operator Dedicated Features

Operator dedicated features are achieved by setting the RNC license and parameters. There is
only one RNC license for a shared RNC. The license can be individually activated for
operators. Then operators are entitled different capacities and functions. The parameters are
defined on different levels as follows:
RNC: RNC-level parameters. An RNC has only one set of the RNC-level parameters
shared by all operators.
Cell: cell-level parameters. Cell-level parameters change with cells. Operators can
achieve different algorithm performances in different cells.
Both RNC and Cell: some parameters on the RNC level and others on the cell level.
Operator: operator-level parameters.
NodeB: NodeB-level parameters.
Table 3-1 lists some features and their parameter levels for reference.

2017-8-11 Page 13 of 94
name.
Table 3-1 Optional features and parameter levels
Optional Feature Parameter Level

PDCP Header Compression (RFC2507) RNC
Cell ID + RTT Function Based LCS Both RNC and cell
Inter-Frequency Load Balance Both RNC and cell
Potential User Control Cell
Intra-Frequency Load Balance Cell
AMR/WB-AMR Speech Rates Control Both RNC and cell
Intra-System Direct Retry Both RNC and cell
Inter-System Direct Retry Both RNC and cell
Inter-System Redirect RNC
Cell Broadcast Service Both RNC and cell
AGPS Based LCS Both RNC and cell
OTDOA Based LCS Both RNC and cell
Hierarchical Cell Structure (HCS) Both RNC and cell
Queuing and Pre-emption RNC
Inter-RAT Handover Based on Service Both RNC and cell
Inter-RAT Handover Based on Load Both RNC and cell
RAB Quality of Service Renegotiation over Iu RNC
LCS Classified Zones Operator
Iu Flex Operator
Iu Flex Load Distribution Management Operator
Adaptive Multi Rate Wide Band (AMR-WB) Both RNC and cell
High Speed Downlink Packet Access Both RNC and cell
High Speed Uplink Packet Access Both RNC and cell
IP Transportation on Iub Interface NodeB
Satellite Communication on Iub Interface NodeB
IMS Signaling over HSPA RNC
HSDPA 13.976 Mbps per User RNC
HS-DPCCH Preamble support RNC
HSDPA over Iur RNC
SRB over HSDPA RNC

2017-8-11 Page 14 of 94
name.
Optional Feature Parameter Level

2ms/10ms TTI Handover RNC
HSUPA 5.74 Mbps per User RNC
HSUPA over Iur RNC
SRB over HSUPA RNC
MBMS P2P over HSDPA RNC
PDCP Header Compression (RoHC) RNC
Active Queue Management (AQM) RNC
Inter Frequency Hard Handover Based on DL QoS RNC
3G/2G Common Load Management RNC
Inter-RAT Handover Based on DL QoS RNC
Multi Frequency Band Networking Management RNC
60 HSUPA Users per Cell Both RNC and cell
Separation of Transmission Resources for the Iub User Plane RNC
Traffic Priority Mapping on Transport RNC
FP MUX RNC
BFD/ARP IP Re-route RNC
Overbooking on IP Transmission RNC
Dynamic Bandwidth Control of Iub IP RNC
3.1.6 RAN Sharing Mobility Management

In RAN Sharing, operators have their own cells that broadcast independent PLMNs.
Therefore, mobility management on a multi-operator network is the same as that on a
single-operator network. Mobility management involves intra-frequency handovers,
inter-frequency handovers, inter-RNC handovers, inter-RAT handovers, cell/UTRAN
registration area (URA) updates, cell reselections, and inter-RAT reselections.
In addition, RAN Sharing supports handovers between operators. The Inter Plmn Ho
Allowed parameter specifies whether to allow handovers between operators.
The following contents describe two handover scenarios and the impacts.
Handovers Between RAN Sharing Cells and Private Cells (Intra-Operator)

The cell adjacent to a RAN Sharing cell is a private cell of an operator. The RNC delivers
measurement control messages by operator attributes. Only the UEs that are served by this
operator (for example, OpA in Figure 3-3) can be handed over.

2017-8-11 Page 15 of 94
name.
Figure 3-3 Handover between a RAN Sharing cell and a private cell (intra-operator)
The RAN Sharing cell on F2 is adjacent to the private cell of OpA. It is not allowed to hand
UEs of OpB over to this private cell. Therefore, Intra-frequency interference occurs on UEs of
both OpB and OpA. This problem may occur on a radio network where RAN Sharing cells
are networked with private cells. To solve the problem, the following methods are available:
1. Isolate the RAN Sharing cells from the private intra-frequency cells during network
planning.
2. Locate the border between a RAN Sharing cell and an intra-frequency private cell in an
area with low traffic and few UEs to reduce interference.
3. Add inter-frequency or inter-RAT neighboring cells for a RAN Sharing cell and enable
the coverage-based handover to hand over interfered UEs.
4. Enable the uplink QoS-based handover on the RNC to hand over the UEs with poor
uplink signal quality out of the border cell. However, the switch and threshold are of
RNC-level, which affect other cells.
Reselections and Handovers Between RAN Sharing Cells and 2G Roaming Cells
In 3G RAN Sharing, operators may adopt the 2G roaming sharing mode to share the 3G RAN
and 2G network at the same time. For example, UEs of an operator can roam to the 2G
network of another operator. In this scenario, the performance of 3G RAN Sharing may be
affected.
1. 2G-to-3G reselection and handover
Reselection
When a roaming UE of an operator (OpB, for example, as shown in) is reselected
from a 2G cell to a 3G cell, it takes more time than the reselection between 2G cells
or 3G cells.

2017-8-11 Page 16 of 94
name.
Figure 3-4 Reselection from a 2G roaming cell to a RAN Sharing cell
Reselection from a 2G cell

to a 3G cell takes a longer
time for UEs of OpB.
Generally, the Registered PLMN (RPLMN) is preferred. When a UE of OpB

performs an inter-RAT reselection, the UE first tries to camp on the cell of OpA not
OpB. However, the OpA CN rejects the UE. Therefore, the UE reselects a network
and then camps on the cell of OpB. This process lasts for a long time, and the UE
may be disconnected from the network for a short period, affecting key performance
indicators (KPIs), such as the paging success rate.
To speed up the UE reselection and avoid unfavorable UE behaviors, the following
solutions are recommended:
Solution 1:
When a UE of OpB roams to the 2G network of OpA, the location update message
delivered in the OpA CN need change the Home PLMN (HPLMN) of OpB to
Equivalent PLMN (EPLMN) of OpA. As a result, if a UE of OpB performs an
inter-RAT reselection, the HPLMN has the same priority as that of PLMN of OpA,
shortening the reselection process. If the EPLMN of OpB is not configured, the
reselection duration relates to the CN rejection cause and HPLMN reselection timer.
The reselection process may last for several minutes or longer.
Solution 2:
The CN of OpA will reject UEs of OpB requesting for access to the 3G cell of OpA.
The rejection cause value cannot be "PLMN Not Allowed". Otherwise, UEs of OpB
will not roam to the 2G network of OpA unless otherwise manually selected.
Therefore, a less severity value is recommended, for example, "Roaming not allowed
in this location area" or "LAC not Allowed".
Handover
UEs of both OpA and OpB access the OpA 2G cell, and all UEs are connected to the
CN of OpA. Therefore, the base station controller (BSC) of OpA cannot distinguish
UEs of OpA from UEs of OpB. If the 3G cells of OpA and OpB are configured as the
neighboring cells of 2G cells of OpA, the BSC of OpA hands over the UEs to a cell
of an operator only based on the signal measurement result. As a result, UEs of OpA
are handed over to the 3G cell of OpB or UEs of OpB are handed over to the 3G cell
of OpA. This type of handover requires handover relationships between CNs of OpA
and OpB.

2017-8-11 Page 17 of 94
name.
Generally, a 2G network provides wider coverage and larger capacity than a 3G

network does. In addition, operators expect that UEs stay on the 3G network.
Therefore, 2G-to-3G handovers are not recommended.
If 2G-to-3G handover is necessary for a site, it is recommended that the 2G-to-3G
handover be restricted to the networks of OpA. For UEs of OpA, the handover is the
same as that in a common scenario. The UEs of OpB are first handed over to the 3G
cell of OpA to maintain calls. When the calls end, the UEs of OpB are reselected to
3G cells of OpB.
2. 3G-to-2G reselection and handover
Reselection
Figure 3-5 Reselection from a RAN Sharing cell to a 2G roaming cell
For UEs of OpA, the 3G-to-2G reselection is the same as that in a common scenario.
To accelerate the reselection of UEs of OpB, the CN of OpB needs to change the
PLMN of OpA to the EPLMN of OpB in the location update message delivered to
UEs of OpB. In this way, when a UE of OpB performs an inter-RAT reselection, the
PLMN of OpA has the same priority as the PLMN of OpB, shortening the reselection
process. As a result, the CN of OpA rejects the UEs of OpB that try to access the 3G
network of OpA. However, as the rejection cause value is changed to that of less
severity (detailed in the preceding section), the process of reselecting UEs of OpB to
the 2G network of OpA is not affected.
Handover
For UEs of OpA, the 3G-to-2G handover is the same as that in a common scenario.
For UEs of OpB, configure 2G cells of OpA as the neighboring cells of 3G cells of
OpA and enable inter-RAT and inter-operator handovers. This type of handover
requires handover relationships between CNs of OpA and OpB.
3.1.7 Operator Identities and Types

Operator identities and types of RAN Sharing are used to identify an operator.

2017-8-11 Page 18 of 94
name.
Operator Identities
Both PLMN identity and CnOpIndex are used to identify an operator within different scopes.
An operator globally corresponds to a unique PLMN identity, which consists of mobile
country code (MCC) and mobile network code (MNC). A new parameter CnOpIndex is
introduced to identify a unique operator in a RAN.
Operator Types
There are two types of operators, primary operator and secondary operator, in RAN Sharing.
A primary operator takes precedence over a secondary operator in authority management and
license management. The primary operator can be anyone, for example, a third party in charge
of the shared RAN or an operator in possession of physical RAN equipment.
When adding an operator to the RNC, OperatorType must be used to check whether the
operator is a primary one or a secondary one. The primary operator must be specified in an
RNC, and the primary operator is only configured one. The number of operators is not more
than four in an RNC.
3.1.8 Long-Term Evolution of HSPA+

Huawei RAN Sharing supports the long-term evolution of HSPA+, such as 64 Quadrature
Amplitude Modulation (64QAM), Multiple-Input Multiple-Output (MIMO), uplink 16 QAM
(UL16QAM), and Dual Cell HSDPA (DC-HSDPA). DC-HSDPA, including Dual Cell High
Speed Uplink Packet Access (DC-HSUPA), involves two carriers. If each operator has two
consecutive carriers, enable DC-HSDPA for each operator respectively, like that in a common
scenario. However, if each operator has only one carrier and DC-HSDPA needs to be shared,
perform the following operations:
1. Enable DC-HSDPA for operators that the DC carriers belong to.
2. Configure public groups not private groups for the license groups of NodeB.
In addition, DC UEs of an operator may use the carrier resources of another operator. If an
operator has a large number of DC capable UEs, they occupy the resources that should be
allocated for UEs of another operator, which impairs resource usage fairness. Therefore,
operators need to reach an agreement or understanding about allocation of shared resources.
3.2 MOCN Overview

Huawei MOCN solution:
Supports the sharing between a maximum of four operators.
In the current industry, the sharing between only two or three operators is available.
Huawei UMTS MOCN solution, however, allows four operators to share a RAN.
Broadcasts multiple PLMNs in one cell.
As operators share carriers, multiple PLMNs need to be broadcast in one cell. For details,
see 3.2.4 "System Information Broadcasting."
Requires cooperation from the CN and UEs.
In the MOCN solution, the CN must support the MOCN. Huawei MOCN supports UEs
of all versions, including UEs earlier or later than release 6. However, UE behaviors vary
depending on the versions. For details, see 3.2.2 "Requirements of MOCN on the CN."
Routes UEs to correct CN nodes.

2017-8-11 Page 19 of 94
name.
The RNC selects correct CN nodes for UEs that are under the same carrier but served by
different operators.
Shares network features among operators.
Operators share carriers. Therefore, all the network features are shared among operators.
Realizes independent performance statistics.
Operators share carriers. Therefore, Huawei MOCN does not allow operators to perform
independent FM(Fault Management) and CM(Configuration Management). However,
operators can perform PM(Performance Management) independently. For example,
operators can independently measure the radio access bearer (RAB) setup success rate,
the number of RAB releases with different causes, the circuit switched (CS) and packet
switched (PS) traffic volumes, and the consumption of resources, such as code, power,
and channel elements (CEs).
Achieves flexible configurations of shared and private NodeBs.
Huawei MOCN enables operators to deploy private NodeBs under a shared RNC, as
shown in Figure 3-6.
Figure 3-6 Private NodeBs supported by MOCN
As shown in Figure 3-6, the dedicated NodeB indicates the private NodeB of operator A.
Like that in a common scenario, all UEs in the private NodeB access only to the CN of
OpA.
Cells under the private NodeB broadcast only PLMN IDs of the operator that the private
NodeB belongs to. UEs in the cells under the private NodeB can be handed over to
MOCN cells. The private cells of OpA are not available to the UEs of OpB and OpC.
The RNC filters the neighboring cell list according to the PLMN information of the
operator serving the current UEs. For details about mobility management, see 3.2.12
"MOCN Mobility Management."
The flexible configurations suit the MOCN in which partial frequencies are shared.
Supports full sharing of Iub transmission resources.
The MOCN allows operators to fully share the Iub transmission resources only.
Ensures the CS/PS coordination.
For the non-supporting roaming UEs (roaming UEs that do not support the MOCN),
their CS and PS services may register on the CNs of different operators. In this case,
CS/PS coordination must be ensured in the MOCN solution. For details, see 3.2.9
"CS/PS Coordination."

2017-8-11 Page 20 of 94
name.
Implements differentiated QoS configuration.

Operators configure different QoS policies, such as ARP, TC, and THP, and map the
policies to different SPI weights and GBRs. In this way, the differentiated QoS
requirements of operators are met. Operators implement UE admission control, flow
control, and scheduling according to the relevant mapping. For details, see Figure 3-2.
As operators share carriers, differentiated QoS configurations may result in uneven
resource distribution among operators.
Supports the long-term evolution of HSPA+.
Huawei MOCN supports the long-term evolution of HSPA+ technologies.
3.2.1 CN Node Selection

This section describes the basic concepts related to CN selection.
Pool Area
A RAN node service area contains all the cells controlled by the RAN node. A pool area
comprises one or more RAN node service areas. In a pool area, one or more CN nodes that
work in load sharing mode provide services in parallel.
UEs are served by one dedicated CN node in a pool area as long as the UEs are covered by
the pool area. Pool areas can overlap each other. If several overlapping pool areas cover the
same RAN node service area, the RAN node service area belongs to these pool areas. The CS
pool area and PS pool area are configured on a per-RAN node service area basis.
In a pool area, UEs can roam freely without changing the serving CN node. The RAN node
service area of a pool area can belong to one pool area or several pool areas. If several
overlapping pool areas cover the same RAN node service area, the RAN node service area
belongs to these pool areas.
Figure 3-7 shows an example of the pool area configuration.
Figure 3-7 Example of pool area configuration

2017-8-11 Page 21 of 94
name.
Figure 3-7 shows the following four pool areas:

CS pool area 1: includes RAN node areas 1, 2, 5, and 6, as well as MSC servers 1, 2, and
3, which provide services for the RAN node areas.
CS pool area 2: includes RAN node areas 2, 3, 6, and 7, as well as MSC servers 4, 5, and
6, which provide services for the RAN node areas.
PS pool area 1: includes RAN node areas 1 and 5, as well as SGSNs 1 and 2, which
provide services for the RAN node areas.
PS pool area 2: includes RAN node areas 2, 3, 6, and 7, as well as SGSNs 3, 4, and 5,
which provide services for the RAN node areas.
As shown in Figure 3-7, the pool areas that do not support the Iu Flex, such as RAN node areas 4 and 8,
can coexist with the pool areas that support the Iu Flex.
The CS pool area and PS pool area can be configured as identical pool areas, such as CS pool
area 2 and PS pool area 2, or different pool areas, such as CS pool area 1 and PS pool area 1.
Each pool area is configured with unique CN node capability or number.
NRI
The Network Resource Identifier (NRI) uniquely identifies a CN node that serves a pool area.
The NRI ranges from 0 bit to 10 bits in length. In one pool area, all CN nodes use the same
NRI length. In areas where pool areas overlap, the NRI identifies the CN node that serves
these overlapping pool areas. For overlapping pool areas, all CN nodes serving specific pool
areas use the same NRI length.
The CN nodes in the CS domain and PS domain are addressed separately, so the NRIs of the
CS and PS domains are independent of each other.
One or more NRIs can be assigned to one CN node.
Parameters related to NRIs are as follows:
Length of PS NRI in bits
Length of CS NRI in bits
Network resource identifier
The NRI is part of the Temporary Mobile Station Identity (TMSI) for the CS domain, or
part of the Packet TMSI (P-TMSI) for the PS domain (from bit 14 to 23). TMSIs or
P-TMSIs are assigned to UEs by the serving CN node, with NRIs determined by using
certain bits. The NRI length can be configured on the RNC. If an NRI is less than 10 bits,
the NRI should count from bit 23. If an NRI is 0 bits, the NRI feature is not used. The
mapping between the NRIs and the CN nodes in the CN pool area is configured on RAN
nodes.
NullNRI
NullNRI is a special value of the NRI, which is configured on the RNC and is used to
identify an operator. Assume that the state of a CN node is OFFLOAD (which can be
configured on the RNC). When the NRI that the TMSI or P-TMSI of a UE carries is
NullNRI, the UE cannot access the CN node. The RNC connects the UE to a CN node in
the Normal state instead. If the NRI is valid and is not NullNRI, the UE can access the
CN node.

2017-8-11 Page 22 of 94
name.
If an NRI is invalid (an NRI which is not configured on the RNC), the UE cannot access the CN node in
the OFFLOAD state.
NullNRI applies when Iu Flex is used, which can offload a CN node in the Iu Flex only
or Iu Flex + MOCN scenario. In MOCN only scenarios, NullNRI is not configured
because each operator has only one CN node.
IDNNS
In the Wideband Code Division Multiple Access (WCDMA) system, the UE provides an Intra
Domain NAS Node Selector (IDNNS) in the access stratum (AS) part of the Initial Direct
Transfer message to the RAN node. The IDNNS contains a 10-bit routing parameter, which
specifies the NRI value. In addition, the IDNNS contains the identity that indicates the source
of the routing parameters. The identity can be TMSI/P-TMSI, international mobile subscriber
identity (IMSI), international mobile equipment identity (IMEI), or others. The RAN node
masks the significant bits out of the routing parameter part of the IDNNS to determine the
NRI that is used to identify the relevant CN node. The most significant bit of the NRI
corresponds to the most significant bit of the routing parameter in the IDNNS.
If the IDNNS is obtained from IMSI, the value ranges from 0 to 999, with each value
corresponding to a CN node. RAN nodes can route messages to the correct CN nodes
according to the values.
NNSF
The NAS node selection function (NNSF) performs the selection of a CN node and the
processing of the IMSI paging message in both CS and PS domains. The MOCN introduces
the NNSF for selecting CN nodes regardless of whether Iu Flex is employed.
In a RAN node (namely the RNC), the NNSF selects a specific CN node (MSC server or
SGSN) and routes the initial NAS signaling message to the selected CN node.
If a CN node address configured for the NRI can be obtained from the initial NAS signaling
message, the NNSF routes the message to the CN node. If no CN node address is configured
for the obtained NRI or no NRI can be obtained (for example, the UE indicates an identity
corresponding to a UE contains no NRI), the NNSF selects an available CN node based on
load balancing and routes the message to the selected CN node.
Processing of the IMSI Paging Message (CS Domain)

To increase the success rate of sending the paging response message to the CN node that
initiates the paging request, the RNC capable of the MOCN or the Iu Flex needs to process
the IMSI paging message as follows:
If the paging message delivered by the CN contains the IMSI not the TMSI, the IMSI
paging message must contain the Global-CN-ID. Otherwise, the RNC fills in a Global
CN-ID as configured.
The NNSF in the RNC temporarily stores the mapping between the IMSI and the
Global-CN-ID upon reception of the paging response message. When the NNSF receives
the Initial Direct Transfer message (a paging response with an IMSI), it directly forwards
the paging response to the CN node identified by this Global-CN-ID. If the MSC or
Visitor Location Register (VLR) triggers the paging over the Gs interface, the SGSN
needs to add the MSC/VLR-ID to the paging message.

2017-8-11 Page 23 of 94
name.
No matter whether the IMSI or TMSI is contained in the paging request message that the CN sends to
page a UE, the UE responds with a paging response message containing the TMSI. The RNC determines
the CN node that the UE can access according to the NRI carried in the TMSI paging response message.
Processing of the IMSI Paging Message (PS Domain)

When the RNC responds to the IMSI paging message received from the PS domain, the RNC
does not store the Global-CN-ID.
Based on 3GPP TS 23.236, a UE returns an Attach Request message containing the IMSI
parameter as a response to the PS IMSI paging. In addition, the SGSN does not start the timer
when waiting for the PS IMSI paging response after sending the message. Therefore, the
NNSF in the RNC does not need to store the SGSN ID upon the reception of the paging
request. This means that the NNSF in the RNC selects an available SGSN when it receives an
Attach Request containing the IMSI parameter.
For details about the concepts, see the Iu Flex Feature Parameter Description.
3.2.2 Requirements of MOCN on the CN

The MOCN requires that:
Each operator has an independent CN.
The MOCN requires that operators have their own CNs.
The TMSIs or P-TMSIs assigned to UEs contain an NRI.
The TMSIs or P-TMSIs that the CN assigns to UEs must contain NRIs, which describe
the CN node information.
NRIs are allocated consistently on a network.
If the NRIs overlap, UEs are not routed to correct CNs, prolonging the network
connection time. To avoid this problem, NRIs need to be allocated consistently on a
network, that is, NRIs allocated by operators must be unique.
The Direct Transfer message can be retransmitted over the Iu interface.
In MOCN scenarios, each operator has an independent CN. A CN must identify the
Redirect Attempt Flag carried in the Initial Direct Transfer message delivered by the
RNC and determine whether to admit a UE according to information such as PLMN and
Location Area Code (LAC). If the CN admits the UE, the CN adds the Redirect
Completed information element (IE) to the Direct Transfer message returned to the RNC.
If the CN rejects the UE, the CN adds the Redirection Indication IE and relevant cause
value, such as "PLMN not allowed" and "CS/PS coordination required", to the Direct
Transfer message. For details, see 3GPP TS 25.413.
Currently, Huawei RNC carries the Redirect Attempt Flag only in Initial Direct Transfer
messages for registration, location update, and system reselection not service-type Direct
Transfer messages.
Common PLMNs are supported.
Non-supporting UEs can read only common PLMNs (see section 4.2.3 "Coexistence of
Full and Partial Coverage for Different Operators" and section 4.2.4 "Coexistence of Iu
Flex and RAN Sharing") and fill them in the Initial Direct Transfer messages. In this way,
the initial UE messages that the RNC transmits to the CN carry common PLMNs.
Therefore, common PLMNs must be carried in the Direct Transfer message returned by
the CN.

2017-8-11 Page 24 of 94
name.
UEs regard that a location update fails and repeat the location update if the following
three types of PLMNs are inconsistent:
PLMNs of the RNC broadcast information decoded by the UE
PLMNs carried in the location area identity (LAI) and service area identifier (SAI) of
the Initial UE message (namely location registration request) that the RNC transmits
to the CN
PLMNs carried in the LAI and SAI of the location registration reception message that
the CN transmits to UEs
Independent CNs indicate independent signaling points and PLMNs.
3.2.3 Difference Between Supporting UEs and Non-Supporting

UEs
The MOCN feature has two types of UEs.
Supporting UEs: UEs that support MOCN. The supporting UEs are compatible with
3GPP R6 or later. On the MOCN-based network, the RNC broadcasts the PLMN
information (namely the Multiple-PLMN List IE in the master information block (MIB))
about multiple operators in the system information. Supporting UEs can decode the
PLMN information and notify the selected PLMN to the RNC over the Initial Direct
Transfer message. Then, the UE routes the PLMN to the correct CN.
Non-supporting UEs: UEs that do not support MOCN. Most UEs with the version earlier
than 3GPP R6 are non-supporting UEs. The non-supporting UEs cannot decode the
PLMN information of multiple operators in the system but can read the common PLMN
ID and use it as their own PLMN. Non-supporting UEs do not add the selected PLMNs
in the Initial Direct Transfer message.
For details about the process in which the RNC selects a CN for non-supporting UEs, see
section 3.2.5 "Initial NAS Message Routing."
Table 3-2 lists some supporting UEs and non-supporting UEs.
Table 3-2 Supporting UEs and non-supporting UEs
Brand Supporting UE Non-Supporting UE

Huawei U8820 Other models of Huawei
(Mobile) products
U8800
U9000
Nokia N8
iPhone IPhone4 IPhone3
BlackBerry BlackBerry 9800 BlackBerry 9000
Qualcomm 9200
Huawei (Data E372 E176 and other models
Card)
E182E

2017-8-11 Page 25 of 94
name.
3.2.4 System Information Broadcasting

The PLMN identity (Common PLMN ID), MIB PLMN identity, and Multiple PLMN ID
LIST fields must be set in the MIB in the MOCN cell. The Common PLMN ID and
Multiple-PLMN LIST field values are available in the cell configuration information.
If the value of MIB PLMN identity is set to True, the supporting UE selects the PLMN
identity (Common PLMN ID) as a candidate PLMN.
If the value of MIB PLMN identity is set to False, the supporting UE (3GPP R6 or later
and supporting MOCN) selects the PLMN only from the Multiple PLMN ID LIST.
A non-supporting UE can read only the Common PLMN ID and regard the common PLMN
as its own PLMN.
An example of MIB information is as follows:
Master Information Block
{
PLMN identity --- Common PLMN ID
Multiple PLMN List
{
MIB PLMN identity --- indicates whether the common PLMN ID is an option
of Multiple PLMN ID List.
Multiple PLMNs --- PLMN List
{
OperA PLMN
OperB PLMN --- read by supporting UEs
OperC PLMN

}
}

}
3.2.5 Initial NAS Message Routing

A supporting UE selects its home PLMN and instructs the RNC to select the same PLMN.
According to the UE instruction, the RNC routes the NAS message to the correct CN node.
A non-supporting UE does not specify the selected PLMN-id. Therefore, the RNC needs to
select a proper route instead.
If the IMSI or TMSI (P-TMSI) is available for the RNC, the RNC first obtains the PLMN-id
from the IMSI. Then, the RNC routes the UE to the HPLMN according to the PLMN-id or
routes the UE to the relevant CN according to the NRI value of the TMSI (P-TMSI).
If the IMSI or TMSI (P-TMSI) is unavailable for the RNC or the NRI obtained from the
TMSI (P-TMSI) is invalid, the RNC selects the CN node of the primary operator as
configured or selects a CN node of each operator according to the round robin algorithm. Try
all CN nodes according to the cell PLMN lists by using the Redirect mechanism until a proper
CN node is selected.
After redirection, the MSC or SGSN serving the UE allocates an NRI that is carried in the
TMSI or P-TMSI to the UE. Next time the UE accesses the CN, the RNC routes the UE to the
correct CN according to the NRI value. When Iu Flex is used, multiple SGSNs or MSC
servers of one operator connect to an RNC.

2017-8-11 Page 26 of 94
name.
If Iu Flex is not used, there is only one CN node for the operator in each domain.
Therefore, the initial NAS message is directly routed to this CN node according to the
CN domain.
If Iu Flex is used, the NNSF procedure is performed to select a specific CN node from
the CN nodes of the operator.
Regardless of whether MOCN is adopted, a CN node such as MSC server and SGSN belongs to only
one operator.
Network Selection Process of Non-Supporting UEs
Figure 3-8 Network selection process of non-supporting roaming UEs
UE RNC MSC A MSC B MSC C HLR
RRC Connection Establishment
Initial Direct Transfer

1. Initial UE(Attach request,redirect attempt flag)
Roaming not allowed for HPLMN of IMSI /

Roaming allowed but CS/PS coordination required
2.Reroute Command
3. Initial UE(Attach request,redirect attempt flag,IMSI,...)
4.Authentication & Ciphering

5.Update Location /
Insert Subscr. Data
Roaming not allowed for

HPLMN of IMSI
6.Reroute Command
7. Initial UE(Attach request,redirect attempt flag,IMSI,...)
8.Authentication & Ciphering

Update Loc./ Cancel Loc./
Insert Subscr. Data
9.Reroute Complete ( Attach accept, )

Direct Transfer (Attach accept)
Attach Complete
The network selection process of non-supporting UEs is as follows:

1. The RNC sends the Initial UE message carrying the Redirect Attempt Flag to MSC A.
2. A CS/PS coordination check is not performed during the location update initiated
according to the IMSI. For the location update initiated according to the TMSI, if the
VLR does not contain the TMSI, MSC A sends the Reroute Command message as an
extension of the Direct Transfer message to the RNC. Then, the service process of MSC
A ends. The Reroute Command message carries the NAS protocol data unit (PDU) IE,
CS/PS Coordination required IE, and IMSI contained in the Initial UE message.
3. The RNC sends the new Initial UE message carrying the new Redirect Attempt Flag and
IMSI to MSC B, which indicates that the CS/PS coordination check is complete.

2017-8-11 Page 27 of 94
name.
4. MSC B authenticates and encrypts the UE.

5. MSC B obtains the subscriber data from the home location register (HLR).
6. If roaming is not allowed, MSC B sends the Reroute Command message carrying the
new Reject Cause IE to the RNC. The value of this IE is the same as that indicated in the
location update rejection message.
7. The RNC sends the Initial UE message carrying the Redirect Attempt Flag and IMSI to
MSC C, which indicates that the CS/PS coordination check is complete.
8. Upon receiving the Initial UE message, MSC C authenticates and encrypts the UE and
then obtains the subscriber data from the HLR.
9. If UE roaming is allowed, MSC C delivers the Direct Transfer message containing the
Location Update Accept message and Reroute Complete message.
Network Selection Process of Supporting UEs
Figure 3-9 Network selection process of supporting UEs
Supporting
MSC A MSC B RNC UE
1.System information
2.UE decodes network sharing

information in system broadcast
information
3.Network selection
4.Location Update Request RNC uses information in header to

route the ATTACH REQUEST to
the chosen core network operator
5.CN node determines whether the
UE is allowed to attach
6.Location Update Accept/Reject
The network selection process of supporting UEs is as follows:

1. The supporting UE decodes the system broadcast information (system information) of
RAN sharing. The RNC broadcasts the PLMN IDs of operators by using the system
information so that the UE selects a PLMN.
2. The supporting UE decodes the PLMN ID list in the system information.
3. The supporting UE selects a home PLMN ID in the PLMN ID list to initiate a location
update.
4. According to the configuration, the RNC sends the Location Update Request to MSC A.
5. The CN determines whether to admit the UE.

2017-8-11 Page 28 of 94
name.
6. If UE roaming is allowed, MSC B delivers the Location Update Accept message to the
UE. If UE roaming is not allowed, MSC B delivers the Location Update Reject message
to the UE.
3.2.6 Operator CBS Deployment

In MOCN scenarios, operators must deploy the CBS jointly. One cell corresponds to only one
CBS SA, and the operator broadcasts messages in the joint CBS SA.
3.2.7 Operator Shared Features

In MOCN scenarios, operators share cells and therefore they provide the same features.
3.2.8 Operator Types

In MOCN scenarios, there are two types of operators, primary operator and secondary
operator, in MOCN scenarios. A primary operator takes precedence over a secondary operator
in authority management. The primary operator can be anyone, for example, a third party in
charge of the shared RAN or an operator in possession of physical RAN equipment.
When adding an operator to the RNC, OperatorType must be used to check whether the
operator is a primary one or a secondary one. The primary operator must be specified in an
RNC. An RNC cannot be configured with more than four operators (ranging from 0 to 3). The
primary and secondary operators must be real.
In addition, the following two types of operators are required for commercial use:
Outer operator: In mobility management, UEs need to be handed over from the operator
of the source RNC to the operator of the destination RNC. If the destination operator is
not in the list of primary and secondary operators of the source RNC, it is defined as an
outer operator (ranging from 5 to 31).
Common operator: Operators serving non-supporting UEs are defined as common
operators. The PLMN-ID is notified to UEs on a shared network the same as that on a
traditional network. It is equivalent to serving operator for non-supporting UEs on the
shared network and ranges from 5 to 31
3.2.9 CS/PS Coordination

After the MOCN is introduced, a roaming non-supporting UE may register with the CS
domain of one operator but with the PS domain of another operator. For example, the CNs of
two operators admit non-supporting roaming UEs. The PS domain triggers registration only
after the CS domain registers successfully on the CN of one operator. As a result, CS and PS
domains may belong to CNs of different operators. CS/PS coordination is used in the MOCN
to solve the problem.
Registration Phase
1. If the Gs interface exists between the CS domain and the PS domain of a CN, the
registration information in the CS domain is forwarded by the PS domain. Therefore, the
CN ensures CS/PS coordination.
2. If the Gs interface does not exist, the RNC ensures CS/PS coordination.
When the CN detects that the CS and PS domains register on different operators, the CN
carries "Redirection Indication" in the downlink Direct Transfer message with the cause value
"CS/PS coordination required". In addition, the CN sends the IMSI to the RNC and requests
for ensuring CS/PS coordination. Upon receiving the cause value "CS/PS coordination

2017-8-11 Page 29 of 94
name.
required", the RNC checks the IMSI. If the IMSI belongs to the primary or secondary operator,
the RNC forwards a Direct Transfer message to the relevant CN. If the IMSI does not belong
to the primary or secondary operator, the RNC sends an Initial Direct Transfer message
carrying the Permanent NAS UE Identity IE (namely, IMSI) and NAS Sequence Number IE
again back to the CN to retry CS/PS coordination.
Existing application cases show that sites with the Gs interface are rare in the commercial network.
Generally, the RNC instead of the CN ensures CS/PS coordination.
Due to different understanding and implementation methods on protocols, the CNs of

different operators perform CS/PS coordination under different conditions.
Huawei CN performs CS/PS coordination under the following conditions:
The RNC adds the Redirect flag to the Initial UE message but this message carries only
the TMSI or P-TMSI. If the TMSI or P-TMSI does not exist in the VLR, the CN
originates a CS/PS coordination check.
If the IMSI, TMSI, or P-TMSI is carried in the Initial UE message and exists in the VLR,
the CN does not originate a CS/PS coordination check.
Service Operation Phase

In the previous scenario, the RNC retransmits the registration information only to the CN of
an operator once. If the roaming UE reaches a roaming agreement with both operators, CS/PS
coordination cannot be ensured. If CS/PS coordination at the registration phase is mandatory,
the RNC must save the UE registration information of one domain. When the other domain
originates CS/PS coordination, the RNC forwards the UE registration information to the
operator where the previous domain exists. However, a large amount of information needs to
be stored on the RNC, which requires great additional cost.
If the CS domain and PS domain of roaming UEs register separately on two operators, single
CS services or single PS services are not affected. However, if CS and PS combined services
are used, CS domain and PS domain of UEs must belong to one operator. As a result, the
services may be affected. Currently, the RNC solves the problem as follows:
If a domain of a roaming UE has already been providing services and the other domain
originates a service request, the RNC directly routes the request to the other domain of the
same operator without carrying the Redirect flag. Therefore, the CN does not perform a check
on the CS/PS coordination but rejects the service request after confirming that no registration
information exists in the current operator. After being rejected, the UE triggers another
registration. The previous domain is in connected mode (the Iu interface is connected).
Therefore, the UE directly requests a registration on the operator to which the previous
domain belongs. Upon the registration success, services on the other domain can be
provisioned normally.
If a default operator is configured on the RNC, CS/PS coordination cannot be ensured because
CS and PS domains of non-supporting roaming UEs will register on the operator by default.
The previous CS/PS coordination targets at non-supporting roaming UEs. For non-supporting
non-roaming UEs, CS and PS domains will not register on two operators. As specified in 3GPP
protocols, supporting roaming UEs ensure CS/PS coordination.
3.2.10 Routing Roaming UEs in Proportion

In versions earlier than RAN13.0, routes are selected at random for non-supporting roaming
UEs to achieve load balancing among operators.

2017-8-11 Page 30 of 94
name.
Routing roaming UEs in proportion is a new feature added in RAN13.0. The RNC routes
non-supporting roaming UEs by predefined proportion and ensure that the number of roaming
UEs routed to different operators conforms to the proportion. This feature ensures
MOCN-enabled operators to benefit from roaming UEs (roaming fees) by predefined
proportion in the shared network.
This feature does not conflict with the default operator. That is, if a default operator is
configured, the RNC still distributes roaming UEs among operators by proportion.
3.2.11 MOCN Cell Resource Demarcation

In MOCN networking scenarios, the MOCN Cell Resource Demarcation feature
(corresponding to feature WRFD-140223 MOCN Cell Resource Demarcation) introduced in
RAN14.0 prevents UEs of an operator from occupying excessive cell resources. This ensures
fairness to each operator in using shared cell resources. With this feature, the percentage of
cell resources available for each operator in a shared MOCN cell is configurable. The
predefined cell resources are downlink spreading codes (SCs) assigned for R99 UEs (DL R99
SCs for short) and HSDPA power resources.
When cell resources are sufficient, the RNC admits UEs without differentiating between
operators. UEs of any operator can use more resources than the predefined resource
percentage. When a UE cannot be admitted due to insufficient cell resources, the RNC
determines whether to trigger preemption based on the actual percentage of resources being
used by each operator. When congestion triggered by insufficient DL R99 SCs occurs in the
cell, the RNC preferentially performs congestion control on R99 UEs whose serving operator
exceeds its predefined percentage of DL R99 SCs the most. For details, see section 5.6.
The detailed introduce please refer to Product Feature Documentation.
3.2.12 MOCN Mobility Management

MOCN features many affecting factors and complex scenarios.
Assume that OpA, OpB, and OpC construct the MOCN together. OpA is the primary operator.
The three operators have respective PLMNs and another PLMN is used as the common
PLMN. Huawei MOCN supports a maximum of four operators. Three operators, however, are
used in the following example to simplify the description.
Handover Management
When UEs are connected, handover execution depends on the measurement control messages
delivered by the RNC and the UE measurement result.
1. Handovers between MOCN cells (intra-operator)
This type of handovers requires that the RNC determine the operator attributes of
neighboring cells before delivering measurement control messages. Only the information
about neighboring cells contains the operator to which the UE belongs can be delivered
to the UE through the measurement control message. In this case, the UE can be handed
over to the correct neighboring cell. Handovers between intra-operator MOCN cells are
classified into intra-frequency handovers and inter-frequency handovers. The handover
can be triggered by factors such as coverage, load, and QoS, as shown in Figure 3-10:

2017-8-11 Page 31 of 94
name.
Figure 3-10 Handovers between MOCN cells (intra-operator)
At the radio resource control (RRC) phase, the RNC cannot confirm the PLMN that the
UE accesses. In this case, the RNC performs the handover first before confirming the
PLMN to prevent call drop. Then, the RNC delivers the information about all
neighboring cells to the UE through the measurement control message. After the new cell
admits the UE, the RNC determines the PLMN for admitting the UE before sending the
Initial Direct Transfer message, which is the same as the process in which the original
cell directly admits the UE.
2. Handovers between MOCN cells and private cells (intra-operator)
Neighboring cells of MOCN cells are private cells of an operator. The RNC delivers
measurement control messages by operator attributes. Only the UEs that belong to this
operator (for example, OpA in Figure 3-11) can be handed over.
Figure 3-11 Handovers between MOCN cells and private cells (intra-operator)
The MOCN cell on F1 is adjacent to the private cell of OpA. UE handovers are not
allowed between OpB and OpC. Therefore, intra-frequency interference occurs on UEs
of both OpB and OpC. This problem often occurs on a radio network where MOCN cells
are mixed with private cells. To solve the problem, refer to the following methods:
Isolate the MOCN cells from the private intra-frequency cells during network
planning.
Locate the border between an MOCN cell and an intra-frequency private cell in an
area with low traffic and few UEs to reduce interference.
Add inter-frequency or inter-RAT neighboring cells for an MOCN cell and enable the
coverage-based handover to hand over interfered UEs.

2017-8-11 Page 32 of 94
name.
Enable the uplink QoS-based handover on the RNC to hand over the UEs with poor
uplink signal quality out of the border cell. However, the switch and threshold are of
RNC-level, which affect other cells.
3. Handovers between MOCN cells and 2G cells (intra-operator)
Neighboring 2G cells of 3G MOCN cells belong to one operator. The RNC delivers
measurement control messages by operator attributes. Only the UEs that belong to this
operator can be handed over. If the 2G-to-3G handover function is enabled, the UEs can
also be handed over to 3G MOCN cells (for example, OpB in Figure 3-12).
Figure 3-12 Handovers between MOCN cells and 2G cells (intra-operator)
4. Inter-operator handovers
In 3G MOCN, the inter-operator handover must be enabled in special application
scenarios. Intra-RAT inter-operator handovers and inter-RAT inter-operator handovers
can be controlled on the RNC. If they are enabled, the RNC does not filter the
neighboring cells of an operator when delivering a measurement control message to UEs
of the operator but deliver the message to all neighboring cells. In this case, the UE may
be handed over to a cell of another operator (for example, OpB in Figure 3-13).
Figure 3-13 Inter-operator handovers
Currently, sites support inter-RAT inter-operator handovers but do not support intra-RAT
inter-operator handovers. Network sharing is implemented at such sites by using 3G
MOCN + 2G roaming. For example, in the TMV shared network of country T, UE 00
needs to be handed over from the MOCN cell to the GSM R99 cell. For details, see
section 5.2.3 "Coexistence of the MOCN RNC and Dedicated RNC."
5. Inter-RNC handovers
Same as the inter-RNC handovers in common scenarios, the inter-RNC handovers in
MOCN scenarios also require the neighboring combination switch.
If the neighboring combination switch for serving radio network controller (SRNC) is
turned off:

2017-8-11 Page 33 of 94
name.
When the optimum cell is in the SRNC, only the neighboring cells that the SRNC
configures in the optimum cell will be added to the neighboring cell set of the UE.
The neighboring cell set includes intra-frequency, inter-frequency, and inter-RAT
neighboring cells.
When the optimum cell is in the drift RNC (DRNC), only the neighboring cells that
the DRNC configures in the optimum cell will be added to the neighboring cell set of
the UE. The neighboring cell set includes intra-frequency, inter-frequency, and
inter-RAT neighboring cells.
If the neighboring combination switch for SRNC is turned on:
No matter whether the optimum cell is in the SRNC or DRNC, the target neighboring
cells configured in the SRNC and DRNC will be added to the neighboring cell set of
the UE.
Currently, the neighboring cell switch is turned on by default.
The operators to which target neighboring cells belong must also be considered in
inter-RNC handovers in MOCN scenarios. The Multiple PLMN List IE is added to
the Neighboring FDD Cell Information IE of the inter-RNC Radio Link Setup
Response message specified in 3GPP R7 or later. The Multiple PLMN List IE
informs the SRNC of the operator to which neighboring cells belong.
If inter-operator handover is disabled, the information about neighboring cells will be
delivered to the UE through the measurement control message only when the
information contains the operator to which the UE belongs. The PLMN information
delivered by the DRNC prevails even if neighboring cells have already been
configured in the SRNC.
Figure 3-14 shows the intra-operator inter-RNC handover.
Figure 3-14 Inter-RNC handover
Operator
information about
neighboring cells
6. Relocation
Relocation in MOCN scenarios is the same as relocation in common scenarios.
Relocation includes static relocation, hard handover-triggered relocation, and
cell/UTRAN registration area (URA) update-triggered relocation. The difference lies in
that operators to be selected must be specified for relocation in MOCN scenarios.
After determining the CN operator of the destination network based on the available
access information, current PLMN, or similar information in a node of the shared

2017-8-11 Page 34 of 94
name.
network during relocation, the SRNC informs the destination network of the selected CN
operator. The SRNC fills in the PLMN ID of the selected operator in Target RNC ID of
the Relocation Required message. In this way, the CN does not need to select the PLMN.
In static relocation, the target RNC (TRNC) notifies the UE of the PLMN of the new cell
by sending a Utran Mobility Information message, in which the PLMN identity is set to
the common PLMN and the primary PLMN identity to the PLMN of the selected
operator. Non-supporting UEs obtain the new PLMN ID based on the PLMN identity,
whereas supporting UEs obtain the new PLMN ID based on the primary PLMN identity.
In hard handover-triggered relocation, the SRNC notifies the UE of the PLMN identity
and primary PLMN identity by sending a Radio Bear Reconfiguration message, in which
the PLMN identity is set to the common PLMN and the primary PLMN identity to the
PLMN of the selected operator.
In cell/URA update-triggered relocation, the TRNC notifies the UE of the PLMN
identity and primary PLMN identity by sending a Cell Update Confirm message, in
which the PLMN identity is set to the common PLMN and the primary PLMN identity to
the PLMN of the selected operator.
If the SRNC cannot confirm the operator to which the UE will be relocated, the SRNC
sets the PLMN in Target RNC ID of the Relocation Required message to the common
PLMN. The source CN selects a CN, and the target CN sends the selected PLMN in the
Relocation Request message to the TRNC.
7. Cell/URA update
The cell/URA update in MOCN scenarios is the same as that in common scenarios.
After receiving a location update request, the RNC checks the PLMN ID list contained in
the target cell. If the list contains the PLMN that the UE connects to, the RNC allows the
cell/URA update. Otherwise, the RNC determines whether to enable inter-PLMN
handovers. If the switch is turned on, the RNC allows the cell/URA update; if not, the
RNC does not allow the cell/URA update.
Cell Reselection
Cell reselection is a proactive behavior of UEs. It is free from the control by the network but
affected by network parameters.
Cell reselection in MOCN scenarios is more complicated than that in common scenarios,
because non-supporting UEs and supporting UEs have different understandings on the PLMN
and cell reselection is affected by the mixing of MOCN cells, private cells, and 2G cells. The
following details the difference between cell reselection in MOCN scenarios and cell
reselection in common scenarios.
1. Reselections between MOCN cells
If adjacent MOCN cells are served by the same operator, non-supporting UEs and
supporting UEs of all operators can perform cell reselection like that in a common
scenario.

2017-8-11 Page 35 of 94
name.
Figure 3-15 Reselections between MOCN cells (intra-operator)
If adjacent MOCN cells are served by different operators, cell reselection is more
complicated. As shown in Figure 3-16, when cell 3 is not served by OpC, UEs of OpC
will not be reselected to cell 3.
Figure 3-16 Reselections between MOCN cells (inter-operator)
However, cell reselections are different for non-supporting UEs and supporting UEs,
which is described as follows:
Non-supporting UEs
Cell 1 and cell 2 are configured with the same common PLMN, and cell 2 and cell 3
are configured with different common PLMNs. In this way, non-supporting UEs of
OpC do not regard cell 3 to be served by the same operator and therefore will not be
reselected to the cell. Cell 2 and cell 3 can be configured with the same LAC. In this
way, UEs of OpA and OpB can move randomly, without affecting the non-supporting
UEs of OpC. OpA CN and OpB CN need to configure the common PLMNs of cell 2
and cell 3 as mutual EPLMNs and deliver the EPLMNs to UEs of OpA and OpB
through the location update message.
In addition, common PLMNs of cell 2 and cell 3 correspond to logos of OpA and
OpB.
Supporting UEs
A supporting UE of OpC does not read its own PLMN from cell 3. Therefore, the
supporting UE will not be reselected to cell 3.
2. Reselections between MOCN cells and private cells
If an MOCN cell is adjacent to a private cell, UEs of non-private cells cannot be
reselected to the private cell. As shown in Figure 3-17, both non-supporting UEs and
supporting UEs of OpB and OpC cannot find the HPLMNs from cell 2 and cell 3.
Therefore, the UEs will not be reselected to the cells.

2017-8-11 Page 36 of 94
name.
Figure 3-17 Reselections between MOCN cells and private cells
Cell reselections are different for non-supporting UEs and supporting UEs of OpA,
which is described as follows:
Non-supporting UEs
A non-supporting UE of OpA can only read the common PLMN from an MOCN cell
(for example, cell 1) and read the HPLMN of OpA from a private cell (for example,
cell 2 or cell 3). Therefore, during the reselection from an MOCN cell to a private cell,
the UE first camps on an MOCN cell (RPLMN is preferred). When no MOCN cell is
available, the UE will be reselected to its own private cell using periodic HPLMN
reselection.
The HPLMN reselection period is the multiples of six minutes, ranging from six minutes to eight hours.
The period is written into the SIM card. If the period is not written, it is 60 minutes by default.
During the reselection from a private cell to an MOCN cell, the UE first camps on the
private cell, not the MOCN cell. To speed up the reselection, the OpA CN needs to
set the common PLMN to the EPLMN of the HPLMN in the private cell. In this way,
the UE regards the MOCN cell as a cell in the EPLMN.
The CN delivers the EPLMN to the UE in the location update message. The EPLMN is configured
according to the LAC and IMSI. The EPLMN is updated each time the UE performs a location update.
CS and PS domain of the core network needs configure the same EPLMN, otherwise the last location
area or routing area updated EPLMN list overwrites the previous one.
Supporting UEs
A supporting UE of OpA reads the HPLMN of the operator from both an MOCN cell
and a private cell. Therefore, the reselection is the same as a common reselection,
which does not require special configurations and is not affected by the
configurations of the previous non-supporting UEs.
3. Reselections between MOCN cells and 2G cells
If an MOCN cell is adjacent to a 2G cell, UEs of non-2G cells cannot be reselected to the
2G cell. As shown in Figure 3-18, both non-supporting UEs and supporting UEs of OpB
and OpC cannot find HPLMNs from cell 4. Therefore, the UEs will not be reselected to
the cell.

2017-8-11 Page 37 of 94
name.
Figure 3-18 Reselection between an MOCN cell and a 2G cell
Like a private cell, cell reselections are different for non-supporting UEs and supporting
UEs of OpA, which are described as follows:
Non-supporting UEs
A non-supporting UE of OpA can only read the common PLMN from an MOCN cell
(for example, cell 1) and read the HPLMN of OpA from a 2G cell (for example, cell
4). Therefore, during the reselection from an MOCN cell to a 2G cell, the UE camps
on its own 2G cell using the periodic HPLMN reselection.
During the reselection from a 2G cell to an MOCN cell, the UE first camps on the
private cell, not the MOCN cell because the RPLMN is preferred. To speed up the
reselection, the OpA CN needs to set the common PLMN to the EPLMN of the
HPLMN in the 2G cell. In this way, the UE regards the MOCN cell as a cell in the
EPLMN.
The 2G network provides seamless coverage. Therefore, this scenario is common.
However, the previous configurations may result in ping-pong reselections of a
non-supporting UE between a 2G cell and a 3G cell. That is, the UE will be
reselected from the 3G cell to the 2G cell based on the HPLMN reselection period
and then reselected back from the 2G cell to the 3G cell based on the EPLMN and 3G
network. Use the following methods to solve the problem:
Set the common PLMN as the EHPLMN of the HPLMN and write the common
PLMN into the SIM card (EFEHPLMN) of OpA. As a result, UEs of OpA will be
reselected to the common PLMN (namely the 3G MOCN cell) during each
HPLMN reselection.
Prolong the HPLMN reselection period in the SIM card to avoid ping-pong
reselection.
However, these operations require that relevant information be written in the SIM
card before sales, which is difficult to implement on commercial networks. For
details, contact operators.
Supporting UEs
A supporting UE of OpA reads the HPLMN of the operator from both an MOCN cell
and a 2G cell. Therefore, the reselection is the same as a common inter-RAT
reselection, which does not require special configurations and is not affected by the
configurations of the previous non-supporting UEs.
The reselection between an MOCN cell and a OpA 2G cell is the same as the
reselection between an MOCN cell and a OpB/OpC 2G cell.
4. Reselections between MOCN cells and 2G roaming cells
When roaming is enabled on 2G cells, reselections between MOCN cells and 2G
roaming cells are more complicated than reselections between MOCN cells and 2G cells.
For example, in the offices of country T and country PH, operators use 2G roaming + 3G
MOCN to implement network sharing. Figure 3-19 shows that the OpA GSM allows

2017-8-11 Page 38 of 94
name.
UEs of OpB and OpC to roam in certain areas, such as LAC 5 and cell 5. OpA CN
configures roaming in different areas and determines whether to allow roaming UEs of
other operators according to different LACs.
Figure 3-19 Reselection between an MOCN cell and a 2G roaming cell
(Roaming not allowed)
(Roaming allowed)
Reselection between an MOCN cell and a 2G roaming cell does not affect the operator
serving roaming UEs, such as OpA, but affects the UEs of roaming operators, such as
OpB and OpC. Cell reselections are different for non-supporting UEs and supporting
UEs, which is described as follows:
Non-Supporting UEs
Reselection from an MOCN cell to a 2G roaming cell
Non-supporting UEs of OpB and OpC can only read the common PLMN from an
MOCN cell (for example, cell 1). A 2G cell (for example, cell 5) of OpA
broadcasts the PLMN of OpA, which will not be selected by UEs of OpB and
OpC. Therefore, OpB CN and OpC CN need to configure the PLMN of OpA as
the EPLMN of the common PLMN in the MOCN cell and deliver the EPLMN to
UEs of OpB and OpC through the location update message. In this way, UEs of
OpB and OpC regard the 2G cell of OpA as a cell in the EPLMN and are
reselected to the 2G cell where roaming is permitted. The reselection is the same
as a common inter-RAT reselection.
However, a private 3G cell (cell 3) or a 2G cell (cell 4) of OpA where roaming is
forbidden exists near the MOCN cell (cell 1). The PLMNs broadcast by cell 3 and
cell 4 are the same as that broadcast by cell 5. According to the preceding
configurations, UEs of OpB and OpC try to connect to cell 3 and cell 5 but are
rejected by OpA CN. To ensure that UEs roam in 2G cells of OpA, the rejection
cause value is of less severity, for example, "No Suitable Cell in LA." In this way,
UEs do not attempt to be reselected to the cell of the LAC after the rejection but
attempt to be reselected to other LACs of OpA.
Reselection from a 2G roaming cell to an MOCN cell
During the reselection from a 2G roaming cell of OpA to an MOCN cell,
non-supporting UEs of OpB and OpC first camp on the private cell, not the
MOCN cell because the RPLMN is preferred. To speed up the reselection, the
OpA CN needs to configure the common PLMN as the EPLMN of the HPLMN in

2017-8-11 Page 39 of 94
name.
the 2G roaming cell and send the EPLMN to UEs of OpB and OpC (also UEs of
OpA in the preceding section) through the location update message. In this way,
the UE regards the MOCN cell as a cell in the EPLMN.
The NRI obtained by the UE belongs to OpA because the UE is reselected from
the cell of OpA. In this way, after the UE is reselected to the MOCN cell and
initiates the location update (registration), the RNC first routes the UE to OpA CN.
After being rejected, the UE re-attempts to be reselected to OpA CN. Several
attempts later, the UE may be reselected back to OpB CN or OpC CN, prolonging
the network connection time of the UE. Therefore, improvements are made in
RAN12.0, that is, the Redirect Attempt flag can be carried in inter-RAT
reselection. When the CN that the UE originally camps on rejects the UE, the UE
attempts to be reselected to its own CN, speeding up the reselection.
Supporting UEs
Reselection from an MOCN cell to a 2G roaming cell
Supporting UEs of OpB and OpC can read their own PLMNs (namely, HPLMNs)
from an MOCN cell (cell 1). A 2G cell of OpA (cell 5) broadcasts the PLMN of
OpA, which will not be selected by UEs of OpB and OpC. Therefore, OpB CN
and OpC CN need to configure the PLMN of OpA as the EPLMN of their own
HPLMN in the MOCN cell and deliver the EPLMN to UEs of OpB and OpC
through the location update message. In this way, UEs of OpB and OpC regard the
2G cell of OpA as a cell in the EPLMN and are reselected to the 2G cell that OpA
allows for roaming. The reselection is the same as a common inter-RAT
reselection.
Similarly, UEs may be reselected to a private 3G cell of OpA (cell 3) or a 2G cell
that does not allow roaming (cell 4). The rejection cause value is of less severity,
for example, "No Suitable Cell in LA."
Reselection from a 2G roaming cell to an MOCN cell
Supporting UEs of OpB and OpC can be reselected from the 2G roaming cell of
OpA to the MOCN cell by the following methods:
Method 1: OpA CN configures the PLMNs of OpB and OpC as the EPLMN of
the OpA PLMN in the 2G roaming cell and delivers the EPLMN to UEs of OpB
and OpC but not UEs of OpA through the location update message. In this way,
UEs of OpB and OpC regard the 2G roaming cell of OpA as a cell in the EPLMN.
However, supporting UEs of OpB and OpC can also read the PLMN of OpA in
the MOCN cell. Some UEs may attempt to be reselected to the PLMN of OpA
because OpA belongs to the RPLMN and are rejected. Then, the UEs attempt to
be reselected to the HPLMN, prolonging the UE reselection time.
The rejection cause value shall be of greater severity. In this way, the UE can be triggered to initiate the
PLMN reselection, for example, "Roaming not allowed in this location area." For details, see 3GPP TS
23.122.
Method 2: Supporting UEs of OpB and OpC can be reselected to the MOCN cell
using periodic HPLMN reselection.
3.2.13 Long-Term Evolution of HSPA+

Huawei MOCN supports the long-term evolution of HSPA+, such as 64QAM, MIMO,
UL16QAM, and DC-HSDPA. The features in MOCN scenarios are the same as that in
common scenarios.

2017-8-11 Page 40 of 94
name.
3.2.14 MOCN Independent CE Resource Allocation

The MOCN Independent CE Resource Allocation feature provides the following functions:
The M2000 allocates NodeB-level uplink and downlink CE resources by operator. The
M2000 allocates CE resources by configuring private and common groups
Private group: CE resources in a private group belong to only one operator.

Common group: CE resources in the common group can be shared by all operators.
After identifying a UE's operator, the NodeB allocates CE resources to the UE.
After dividing CE resources into groups and identifying a UE's serving operator, the
NodeB allocates the CE resources in this operator's private groups to the UE. If the CE
resources in the operator's private groups are used up, the CE resources in the common group
can be used. The CE resources in the common group are used on a first come, first served
basis.
The RNC relieves CE congestion for each operator separately, this feature introduces
operator-level congestion relief for uplink CE resources, including: BE service rate
reduction and Switching from 2 ms TTI to 10 ms TTI.
Benefits
This feature prevents a single operator from occupying excess CE resources in MOCN
scenarios and ensures that each operator retains independent CE resources.
This feature slightly decreases CE resource utilization. If CE resources are not properly
allocated (for example, if insufficient CE resources are allocated to an operator), this feature
brings some negative effects. The negative effects include access performance deterioration
(for example, a decrease in the RRC setup success rate and RAB setup success rate) and
HSUPA throughput decrease.
System Capacity
This feature has no impact on system capacity when the CE resources allocated to each
operator are sufficient.
If the resources are not properly allocated among operators, system capacity decreases. For
example, if a total of 100 CEs are equally allocated to operators A and B who require 60 and
40 CEs, respectively, only 90 CEs are utilized, with a 10% decrease in system capacity.
Network Performance
Before you deploy this feature, allocate CE resources to operators based on their traffic
requirements.
For example, allocate the CE resources equally if all operators have almost the same traffic
requirements.

2017-8-11 Page 41 of 94
name.
This feature has no impact on network performance when the CE resources allocated to each
operator are sufficient.
If the CE resources are not properly allocated among operators, network performance
deteriorates. For example, if a total of 100 CEs are equally allocated to operators A and B who
require 60 and 40 CEs, respectively, network performance deteriorates, with a 10% decrease
in resource utilization, cell HSUPA throughput, R99 PS throughput, and access success rate.
Related Features
Prerequisite Features: This feature requires the WRFD-021311 MOCN Introduction

Package feature.
Mutually Exclusive Features: This feature cannot be used with the WRFD-021304 RAN
Sharing Introduction Package feature.
3.2.15 MOCN Independent Iub Transmission Resource Allocation

The MOCN Independent Iub Transmission Resource Allocation feature allocates Iub
transmission resources to operators in MOCN scenarios, which prevents one operator from
occupying excess Iub transmission resources and ensures that each operator retains
independent Iub transmission resources.
Iub transmission resources are logically divided into user- and control-plane transmission
resources. In MOCN scenarios, this feature allocates user-plane bandwidth to each operator
independently and enables operators to share control-plane bandwidth and the common
channel bandwidth in a shared cell.
Figure 3-20 Allocating Iub bandwidth
To allocate user-plane bandwidth independently, the RNC is configured with multiple logical
ports, where each logical port corresponds to one operator. After identifying the UE's serving
operator, the RNC sends the UE's user-plane data to the corresponding logical port.

2017-8-11 Page 42 of 94
name.
This feature applies to the following scenarios: (including IP or ATM transmission)

Operators share one physical link over the Iub interface, as shown in Figure 3-21.
Figure 3-21 Sharing one physical link over the Iub interface
Each operator uses a dedicated physical link over the Iub interface, as shown in
Figure 3-22.
Figure 3-22 Using dedicated physical links over the Iub interface
This feature applies only to RNC downlink transmission resources, not to NodeB uplink
transmission resources.
Benefits
This feature allocates Iub transmission resources to operators in MOCN scenarios, which
prevents one operator from occupying excess Iub transmission resources and ensures that
each operator retains independent Iub transmission resources.
This feature slightly decreases Iub resource utilization. If Iub resources are not properly
allocated (for example, if insufficient Iub bandwidth is allocated to an operator), this feature
brings some negative effects. The negative effects include access performance deterioration
(for example, a decrease in the RRC setup success rate and RAB setup success rate) and
HSPA throughput decrease.

2017-8-11 Page 43 of 94
name.
System Capacity
This feature has no impact on system capacity when the Iub transmission resources allocated
to each operator are sufficient.
If the resources are not properly allocated among operators, system capacity decreases. For
example, if a total of 10 Mbit/s bandwidth is equally allocated to operators A and B who
require 6 Mbit/s and 4 Mbit/s, respectively, only 9 Mbit/s bandwidth is utilized, with a 10%
decrease in system capacity.
Network Performance
Before you deploy this feature, allocate Iub transmission resources to operators based on their
traffic requirements. For example, allocate the Iub transmission resources equally if all
operators have almost the same traffic requirements.
This feature has no impact on network performance when the Iub transmission resources
allocated to each operator are sufficient.
If the Iub transmission resources are not properly allocated among operators, network
performance deteriorates. For example, if a total of 10 Mbit/s bandwidth is equally allocated
to operators A and B who require 6 Mbit/s and 4 Mbit/s, respectively, resource utilization and
access success rate decrease by 10%. The throughput of a single HSDPA user decreases as
follows:
100% x (1 Minimum bandwidth allocated to an operator/Min(Bandwidth obtained before
service activation, Maximum bandwidth required by an UE)).
Related Features
Prerequisite Features: This feature requires the WRFD-021311 MOCN Introduction

Package feature.
Mutually Exclusive Features: This feature cannot be used with the feature WRFD-140208
Iub Transmission Resource Pool in RNC.

2017-8-11 Page 44 of 94
name.
4 RAN Sharing Service Design
4.1 Design Overview

This section describes the contents and methods of the RAN Sharing service design.
4.2 Typical Networking Modes of RAN Sharing

Typical networking modes of RAN Sharing include five typical application scenarios:
Coexistence of shared and non-shared RNCs under full coverage
Coexistence of the shared RNC and 2G network
Coexistence of full and partial coverage for different operators
Coexistence of Iu Flex and RAN Sharing
Coexistence of multiple operators
4.2.1 Coexistence of Shared and Non-Shared RNCs Under Full

Coverage
As shown in Figure 4-1, both operator A and operator B have deployed their own non-shared
3G networks in one area and decide to deploy a shared 3G network together in another area.
Shared RNC1 connects to shared RNC2, RNC A, and RNC B over the Iur interfaces. The
neighboring cell relationships are also configured. In this way, a UE of operator A is free to be
handed over from a cell of operator A to the neighboring cell of operator A. The same
situation applies to operator B. This scenario is applicable to an early stage of network rollout
when there is a small number of subscribers.

2017-8-11 Page 45 of 94
name.
Figure 4-1 Coexistence of shared and non-shared RNCs under full coverage
Operator A CN Operator B CN
RNC A
Iur
Shared Iur Shared

RNC B RNC1 RNC2
Iur
Operator A Cell Operator A Cell Operator A Cell Operator A Cell
Operator B Cell Operator B Cell Operator B Cell Operator B Cell
If an operator shares a carrier in some areas with another operator but does not share the
carrier in other areas, co-channel interference may occur. Figure 4-2 shows that operator B
shares F2 with operator A in some areas. Co-channel interference occurs in the border areas of
operator A and operator B (as shown in the dashed circle in Figure 4-2).
Figure 4-2 Coexistence of shared and dedicated RNCs (co-channel interference)
Use the following methods to solve the co-channel interference:

Reduce this kind of scenarios and isolate the intra-frequency inter-operator neighboring
cells during network planning.

2017-8-11 Page 46 of 94
name.
Deploy the borders of intra-frequency inter-operator cells in an area with low traffic and
fewer UEs to reduce interference.
Add inter-frequency or inter-RAT neighboring cells to intra-frequency inter-operator
cells and enable the coverage-based handover to hand over interfered UEs.
Enable the uplink QoS-based handover on the RNC to hand over the UEs with poor
uplink signal quality on intra-frequency inter-operator cells. However, the switch and
threshold are of RNC-level, which affect other cells.
4.2.2 Coexistence of the Shared RNC and 2G Network

As shown in Figure 4-3, both operator A and operator B have deployed a GSM network and
decide to deploy a shared 3G network. To fully use the GSM resources, the new RAN
network is required to interwork with the existing GSM network. Therefore, the neighboring
cells on shared RNC1, base station subsystem (BSS) A and BSS B are configured. Service
continuity is ensured when a UE of operator A transfers between the operator A UMTS cell
and the neighboring operator A GSM cell. The same situation applies to operator B.
Figure 4-3 Coexistence of the shared RNC and 2G network
Shared
BSS A BSS B
RNC1
Operator A Cell Operator A Cell Operator A Cell
Operator B Cell Operator B Cell Operator B Cell
There is a special scenario, that is, RAN Sharing is enabled on the shared 3G network, but
roaming is enabled on the 2G network for sharing. As shown in Figure 4-4, UEs of operator A
can roam to GSM cells of operator B. Therefore, in addition to the neighboring relationships
between the GSM cell of operator B and the MOCN cell, the neighboring relationships
between the GSM cell of operator A and the MOCN cell and the neighboring relationships
between GSM cells of operator A and operator B must be configured.
Handovers from a shared 3G cell of operator A to a GSM cell of operator B: The
inter-RAT inter-PLMN handover switch must be turned on.
Reselection from a shared 3G cell to a GSM cell of operator B: Configure the PLMN of
operator B to the EPLMN of operator A in the CN of operator A and deliver the EPLMN
to the shared 3G cell of operator A adjacent to the GSM cell of operator B. In this way,
UEs of operator A can be reselected to the GSM cell of operator as the EPLMN,

2017-8-11 Page 47 of 94
name.
speeding up the reselection. In addition, the shared 3G cell of operator A does not
configure the shared 3G cell of operator B as the neighboring cell. Therefore, UEs of
operator A do not attempt to be reselected to the shared 3G cell of operator B.
Reselection from a GSM cell to a shared 3G cell of operator A: The reselection relies on
the periodic HPLMN reselection of operator A, prolonging the reselection.
Figure 4-4 Coexistence of the shared RNC and roaming 2G network
4.2.3 Coexistence of Full and Partial Coverage for Different

Operators
As shown in Figure 4-5, operator A has already deployed a RAN network and has a full
coverage, whereas operator B only has partial coverage. Operator B must share the RAN
network with operator A in uncovered areas of operator B to achieve full coverage.
When a UE of operator B transfers from the edge of a cell under operator B's coverage to an
area under operator A's coverage, the UE can access the cell of operator A through handover,
cell reselection, or cell update. When the UE transfers back to an area covered by both
operators, the UE can also re-access operator B's network through Shared Network Area
(SNA) or International Mobile Subscriber Identity (IMSI)-based handover.
In this scenario, the switch of InterPlmnHoAllowedIntraRat must be enabled and the
neighboring cell relationships must be configured.

2017-8-11 Page 48 of 94
name.
Figure 4-5 Coexistence of full and partial coverage for different operators
Iur Shared
RNC A
RNC1
Operator A Cell Operator A Cell Operator A Cell Operator A Cell
Operator B Cell Operator B Cell
4.2.4 Coexistence of Iu Flex and RAN Sharing

As shown in Figure 4-6, operator A and operator B share the RAN. To improve the network
reliability, operator A applies Iu Flex to both the CS and the PS domains, and operator B
applies Iu Flex to the PS domain.
This scenario focuses on the interaction between the RAN Sharing feature and basic functions
of Iu Flex. For example, a shared RAN can properly process the Initial Direct Transfer
messages of UEs and the paging messages delivered by the CN.
Figure 4-6 Coexistence of Iu Flex and RAN Sharing
Operator A
MSC server 3
MSC server 2
MSC server 1
MGW 4 SGSN 2
MGW 3 SGSN 1
MGW 2
MGW 1
Operator B
MGW MSC server
SGSN 1
Shared SGSN 2
RNC SGSN 3
Operator A Cell Operator A Cell
Operator B Cell Operator B Cell

2017-8-11 Page 49 of 94
name.
4.2.5 Coexistence of Multiple Operators

As shown in Figure 4-7, operator A and operator B share a RAN, and operator C has a
roaming agreement with operator B. This agreement allows all the UEs of operator B and
operator C to share the network resources.
To achieve roaming (such as handover and cell reselection) between the cells of operator B
and operator C, the switch of InterPlmnHoAllowedIntraRat must be enabled and the
neighboring cell relationships must be configured.
Figure 4-7 Coexistence of multiple operators
Operator C CN Operator A CN Operator B CN
Shared Iur Shared

RNC C
RNC1 RNC2
Operator A Cell Operator A Cell Operator A Cell
Operator C Cell
Operator B Cell Operator B Cell Operator B Cell
4.3 Interface Design

All physical connections supported by the shared RNC are the same as those supported by the
non-shared RNC.
4.3.1 Iu Interface
An operator can only use the operator's own CN nodes. Therefore, each operator can use one
or more physical ports to connect its own CN nodes. The physical bandwidth related to the
physical ports is operator dedicated.
In the shared RNC, a global CN identity is added to each CN node. The global CN identity
consists of the PLMN ID and the CN ID.
Figure 4-8 shows an example where the RNC is shared by operator A and operator B.
Operator A uses Iu Flex, whereas operator B does not.

2017-8-11 Page 50 of 94
name.
Figure 4-8 Operator A and operator B share an RNC with operator A using Iu Flex
The switch to enable or disable Iu Flex is configurable for each operator, that is, the operator
can individually enable or disable Iu Flex. The configuration of Iu Flex in the shared RNC is
similar to that in the non-shared RNC. In the shared RNC, the configuration for the initial
NAS message routing should be performed separately by each operator. The configuration is
as follows:
NRI length for the CS or PS domain
Mapping between NRI and global CN identity
Mapping between IMSI route value and global CN identity
IMSI route value = (IMSI div 10) mod 1000. The value range is 0-999.
4.3.2 Iu-BC Interface

In a non-shared RNC, only one CBC can be connected. In a shared RNC, each operator can
have a dedicated CBC and a maximum of four CBCs can be connected. The Iu-BC interface
is dedicated to each operator and the CBS is limited in each operator's own cells.
On the Iu-BC interface, the Service Area Broadcast Protocol (SABP) peer entity uses
Transmission Control Protocol/Internet Protocol (TCP/IP). Each operator that employs CBS
should separately configure the dedicated connections to the operator's own CBC, as shown in
Figure 4-9.

2017-8-11 Page 51 of 94
name.
Figure 4-9 Operator dedicated Iu-BC connection in the shared RAN
Cell NodeB Physical RNC Operator dedicated Iu-BC

interface
Iub
1
IPoA/IP
Logical RNC 1 CBC 1
IPoA/IP
Logical RNC 2 CBC 2
Operator A
Operator B
4.3.3 Iub Interface

The shared RNC supports both shared and non-shared NodeBs. The maximum number of
NodeBs and cells supported by the shared RNC is the same as that supported by the
non-shared RNC.
Transmission for the Iub Control Plane and Management Plane

As shown in Figure 4-10, the NodeB control port (NCP), communication control port (CCP),
access link control application part (ALCAP) link, and OM path are common to all operators
that share the NodeB. Each NodeB has one unique NCP, one unique ALCAP link, and
multiple CCPs. The mapping between cells and CCPs is not fixed. A unique OM path for one
NodeB is recommended though multiple OM paths are allowable.
The NCP is used for the common NodeB application part (NBAP) procedures such as cell
setup, cell reconfiguration, common transport channel setup, and radio link setup. All the
operators must share the NCP, such as cell setup for cell 1, cell 2, and cell 3. The CCP is
selected by the load balancing policy instead of the operator involved or the cell where a call
is originated.

2017-8-11 Page 52 of 94
name.
Figure 4-10 Shared Iub connections
Figure 4-11 Separation of transmission resources for the Iub user plane
Transmission for the Iub User Plane

The transmission resources for the Iub user plane can be shared or dedicated by operators, as
shown in Figure 4-11.
Dedicated Iub User Plane

When separation of the transmission resources for the Iub user plane is enabled, the
transmission resources for the Iub user plane can be configured into different Virtual Ports
(VPs) or Logical Ports (LPs), as shown in Figure 4-12. The VP is for ATM and the LP is for IP.
Each VP or LP is specified for an individual operator only.
The VP and LP traffic shaping is supported. The admission control is based on a VP or an LP.
RNC detects and resolves the transmission congestion through an individual operator.

2017-8-11 Page 53 of 94
name.
Figure 4-12 Separation by VP or LP
When Iub user plane is dedicated, the transmission resources for the user planes of operators
are independent physical links, as shown in Figure 4-13.
Figure 4-13 Iub physical link isolation
When ATM/IP dual stack is adopted, there are two cases, as shown in Table 4-1.
Table 4-1 Cases when ATM/IP dual stack is adopted
Case Method
Two operators engage dual stacks respectively.
Two operators engage each stack.
Remarks:
1 Generally only consider the downlink (RNC-> Node B) the user plane Dedicated; does
not support user plane dedicated uplink (NodeB-> RNC); main reasons: the uplink
transmission more congestion than the downlink transmission;
2 Downlink user plane dedicated is to configure the logical port;

2017-8-11 Page 54 of 94
name.
Shared Iub User Plane

If the Iub user plane is fully shared, user plane resources of operators are fully shared without
separating virtual links or logical links. Shared Iub user plane features the most effective
transmission, as shown in Figure 4-14.
Figure 4-14 Fully-shared Iub user plane
TRM Policy over Iub Interface

The transmission resource management (TRM) policy of the Iub interface includes the
admission control and flow control of the user plane. In RAN Sharing scenarios, operators can
implement independent or unified admission control and flow control over Iub interfaces.
Relevant concepts are described as follows:
Independent admission control:
If a UE of an operator requests for transmission resource admission, the required
transmission bandwidth can only be allocated from the dedicated bandwidth of the
operator. The RNC implements independent admission control of UEs of each operator.
Independent admission control:
If a UE of an operator requests for transmission resource admission, the required
transmission bandwidth can only be allocated from the dedicated bandwidth of the
operator. The RNC implements unified admission control for UEs of all operators.
Independent flow control:
The RNC detects congestion separately on the dedicated bandwidth of each operator.
When congestion is detected on the bandwidth of an operator, the RNC only performs
flow control for the UEs of the operator.
Unified flow control:
The RNC detects congestion on the total bandwidth of all operators. When congestion is
detected, the RNC only performs flow control for the UEs of all operators.
In RAN Sharing scenarios, the TRM policy over the Iub interface can be implemented
through configuration, as shown in Table 4-2.
Table 4-2 TRM policy over Iub interface

Bandwidth TRM Policy
Usage and
Features Independent admission Unified admission Independent
control and unified flow control and flow control admission control
control and flow control
Bandwidth -
dedicated

2017-8-11 Page 55 of 94
name.
Bandwidth TRM Policy

Usage and
Features Independent admission Unified admission Independent
control and unified flow control and flow control admission control
control and flow control
Bandwidth - -
shared
Features Ensures the admission Features the highest Iub Features the
independence of operators transmission bandwidth highest
and high transmission usage. This TRM policy independence of
resources usage. is recommended and is Iub transmission
(Non-realtime services broadly used on bandwidth of
will be admitted commercial networks, operators.
according to the GBR. such as operator V and However, the
Therefore, in most operator O in country S. resource usage is
scenarios, non-realtime low.
services will not be
rejected. In actual
applications, however,
resources may be
congested. Therefore, this
mode is not
recommended.)
4.3.4 Iur Interface

Iur transmission resources are totally shared by operators.
Iur total transmission bandwidth=(Iur transmission bandwidth which Operator I need)
Iur interface design method in RAN sharing is the same as that of non-shared RAN. For
details about the design method, see the Technical Clarification of UMTS RAN13.0 Network
Design Service.
The physical interfaces and bandwidth are shared by operators.
As shown in Figure 4-15, the Iur control plane is shared.
Figure 4-15 Iur control plane of two RNCs shared by operators A and B

2017-8-11 Page 56 of 94
name.
As shown in Figure 4-16, the Iur user plane is also shared.
Figure 4-16 Iur user plane of two RNCs shared by operators A and B
Physical RNC 1 Physical RNC 2
Signaling node 1 Signaling node 2
Transport paths
Logical RNC 1a Logical RNC 2a
Logical RNC 1b Logical RNC 2b
Operator A
Operator B
Common
Traffic of Operator A
Traffic of Operator B
4.4 OM Design
The OM mode of a shared network is closely related to that negotiated between operators.
OM modes are classified into joint OM mode and rent OM mode, which are described as
follows:
In joint OM mode, operators A and B provide respective devices to establish a joint
company and the joint company operates and maintains the network.
In rent OM mode, operator A shares some devices with operator B and operator A
operates and maintains the network.

2017-8-11 Page 57 of 94
name.
In the two OM modes, a network is managed by one element management system (EMS) or
M2000, and then the message and private data are transmitted to the respective system of each
operator through the northbound interface. Currently, it is not allowed for each operator to use
an M2000 to manage an MOCN network.
In joint OM mode, the joint company provides information about each operator to the
upper-level network management system (NMS) of operator A and operator B. The joint
company can be any one of operator A and operator B. In rent OM mode, primary operator A
provides information about operator B to the upper-level NMS of operator B.
In RAN Sharing, M2000 northbound interfaces can distinguish cell-level data. If cell A
belongs to operator A, operator A can receive the private data of cell A and all public data over
the northbound interface(NBI).
Private data
Private data indicates the cell-level FM, PM, and CM data, which are related only to
dedicated operators. Private data are delivered to the NMS of the operator over the
M2000 northbound interface.
Shared data
Shared data indicates all the FM, PM, and CM data not the cell-level data exported over
the northbound interface.
The traffic statistics on RNC and NodeB can be performed independently for operators. The
measurement object is Operator. The traffic statistics can be subscribed and queried on M2000
PM window. Currently, the Operator objects of the northbound interface are reported without
distinguishing the operators.
During the northbound interconnection of different FMs, CMs, and PMs, confirm the
interface format supported by the existing system of the operator. Currently, the M2000
supports the following interfaces.
FM interface: includes Corba alarm interface and American Standard Code for
Information Interchange (ASCII) streaming interface of the M2000.
PM interface: indicates the M2000 performance file interface.
CM interface: indicates the CME file import and export interface.
4.5 License Management Design

There is only one RNC license and one NodeB license for a shared RAN. Licenses, which
define all the functions and equipment resources, can be distributed between different
operators and must be activated before using the functions and resources.
The RNC license can be managed either on the M2000 or on the local maintenance terminal
(LMT), whereas the NodeB license can only be managed on the M2000.
RAN Sharing NodeB License

The NodeB license consists of resource control items and function control items. The
operators' resources and functions are defined by different groups in a NodeB license,
including a private group for each operator and a common group.
License group

2017-8-11 Page 58 of 94
name.
Private group
Each operator who shares the NodeB has a corresponding private group in the NodeB
license. The private group defines the operator's dedicated resources and functions.
For example, private group A defines resources and functions that can be used by
operator A only.
Common group
The common group is optional in the NodeB license. The group defines common
resources and functions that can be used by all operators.
Resource control items
Resource control items include CEs, frequencies, and Power Amplifier (PA) output
power. The total number of CEs in a NodeB license cannot exceed the supported
capacity of the NodeB hardware. Resource control items could be deployed respectively
by operators on M2000
CE usage principle
The primary operator purchases the CE license from Huawei and obtains the total
number of available CEs in a NodeB. Then, the primary operator negotiates with the
secondary operator to determine the number of CEs that each operator can consume.
That is, determine private groups corresponding to the fixed frequencies (namely, cells).
In addition, some CE resources can be used in public groups and shared by operators.
When a Radio Link (RL) is to be set up, it consumes the CEs in the private group first. If
the required CEs exceed 110% of the CEs in the private group, the RL begins to
consume the CEs in the common group. If the required CEs still exceed 110% of the CEs
in the common group, the RL setup fails.
For example, assume that one NodeB is shared by operators A and B. Operator A has
cells 0, 1, and 2. Operator B has cells 3, 4, and 5. There are three groups in the NodeB
license: private group A, private group B, and common group. Each of the three groups
has 8 UL CEs and 8 DL CEs. If there is a 384 kbit/s call request in cell 0, the call
requires 10 UL CEs. The call uses 9 UL CEs of private group A and 1 UL CE of the
common group. If, at the same time, there is another 384 kbit/s call request in cell 3 and
the call also requires 10 UL CEs, the call uses 9 UL CEs of private group B and 1 UL CE
of the common group. In total, 2 UL CEs of the common group are used.
NodeB can make statistics on the number of CEs consumed by each operator, and RNC
can implement admission control according to the number of CEs configured for each
operator.
Function control items
NodeB function control items are oriented to NodeB-level features, which are configured
on the M2000. The function control items are shared by operators and cannot be
configured independently for each operator.
RAN Sharing RNC License Control Items

The RNC license consists of resource control items and function control items. The RNC
license must be activated by each operator. When there are multiple operators in the RNC, the
RNC license is activated in the following sequence: by the primary operator, and then by the
secondary operators. No sequence between secondary operators is required.
Resources and function control items of the RNC license can be configured separately for
operators. The sum of resources of RAN sharing operators cannot exceed the maximum
number of resources purchased from the license center. First, the RNC license can be
activated for all operators at the same time. Then, configure the resource and function control

2017-8-11 Page 59 of 94
name.
items in the following sequence: the primary operator, and then the secondary operators. No
sequence between secondary operators is required.
Resource control items
On the RNC, resource control items can be configured for different operators as required.
Resource control items in the RNC license include the maximum traffic volume of CS,
the maximum throughput of PS, HSDPA, HSUPA, and MBMS, and the maximum
number of activated UEs of the enhanced FastDormancy. In addition, hardware capacity
is included for the primary operator. The maximum number of resources used by each
operator cannot exceed the threshold configured in the License.
Function control items
The RNC license provides more than 60 function control items, which can be classified
into two types: items totally controlled by the primary operator and items controlled by
each operator.
Items totally controlled by the primary operator allow the function to be enabled or
disabled by the RNC not an individual operator. The function is not activated when any
of the following conditions is true:
The function control item is not activated in the RNC license.
The function control item is not selected when the primary operator runs the ACT
license.
Items controlled by each operator allow an operator to determine whether to activate the
function. The function is not activated when any of the following conditions is true:
The function control item is not activated in the RNC license.
The function control item is not selected when the operator sets the RNC license.
Items totally controlled by the primary operator (based on RAN13.0) are as follows:
RANSHARE(RAN sharing).
RAN_SHARING_ENHANCED_PACKAGE(RAN Sharing Enhanced Package).
ATMIPDUALSTACK(IUB ATM/IP Dual Stack Transportation Function).
IPTRANINIUR(IP Transportation in Iur Interface).
FRACTIONALIP(Fractional IP).
FRACTIONALATM(Fractional ATM).
IPIUBOVERBOOKING(IP IUB overbooking Function).
ATMOVERBOOKING(ATM IUB overbooking Function).
IUBHYBRIDIPTRAN(IUB Hybrid IP Transportation Function).
ACRWHENSPUOVER(Access Class Restriction when service processing unit (SPU)
overload).
License control for urgency
Hardware capacity license (165 Mbit/s) (per board)
Hardware capacity license (300 Mbit/s) (per board)
Other function control items in the RNC license can be controlled by each operator.
4.6 Resource Capacity Design

Refer to the non-shared network for the resource capacity design of RAN sharing. According
to the expected traffic model, calculate the hardware resources required by each operator,

2017-8-11 Page 60 of 94
name.
obtain the total number of hardware resources required by the network, and then design the
network capacity based on the calculation.
4.7 Carrier Allocation in Typical BTS Hardware

Configuration
This section describes the carrier allocation of BTS3812E, BTS3812AE, DBS3800, BTS3900,
BTS3900A, and DBS3900 under the typical RF hardware configuration in RAN Sharing.
Currently, two operators share a RAN. The following sections describe the carrier allocation
of two operators as an example.
4.7.1 BTS3812E/BTS3812AE
The following table lists the carriers that can be used by the two operators independently.
Configuration Operator A Operator B Remarks

3x2 MTRU: 3 3x1 3x1 For MTRU, IBW is 10MHz, so a pair
MAFU: 3 of frequencies in the same sector
must be two consecutive frequencies
within 10 MHz.
There is no such limitation for
8U-height WRFU.
MTRU: 6 3x1 3x1
MAFU: 6
3x4 MTRU: 6 3x1 3x3 For MTRU, IBW is 10MHz, One
MAFU: 6 sector uses two PAs. A pair of
3x2 3x2 frequencies in the same PA must be
two consecutive frequencies within
3x3 3x1
10 MHz.
The frequencies in different PAs can
be inconsecutive.
There is no such limitation for
8U-height WRFU.

2017-8-11 Page 61 of 94
name.
4.7.2 DBS3800

3x2 RRU: 3 3x1 3x1 For RRU3801C (IBW is
BBU: 2 10MHz):
The pair f1, f2 must be two
consecutive frequencies
within 10 MHz.
There is no such limitation
for modules such as
RRU3804.
RRU: 6 3x1 3x1
BBU: 2
3 x 2 MIMO RRU3808: 3 3 x 1 MIMO 3 x 1 MIMO
3x4 RRU: 6 3x1 3x3 For RRU3801C (IBW is
BBU: 2 10MHz):
3x2 3x2
3x3 3x1 consecutive frequencies
within 10 MHz.
consecutive frequencies
within 10 MHz.
There is no limit to the
continuity of the pair f1, f2
and the pair f3, f4.
There is no such limitation
for modules such as
RRU3804.
4.7.3 BTS3900/BTS3900A

3x2 WRFU-40W2C: 3 3x1 3x1 -
WRFU-80W4C: 6 3x1 3x1 -
3x 2 MIMO WRFUd: 3 3 x 1 MIMO 3 x 1 MIMO
3x4 WRFU-80W4C: 3 3x1 3x3 -

3x2 3x2
3x3 3x1

2017-8-11 Page 62 of 94
name.

WRFU-80W4C: 6 3x1 3x3 -
3x2 3x2
3x3 3x1
3x4 WRFUd: 3 3 x 2 DC + 2 x 3 x 2 DC + 2 x
DC+2*MIMO MIMO MIMO
4.7.4 DBS3900

3x2 RRU3804: 3 3x1 3x1 -
RRU3804: 6 3x1 3x1 -
3 x 2 MIMO RRU3829: 3 3 x 1 MIMO 3 x 1 MIMO
3x4 RRU3804: 3 3x1 3x3 -

3x2 3x2
3x3 3x1
RRU3804: 6 3x1 3x3 -
3x2 3x2
3x3 3x1
3 x 4 DC + 2 x RRU3829: 3 3 x 2 DC+2*MIMO 3 x 2 DC + 2 x
MIMO MIMO
4.8 Typical Configuration Parameters

The following uses RAN12.0 and RAN sharing between two operators as an example to
configure typical parameters. For details about parameter settings, see the Guide to Deploying
RAN Sharing.
4.8.1 Activating RAN Sharing

Activate the license for RAN sharing.
ACT LICENSE: ISPRIMARYPLMN=YES, CNOPERATORINDEX=0,
FUNCTIONSWITCH2=RANSHARE-0;
If separated Iub transmission is required, RAN_SHARING_ENHANCED_PACKAGE
in the license file also needs to be activated.

2017-8-11 Page 63 of 94
name.
ACT LICENSE: ISPRIMARYPLMN=YES, CNOPERATORINDEX=0,

FUNCTIONSWITCH3=RAN_SHARING_ENHANCED_PACKAGE-0;
Configure basic information about RAN Sharing.
SET UOPERATORSHARINGMODE: RANSharingSupport=YES, MOCNSupport=NO,
InterPlmnHoAllowedIntraRat=NO, InterPlmnHoAllowedInterRat=NO;
The RANSHARINGSUPPORT parameter specifies whether RAN Sharing is supported.
The availability of inter-PLMN handovers depends on the value of
INTERPLMNHOALLOWEDINTRARAT or
INTERPLMNHOALLOWEDINTERRAT.
4.8.2 Adding Operators

Add the primary secondary.
ADD UCNOPERATOR:CNOPINDEX=0, CNOPERATORNAME="RealMove",
MCC="520", MNC="00", OPERATORTYPE=PRIM;
Add a secondary operator.
ADD UCNOPERATOR:CNOPINDEX=2, CNOPERATORNAME="TrueMove",
MCC="520", MNC="99", OPERATORTYPE=SEC;
4.8.3 Setting Interface Parameters

1. Iu/Iur interface configuration
The Iu interface changes with operators. The primary operator and secondary operators
have their own Iu interface configurations. The configuration procedure is the same as
that when the RNC is not shared.
There is only one set of Iur interface configuration. The configuration procedure is the
same as that when the RNC is not shared.
2. Iub interface configuration
Scenario 1: Iub resource sharing
In this scenario, the procedure for Iub interface configuration is the same as that when
the RNC is not shared.
Scenario 2: Iub resource separated
When VP or LP is used for separated transmission, VP or LP must be configured.
Otherwise, when the physical port shaping capability is used for separated
transmission, the procedure for Iub interface configuration is the same as that when
the RNC is not shared.
For detailed about the Iu, Iur and Iub configurations, see the Guide to Deploying RAN
Sharing.
4.8.4 Configuring Cells

LAC/RAC/SAC/URA information
ADD ULAC:CNOPINDEX=0, LAC=H'2201, PLMNVALTAGMIN=1,
PLMNVALTAGMAX=64;
PLMNVALTAGMAX=2;
ADD URAC:LAC=H'0001, RAC=H'01, CNOPINDEX=1, PLMNVALTAGMIN=1,
PLMNVALTAGMAX=2;

2017-8-11 Page 64 of 94
name.
ADD URAC:LAC=H'2201, RAC=H'00, CNOPINDEX=0, PLMNVALTAGMIN=1,

PLMNVALTAGMAX=64;
ADD USAC:LAC=H'0001, SAC=H'0001, CNOPINDEX=1;
ADD USAC:LAC=H'2201, SAC=H'0000, CNOPINDEX=0;
ADD UURA:URAID=0, CNOPINDEX=0;
ADD UURA:URAID=1, CNOPINDEX=1;
The operator information also needs to be specified in LAC/RAC/SAC/URA
configuration. The number of URAs depends on the area division of operators. In actual
scenarios, the LAC is unique in an office, and the URA is unique in an RNC. Exercise
caution when adding the AC, URA, or Cell.
Cell information
ADD UCELLQUICKSETUP: CellId=280, CellName="CELL280",
PeerIsValid=INVALID, CnOpGrpIndex=0, BandInd=Band1, UARFCNDownlink=10688,
PScrambCode=280, TCell=CHIP0, LAC=8705, SAC=0, CfgRacInd=REQUIRE,
RAC=0, SpgId=1, URANUM=D1, URA1=0, NodeBName="NodeB2208", LoCell=280,
SupBmc=FALSE, CPICHPower=40;
The operator information also needs to be specified for cell setup.
4.9 Acceptance Solution

The RAN Sharing acceptance criteria involve the functionality test and KPI test.
1. Functionality test
UE registration
AMR/PS/HSPA services
Mobility (inter-NodeB and inter-RAT handovers)
Resource sharing (Iub and NodeB credit resource sharing)
2. Network KPI test
Check KPIs before and after RAN Sharing reconstruction and ensure that no KPI
deteriorates obviously.
4.10 Impact on Network KPIs

In current offices, after RAN Sharing is activated, KPIs do not deteriorate obviously.

2017-8-11 Page 65 of 94
name.
5 MOCN Service Design
5.1 Design Overview

This section describes the contents and methods of the MOCN service design.
5.2 Typical Networking Modes of MOCN

Typical networking modes of MOCN include five typical application scenarios:
Full MOCN
Coexistence of MOCN cells and private cells
Coexistence of the MOCN RNC and dedicated RNC
Coexistence of the MOCN RNC and 2G network
Coexistence of Iu Flex and MOCN
Coexistence of multiple operators
MOCN cell resource demarcation
5.2.1 Full MOCN

In a full MOCN, all carriers in the network are shared by operators, without any dedicated
devices.

2017-8-11 Page 66 of 94
name.
Figure 5-1 Full MOCN
Only mobility management between MOCN cells is involved in this scenario. For details, see
the related description of MOCN mobility management in section 3.2.12 "MOCN Mobility
Management."
For typical commercial networks, see the networks deployed by operator T and operator B in
country C in section 5.2.1 "Full MOCN."
5.2.2 Coexistence of MOCN Cells and Private Cells

Shared carriers and dedicated carriers need to coexist under an RNC. Huawei MOCN solution
can meet this requirement.
Figure 5-2 MOCN private cell networking
In this scenario, mobility management between MOCN cells and mobility management
between MOCN cells and private cells are involved. For details, see the related description of
MOCN mobility management in section 3.2.12 "MOCN Mobility Management."

2017-8-11 Page 67 of 94
name.
The methods or principles for resource management, operation and maintenance, and function
control comply with the regulations of MOCN, not RAN Sharing. For typical commercial
networks, see TMV network sharing of country T in section 5.2.3 "Coexistence of the MOCN
RNC and Dedicated RNC", network sharing between operator P and operator O of country P
in section 5.2.4 "Coexistence of the MOCN RNC and 2G Network", and network sharing
between operator S and operator D of country PH in section 5.2.5 "Coexistence of Iu Flex and
MOCN."
5.2.3 Coexistence of the MOCN RNC and Dedicated RNC

As shown in Figure 5-3, operator A and operator B have deployed their own non-shared 3G
networks in one area and decide to deploy an MOCN in another area.
Figure 5-3 Coexistence of the MOCN RNC and dedicated RNC under full coverage
Iu
Operator A
Iur
Dedicated RNC MOCN Shared
RNC
Operator B Iur
Dedicated RNC
Operator B Cell
MOCN Cell
Operator A Cell
The MOCN RNC connects to dedicated RNC A and RNC B over the Iur interface, and
neighboring cell relationships are configured. When a UE of operator A in the same MOCN
cell transfers from a shared area to a non-shared area, the RNC enables the UE of operator A
to be handed over to a neighboring cell of operator A. The same situation applies to operator
B. For details about mobility management in this scenario, see the related description of
MOCN mobility management in section 3.2.12 "MOCN Mobility Management."
For typical commercial networks, see network sharing between operator S and operator D of
country PH in section 5.2.5 "Coexistence of Iu Flex and MOCN."
5.2.4 Coexistence of the MOCN RNC and 2G Network

As shown in Figure 5-4, both operator A and operator B have deployed a GSM network and
decide to deploy an MOCN 3G network. To fully use the GSM resources, the new MOCN
network needs to interwork with the existing GSM network. Therefore, the neighboring cells
on MOCN RNC1, BSS A and BSS B are configured on the MOCN RNC. In this way, service
continuity is ensured when a UE of operator A transfers between the operator A UMTS cell
and its neighboring GSM cell. The same situation applies to operator B. For details about

2017-8-11 Page 68 of 94
name.
mobility management in this scenario, see the related description of MOCN mobility
management in section 3.2.12 "MOCN Mobility Management."
Figure 5-4 Coexistence of the MOCN RNC and 2G network
Operator A MOCN Operator B

BSS Shared RNC BSS
GSM Cell MOCN Cell GSM Cell
There is a special scenario, in which MOCN is enabled on the shared 3G network but roaming
is enabled on the 2G network for sharing. As shown in Figure 5-5, UEs of operator A can
roam to GSM cells of operator B. Therefore, in addition to the neighboring relationships
between the GSM cell of operator B and the MOCN cell, the neighboring relationships
between the GSM cell of operator A and the MOCN cell and the neighboring relationships
between GSM cells of operator A and operator B must be configured. For details about
mobility management in this scenario, see the related description of MOCN mobility
management in section 3.2.12 "MOCN Mobility Management."
Figure 5-5 Coexistence of the MOCN RNC and roaming 2G network
For typical commercial networks, see TMV network sharing of country T in section 5.2.3
"Coexistence of the MOCN RNC and Dedicated RNC" and network sharing between operator
S and operator D in country PH in section 5.2.5 "Coexistence of Iu Flex and MOCN."

2017-8-11 Page 69 of 94
name.
5.2.5 Coexistence of Iu Flex and MOCN

As shown in Figure 5-6, operator A and operator B share the MOCN. To improve network
reliability, operator A applies Iu Flex to both CS and PS domains, and operator B applies Iu
Flex only to the PS domain.
In this scenario, services of one operator can only be processed by the CN nodes of this
operator. Each operator has many CN nodes. Therefore, in addition to MOCN, Iu Flex needs
to be applied in the RNC. For the typical commercial network, see the network deployed by
operators Tellus& B of country C.
If offload must be enabled on a CN node, NullNRI needs to be configured and the
configuration is consistent with that on the CN.
Figure 5-6 Coexistence of Iu Flex and MOCN
Operator A
MSC server 3
MSC server 2
MSC server 1
MGW 4 SGSN 2
MGW 3 SGSN 1
MGW 2
MGW 1
Operator B
MGW MSC server
MOCN SGSN 1
SGSN 2
Shared
RNC SGSN 3
MOCN Cell MOCN Cell MOCN Cell
5.2.6 Coexistence of Multiple Operators

As shown in Figure 5-7, operator A and operator B share an MOCN, and operator C has a
roaming agreement with operator B. This agreement allows all the UEs of operator B and
operator C to share network resources.
To achieve handovers between the cells of operator B and operator C, the switch of Inter
Plmn Ho Allowed must be turned on and neighboring cell relationships must be configured
correctly.

2017-8-11 Page 70 of 94
name.
Figure 5-7 Coexistence of multiple operators

MOCN aims to share resources and reduce costs. However, cooperation among operators is
diversified. For example, operators reach an agreement on proportional demarcation and
charging of shared cell resources. This operation reduces resource efficiency, but allows
independence of operators in MOCN scenarios. As a result, the number of operator UEs
matches resource amount and conflicts among operators are reduced.
Compared with other MOCN scenarios, this solution enables operators to demarcate resources
and set resource demarcation proportion through negotiation. This solution is introduced in
RAN14.0. Operator-based resource demarcation involves RNC-level CS traffic volume and
PS throughput rate, cell-level spreading codes (SFs), and cell-level HSDPA power resources.
For the typical commercial network, see network sharing between operator P and operator O
of country P in section 5.2.4 "Coexistence of the MOCN RNC and 2G Network."
5.3 Interface Design

All physical connections supported by the MOCN RNC are the same as those supported by
the non-shared RNC.
5.3.1 Iu Interface
On the Iu interface, an operator can only use its own CN nodes. Therefore, each operator can
use one or more physical ports to connect its own CN nodes. The physical bandwidth related
to the physical ports is operator dedicated.
In the MOCN RNC, a global CN identity is added to each CN node. The global CN identity
consists of the PLMN ID and the CN ID.
Figure 5-8 shows an example where the RNC is shared by operator A and operator B.
Operator A uses Iu Flex, whereas operator B does not.

2017-8-11 Page 71 of 94
name.
Figure 5-8 Operator A and operator B share an RNC with operator A using Iu Flex
MSC MSC MSC MSC

Server 1 Server 2 Server 3 server
MGW 1 MGW 2 MGW 3 MGW 1 MGW 2 SGSN
SGSN 1
SGSN 2
Iu
Operator A
MOCN Shared RNC
Operator B
The switch to enable or disable Iu Flex is configurable for each operator, that is, the operator
can individually enable or disable Iu Flex. The configuration of Iu Flex in the MOCN RNC is
similar to that in the non-shared RNC. In the MOCN RNC, the configuration for the initial
NAS message routing should be performed separately by each operator. The configuration is
as follows:
NRI length for the CS or PS domain
Mapping between NRI and global CN identity
Mapping between IMSI route value and global CN identity
IMSI route value = (IMSI div 10) mod 1000. The value range is 0-999.
5.3.2 Iub Interface

The MOCN RNC supports both shared and non-shared NodeBs. The maximum number of
NodeBs and cells supported by the MOCN RNC is the same as that supported by the
non-shared RNC.
In RAN14.0 and earlier version, All Iub transmission resources are shared by operators.
Transmission for the Iub control plane and management plane
As shown in Figure 5-9, the NCP, CCPs, ALCAP link, and OM path are common to all
operators that share the NodeB. Each NodeB has one unique NCP, one unique ALCAP
link, and multiple CCPs. The mapping between cells and CCPs is not fixed. One OM
path is recommended for one NodeB though multiple OM paths are allowable.
The NCP is used for the common NBAP procedures such as cell setup, cell
reconfiguration, common transport channel setup, and radio link setup. All the operators
must share the NCP, such as cell setup for cell 1, cell 2, and cell 3.

2017-8-11 Page 72 of 94
name.
Figure 5-9 Shared Iub connections
Cell NodeB MOCN RNC

Control plane
NCP
1
CCP1 MOCN
2 CCP2 Shared
RNC
ALCAP
3 OM path
Operator A
Operator B
Common
Transmission at the Iub user plane

In MOCN scenarios, transmission resources for the Iub user plane are totally shared by
operators, as shown in Figure 5-10.
Figure 5-10 Iub user plane shared by operator A and operator B
RNC NodeB
Transport paths
MOCN MOCN
Shared Shared
RNC NodeB
Operator A
Operator B
Common
In RAN15.0 and later version, the introduction of 3.2.15 MOCN Independent Iub
Transmission Resource Allocation Featrue, to support the user plane transmission resource of
Iub interface independent, the Iub signal bandwidth shared by each operator, wherein MOCN
share a common channel of the cell bandwidth must be shared. This feature is only for the

2017-8-11 Page 73 of 94
name.
RNC downlink transmission resources to be divided, does not support the NodeB side uplink
transmission resource partitioning.
MOCN Independent Iub Transmission Resource Allocation feature applies to the following
scenarios:
Operators share one physical link over the Iub interface, as shown in Figure 5-11.
Figure 5-11 Sharing one physical link over the Iub interface
Each operator uses a dedicated physical link over the Iub interface, as shown in
Figure 5-12.
Figure 5-12 Using dedicated physical links over the Iub interface
In MOCN scene, the customer requirements that the Iub bandwidth must assign by the
operator, you can deploy this feature.
Pre-deployment need to evaluate to prevent the traffic operators assigned Iub bandwidth is
less than the traffic demand.
If the inter-operators independence requirements of resources, you can deploy this feature. To
protect operator bandwidth usage completely independent, the total bandwidth of
configuration of the all logical ports bandwidth do not recommend more than the physical
port bandwidth.

2017-8-11 Page 74 of 94
name.
5.3.3 Iur Interface

Iur transmission resources are totally shared by operators.
Figure 5-13 shows a shared Iur control plane.
Figure 5-13 Iur control plane of two RNCs shared by operators A and B
RNC 1 SPC 1 RNC 2 SPC 2
Control links
MOCN MOCN
Shared ... Shared
RNC 1 RNC 2
Load sharing
Operator A
Operator B
Common
As shown in Figure 5-14, the Iur user plane is shared.
Figure 5-14 Iur user plane of two RNCs shared by operators A and B
RNC 1 RNC 2
Transport paths
MOCN MOCN
Shared Shared
RNC 1 RNC 2
Operator A
Operator B
Common

2017-8-11 Page 75 of 94
name.
5.4 OM Design
The OM mode of an MOCN network is closely related to that negotiated between operators.
OM modes are classified into joint OM mode and rent OM mode, which are described as
follows:
In joint OM mode, operators A and B provide respective devices to establish a joint
company and the joint company operates and maintains the network.
In rent OM mode, operator A shares some devices with operator B and operator A
operates and maintains the network.
Figure 5-15 MOCN OM
In either of the two OM modes, a network is managed by one EMS or M2000, and then the
public and private data are transmitted to the respective system of each operator through the
northbound interface(NBI). Currently, an MOCN network cannot be managed on operators'
respective M2000s.
An MOCN shares FM and CM. Each operator can manage and monitor all shared cells to
obtain alarms and configurations of these cells. A configuration change in shared cells made
by an operator affects other operators. Therefore, it is recommended that the joint OM team or
the primary operator team change the configuration. PM can be partially dedicated to each
operator. That is, each operator can obtain the statistics about independent RNC-level traffic
volume, for example, CS traffic (unit: Erlang) and PS throughput. However, each operator
still needs to share the performance statistics of shared cells. Operator-specific statistics can
be subscribed to or queried on the M2000. Currently, the northbound interface cannot report
operator-specific statistics.
If each shared operator does not have its own NMSs, one set of M2000 is required for
managing the network, and it is recommended that the joint OM team or the primary operator
team operate and maintain the network.

2017-8-11 Page 76 of 94
name.
5.5 License Management Design

There is only one RNC license and one NodeB license for an MOCN RAN. Licenses define
all the functions and resources and must be activated and distributed among operators before
used.
The RNC license can be managed either on the M2000 or on the LMT, whereas the NodeB
license can only be managed on the M2000.
The RNC license consists of resource control items and function control items. Resource
control items can be set individually for each operator. The total capacity of operators must be
greater than the maximum capacity defined in the RNC license. Function control items are
shared by operators. That is, functions used by the secondary operators are the same as those
used by the primary operator. The RNC license can be first activated without differentiating
operators. Then license resources are allocated for the primary operator and then for
secondary operators. Secondary operators are not sequenced in license resource allocation.
Resource Control Items

On the RNC, resource control items can be set individually for each operator. The resource
control items in the RNC license include:
Maximum CS traffic volume
Maximum throughput rate of PS services
Maximum throughput rate of HSDPA services
Maximum throughput rate of HSUPA services
Maximum throughput rate of MBMS services
Maximum number of enhanced FastDormancy activity users
For the primary operator, hardware capacity is also included.
For each operator, the maximum capacity of each resource item cannot be greater than
the specification of the license.
On the NodeB, resources are shared by operators.
Function Control Items

The function control items provided by the RNC license and NodeB license are totally shared
by operators. That is, each operator uses the same features.
5.6 Resource Capacity Design

In RAN13.0 and earlier versions, licenses are used to specify the maximum traffic (unit:
Erlang) and throughput so that capacity planning of operators can be controlled.
In MOCN networking scenarios, the MOCN Cell Resource Demarcation feature
(corresponding to feature WRFD-140223 MOCN Cell Resource Demarcation) introduced in
RAN14.0 prevents UEs of an operator from occupying excessive cell resources. This ensures
fairness to each operator in using shared cell resources. With this feature, the percentage of
cell resources available for each operator in a shared MOCN cell is configurable. The
predefined cell resources are downlink spreading codes (SCs) assigned for R99 UEs (DL R99
SCs for short) and HSDPA power resources. After this feature is enabled, the RAN manages
DL R99 SCs and HSDPA power resources in a shared MOCN cell as follows:

2017-8-11 Page 77 of 94
name.
The RNC performs admission, preemption, and congestion control.

When cell resources are sufficient, the RNC admits UEs without differentiating between
operators. UEs of any operator can use more resources than the predefined resource
percentage.
When a UE cannot be admitted due to insufficient cell resources, the RNC determines
whether to trigger preemption based on the actual percentage of resources being used by
each operator.
When congestion triggered by insufficient DL R99 SCs occurs in the cell, the RNC
preferentially performs congestion control on R99 UEs whose serving operator exceeds
its predefined percentage of DL R99 SCs the most.
The NodeB adjusts the scheduling priority and performs scheduling for HSDPA UEs.
The NodeB adjusts the scheduling priority among HSDPA UEs of different operators in
real time. This adjustment is based on the actual percentage of HSDPA power resources
each operator is using and the percentage of available HSDPA power resources
predefined for each operator. The real-time scheduling adjustment ensures that the
NodeB schedules resources as they are demarcated whenever possible.
The available cell resources configurable for each operator are DL R99 SCs and HSDPA
power resources. They are specified by parameters DLAvaiSFRatio and DPAAvaiPwrRatio,
respectively. Other cell resources are not assigned on a per operator basis.
In a shared MOCN cell, the predefined percentages must meet the following requirements:
The sum of the DLAvaiSFRatio values configured for all operators must be smaller
than or equal to 100.
The sum of the DPAAvaiPwrRatio values configured for all operators must be smaller
than or equal to 100.
Note that:
If DLAvaiSFRatio is set to 0 for an operator, DL R99 services of this operator will no
longer be assigned SCs. As a result, DL R99 services of this operator cannot be accessed.
If DPAAvaiPwrRatio is set to 0 for an operator, HSDPA services of this operator will no
longer be assigned HSDPA power resources. As a result, HSDPA services of this
operator cannot be accessed.
Figure 5-14 illustrates example configurations for resource demarcation in a shared MOCN
cell. The MOCN cell shown in Figure 5-14 is shared by operators A, B, and C. Operator A is
the primary operator, and operators B and C are secondary operators. The percentages of
available DL R99 SCs configured for operators A, B, and C are 30%, 40%, and 30%,
respectively. The percentages of HSDPA power resources configured for operators A, B, and
C are 40%, 40%, and 20%, respectively.

2017-8-11 Page 78 of 94
name.
Figure 5-16 Example configurations for MOCN Cell Resource Demarcation
When MOCN Cell Resource Demarcation is active, handover switch between different
operators cannot be opened.It is not recommended that this feature be used with the feature
WRFD-010696 DC-HSDPA because enabling Dual-Carrier High Speed Downlink Packet
Access (DC-HSDPA) results in inaccurate statistics on HSDPA power. DC-HSDPA takes
statistics of HSDPA power resources based on two cells whereas MOCN takes statistics of
HSDPA power resources based on one cell.
RAN15.0 introduces MOCN CE separate allocation of CE resources (details please refer to
3.2.14 MOCN Independent CE Resource Allocation), support the operators to allocate the CE
License resource by NodeB level. if the customer have this requirement, you can deploy this
feature.
1) Before you deploy this feature, allocate CE resources to operators based on their
traffic:If among the operators the independent request to resources is high, then the
sharing group may not configure CE, only configures in the private group; But the total
CE utilization of NodeB resources will decline.
2) If the operators consider the balance between independence and resource utilization, then
the sharing group may configure more CE, in the sharing group CE is more, the
utilization is higher, the independence is lower.
Sum of Various operators' private group CE and sharing group CE cannot exceed the purchase
of the CE license document total.
5.7 Operator Management Design

5.7.1 Operator Type
The operator types are described as follows:
Primary operator: determines the functions to be supported by the entire RAN system
and allocates licenses to secondary operators. The primary operator permits registration
and access of UEs.
Secondary operator: determines the functions to be supported by the entire RAN system.
The licenses of secondary operators are controlled by the primary operator. Secondary
operators permit access of UEs.

2017-8-11 Page 79 of 94
name.
Outer operator: In mobility management, UEs need to be handed over from the operator
of the SRNC to the operator of the TRNC. If an operator is not a primary operator or a
secondary operator of the SRNC, the operator is defined as an outer operator to support
mobility management.
Common operator: The PLMN ID is indicated in the system broadcast information. UEs
that do not support HSDPA consider the corresponding operator as the serving operator,
as in conventional networks. Common operators support non-supporting UEs.
Originally, the primary operator and secondary operators are configured. To support the
MOCN, common operators are added. Considering that a cell under the neighboring RNC
may be an MOCN cell, outer operators are added for the purpose of convenient configuration.
5.7.2 Operator Group

After MOCN is introduced, more than one operator can be configured for a cell. To facilitate
maintenance and management, the concept of operator group is introduced. Each cell
corresponds to an operator group. Each operator group can be configured with 1 to 4 available
operators and 0 or 1 common operator.
5.8 Load Balancing Design

In some scenarios, more than one operator may serve a UE (for example, a roaming UE). In
this case, the load balancing mechanism is required to ensure load balancing among operators
and fairness to each operator in using shared network resources.
5.8.1 Load Balancing in RAN10.0 to RAN12.0

The RNC supports MOCN load sharing. During initial or subsequent attempts of relocation,
an operator with the least number of accessed UEs is selected so that UEs evenly access
different operators' CNs, achieving load balancing among operators.
In RAN11.0, the RNC counts the number of hits for each UE in the Redirect process, that is,
local UEs of each operator are counted. Therefore, load balancing is of little significance.
However, local UEs can access only the operators that UEs subscribe to. If two operators have
different UE bases, the RNC cannot implement load balancing between the two operators.
Therefore, in RAN11.0, the default mode is used, that is, the default operator is considered as
the primary operator. If load balancing is required, the round robin selection mode is
recommended.
5.8.2 Load Sharing for Routing Roaming UEs in Proportion in

RAN13.0
In RAN13.0, the RNC checks whether a UE has roaming relationships with several operators.
If yes, the Routing Roaming UEs in Proportion feature can be enabled, ensuring the profits of
operators from roaming UEs.
1. Roaming relationship and roaming capacity ratio
After the function of routing roaming UEs in proportion is introduced, the command
ADD UROAMMAP can be used at a shared RNC to configure roaming relationships
between operators and the roaming capacity ratio. Based on the configurations, the RNC
can distribute load among CN nodes. Assume that operator A has roaming relationships
with operators B, C, and D (operators B, C, and D share one RNC), as described in the
following table.

2017-8-11 Page 80 of 94
name.
Operator Having Roaming Operator B Operator C Operator D

Relationships with Operator A
Roaming Capacity 10 20 10
Then, the roaming capacity ratio among B, C, and D is 10:20:10, that is, 1:2:1. That is,
when UEs of operator A roam to the shared RNC, one fourth of the UEs will be routed to
operator B's CN nodes, two fourths to operator C's CN nodes, and one fourth to operator
D's CN nodes.
To share the roaming relationship table between operators, the delay and number of
initial access attempts can be decreased. As specified in the feature, each operator can be
configured with a maximum of 512 PLMNs with roaming relationships. The
configuration of the roaming relationship table increases OM workload of operators
because roaming relationships may change frequently or be added and there is a large
amount of data.
2. Inventory evolution
In the current MOCN market, UEs select MOCNs using the default policy, that is,
roaming UEs are routed geographically. In the specified geographical area, roaming UEs
are routed to the default operator. To route roaming UEs in proportion, use slow
evolution or fast evolution.
Slow evolution
The RNC software is upgraded, and new roaming UEs that access a shared area are
routed in proportion. However, the roaming UEs that have registered before the RNC
software upgrade still camp on the previous operators' CN nodes, because NRI
mapping exists. In this way, roaming UEs in the entire network are not routed in
proportion, that is, this feature takes effect slowly. Roaming UEs move frequently.
Therefore, roaming UEs will roam out of the previous area after a short time. When
roaming UEs move to the MOCN cells, the UEs are routed in proportion. Therefore,
in the entire network, this feature takes effect gradually.
Fast evolution
The RNC software is upgraded, UE registration information is removed from CNs,
and all UEs reregister and reselect networks within one or two days. Roaming UEs
register for the first time, the CN delivers consistency requirement, and the RNC
enables roaming UEs to be routed in proportion. Subscription UEs register back to
the home operators' CN nodes. This feature takes effect fast. However, the removal of
UE registration information prolongs registration time of UEs because the data needs
to be obtained from the HLR. If the registration information of only roaming UEs is
removed, the registration of only roaming UEs is prolonged.
3. Feature verification
Assume that operator A and operator B deploy an MOCN network and 75% roaming
UEs are expected to be routed to operator A's CN nodes and 25% roaming UEs to
operator B's CN nodes.
When UEs that have a roaming agreement with both operators register in the network,
the RNC obtains their IMSIs and performs a mod 4 operator. The UEs of the IMSIs with
the remainders of 0, 1, and 2 will be routed to operator A's CN nodes and the UEs of the
IMSIs with the remainder of 3 will be routed to operator B's CN nodes, routing roaming
UEs in the ratio of 3: 1. After IMSI mod is used, CS and PS domains can register in the
same operator even though they register separately.

2017-8-11 Page 81 of 94
name.
Within a short time, roaming UEs are routed not exactly in a specified proportion. In the
long term, roaming UEs are routed in proportion. If required, feature verification can be
performed in a lab. However, IMSIs of UEs need to be selected properly.
4. License control
No license is used for this feature.
5.9 Cell Parameter Design

A cell can have only one LAC, one SAC, and one RAC. In an MOCN cell, the LAC, SAC,
and RAC must be the same for all operators, as shown in the following figure:
Same LAC for

two operators
Same RAC for

two operators
Same SAC for

two operators
5.10 Typical Configuration Parameters

The following uses RAN12.0 and MOCN between two operators as an example to configure
typical parameters. MOCN activation requires the CN configuration. For details about the
RAN configuration and CN configuration, see the Guide to Deploying RAN Sharing.
5.10.1 Activating MOCN

1. Activate the license for MOCN.
On the WebLMT, run the ACT License command to activate the license file.
2. Enable MOCN.
Run the SET OPERATORSHARINGMODE command to add the local operator
sharing mode.
SET UOPERATORSHARINGMODE: RANSharingSupport=NO, MOCNSupport=YES,
InterPlmnHoAllowedIntraRat=NO, InterPlmnHoAllowedInterRat=NO, DefaultCnOp=0,
MocnControlSwitch=COMM_MOCN_NRI_GLOBAL_CONFIG_MODE_SWITCH-1
&COMM_MIB_MULTI_PLMN_LIST_ALLOWED_SWITCH-1&SPARE_1_SWITCH

2017-8-11 Page 82 of 94
name.
-1&SPARE_2_SWITCH-0&SPARE_3_SWITCH-0&SPARE_4_SWITCH-0&SPARE_5
_SWITCH-0&SPARE_6_SWITCH-1;
If inter-operator handovers are allowed in the MOCN, the InterPlmnHoAllowedIntraRat or
InterPlmnHoAllowedInterRat parameter must be set to ON.
If DefaultCnOp is set to a value ranging from 1 to 3, the default load balancing mode is used.
If DefaultCnOp is set to 255, the round robin selection mode is used for load balancing.
5.10.2 Adding Operators

1. Add an operator.
Run the ADD UCNOPERATOR command to add the flag of the primary operator.
ADD UCNOPERATOR: OperatorType=PRIM, CnOperatorName="Bell",
MCC="302", MNC="221", CnOpIndex=0;
Run the ADD UCNOPERATOR command to add the flag of a secondary operator.
ADD UCNOPERATOR: OperatorType=SEC, CnOperatorName="Telus",
Run the ADD UCNOPERATOR command to add the flag of a common operator.
ADD UCNOPERATOR: OperatorType=COMM, CnOperatorName="Common",
2. Add an operator group.
Run the ADD UCNOPERGROUP command to add an operator group.
ADD UCNOPERGROUP: CnOpGrpIndex=0, CnOpGrpName="Canada",
CnOpNum=TWO, CnOpIndex1=0, CnOpIndex2=1, CnOpIndexComm=5;
If no common operator is configured, the common operator index in an operator group is
set to 255 by default. CnOpIndex1 specifies the common operator.
3. Set operator configuration parameters.
Run the SET UOPERATORCFGPARA command to set configuration parameters
of a primary operator.
SET UOPERATORCFGPARA: CnOpIndex=0,
CsNriCfgMode=SUPP_IUFLEX_MOCN, PsNriCfgMode=SUPP_IUFLEX_MOCN,
CSNRILength=7, PSNRILength=10, NullNRI=0;
In this example, operator configuration parameters need to be set to support Iu Flex +
MOCN. The CS NRI length is 7 bits and PS NRI length is 10 bits. NullNRI is set to
0 or 1.
Run the SET UOPERATORCFGPARA command to set configuration parameters
of a secondary operator.
SET UOPERATORCFGPARA: CnOpIndex=1,
CsNriCfgMode=SUPP_IUFLEX_MOCN, PsNriCfgMode=SUPP_IUFLEX_MOCN,
CSNRILength=7, PSNRILength=10, NullNRI=1;
5.10.3 Adding CN Nodes

Run the ADD UCNNODE command to add CN nodes of the primary operator.
ADD UCNNODE: CnOpIndex=0, CNId=10, CNDomainId=CS_DOMAIN,
CNLoadStatus=NORMAL;
ADD UCNNODE: CnOpIndex=0, CNId=20, CNDomainId=PS_DOMAIN,

2017-8-11 Page 83 of 94
name.
Run the ADD UCNNODE command to add CN nodes of a secondary operator.

ADD UCNNODE: CnOpIndex=1, CNId=11, CNDomainId=CS_DOMAIN,
ADD UCNNODE: CnOpIndex=1, CNId=21, CNDomainId=PS_DOMAIN,
Run the ADD UNRIGLBCNIDMAP command to add the mapping between the NRI
and the global CN node.
ADD UNRIGLBCNIDMAP: CnOpIndex=0, CNId=10, NRI=10;
5.10.4 Adding NodeBs

Run the ADD UNODEB command to add an MOCN NodeB.
ADD UNODEB: TnlBearerType=IP_TRANS, HostType=SINGLEHOST,
SharingType=MOCN;
Run the ADD UNODEB command to add a dedicated NodeB.
ADD UNODEB: TnlBearerType=IP_TRANS, HostType=SINGLEHOST,
SharingType=DEDICATED, CnOpIndex=0;
Resource management of the MOCN NodeB supports only the sharing mode. Therefore,
when an MOCN NodeB is added, the resource management mode cannot be set to dedicated.
5.10.5 Adding Cells

Run the ADD ULAC command to add a location area.
PLMNVALTAGMAX=256;
PLMNVALTAGMAX=256;
In MOCN scenarios, the primary and secondary operators must have the same location
area. Therefore, the same LAC is set for the primary and secondary operators.
Run the ADD UQUICKCELLSETUP command to set up an MOCN cell.
ADD UQUICKCELLSETUP: PeerIsValid=INVALID, CnOpGrpIndex=0, LAC=H'7208,
SupBmc=FALSE;
Run the ADD UEXT3GCELL or ADD UEXT2GCELL command to add a
neighboring RNC cell.
ADD UEXT3GCELL: CellHostType=SINGLE_HOST, CnOpGrpIndex=0,
QqualminInd=FALSE, QrxlevminInd=FALSE, MaxAllowedUlTxPowerInd=FALSE,
UseOfHcs=NOT_USED;
ADD UEXT2GCELL:GSMCELLINDEX=1001, GSMCELLNAME="BKA1156A1",
MCC="520", MNC="99", CNOPGRPINDEX=0, LAC=H'3ADB,
CFGRACIND=NOT_REQUIRE, CID=H'03E9, NCC=4, BCC=5, BCCHARFCN=519,
BANDIND=GSM900_DCS1800_BAND_USED, RATCELLTYPE=EDGE,
USEOFHCS=NOT_USED, NCMODE=NC0, SUPPRIMFLAG=FALSE,
SUPPPSHOFLAG=FALSE, CIO=0, NBSCINDEX=0, LDPRDRPRTSWITCH=OFF;
When a neighboring RNC cell is added, the operator group index must be entered. In this
example, the local operator group index is entered.

2017-8-11 Page 84 of 94
name.
5.10.6 Adding the Roaming Relationship and Roaming Capacity

Proportion
This item is applicable to RAN13.0.
ADD UROAMMAP: MCC="460", MNC="07", CnOpIndex=1, CnOpGrpIndex=1,
AvailRoamCap=50;
The AvailRoamCap parameter involved in the roaming relationship is used to calculate the
proportion of roaming UEs. An absolute value is invalid.

RNC configuration:
According to proportion of HSDPA power, use cell resource:

SET URRCTRLSWITCH: IubPrivateInterfaceSwitch=PSCRR_OpIndex_INCLUDED-1;
SET URRCTRLSWITCH: IubPrivateInterfaceSwitch=RL_OpIndex_INCLUDED-1;
MOD UCELLALGOSWITCH: CellId=0, NBMCacAlgoSwitch=HSDPA_GBP_MEAS-1;
MOD UNRNC: NRncId=1, IurPrivateInterfaceSwitch=PLMNID_INCLUDED-1;
MOD UCELLCAC: CellId=1, NonHPwrForGBPPreemp=40;
ADD UCELLMOCNDPAPOWERDEMAR: CellId=1, CnOpIndex=0,
DPAAvaiPwrRatio=10;
MOD UCELLALGOSWITCH: CellId=1,
DemarcPreemptSwitch=MOCN_DEMARC_PREEMPT_GBP-1;
ADD UCELLLICENSE: CellId=1,
FuncSwitch1=CELL_MOCN_DEMARCATION_SWITCH-1;
According to proportion of R99 downlink code, use cell resource:
ADD UCELLMOCNSFDEMAR: CellId=1, CnOpIndex=0, DLAvaiSFRatio=10;
DemarcPreemptSwitch=MOCN_DEMARC_PREEMPT_SF-1;
MOD UCELLALGOSWITCH: CellId=1, NBMLdcAlgoSwitch=CELL_CODE_LDR-1;
NbmSFLdcUeSelSwitch=NBM_SF_LDC_DEMARC;
ADD UCELLLICENSE: CellId=1,
FuncSwitch1=CELL_MOCN_DEMARCATION_SWITCH-1;
NodeB configuration:
SET MACHSPARA: LOCELL=0, RSCALLOCM=POWERCODE_BAL;

2017-8-11 Page 85 of 94
name.
5.11 Acceptance Solution

The MOCN acceptance criteria involves the functionality test and KPI test.
1. Functionality test
License support
UE registration and basic services in an MOCN cell
Mobility (inter-MOCN cell relocation and MOCN-to-independent cell handover)
2. Network KPI test
Check KPIs before and after MOCN reconstruction and ensure that no KPI deteriorates
obviously.
Note: The test method please refer to the corresponding test instruction document.
5.12 Impact on Network KPIs

In TMV/BFKT offices of Thailand, after the MOCN is reconstructed, the Iu CS paging
success rate decreases by 10%. The analysis on the RNC and CN shows that the CSG IE in
the MSC is abnormal.
After the CSG IE in the MSC becomes normal, the Iu CS paging success rate increases, with a
slight decrease of 1% to 2% compared with that before MOCN reconstruction. However, the
Universal Terrestrial Radio Access Network (UTRAN) paging success rate still decreases by 2%
to 3%.
For MOCN Cell Resource Demarcation, With the MOCN Cell Resource Demarcation feature,
the RNC is more likely to trigger preemption and the call drop rate increases in a cell with
heavy load if any operator uses more DL R99 SCs or HSDPA power resources than its
predefined resource percentage. In a cell with light load, however, this feature has no impact
on network performance because preemption is not triggered.

2017-8-11 Page 86 of 94
name.
6 Design of Feature Combination Policies
6.1 Design Overview

This section describes the design of RAN Sharing, Iu Flex, and MOCN combination policies.
6.2 Design of Feature Combination Policies

The following table lists the characteristics of three features.
Feature Whether Multiple Whether CNs Whether Frequency

CNs Are Belong to an Spectrum Resources
Connected Operator Are Shared
Iu Flex Yes Yes Yes
MOCN Yes No Yes
RAN Sharing with Yes No No
independent
carriers
Multi-logical RNC (MRNC) is implemented at phase 1 and phase 2. Therefore, in narrow

terms, the MRNC is called RAN Sharing.
RAN10.0 supports the combination of Iu Flex and RAN Sharing with independent carriers. In
actual scenarios, commercial requirements are available.
Iu Flex + RAN Sharing
RAN11.0 supports the following two feature combinations:
Iu Flex + RAN Sharing
Iu Flex + MOCN
Currently, there are no actual commercial requirements for the coexistence of MOCN
and RAN Sharing in an RNC, and the product does not support the coexistence. If a
network is required to provide both independent carriers and shared carriers, the MOCN
operator group is used. That is, RAN Sharing can use only one operator in the operator
group, which indicates that a cell belongs to only one operator.

2017-8-11 Page 87 of 94
name.
6.2.1 Iu Flex + RAN Sharing

In the MRNC, a domain of an operator can have multiple CN nodes.
6.2.2 Iu Flex + MOCN

In the MOCN, a domain of an operator can have multiple CN nodes.
6.3 Design of Shared NodeB Types

The NodeB shared by the primary and secondary operators is called a shared NodeB. The
NodeB types are as follows:
MOCN NodeB: does not support separated Iub transmission.
RAN Sharing NodeB: supports shared or separated Iub transmission.
Dedicated NodeB: is for the exclusive use of an operator. It is also called a non-shared
NodeB.
The following table compares the three types of NodeB.
NodeB RNC Configuration NodeB Configuration

Sharing Mode
Whether to Support Whether the Resource
Network Sharing NodeB Is Shared Management Mode
MOCN NodeB Yes Yes Shared

2017-8-11 Page 88 of 94
name.
NodeB RNC Configuration NodeB Configuration

Sharing Mode
Whether to Support Whether the Resource
Network Sharing NodeB Is Shared Management Mode
RAN Sharing Yes Yes Shared or separated
NodeB
Dedicated Depending on actual No -
NodeB requirements
The resource management mode is specified for Iub bandwidth allocation, which corresponds
to the RscMngMode parameter in the ADD NODEB command.
A dedicated NodeB belongs to only one operator. Therefore, resource management for
multiple operators does not exist. During the dedicated NodeB configuration, RscMngMode
is set to SHARE by default.
A dedicated NodeB and a shared NodeB can coexist under an RNC, but the RAN Sharing
NodeB and MOCN NodeB cannot.
To prevent handovers between different operators, it is recommended that all NodeBs under
an RNC be shared unless otherwise specified.

2017-8-11 Page 89 of 94
name.
7 RAN Sharing Product Specifications
7.1 Product Specifications

7.1.1 RAN Sharing-Related Specifications(RAN17.0)
The following table describes RNC specifications involved in RAN sharing.
Item RAN10.0 Specifications

Multi-CN Nodes or MSC/SGSN/MGW/NRNC/CBC Up to
Neighboring RNC 32 MSCs
32 SGSNs
32 MGWs
15 Neighboring RNC
4 CBCs
4 Operators
can be supported
MOCN Roaming relationship Each operator sharing an RNC
Enhancement can configure a maximum of 512
roaming operators.
7.1.2 Other Product Specifications

For other specifications of the RNC and NodeB, please refer to 3ms on the latest product
specifications document:
3ms link address

http://3ms.huawei.com/mm/docMaintain/mmMaintain.do?method=showMMDetail&f_i
d=SR13021803400052
Note: product specifications document with the version on 3ms routine release, please get the
latest version of the product specifications from 3ms.

2017-8-11 Page 90 of 94
name.

2017-8-11 Page 91 of 94
name.
8 Commercial Applications of RAN Sharing
Currently, the number of commercial RAN Sharing offices is smaller than the number of
commercial UMTS offices. However, RAN Sharing offices are facing a growth as operators
pay more attention to the Capital Expenditure (CAPEX) and Operational Expenditure
(OPEX).
The following table lists the commercial RAN Sharing offices of Huawei.
Country Operator Mode

Spain VDF RAN Sharing (Dedicated Carrier)
Orange
Sweden TeliaSonera MOCN
Tele2
Australia VDF RAN Sharing (Dedicated Carrier)
Optus
Australia Telstra MOCN
H3G
Canada Telus MOCN
Bell
Sweden H3G MOCN
Telenor
Poland Sferia RAN Sharing
AERO2

2017-8-11 Page 92 of 94
name.
9 Appendix
9.1 Scripts for Commercial Offices

The scripts provide a reference for network design delivery personnel during project delivery.
9.1.1 RAN Sharing

Script for the RAN10.0 commercial office:
9.1.2 MOCN

2017-8-11 Page 93 of 94
name.
10 Abbreviations and Acronyms
Abbreviation Full Spelling

3G Third-generation technology
3GPP 3rd Generation Partnership Project
CAPEX Capital Expenditure
OPEX Operational Expenditure
RAN Radio Access Network
CN Core Network
IMSI International Mobile Subscriber Identity
MCC Mobile Country Code
MNC Mobile Network Code
MSC Mobile Switching Center
MOCN Multi-Operator Core Network
UTRAN Universal Terrestrial Radio Network Access
PLMN Public Land Mobile Network
RNC Radio Network Controller
SGSN Serving GPRS Support Node
TMSI Temporary Mobile Subscriber Identity
UE User Equipment

2017-8-11 Page 94 of 94
name.

RAN Sharing - HQoS Guidelines - Ver. 3.1

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

RAN Sharing - HQoS Guidelines - Ver. 3.1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RAN Sharing - HQoS Guidelines - Ver. 3.1

Uploaded by

Copyright:

Available Formats

Product Version Confidentiality Level

UMTS Professional Services

UMTS RAN Sharing Technology

Huawei Technologies Co., Ltd.

Date Revision Change Description Author ID

Error! Unknown document property

1 About This Document .................................................................................................................. 6

2 RAN Sharing Information Collection ....................................................................................... 8

3 RAN Sharing Features................................................................................................................ 10

Error! Unknown document property

3.2.14 MOCN Independent CE Resource Allocation..................................................................................... 41

4 RAN Sharing Service Design ................................................................................................... 45

5 MOCN Service Design ............................................................................................................... 66

Error! Unknown document property

5.3.1 Iu Interface ............................................................................................................................................ 71

6 Design of Feature Combination Policies ................................................................................ 87

7 RAN Sharing Product Specifications ...................................................................................... 90

8 Commercial Applications of RAN Sharing ........................................................................... 92

10 Abbreviations and Acronyms ................................................................................................. 94

Error! Unknown document property

1 About This Document

1.2 Applicable Versions and Scope

1.3 Intended Audience

Error! Unknown document property

Applicable Network Topologies

Applicable Network Construction Scenarios

Error! Unknown document property

2 RAN Sharing Information Collection

2.1 Operator Requirements

2.2 Necessary Information

Error! Unknown document property

Error! Unknown document property

3 RAN Sharing Features

Error! Unknown document property

3.1 Overview of RAN Sharing

Figure 3-1 Private NodeBs in RAN Sharing

A dedicated RAN sharing RAN sharing

Error! Unknown document property

Figure 3-2 Differentiated QoS configuration of RAN Sharing

Supports the long-term evolution of Evolved High-Speed Packet Access (HSPA+).

Error! Unknown document property

3.1.1 System Information Broadcasting

3.1.2 Initial NAS Message Routing

3.1.3 Requirements of RAN Sharing on the CN

3.1.4 Operator CBS Deployment

3.1.5 Operator Dedicated Features

Error! Unknown document property

Table 3-1 Optional features and parameter levels

Optional Feature Parameter Level

Error! Unknown document property

Optional Feature Parameter Level

3.1.6 RAN Sharing Mobility Management

Handovers Between RAN Sharing Cells and Private Cells (Intra-Operator)

Error! Unknown document property

Error! Unknown document property

Figure 3-4 Reselection from a 2G roaming cell to a RAN Sharing cell

Reselection from a 2G cell

Generally, the Registered PLMN (RPLMN) is preferred. When a UE of OpB