Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 23.882  Word version:  8.0.0

Top   Top   None   None   Next
0…   4…   7.10…   8…

 

0  Introductionp. 10

To ensure competitiveness of the 3GPP systems in a time frame of the next 10 years and beyond, a long-term evolution of the 3GPP access technology needs to be considered.
In particular, to enhance the capability of the 3GPP system to cope with the rapid growth in IP data traffic, the packet-switched technology utilised within 3G mobile networks requires further enhancement. A continued evolution and optimisation of the system concept is also necessary in order to maintain a competitive edge in terms of both performance and cost. Important parts of such a long-term evolution include reduced latency, higher user data rates, improved system capacity and coverage, and reduced overall cost for the operator.
Additionally, it is expected that IP based 3GPP services will be provided through various access technologies. A mechanism to support seamless mobility between heterogeneous access networks, e.g. I-WLAN and 3GPP access systems, is a useful feature for future network evolution.
In order to achieve this, an evolution or migration of the network architecture, as well as an evolution of the radio interface, partly addressed already by individual WIDs, should be considered.
Architectural considerations will include end-to-end systems aspects, including core network aspects and the study of a variety of IP connectivity access networks (e.g. fixed broadband access).
Up

1  Scopep. 11

The objective of this feasibility study is to develop a framework for an evolution or migration of the 3GPP system to a higher-data-rate, lower-latency, packet-optimized system that supports, multiple RATs. The focus of this work will be on the PS domain with the assumption that voice services are supported in this domain.
The main objectives are to address the following aspects:
  1. Overall architecture impacts stemming from requirements coming out from TSG-RAN's Study Item on Radio Evolution (see SP 040915). The architectural developments should take into account the targets for the evolution of the radio-interface, e.g.:
    1. whether there is a need for a modified network architecture and/or different functional split between network nodes (compared to the current 3GPP architecture);
    2. how to provide a very low latency (including C-plane) for the overall network (including core network, radio access network and radio access technology);
    3. how to provide the efficient support of the various types of services, especially from the PS domain (e.g. Voice over IP, Presence).
  2. Overall architecture impacts stemming from the work in SA1 on an All-IP Network (AIPN) (see TS 22.258 [4]), e.g.:
    1. support of a variety of different access systems (existing and future) and access selection based on combinations of operator policies, user preferences and access network conditions;
    2. how to realize improvements in basic system performance e.g. communication delay, communication quality, connection set-up time, etc.;
    3. how to maintain the negotiated QoS across the whole system; in particular to address inter-domain and inter-network interworking, and, QoS on the network link to the Base Station site.
  3. Overall architecture aspects of supporting mobility between heterogeneous access networks, including service continuity. E.g.:
    1. service continuity between I-WLAN and the 3GPP PS domain;
    2. how to support multiple radio access technologies and terminal mobility between different radio access technologies;
    3. how to maintain and support the same capabilities of access control (authentication, authorization), privacy and charging when moving between different radio access technologies.
Migration aspects should be taken into account for the above, i.e. how to migrate from the existing architecture.
In the course of conducting this feasibility study additional individual Work Items may be identified and prepared to address certain aspects and to take care of the respective specification work. The timelines of those Work Items may or may not concur with the timeline of this feasibility study.
Up

2  Referencesp. 12

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 41.001: "GSM Release specifications".
→ to date, withdrawn by 3GPP
[2]
TR 21 912: (V3.1.0) "Example 2, using fixed text".
→ to date, withdrawn by 3GPP
[3]
TS 23.002: "Network Architecture".
[4]
TS 22.258: "Service Requirements for the All-IP Network (AIPN); Stage 1".
→ to date, withdrawn by 3GPP
[5]
RFC 4004:  "Diameter Mobile IPv4 Application", August 2005.
[6]
RFC 4555:  "IKEv2 Mobility and Multihoming Protocol (MOBIKE)".
[7]
TS 43.129: "Packed-switched handover for GERAN A/Gb mode; Stage 2".
[8]
RFC 4068:  "Fast Handovers for Mobile IPv6".
[9]
R. Koodli and C. E. Perkins: "Mobile IPv4 Fast Handovers", Internet Draft, draft-ietf-mip4-fmipv4-02, October 2006. Available at http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-02.txt.
[10]
RFC 3344:  "IP Mobility Support for IPv4".
[11]
RFC 3775,  "Mobility Support in IPv6".
[12]
H. Levkowetz: "The NETLMM Protocol", Internet Draft, draft-giaretta-netlmm-dt-protocol-02, October 2006. Available at: http://www.ietf.org/internet-drafts/draft-giaretta-netlmm-dt-protocol-02.txt.
[13]  Void.
[14]  Void.
[15]  Void.
[16]
TR 25.931: "UTRAN functions, examples on signalling procedures".
[17]
S. Gundavelli et. Al.: "Proxy Mobile IPv6", Internet Draft, draft-sgundave-mip6-proxymip6-00, October 2006. Available at: http://tools.ietf.org/wg/mip6/draft-sgundave-mip6-proxymip6-00.txt.
[18]
TR 25.912: "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Feasibility Study for Evolved UTRA and UTRAN".
[19]
TS 23.207: "End-to-end Quality of Service (QoS) concept and architecture".
[20]
TS 23.203: "Policy and Charging Control Architecture".
[21]
RFC 2597:  "Assured Forwarding PHB Group".
[22]
RFC 3246:  "An Expedited Forwarding PHB (Per-Hop Behavior)".
[23]
RFC 3344:  "IP Mobility Support for IPv4".
[24]
RFC 3775:  "Mobility Support in IPv6".
[25]  Void.
[26]
K. Leung, G. Dommety, P. Yegani and K. Chowdhury: "Mobility Management using Proxy Mobile IPv4", Internet Draft, draft-leung-mip4-proxy-mode-01, June 2006. http://www.ietf.org/internet-drafts/draft-leung-mip4-proxy-mode-01.txt.
[27]
H. Soliman: "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", Internet Draft, draft-ietf-mip6-nemo-v4traversal-03, October 2006. http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-03.txt.
[28]
TS 23.234: "3GPP System to Wireless Local Area Network (WLAN) Interworking; System Description".
[29]
TS 23.206: "Voice Call Continuity between CS and IMS; Stage 2".
[30]
TR 23.806: "Voice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS) Study".
[31]
RFC 4140:  "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)".
[32]
G. Tsirtsis, H. Soliman, V. Park: "Dual Stack Mobile IPv4", Internet Draft, draft-ietf-mip4-dsmipv4-00.txt, July 2006. http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-00.txt
[33]
K. Chowdhury, A. Singh: "Network Based Layer 3 Connectivity and Mobility Management for IPv6", Internet Draft, draft-chowdhury-netmip6-01.txt, September 2006. http://www.ietf.org/internet-drafts/draft-chowdhury-netmip6-01.txt.
[34]
TR 22.278: "Service requirements for evolution of the 3GPP system".
[35]
TR 22.279: "Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) services".
[36]
3GPP2 C.S0001-A Introduction to cdma2000 Standards for Spread Spectrum Systems - Release A.
[37]
3GPP2 C.S0002-A Physical Layer Standard for cdma2000 Spread Spectrum Systems - Release A
[38]
3GPP2 C.S0003-A Medium Access Control (MAC) Standard for cdma2000 Spread Spectrum Systems - Release A addendum 2.
[39]
3GPP2 C.S0004-A Signaling Link Access Control (LAC) Specification for cdma2000 Spread Spectrum Systems -Addendum 2.
[40]
3GPP2 C.S0005-A Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems - Release A addendum 2.
[41]
3GPP2 C.S0006-A Analog Signaling Standard for cdma2000 Spread Spectrum Systems - Addendum 2.
[42]
3GPP2 A.S0007 - A.S0009 Interoperability Specification (IOS) for High Rate Packet Data (HRPD).
[43]
3GPP2 A.S0011 - A.S0017 Interoperability Specification (IOS) for cdma2000 Access Network Interfaces.
[44]
3GPP2 X.S0011 cdma2000 Wireless IP Network.
Up

3  Definitions, symbols and abbreviationsp. 14

3.1  Definitionsp. 14

For the purposes of the present document, the following terms and definitions apply:
Mobility Management Entity (MME):
manages and stores UE context (for idle state: UE/user identities, UE mobility state, user security parameters). It generates temporary identities and allocates them to UEs. It checks the authorization whether the UE may camp on the TA or on the PLMN. It also authenticates the user.
MME Pool Area:
An MME Pool Area is defined as an area within which a UE may be served without need to change the serving MME. An MME Pool Area is served by one or more MMEs ("pool of MMEs") in parallel.
UPE Pool Area:
A UPE Pool Area is defined as an area within which a UE may be served without need to change the serving UPE. A UPE Pool Area is served by one or more UPEs ("pool of UPEs") in parallel.
User Plane Entity (UPE):
terminates for idle state Ues the downlink data path and triggers/initiates paging when downlink data arrive for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service or network internal routing information. It performs replication of the user traffic in case of interception.
It is FFS whether Charging Information for inter-operator accounting is in UPE or in another functional block.
Idle State:
is LTE_IDLE for SAE/LTE or PMM_IDLE for 2G/3G or URA_PCH, which is FFS
IP Service continuity:
IP service continuity is the capability of a system to hide the impact of mobility events to the end user and the IP application(s), i.e. the service can continue without user intervention or special application support to mask the effects of a mobility event.
Nomadic Terminal:
Terminal that does not have full mobile capabilities but would normally be expected to roam between different points of attachment of the network, both wireless and wired.
Backward Handover:
the source RAN node initiates the handover, and resources are prepared in the target RAN Nodes. Examples of this concept are reported in TR 25.931.
Forward Handover:
The UE changes to the target RAN node without any preparation in the network. Examples of this concept are reported in TR 25.931.
Trusted non-3GPP IP Access:
A non-3GPP IP Access Network is defined as a "trusted non-3GPP IP Access Network" if the 3GPP EPC system chooses to trust such non-3GPP IP access network. The 3GPP EPC system operator may choose to trust the non-3GPP IP access network operated by the same or different operators, e.g. based on business agreements.
Note that specific security mechanisms may be in place between the trusted non-3GPP IP Access Network and the 3GPP EPC to avoid security threats. It is assumed that an IPSec tunnel between the UE and the 3GPP EPC is not required.
On the contrary, an untrusted non-3GPP IP access is an IP access network where 3GPP network requires use of IPSec between the UE and the 3GPP network in order to provide adequate security mechanism acceptable to 3GPP network operator. An example of such untrusted non-3GPP IP access is WLAN and it is made trusted in the Interworking WLAN specifications developed within 3GPP.
Up

3.2  Abbreviationsp. 14

For the purposes of the present document, the following abbreviations apply:
EPC
Evolved Packet Core network
IASA
Inter Access System Anchor

Up   Top   ToC