Multiple Operator Core Network

Multiple Operator Core Network This is a way to share the network resources among multiple operators. The same network infrastructure is used to transmit/receive for different operators. The MIB contains a list of multiple PLMN Identities. The UE reads the MIB and selects a PLMN to register to, based on its subscription.

MIB Contents: ......... Common PLMN .......... mibPLMN-Identity BOOLEAN, mibPLMN-Identity multiplePLMNs multiplePLM Ns SEQUENCE (SIZE(1..5)) •

PLMN1

•

PLMN2

PLMN1, PLMN2, etc are the multiple PLMNs in the cell. If mibPLMN-Identity is st to TRUE, the supporting UE can include the common common PLMN identity also in the list of PLMNs to choose from. If it is FALSE, the supporting UE does not attempt to register on the common PLMN.

The terms associated with MOCN and their definitions are:

Conventional network: A network: A PLMN consisting of radio access network and core network, by which only one serving operator provides services to its subscriber. Subscribers of other operators may  receive services by national or international roaming. Common PLMN: The PLMN-id indicated in the system broadcast information as defined for conventional networks, which non-supporting UEs understand as the serving operator. Core network operator: An operator: An operator that provides services to subscribers as one of multiple serving operators that share at least a radio access network. Each core network operator may provide services to subscriber of other operators by national or international roaming. Gateway Core Network : A network sharing configuration in which part s of the core network  (MSC/SGSNs) are also shared. Multi-Operator Core Network : A network-sharing configuration in which only t he RAN is shared. Non-supporting UE: A UE: A UE that does not support network sharing in the sense that it ignores the additional broadcast system information that is specific for network sharing. In other specifications, the term "network sharing non-supporting UE" may be used. Supporting UE: A UE that supports network sharing in the sense that it is able to select a core network operator as the serving operator within a shared network. In other specifications, the term "network sharing supporting UE" may be used.

http://3gpphelp.blogspot.com/2011/10/comparison-of-lte-security-and-umts.html

Comparison of LTE Security and UMTS Security LTE has inherited most of the Security architecture from UMTS, some enhancements have also been made. While there are lot of places to find the overview of the LTE Security architecture, a side-by-side comparison with UMTS wil l be helpful for peopple coming from UMTS background. Security Elements

Authentication and Key Agreement

UMTS •

•

based on UMTS-AKA key derivation from the UMTS Authentication Quintuplet(RAND, CK, IK, RES, AUTN)

LTE •

•

•

•

Integrity

based on EPS-AKA key derivation from the UMTS Authentication Quintuplet(RAND, CK, IK, RES, AUTN) Key Derivation Functions use HMAC-SHA-256 K(ASME) computed from CK, IK, and AUTN, which is used for Integrity and Encryption keys

UMTS •

Integrity protection mandatory for only few RRC messages.

•

Integrity Protection Algorithm o

UIA1: Kasumi

LTE •

•

Encryption

Integrity Protection mandatory for all messages after (and including) Security Mode Command Integrity Protection Algorithm o

128-EIA 1: based on SNOW 3G

o

128-EIA 2: based on AES-128

UMTS •

Encryption Algorithm o

UEA0: no encryption.

o

UEA1: Kasumi.

LTE •

•

•

Encrption done independently at two levels o

NAS - for EMM and ESM messgaes

o

PDCP-SRB(1 and 2) and DRB (1 .. 11)

two SECURITY MODE COMMANDS for two sets of keys o

{K(NAS-enc), K(NAS-integrity)}

o

{K(RRC-enc), K(RRC-integrity)}

Encryption Algorithm o

128-EEA 0: No Encrption

o

128-EEA 1: based on SNOW 3G

o

128-EEA 2: based on AES-128

Why is CELL_FACH and CELL_PCH not required in LTE?

Before answering that question, lets look at the RRC states in UMTS and what was accomplished by having these. CELL_DCH state •

A dedicated physical channel is allocated to the UE in uplink and downlink.

•

High data rate can be supported because of the dedicated resources

CELL_FACH state •

No dedicated physical channel is allocated to the UE.

•

UE is on shared channel in downlink and uplink.

•

UE keeps monitoring the FACH channel for transmission destined to its C-RNTI.

•

In the Uplink it can access the RACH channel to send small amounts of data.

•

UE was put in CELL_FACH to save some dedicated channel resources in network.

CELL_PCH state •

•

•

•

•

No dedicated or shared physical channel is allocated to the UE. The UE selects a PCH with the algorithm, and uses DRX for monitoring the selected PCH via an associated PICH. No uplink activity is possible. The position of the UE is known by UTRAN on cell level according to the cell where the UE last made a cell update in CELL_FACH state. UE was put in CELL_PCH when there is no activity for a period of time. This saved battery in UE.

URA_PCH: •

•

•

•

•

No dedicated channel is allocated to the UE. The UE selects a PCH with the algorithm, and uses DRX for monitoring the selected PCH via an associated PICH. No uplink activity is possible. The location of the UE is known on UTRAN Registration area level according to the URA assigned to the UE during the last URA update in CELL_FACH state. UE was put in this state to avoid frequent CELL UPDATES

LTE has only two RRC STATES RRC_IDLE •

there is no RRC CONNECTION and no DTCH/DCCH allocated

•

UE can receive Cell Broadcast and monitors paging for incoming call

•

UE does cell reselections based on neighbor cell measurements

•

UE is not known by the eNodeB

RRC_CONNECTED

•

RRC Connection exitsts and UE can receive/transmit data on shared channels

•

UE monitors the control channels corresponding to the Shared Data channels

•

UE provides channel quality and feedback information

•

eNodeB configures DRX based on UE activity.

•

UE is known at cell level

In LTE, the RRC_CONNECTED state has the benefits of CELL_FACH and to some extent CELL_PCH incorporated in it. Since in the downlink the scarce resource is the resource blocks, the downlink logical channels are always mapped onto shared transport channels(exhibiting the CELL_FACH properties). While in RRC_CONNECTED, the UE is configured with DRX cycles, conserving the battery in the UE. With just two RRC states, the RRC state machine is simplified to a great extent, saving a lot of signalling.

Migration to VoIP over mobile networks: Technical challenges and economic opportunity analysis

•

•

•

Access The Full Text SIGN IN:Full text access may be available with your subscription User Name Password

Forgot Username/Password?

•

Athens/Shibboleth Sign In

•

Badard, B. Diascorn, V. Boulmier, G. Vicard, A.D. Renard, V. Dimassi, A.H. Orange Labs., France Telecom, Issy-les-Moulineaux, France This paper appears in: Telecommunications Network Strategy and Planning Symposium (NETWORKS), 2010 14th International Issue Date: 27-30 Sept. 2010 On page(s): 1 - 7 Location: Warsaw Print ISBN: 978-1-4244-6704-4 INSPEC Accession Number: 11639820 Digital Object Identifier: 10.1109/NETWKS.2010.5624906 Date of Current Version: 09 November 2010

ABSTRACT In 3GPP standard, LTE networks are currently specified by considering Mobile VoIP combined with IMS for session control to ensure voice calls support. So, Mobile VoIP over LTE with IMS can be considered as a target for voice support migration from the current support in Circuit Switched (CS) Domain. Because Mobile VoIP services could potentially be supported over HSPA in the coming years and LTE coverage will probably not correspond to HSPA networks coverage before several years, it is necessary to assess if there is a potential interest and way to anticipate Mobile VoIP services launch with, first, a support over HSPA/HSPA+. Thus, on the first hand, the aim of this paper is to analyse the architecture evolutions of current mobile networks for voice support as Mobile VoIP over HSPA/HSPA+, CS over HSPA, the corresponding drivers but also technical requirements, limitations and maturity on the different network parts. On the second hand, the paper aims at analysing the economic appropriateness of supporting voice services over those architecture evolutions. For this, two different analyses have been carried out in parallel. The first one addresses the economic opportunity for a 3G mobile network operator, in terms of expenditure savings, to deploy VoIP over HSPA and/or CS over HSPA. The second analysis assesses the possible costs for VoIP services, in the perspective of  tariff setting. In this analysis, "fair" allocation mode based on the traffic of the different services is favoured. Finally, this paper synthesizes the different pros and cons of each solution in terms of QoS, capacity performance, development maturity and techno-economic analysis. Depending on operator's strategy for migration to VoIP over LTE, the choice of launching one solution prior to another will have to take into account all these topics.