| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 ICT 기업 총람 |

제품 검색

| 네트워크/통신 뉴스 | 기술자료실 | 자유게시판 |  
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 
스폰서채널 |

 

  스폰서채널 서비스란?
Scenarios for EPS/LTE Interoperability Testing
August 19, 2009 | By MSF
코멘트 (0)
6

MSF(MultiService Forum)에서 작성한 EPS/LTE Interoperability testing 관련 문서로, 다음 시나리오를 기술하고 있습니다: Basic Interoperability, Roaming, NonLTE Access, Handover

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Transcript
Scenarios for EPS / LTE Interoperability
Testing

MSF-EPS-LTE-SCN-001.FINAL

MultiService Forum
Implementation Agreement

Contribution Number msf2009.005.03

Document Filename: msf2009.005.03.doc

Working Group: Architecture

Title: Scenarios for EPS / LTE Interoperability Testing

Editor: Dave Hutton (Vodafone), Stuart Walker (Senior Fellow)

Working Group Chairperson: Stuart Walker (Senior Fellow)

Date: 19th August 2009

Abstract:
The MultiService Forum (MSF) is responsible for developing Implementation
Agreements or Architectural Frameworks which can be used by developers and
network operators to ensure interoperability between components from different
vendors. MSF Implementation Agreements are formally ratified via a Straw Ballot and
then a Principal Member Ballot.

Draft MSF Implementation Agreements or Architectural Framework may be published
before formal ratification via Straw or Principal Member Ballot. In order for this to take
place, the MSF Technical Committee must formally agree that a draft Implementation
Agreement or Architectural Framework should be progressed through the balloting
process. A Draft MSF Implementation Agreement or Architectural Framework is
given a document number in the same manner as an Implementation Agreement.

Draft Implementation Agreements may be revised before or during the full balloting
process. The revised document is allocated a new major or minor number and is
published. The original Draft Implementation Agreement or Architectural Framework
remains published until the Technical Committee votes to withdraw it.

After being ratified by a Principal Member Ballot, the Draft Implementation
Agreement or Architectural Framework becomes final. Earlier Draft Implementation
Agreements or Architectural Frameworks remain published until the Technical
Committee votes to withdraw them.

The use of capitalization of the key words “MUST”, “SHALL”, “REQUIRED”, “MUST
NOT”, “SHOULD NOT”, “SHOULD”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY” or “OPTIONAL” is as described in section V-B of the MSF Technical
Committee Operating Procedures.

The goal of the MSF is to promote multi-vendor interoperability as part of a drive to
accelerate the deployment of next generation networks. To this end the MSF looks to
adopt pragmatic solutions in order to maximize the chances for early deployment in
real world networks.

To date the MSF has defined a number of detailed Implementation Agreements and
detailed Test Plans for the signaling protocols between network components and is
developing additional Implementation Agreements and Test Plans addressing some
of the other technical issues such as QoS and Security to assist vendors and
operators in deploying interoperable solutions.

The MSF welcomes feedback and comment and would encourage interested parties
to get involved in this work program. Information about the MSF and membership
options can be found on the MSF website http://www.msforum.org/

Note: Attention is called to the possibility that use or implementation of this MSF
Implementation Agreement may require use of subject matter covered by intellectual
property rights owned by parties who have not authorized such use. By publication
of this Implementation Agreement, no position is taken by MSF as its Members with
respect to the existence or validity of any intellectual property rights in connection
therewith, nor does any warranty, express or implied, arise by reason of the
publication by MSF of this Implementation Agreement. Moreover, the MSF shall not
have any responsibility whatsoever for determining the existence of IPR for which a
license may be required for the use or implementation of an MSF Implementation
Agreement, or for conducting inquiries into the legal validity or scope of such IPR that
is brought to its attention.



DISCLAIMER

The information in this publication is believed to be accurate as of its publication
date. Such information is subject to change without notice and the MultiService
Forum is not responsible for any errors or omissions. The MultiService Forum does
not assume any responsibility to update or correct any information in this publication.
Notwithstanding anything to the contrary, neither the MultiService Forum nor the
publisher make any representation or warranty, expressed or implied, concerning the
completeness, accuracy, or applicability of any information contained in this
publication. No liability of any kind whether based on theories of tort, contract, strict
liability or otherwise, shall be assumed or incurred by the MultiService Forum, its
member companies, or the publisher as a result of reliance or use by any party upon
any information contained in this publication. All liability for any implied or express
warranty of merchantability or fitness for a particular purpose is hereby disclaimed.



The receipt or any use of this document or its contents does not in any way create by
implication or otherwise:



Any express or implied license or right to or under any MultiService Forum
member company’s patent, copyright, trademark or trade secret rights which
are or may be associated with the ideas, techniques, concepts or expressions
contained herein; nor



Any warranty or representation that any MultiService Forum member
companies will announce any product(s) and/or service(s) related thereto, or
if such announcements are made, that such announced product(s) and/or
service(s) embody any or all of the ideas, technologies, or concepts contained
herein; nor



Any commitment by a MultiService Forum company to purchase or otherwise
procure any product(s) and/or service(s) that embody any or all of the ideas,
technologies, or concepts contained herein; nor



Any form of relationship between any MultiService Forum member companies
and the recipient or user of this document.



Implementation or use of specific MultiService Forum Implementation Agreements,
Architectural Frameworks or recommendations and MultiService Forum
specifications will be voluntary, and no company shall agree or be obliged to
implement them by virtue of participation in the MultiService Forum.




For addition information contact:

MultiService Forum

48377 Fremont Blvd., Suite 117

Fremont, CA 94538 USA

Phone: +1 510 492-4050

Fax: +1 510 492-4001

info@msforum.org

http://www.msforum.org







I. The MultiService Forum



The MultiService Forum (MSF) is a global association of service providers, system suppliers and other
organizations committed to developing and promoting open-architecture, multiservice communication
systems. Founded in 1998, the MSF is an open-membership organization comprised of the world\'s
leading telecommunications companies.



The MSF\'s activities include developing implementation agreements, promoting worldwide
compatibility and interoperability, and encouraging input to appropriate national and international
standards bodies.



As part of MSF’s effort to drive and promote interoperability, the MSF has created a number of
programs geared toward accelerating real world network deployments:



1. Global MSF Interoperability (GMI) events. GMI events provide a real-world setting for
vendors to test their solutions and provide evidence that vendor products meet the
interoperability standards set forth by MSF Implementation Agreements. Each MSF GMI
event is built around a set of capabilities defined for a given release of the MSF Architecture.






2. Next Generation Network (NGN) Test Bed. The NGN test bed provides a facility to enable
carriers and vendors to perform in-depth testing of a specific interface as defined in a given
release of the MSF architecture.






3. Certification Programs. For more mature technologies the MSF can provide Certification of
compliance to a given Implementation Agreement where MSF members believe that it is of
value to the industry to do so.






II. An introduction to MSF R5 documentation



This document is part of the MSF Release 5 set of architectural, protocol and test documentation.



The MSF Release 5 Architecture is a physical implementation of the functional architectures that have
been proposed by the key Standards Development Organizations. As such the MSF Release 5
Architecture represents the current state of the industry and it identifies current open interfaces between
physically separate network elements.



MSF Implementation Agreements define the protocols to be used over specific open interfaces. Where
possible MSF Implementation Agreements are based on industry standard protocols augmented with
additional information so as to ensure interoperability between communicating network elements. This
level of interoperability is achieved by closing any gaps and tightening any optional capabilities in
those industry standards to remove the danger of mutually incompatible selections by vendors. An
MSF Implementation Agreement is targeted at a given release of the MSF architecture but can be used
in any circumstance where an operator wishes to deploy the open interface and its functionality within
their own network.




The MSF Release 5 architecture and its associated implementation agreements are used as the basis for
MSF Interoperability Events in the 2009-10 timeframe.



Detailed test scenarios will be developed and a number of test plans defined for any given MSF
Interoperability Event. Test plans contain the set of test cases required to demonstrate a given MSF
Release 5 capability and serve to exercise and validate the set of Implementation Agreements required
to realize the capability.



Following the completion of a MSF Interoperability Event, the MSF Release 5 architecture and
individual implementation agreements will be updated if the testing identifies any deficiencies in the
documents.



For more information about the scope of MSF Interoperabilty Events, please go to
http://www.msforum.org



III. Impact on previously published MSF documents



This is a new specification for MSF release 5.









1 INTRODUCTION.........................................................................................................................7
1.1 TEST SCENARIOS......................................................................................................................9
2 TESTING SCENARIOS..............................................................................................................10
2.1 SCENARIO 1 . BASIC INTEROPERABILITY................................................................................10
2.1.1 Network Components......................................................................................................11
2.1.2 Protocols and Reference Points......................................................................................12
2.1.3 Test Cases.......................................................................................................................12
2.2 SCENARIO 2 . ROAMING..........................................................................................................14
2.2.1 Network Components......................................................................................................15
2.2.2 Protocols and Reference Points......................................................................................16
2.2.3 Test Cases.......................................................................................................................16
2.3 SCENARIO 3 . NON-LTE ACCESS............................................................................................17
2.3.1 Network Components......................................................................................................18
2.3.2 Protocols and Reference Points......................................................................................19
2.3.3 Test Cases.......................................................................................................................20
2.4 SCENARIO 4 . HANDOVERS.....................................................................................................21
2.4.1 Network Components......................................................................................................22
2.4.2 Protocols and Reference Points......................................................................................23
2.4.3 Test Cases.......................................................................................................................23
3 INTERFACE SPECIFICATIONS..............................................................................................25
3.1 S1-MME (ENB . MME).........................................................................................................25
3.2 S1-U (ENB-SGW)...................................................................................................................25
3.3 S2A........................................................................................................................................25
3.4 S2B.........................................................................................................................................25
3.5 X2 (ENB . ENB).....................................................................................................................25
3.6 S3 (S4 SGSN . MME)............................................................................................................25
3.7 S4 (S4 SGSN . SGW).............................................................................................................25
3.8 S5 (SGW-PGW).....................................................................................................................25
3.9 S6A (HSS . MME)..................................................................................................................25
3.10 S6B (PGW . 3GPP AAA).......................................................................................................25
3.11 S6D (HSS . S4 SGSN)............................................................................................................25
3.12 S8 (SGW . PGW)...................................................................................................................25
3.13 S9 (PCRF . PCRF).................................................................................................................25
3.14 S10 (MME . MME)................................................................................................................26
3.15 S11 (MME . SGW)................................................................................................................26
3.16 S12 (UTRAN . SGW)............................................................................................................26
3.17 GX (PCRF . PGW).................................................................................................................26
3.18 GXC (PCRF-SGW).................................................................................................................26
3.19 RX (PCRF - IP APPLICATION [P-CSCF FOR IMS]).................................................................26
3.20 GR (SGSN . HSS)...................................................................................................................26
3.21 GN (SGSN . MME / SGSN . PGW).......................................................................................26
3.22 GP (SGSN . PGW).................................................................................................................26
3.23 STA........................................................................................................................................26
3.24 SWA.......................................................................................................................................26
3.25 SWM......................................................................................................................................26





1 Introduction






The Evolved Packet System (EPS) is an evolution of the 3GPP defined architecture aimed at coping
with the rapid growth in IP data traffic. EPS was defined in 3GPP Release 8 and comprised two main
components.

. Radio Access Network. The Evolved Universal Terrestrial Radio Access Network (E-
UTRAN); this is often referred to as 3G Long Term Evolution (LTE).


. Core Network. The Evolved Packet Core (EPC), this is often referred to as the System
Architecture Evolution (SAE).






The figure below shows the main components of the EPS in the simplest (non-roaming) configuration.



GxSGiRxS1-US1-MMES10S-11S4S12MMES-GWHSSP-GWPCRFUEENBLTE-UuS5S6aS4-SGSNUTRANGERANS3S6dOperator IP
Services
(e.g. IMS)


Figure 1 - EPS Architecture

The main components of the Architecture are described below.



. UE (User Equipment). The User Equipment that is used to connect to the EPS, in the figure
above this is an LTE capable UE accessing EPS via the LTE-Uu radio interface.






. ENB (eNodeB). The evolved RAN (E-UTRAN) consists of a single node, the eNodeB (ENB)
that interfaces with the UE. The eNodeB hosts the Physical (PHY), Medium Access Control
(MAC), Radio Link Control (RLC), and Packet Data Convergence Protocol (PDCP) layers
that include the functionality of user-plane header-compression and encryption. It also offers
Radio Resource Control (RRC) functionality corresponding to the control plane. It performs
many functions including radio resource management, admission control, scheduling,
enforcement of negotiated UL QoS, cell information broadcast, ciphering/deciphering of user
and control plane data, and compression/decompression of DL/UL user plane packed headers.






. MME (Mobility Management Entity). The Mobility Management Entity (MME) is the key
control-node for the LTE access-network. It is responsible for idle mode UE tracking and
paging procedures including retransmissions. It is involved in the bearer activation /
deactivation process and is also responsible for choosing the SGW (see below) for the UE at
the initial attach and at time of intra-LTE handover involving Core Network node relocation.
It is responsible for authenticating the user (in conjunction with the HSS). The NAS (Non-
Access Stratum) signalling terminates at the MME which is also responsible for the generation
and allocation of temporary identities to the UEs. The MME validates the permission of the
UE to camp on the service provider’s PLMN (Public Land Mobile Network) and enforces UE
roaming restrictions. The MME is the termination point in the network for ciphering/integrity
protection for NAS signalling and handles security key management. Lawful interception of
signalling is also a function provided by the MME. The MME provides the control plane





function for mobility between LTE and 2G/3G access networks and interfaces with the home
HSS for roaming UEs.






. S-GW (Serving Gateway). The S-GW routes and forwards user data packets, while also
acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the
anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and
relaying the traffic between 2G/3G systems and PDN GW). For idle state UE, the S-GW
terminates the DL data path and triggers paging when the DL data arrives for the UE. It
manages and stores UE contexts and performs replication of the user traffic in case of lawful
interception. It is likely that the S-GW and P-GW functions would be realized as a single
network element.






. P-GW (Packet Data network GateWay). The P-GW provides connectivity between the UE
and external packet data networks, it provides the entry and exit point of traffic for the UE. A
UE may have simultaneous connectivity with more than one P-GW for accessing multiple
Packet Data Networks. The PGW performs policy enforcement, packet filtering for each user,
charging support, lawful interception and packet screening. The P-GW also acts as the anchor
for mobility between 3GPP and non-3GPP technologies such as WiMAX or DSL. It is likely
that the S-GW and P-GW functions would be realized as a single network element.






. PCRF (Policy Charging and Rules Function). The PCRF provides policy control decisions
and flow based charging controls. The PCRF determines how a service data flow shall be
treated in the enforcement function (PGW in this case) and ensure that the user plane traffic
mapping and treatment is in accordance with the user’s profile.






. HSS (Home Subscriber Server). The HSS is a network database that holds both static and
dynamic data elements related to subscribers. The HSS provides user profile information to
the MME during user authentication.






. S4-SGSN (Serving GPRS Support Node). The SGSN supports the legacy access for
UTRAN and GERAN. In the EPS architecture (3GPP release 8) the SGSN is enhanced to
support the S4 and S3 interfaces (hence referred to as the S4 SGSN). The S4 interface
provides control and mobility support between GPRS Core and the 3GPP Anchor function of
the Serving GW. The S3 interface enables user and bearer information exchange for inter
3GPP access network mobility.








The main interfaces of the Architecture are described below.



. LTE-Uu. The radio interface between the eNodeB and the User Equipment. Interoperability
of this interface is out of scope for the scenarios described in this document and is covered by
the work of other organizations, principally LTSI.






. S1-MME. The control plane interface between EUTRAN and MME. The protocols used over
this interface are the Non-access stratum protocols (NAS).






. S1-U. The interface between EUTRAN and the SGW for per-bearer user plane tunnelling and
inter-eNB path switching during handover. The transport protocol over this interface is GPRS
Tunnelling Protocol-User plane (GTPv1-U).






. S3. The interface between the S4-SGSN and the MME enabling user and bearer information
exchange for inter 3GPP access network mobility. The protocol used on the S3 interface is
GPRS Tunnelling Protocol-Control plane (GTPv2-C).






. S4. The interface between the S4-SGSN and the SGW providing user plane and related
control and mobility support. The protocols used on the S4 interface are GPRS Tunnelling
Protocol-Control plane (GTPv2-C) and is GPRS Tunnelling Protocol-User plane (GTPv1-U).







. S5. The interface provides user plane tunnelling and tunnel management between SGW and
PGW. It is envisaged that the SGW and PGW may be realized as single network element in
which case the S5 interface is not exposed. The protocol used on the S5 interface is either
GTPv1-U/GTPv2-C or PMIPv6.






. S6a. The interface enables the transfer of subscription and authentication data for
authenticating/authorizing user access. The protocol used on the S6a interface is Diameter.






. S10. The interface provides for MME . MME information transfer and is used to enable
MME relocation. The protocol used on the S10 interface is GPRS Tunnelling Protocol-
Control plane (GTPv2-C).






. S11. The interface between the MME and SGW. The protocol used on the S11 interface is
GPRS Tunnelling Protocol-Control plane (GTPv2-C).






. S12. The interface between the legacy UTRAN and the SGW for user plane tunnelling when
direct tunnel is established. The protocol used on the S12 interface is GPRS Tunnelling
Protocol-User plane (GTPv1-U). Usage of the S12 interface is an operator configuration
option.






. Gx. The interface between the PCRF and the PGW, allowing the PCRF direct control over the
policy enforcement functions of the PGW. The protocol used on the Gx interface is Diameter.






. Gxc. The interface between the PCRF and the SGW, allowing the PCRF direct control over
the bearer binding and event reporting functions (BBERF) of the SGW when PMIPv6 is used
as a S5/S8 protocol. The protocol used on the Gxc interface is Diameter.






. Rx. The interface between the appropriate Application Function (the P-CSCF in the case of
IMS) and the PCRF allowing the Application Function to request the application of an
appropriate policy for a session.






. SGi. The interface between the PGW and the Packet Data Network which can be an operator
external public or private packet data network or an intra operator packet data network (e.g.
for provision of IMS services).










1.1 Test Scenarios






This document describes four test scenarios that will be used to exercise interoperability of the key
interfaces of the EPS architecture these being:-



Basic Interoperability. In this scenario a single instance of the EPS architecture will be created using
components from different vendors. Testing will include attachment and detachment from the network,
Tracking Area Update, IPCAN session establishment, SIP registration (to IMS), SIP session
establishment, MME pooling and SGW Selection.



Roaming. In this scenario the different roaming scenarios are tested including the home routed traffic
model and the local breakout model with both home and visited operator applications. The test set will
be the same as for the Basic Interoperability case (with the exception of MME pooling).



Non-LTE Access. In this scenario, the ‘legacy’ 3G access types of UMTS (UTRAN) and EDGE
(GERAN) are used to interface to the EPC along with non-3G access such as DSL or WIMAX. The
test set will be the same as for the Basic Interoperability case (with the exception of MME pooling).



Handover. In this test case the different handover scenarios are tested, this will include handover
between eNBs, MME/SGW relocation and handover between LTE and legacy 3G (UMTS, EDGE)
access.




2 Testing Scenarios


2.1 Scenario 1 . Basic Interoperability






The architecture for the Basic Interoperability test case is shown in the figure below. The interfaces for
which interoperability will be tested are shown in red (viz S1-MME, S1-U, S-11, S6a, Gx and Rx). In
some circumstances it may be necessary to interoperate multiple of the interfaces together rather than
in isolation.





Figure 2 - Scenario 1a Physical Architecture . Basic Configuration



Additionally an extension scenario 1b (shown below) extends the basic architecture in order to
demonstrate MME ‘pooling’ and test the interoperability of the pooling function.



MMES-GWHSSP-CSCFP-GWPCRFIMS CoreS-11S5GxSGiRxS6aS1-MMEIMS UAIMS UAUEMMEMMES-11S-11S6aS6aENBLTE-UuS1-MMES1-MMES1-UMME PoolS10S10S10




Figure 3 - Scenario 1b Physical Architecture . MME Pooling

Additionally an extension scenario 1c (shown below) extends the basic architecture in order to
demonstrate S-GW Selection and test the interoperability of the selection function.




S-GWS-GWHSSP-CSCFP-GWPCRFIMS CoreS5GxSGiRxS1-MMEIMS UAIMS UAUES-GWMMES-11S6aENBLTE-UuS1-US-11S-11S1-US1-US5S5


Figure 4 - Scenario 1c Physical Architecture . S-GW Selection



2.1.1 Network Components


2.1.1.1 Scenario 1a




The following components are required for this scenario.



. One LTE UE (likely a data dongle on a laptop).


. One IMS UA to run on the LTE UE (likely a soft client on a laptop).


. One eNB


. One MME


. One S-GW


. One P-GW


. One PCRF


. An IMS Core with the P-CSCF exposing the Rx interface and the HSS exposing the S6a
interface.


. An IMS UA registered with the IMS Core.






2.1.1.2 Scenario 1b




The following components are required for this scenario.



. At least one LTE UE (likely a data dongle on a laptop) per MME instance.


. One IMS UA per LTE UE (likely a soft client on a laptop).


. One eNB


. Two or more MME\'s configured in a pool.


. One S-GW


. One P-GW


. One PCRF


. An IMS Core with the P-CSCF exposing the Rx interface and the HSS exposing the S6a
interface.


. An IMS UA registered with the IMS Core.






2.1.1.3 Scenario 1c




The following components are required for this scenario.



. At least one LTE UE (likely a data dongle on a laptop) per MME instance.





. One IMS UA per LTE UE (likely a soft client on a laptop).


. One eNB


. One MME.


. Two or more S-GW\'s


. One P-GW


. One PCRF


. An IMS Core with the P-CSCF exposing the Rx interface and the HSS exposing the S6a
interface.


. An IMS UA registered with the IMS Core.






2.1.2 Protocols and Reference Points




The following reference points will be interoperated in this scenario.



Interface Protocol Sub Scenario

S1-MME

NAS

1a, 1b, 1c

S1-U

GTPv1-U

1a, 1b, 1c

S5

GTPv1-U/GTPv2-C or PMIPv6

1a, 1b, 1c

S10

GTPv2-C

1b

S11

GTPv2-C

1a, 1b, 1c

S6a

Diameter

1a

Gx

Diameter

1a

Gxc

Diameter

1a

Rx

Diameter

1a





2.1.3 Test Cases


2.1.3.1 Scenario 1a




The following tests will be executed in order to verify interoperability of the indicated interfaces
between different vendors.



. LTE UE Attach (IP-CAN Session Establishment)


. Tracking Area Update


. LTE UE Detach (IP-CAN Session Tear Down)


. IMS UA Registration (via LTE UE)


. IMS Session Establishment (from IMS UA on LTE UE)


. IMS Session Establishment (from IMS UA directly connected to IMS Core)


. IMS Session Termination (from IMS UA on LTE UE)


. IMS Session Termination (from IMS UA directly connected to IMS Core)






2.1.3.2 Scenario 1b




The following tests will be executed in order to verify interoperability of the indicated interfaces
between different vendors.



With a single vendor pool (all MME from same vendor)



. LTE UE Attach (IP-CAN Session Establishment) with load balancing across pool.


. LTE UE Detach (IP-CAN Session Tear Down)


. IMS UA Registration (via LTE UE)






With a multi-vendor pool (pool of MME instances from different vendors)

. LTE UE Attach (IP-CAN Session Establishment) with load balancing across pool.


. LTE UE Detach (IP-CAN Session Tear Down)


. IMS UA Registration (via LTE UE)







2.1.3.3 Scenario 1c




The following tests will be executed in order to verify interoperability of the indicated interfaces
between different vendors.



With a single vendor (all S-GW from same vendor)



. LTE UE Attach (IP-CAN Session Establishment) with S-GW Selection across multiple S-
GW\'s.


. LTE UE Detach (IP-CAN Session Tear Down)


. IMS UA Registration (via LTE UE)






With a multi-vendor (S-GW instances from different vendors)

. LTE UE Attach (IP-CAN Session Establishment) with S-GW Selection across multiple S-
GW\'s.


. LTE UE Detach (IP-CAN Session Tear Down)


. IMS UA Registration (via LTE UE)









2.2 Scenario 2 . Roaming






The Roaming test case actually represents three different test architectures (Roaming with home routed
traffic, Roaming with local breakout and home IP services and Roaming with local breakout and visited
IP services) as depicted in the figures below.

IMS UAMMES-GWHSSP-CSCFP-GWPCRFUEENBIMS CoreLTE-UuS-11GxSGiRxS6aS1-MMES1-US8VPLMNHPLMNIMS UA


Figure 5 - Scenario 2a Roaming with home routed traffic.










Figure 6 - Scenario 2b Roaming with local breakout (home operator application functions)






IMS UAMMES-GWHSSP-GWH-PCRFUEENBIMS CoreLTE-UuS-11S9S6aS1-MMES1-UVPLMNHPLMNS5V-PCRFGxVisited OperatorIP ServicesIMS UASGiP-CSCFRx




Figure 7 - Scenario 2c Roaming with local breakout (Visited Operator Application Functions /
Visited P-CSCF Model)



2.2.1 Network Components






2.2.1.1 Scenario 2a






In the Visited Network

. One LTE UE (likely a data dongle on a laptop).


. One IMS UA to run on the LTE UE (likely a soft client on a laptop).


. One eNB


. One MME


. One S-GW




In the Home Network

. One P-GW


. One PCRF


. An IMS Core with the P-CSCF exposing the Rx interface and the HSS exposing the S6a
interface.


. An IMS UA registered with the IMS Core.






2.2.1.2 Scenario 2b






In the Visited Network

. One LTE UE (likely a data dongle on a laptop).


. One IMS UA to run on the LTE UE (likely a soft client on a laptop).


. One eNB


. One MME


. One S-GW


. One P-GW


. One PCRF


. Visited IP network (router)





. An IMS UA registered with the IMS Core in the Home Network via the Visited IP network.






In the Home Network

. One PCRF


. An IMS Core with the P-CSCF exposing the Rx interface and the HSS exposing the S6a
interface.








2.2.1.3 Scenario 2c






In the Visited Network

. One LTE UE (likely a data dongle on a laptop).


. One IMS UA to run on the LTE UE (likely a soft client on a laptop).


. One eNB


. One MME


. One S-GW


. One P-GW


. One PCRF


. Visited IP network (router)


. One P-CSCF (Visited P-CSCF model of IMS roaming)


. One IMS UA registered with the Home Network IMS core via the P-CSCF in the Visited
Network (or directly with a P-CSCF in the Home Network IMS core).






In the Home Network

. One PCRF


. An IMS Core with the HSS exposing the S6a interface.


. An IMS UA registered with the IMS Core via the Visited IP network.






2.2.2 Protocols and Reference Points




The following reference points will be interoperated in this scenario.



Interface Protocol Sub-Scenarios

S6a

Diameter

2a, 2b, 2c

S8

GTPv2-C (control plane) / GTPv1-U (user
plane) or PMIPv6.

2a

S9

Diameter

2a, 2b, 2c

Rx

Diameter

2c







2.2.3 Test Cases






. LTE UE Attach (IP-CAN Session Establishment)


. LTE UE Detach (IP-CAN Session Tear Down)


. IMS UA Registration (via LTE UE)


. IMS Session Establishment (from IMS UA on LTE UE)


. IMS Session Establishment (from IMS UA directly connected to IMS Core)


. IMS Session Termination (from IMS UA on LTE UE)


. IMS Session Termination (from IMS UA directly connected to IMS Core)







2.3 Scenario 3 . Non-LTE Access






The Non-LTE 3G Access test case can be realized in two different ways depending upon the
compliance or otherwise of the SGSN to 3GPP Release 8 (an SGSN compliant to Release 8 is often
termed an S4 SGSN, because it supports the S4 interface). The two different realizations are shown in
the figure below.



IMS UAMMES-GWHSSP-CSCFP-GWPCRFUEIMS CoreS-11S5GxSGiRxS6aUTRANGERANS4 SGSNS3S4S12S6dIMS UA




Figure 8 - Scenario 3a. Non LTE 3G Access with S4 SGSN





Figure 9 - Scenario 3b. Non LTE 3G Access with legacy SGSN



The EPC core also handles non-3G access (both trusted and untrusted), this is shown in the figure
below.




S-GWHSSP-CSCFP-GWIMS CoreS5GxSGiRxIMS UA3GPP AAAServerePDGTrusted Non-3GPP
IP AccessUntrusted Non-
3GPP IP AccessIMS UAUEIMS UAUESWuSWnSWmGxbS2bS6bSWaSTaS2aGxaPCRF




Figure 10 - Scenario 3c. Non-3G Access.



The next version of this document will include a scenario 3d showing CDMA2000 /
1xEV-DO Rev A access to the EPC.



2.3.1 Network Components


2.3.1.1 Scenario 3a






. One UTRAN / GERAN UE (likely a data dongle on a laptop).


. One IMS UA to run on the UTRAN / GERAN UE (likely a soft client on a laptop).


. UTRAN / GERAN access infrastructure.


. One S4 SGSN





. One MME


. One S-GW


. One P-GW


. One PCRF


. One IMS Core with the HSS exporting the S6a and S6d interfaces and a P-CSCF exporting the
Rx interface.


. One IMS UA registered directly with the IMS Core






2.3.1.2 Scenario 3b






. One UTRAN / GERAN UE (likely a data dongle on a laptop).


. One IMS UA to run on the UTRAN / GERAN UE (likely a soft client on a laptop).


. UTRAN / GERAN access infrastructure.


. One SGSN (pre Rel 8)


. One MME


. One S-GW


. One P-GW


. One PCRF


. One IMS Core with the HSS exporting the S6a and Gr interfaces and a P-CSCF exporting the
Rx interface.




2.3.1.3 Scenario 3c






. One S-GW


. One P-GW


. One ePDG (evolved Packet Data Gateway).


. One PCRF


. One 3GPP AAA Server.


. Trusted non-3GPP Access (could be any access type e.g. DSL).


. Untrusted non-3GPP Access (could be any access type e.g. DSL).


. UE + IMS UA for trusted access.


. UE + IMS UA for un-trusted access.


. One IMS Core with the a P-CSCF exporting the Rx interface.






2.3.2 Protocols and Reference Points




The following reference points will be interoperated in this scenario.



Interface Protocol Sub-Scenarios

S2a

PMIPv6

3c

S2b

PMIPv6

3c

S3

GTPv2-C

3a

S4

GTPv2-C (control plane) / GTPv1-U (user plane)

3a

S6b

Diameter.

3c

S12

GTPv1-U

3a

S6d

Diameter

3a

Gr

MAP

3b

Gn

GTPv1

3b

Gp

GTPv1

3b

STa

Diameter

3c

SWa

Diameter

3c

SWm

Diameter

3c

SWn

Unspecified

3c

SWu

Unspecified

3c






2.3.3 Test Cases






For all three sub-scenarios

. UE Attach (IP-CAN Session Establishment)


. UE Detach (IP-CAN Session Tear Down)


. IMS UA Registration (via UTRAN/GERAN UE)


. IMS Session Establishment (from IMS UA on UTRAN/GERAN UE)


. IMS Session Establishment (from IMS UA directly connected to IMS Core)


. IMS Session Termination (from IMS UA on UTRAN/GERAN UE)


. IMS Session Termination (from IMS UA directly connected to IMS Core)





S-11S6aS1-MMES1-US-11S6aX2X2S3S4S12S6dS10



2.4 Scenario 4 . Handovers






This scenario tests the different handover conditions both with registered terminals and with active
sessions. There are two sub-test cases for this scenario, 4a in which an S4-SGSN is used and 4b in
which an earlier version of the SGSN is used. The architectures for these scenarios are shown in the
figures below.



IMS UAMME (a)
S-GWHSSP-CSCFP-GWPCRFUE
ENB (y)
IMS CoreLTE-Uu


Figure 11 . Scenario 4a. Handovers with S4 SGSN






Figure 12 - Scenario 4b. Handovers with legacy SGSN



The next version of this document will include a scenario 4c for handover between CDMA2000 /
1xEV-DO Rev A and LTE.

2.4.1 Network Components






2.4.1.1 Scenario 4a






. One Multi-mode (LTE . UTRAN/GERAN) UE (likely a data dongle on a laptop).


. One IMS UA on the Multi-mode UE (likely a soft client on a laptop).


. Three eNB


. Two MME


. One SGW


. One S4 SGSN


. GERAN/UTRAN access infrastructure.


. One P-GW.


. One PCRF.


. One IMS Core with the HSS exposing the S6a and S6d interfaces and the P-CSCF exposing
the Rx interface.


. One IMS UA directly registered to the IMS Core.






2.4.1.2 Scenario 4b






. One Multi-mode (LTE . UTRAN/GERAN) UE (likely a data dongle on a laptop).


. One IMS UA on the Multi-mode UE (likely a soft client on a laptop).


. Three eNB


. Two MME





. One SGW


. One SGSN (pre release 8).


. GERAN/UTRAN access infrastructure.


. One P-GW.


. One PCRF.


. One IMS Core with the HSS exposing the S6a and S6d interfaces and the P-CSCF exposing
the Rx interface.


. One IMS UA directly registered to the IMS Core.








2.4.2 Protocols and Reference Points






Interface Protocol Sub Scenarios

S1-MME

NAS

4a, 4b

S1-U

GTPv1-U

4a, 4b

X2

X2 AP (signalling) / GTPv1-U (user plane)

4a, 4b

S3

GTPv2-C

4a

S4

GTPv2-C (control plane) / GTPv1-U (user plane) or
PMIPv6.

4a

S10

GTPv2-C

4a, 4b

S11

GTPv2-C

4a, 4b

S12

GTPv1-U

4a

S6a

Diameter

4a, 4b

S6d

Diameter

4a

Gn

GTP

4b

Gr

MAP

4b

Gp

GTP

4b





2.4.3 Test Cases




The handover scenarios will be tested both for registered terminals and with established (IMS)
sessions.

Basic Attachment.

. The UE attaches to ENB (y) and hands over to ENB(x), the UE remains attached.


. The UE attaches to ENB(y) and hands over to ENB(z), moving from MME(a) to MME(b), the
UE remains attached.


. The UE attaches to ENB(y) and hands over to ENB(z), moving from SGW(a) to SGW(b), the
UE remains attached.


. The UE attaches to ENB (x) and hands over to UTRAN/GERAN, the UE remains attached.


. The UE attaches to UTRAN/GERAN and hands over to ENB(x), the UE remains attached.




IMS Registration.

. The UE attached to ENB (y) and the UA registers with the IMS Core. The UE hands over to
ENB(x), the UA remains registered with the IMS Core.


. The UE attaches to ENB(y) and the UA registers with the IMS Core. The UE hands over to
ENB(z), moving from MME(a) to MME(b), the UA remains registered with the IMS Core.


. The UE attaches to ENB(y) and the UA registers with the IMS Core. The UE hands over to
ENB(z), moving from SGW(a) to SGW(b), the UA remains registered with the IMS Core.





. The UE attaches to ENB (x) and the UA registers with the IMS Core. The UE hands over to
UTRAN/GERAN, the UA remains registered with the IMS Core.


. The UE attaches to UTRAN/GERAN and the UA registers with the IMS Core. The UE hands
over to ENB(x), the UA remains registered with the IMS Core.






IMS Session.

. The UE attaches to ENB (y) , the UA registers with the IMS Core and establishes a session
with the directly connected IMS UA. The UE hands over to ENB(x), the IMS session remains
active.


. The UE attaches to ENB(y), the UA registers with the IMS Core and establishes a session
with the directly connected IMS UA. The UE hands over to ENB(z), moving from MME(a) to
MME(b), the IMS session remains active.


. The UE attaches to ENB(y), the UA registers with the IMS Core and establishes a session
with the directly connected IMS UA. The UE hands over to ENB(z), moving from SGW(a) to
SGW(b), the IMS session remains active.


. The UE attaches to ENB (x), the UA registers with the IMS Core and establishes a session
with the directly connected IMS UA. The UE hands over to UTRAN/GERAN, the IMS
session remains active.


. The UE attaches to UTRAN/GERAN, the UA registers with the IMS Core and establishes a
session with the directly connected IMS UA. The UE hands over to ENB(x), the IMS session
remains active.







3 Interface Specifications






The following is a set of references for the interfaces tested in these scenarios.



3.1 S1-MME (eNB . MME)




3GPP TS 24.301(NAS)

3.2 S1-U (eNB-SGW)




3GPP TS 29.281 (GTPv1-U)

3.3 S2a




3GPP TS 29.275 (PMIPv6)

3.4 S2b




3GPP TS 29.275 (PMIPv6)

3.5 X2 (eNB . eNB)




Signaling 3GPP TS 36.423 (X2 Application Protocol).

User Plane 3GPP TS 29.281 (GTPv1-U)

3.6 S3 (S4 SGSN . MME)




3GPP TS 29.274 (GTPv2-C)

3.7 S4 (S4 SGSN . SGW)




Control Plane 3GPP TS 29.274 (GTPv2-C).

User Plane 3GPP TS 29.281 (GTPv1-U).

3.8 S5 (SGW-PGW)




User Plane 3GPP TS 29.281 (GTPv1-U)

Control Plane 3GPP TS 29.274 (GTPv2-C)

or

3GPP TS 29.275 (PMIPv6)

3.9 S6a (HSS . MME)




3GPP TS 29.272 (Diameter)

3.10 S6b (PGW . 3GPP AAA)




3GPP TS 29.273 (Diameter)

3.11 S6d (HSS . S4 SGSN)




3GPP TS 29.273 (Diameter)

3.12 S8 (SGW . PGW)




User Plane 3GPP TS 29.281 (GTPv1-U)

Control Plane 3GPP TS 29.274 (GTPv2-C)

or

3GPP TS 29.275 (PMIPv6)

3.13 S9 (PCRF . PCRF)




3GPP TS 29.215 (Diameter).


3.14 S10 (MME . MME)




3GPP TS 29.274 (GTPv2-C).

3.15 S11 (MME . SGW)




3GPP TS 29.274 (GTPv2-C)

3.16 S12 (UTRAN . SGW)




3GPP TS 29.281 (GTPv1-U, utilized for direct tunnel model).

3.17 Gx (PCRF . PGW)




3GPP TS 29.212 (Diameter).

3.18 Gxc (PCRF-SGW)




3GPP TS 29.212 (Diameter)

3.19 Rx (PCRF - IP Application [P-CSCF for IMS])




3GPP TS 29.214 (Diameter).

3.20 Gr (SGSN . HSS)




3GPP TS 29.002 (MAP)

3.21 Gn (SGSN . MME / SGSN . PGW)




3GPP TS 29.060 (GTP)

3.22 Gp (SGSN . PGW)




3GPP TS 29.060 (GTP)

3.23 STa




3GPP TS 29.273 (Diameter)

3.24 SWa




3GPP TS 29.273 (Diameter)

3.25 SWm




3GPP TS 29.273 (Diameter)
View All (815)
4G (2) 4G Evolution (1) 5G (35) 5g (1) 802.11 (1) 802.1X (1) ALTO (1) ANDSF (1) AT&T (2) Acceleration (1) Adobe HDS (3) Akamai (6) Amazon (3) Apple HLS (4) Authentication (1) BRAS (2) BT (1) Backbone (4) Backhaul (12) BitTorrent (1) Broadcasting (3) C-RAN (13) C-RAN/Fronthaul (12) CCN (4) CDN (52) CDNi (1) COLT (1) CORD (1) CPRI (2) Cache Control (1) Caching (5) Carrier Cloud (2) Carrier Ethernet (9) Channel Zapping (4) China Mobile (1) China Telecom (1) Cloud (10) Cloudfront (1) DASH (2) DCA (1) DHCP (3) DNS (1) DSA (1) Data Center (7) Dynamic Web Acceleration (1) EPC (5) Energy (1) Ericsson (5) Ethernet (8) FEO (2) Fairness (1) Fronthaul (5) GiGAtopia (1) Gigabit Internet (2) Global CDN (1) Google (5) HLS (1) HTTP (1) HTTP Adaptive Streaming (18) HTTP Progressive Download (3) HTTP Streaming (1) HetNet (1) Hot-Lining (1) Hotspot 2.0 (2) Huawei (3) ICN (4) IP (1) IP Allocation (1) IP Routing (8) IPTV (15) Intel (1) Internet (1) Interoperability (2) IoST (1) IoT (14) KT (22) LG U+ (3) LTE (70) LTE MAC (1) LTE-A (2) Licensed CDN (1) M2M (3) MEC (2) MPLS (25) MVNO (1) Market (4) Metro Ethernet (7) Microsoft (2) Migration (1) Mobile (4) Mobile Backhaul (1) Mobile Broadcasting (1) Mobile CDN (2) Mobile IP (1) Mobile IPTV (3) Mobile Video (1) Mobile Web Perormance (1) Mobility (1) Multi-Screen (7) Multicast (7) NFC (1) NFV (2) NTT Docomo (2) Netflix (6) Network Protocol (31) Network Recovery (3) OAM (6) OTT (31) Ofcom (1) Offloading (2) OpenFlow (1) Operator CDN (14) Orange (1) P2P (4) PCC (1) Page Speed (1) Programmable (1) Protocol (7) Pseudowire (1) QoS (5) Router (1) SCAN (1) SD-WAN (1) SDN (15) SDN/NFV (15) SK Telecom (21) SON (1) SaMOG (1) Samsung (2) Security (6) Service Overlay (1) Silverlight (4) Small Cell (3) Smart Cell (1) Smart Grid (2) Smart Network (2) Supper Cell (1) Telefonica (1) Telstra (1) Terms (1) Traffic (2) Traffic Engineering (1) Transcoding (3) Transparent Cache (2) Transparent Caching (14) VLAN (2) VPLS (2) VPN (9) VRF (2) Vendor Product (2) Verizon (2) Video Optimization (4) Video Pacing (1) Video Streaming (14) Virtual Private Cloud (1) Virtualization (3) White Box (1) Wholesale CDN (4) Wi-Fi (13) WiBro(WiMAX) (4) Wireless Operator (5) YouTube (4) eMBMS (4) eNB (1) 망이용대가 (1) 망중립성 (1) 스마트 노드 (1)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2019년 1월 현재 넷매니아즈 회원은 49,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호