Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 6459 Nokia Siemens Networks
Category: Informational J. Soininen
ISSN: 2070-1721 Renesas Mobile
B. Patil
T. Savolainen
G. Bajko
Nokia
K. Iisakkila
Renesas Mobile
January 2012
IPv6 in 3rd Generation Partnership Project (3GPP)
Evolved Packet System (EPS)
Abstract
抽象
The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deployed networks based on 3rd Generation Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures.
スマートフォン、タブレット、ノートブック/ネットブックコンピュータを介してインターネットおよびその他のデータサービスにアクセスするセルラブロードバンドの使用は、HSPA、HSPA +、今ロングタームエボリューション（LTEなどの高速パケットデータネットワークの結果として急速に増加しています）に配備されています。 3GPP（3rd Generation Partnership Project）のネットワーク・アーキテクチャに基づいてネットワークを展開している事業者は、インターネットレジストリでのIPv4アドレスの不足に直面しているとIPv6への移行に圧力を感じています。このドキュメントは、3GPPネットワーク・アーキテクチャにおけるIPv6のサポートについて説明します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6459.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6459で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
2. 3GPP Terminology and Concepts ...................................5
2.1. Terminology ................................................5
2.2. The Concept of APN ........................................10
3. IP over 3GPP GPRS ..............................................11
3.1. Introduction to 3GPP GPRS .................................11
3.2. PDP Context ...............................................12
4. IP over 3GPP EPS ...............................................13
4.1. Introduction to 3GPP EPS ..................................13
4.2. PDN Connection ............................................14
4.3. EPS Bearer Model ..........................................15
5. Address Management .............................................16
5.1. IPv4 Address Configuration ................................16
5.2. IPv6 Address Configuration ................................16
5.3. Prefix Delegation .........................................17
5.4. IPv6 Neighbor Discovery Considerations ....................18
6. 3GPP Dual-Stack Approach to IPv6 ...............................18
6.1. 3GPP Networks Prior to Release-8 ..........................18
6.2. 3GPP Release-8 and -9 Networks ............................20
6.3. PDN Connection Establishment Process ......................21
6.4. Mobility of 3GPP IPv4v6 Bearers ...........................23
7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks ........24
8. Deployment Issues ..............................................25
8.1. Overlapping IPv4 Addresses ................................25
8.2. IPv6 for Transport ........................................26
8.3. Operational Aspects of Running Dual-Stack Networks ........26
8.4. Operational Aspects of Running a Network with
IPv6-Only Bearers .........................................27
8.5. Restricting Outbound IPv6 Roaming .........................28
8.6. Inter-RAT Handovers and IP Versions .......................29
8.7. Provisioning of IPv6 Subscribers and Various
Combinations during Initial Network Attachment ............29
9. Security Considerations ........................................31
10. Summary and Conclusions .......................................32
11. Acknowledgements ..............................................32
12. Informative References ........................................33
IPv6 support has been part of the 3rd Generation Partnership Project (3GPP) standards since the first release of the specifications (Release 99). This support extends to all radio access and packet-based system variants of the 3GPP architecture family. In addition, a lot of work has been invested by the industry to investigate different transition and deployment scenarios over the years. However, IPv6 deployment in commercial networks remains low. There are many factors that can be attributed to this lack of deployment. The most relevant factor is essentially the same as the reason for IPv6 not being deployed in other networks either, i.e., the lack of business and commercial incentives for deployment.
IPv6のサポートは、仕様（リリース99）の最初のリリース以来、3GPP（3rd Generation Partnership Project）の標準規格の一部となっています。このサポートは、3GPPアーキテクチャファミリーの全ての無線アクセスおよびパケットベースのシステムの変種にも及びます。また、作業の多くは、長年にわたって異なる遷移および展開シナリオを調査するために、業界が投資されています。ただし、商用ネットワークでのIPv6の展開は低いままです。展開の欠如に起因することができ、多くの要因があります。最も関連性の要因は、基本的にIPv6がいずれかの他のネットワークで展開されていない理由、すなわち、展開のためのビジネス・商業のインセンティブの欠如と同じです。
3GPP network architectures have continued to evolve in the time since Release 99, which was finalized in early 2000. The most recent version of the 3GPP architecture, the Evolved Packet System (EPS) -- commonly referred to as System Architecture Evolution (SAE), Long-Term Evolution (LTE), or Release-8 -- is a packet-centric architecture. In addition, the number of subscribers and devices using the 3GPP networks for Internet connectivity and data services has also increased phenomenally -- the number of mobile broadband subscribers has increased exponentially over the last couple of years.
一般的にシステムアーキテクチャエボリューション（SAE）と呼ばれる、 - 3GPPネットワーク・アーキテクチャは、進化したパケットシステム（EPS）、初期の2000年に3GPPアーキテクチャの最新バージョンを確定したリリース99、以降の時間に進化し続けていますロングタームエボリューション（LTE）、またはリリース-8は、 - パケット中心のアーキテクチャです。また、インターネット接続およびデータ・サービスのために3GPPネットワークを使用して加入者とデバイスの数も驚異的に増加している - モバイル・ブロードバンドの加入者数は、過去数年間にわたり指数関数的に増加しています。
With subscriber growth projected to increase even further, and with recent depletion of available IPv4 address space by IANA, 3GPP operators and vendors are now in the process of identifying the scenarios and solutions needed to deploy IPv6.
さらに、およびIANAによって利用できるIPv4アドレス空間の最近の枯渇に伴って増加すると予測加入者の増加に伴い、3GPP事業者やベンダーがIPv6を展開するために必要なシナリオと解決方法を特定するプロセスになりました。
This document describes the establishment of IP connectivity in 3GPP network architectures, specifically in the context of IP bearers for 3G General Packet Radio Service (GPRS) and for EPS. It provides an overview of how IPv6 is supported as per the current set of 3GPP specifications. Some of the issues and concerns with respect to deployment and shortage of private IPv4 addresses within a single network domain are also discussed.
この文書では、特に3G汎用パケット無線サービス（GPRS）用とEPSのためのIPベアラのコンテキストで、3GPPネットワーク・アーキテクチャにおけるIP接続の確立について説明します。これは、IPv6が3GPP仕様の現在のセットごとにサポートされる方法の概要を説明します。単一のネットワークドメイン内の展開とプライベートIPv4アドレスの不足に関して問題や懸念のいくつかは、議論されています。
The IETF has specified a set of tools and mechanisms that can be utilized for transitioning to IPv6. In addition to operating dual-stack networks during the transition from IPv4 to IPv6, the two alternative categories for the transition are encapsulation and translation. The IETF continues to specify additional solutions for enabling the transition based on the deployment scenarios and operator/ISP requirements. There is no single approach for transition to IPv6 that can meet the needs for all deployments and models. The 3GPP scenarios for transition, described in [TR.23975], can be addressed using transition mechanisms that are already available in the toolbox. The objective of transition to IPv6 in 3GPP networks is to ensure that:
IETFは、IPv6への移行のために利用できるツール及び機構のセットを指定しています。 IPv4からIPv6への移行時にデュアルスタックネットワークを動作させることに加えて、移行のための2つの代替的なカテゴリーは、カプセル化と翻訳されています。 IETFは、展開シナリオとオペレータ/ ISPの要件に基づいて、遷移を可能にするための追加的なソリューションを指定し続けます。すべて展開とモデルのためのニーズを満たすことができるIPv6への移行のための単一のアプローチはありません。 【TR.23975]に記載の遷移のための3GPPシナリオは、ツールボックスに既に利用可能である移行メカニズムを使用して対処することができます。 3GPPネットワークにおけるIPv6への移行の目的は、それを保証することです。
1. Legacy devices and hosts that have an IPv4-only stack will continue to be provided with IP connectivity to the Internet and services.
IPv4のみのスタックを持っている1.レガシーデバイスとホストは、インターネットやサービスへのIP接続が提供されていきます。
2. Devices that are dual-stack can access the Internet either via IPv6 or IPv4. The choice of using IPv6 or IPv4 depends on the capability of:
デュアルスタックは、いずれかのIPv6またはIPv4を介してインターネットにアクセスすることができます2.デバイス。 IPv4またはIPv6を使用しての選択はの能力に依存します。
A. the application on the host,
A.ホスト上のアプリケーション、
B. the support for IPv4 and IPv6 bearers by the network, and/or
B.ネットワークによって、IPv4とIPv6ベアラのためのサポート、および/または
C. the server(s) and other end points.
C.サーバ（複数可）および他のエンドポイント。
3GPP networks are capable of providing a host with IPv4 and IPv6 connectivity today, albeit in many cases with upgrades to network elements such as the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN).
3GPPネットワークは、サービングGPRSサポートノード（SGSN）とゲートウェイGPRSサポートノード（GGSN）のような要素をネットワークにアップグレードして多くの場合にもかかわらず、今日、IPv4とIPv6の接続性を持つホストを提供することができます。
Access Point Name
アクセスポイント名
The Access Point Name (APN) is a Fully Qualified Domain Name (FQDN) and resolves to a set of gateways in an operator's network. The APNs are piggybacked on the administration of the DNS namespace.
アクセスポイント名（APN）は、完全修飾ドメイン名（FQDN）で、オペレータのネットワークにおけるゲートウェイのセットに解決されます。 APNは、DNS名前空間の管理に背負わされています。
Dual Address PDN/PDP Type
デュアルアドレスPDN / PDPタイプ
The dual address Packet Data Network/Packet Data Protocol (PDN/ PDP) Type (IPv4v6) is used in 3GPP context in many cases as a synonym for dual-stack, i.e., a connection type capable of serving both IPv4 and IPv6 simultaneously.
デュアルアドレスパケット・データ・ネットワーク/パケットデータプロトコル（PDN / PDP）タイプ（IPv4v6）は、デュアルスタック、すなわち、同時にIPv4とIPv6の両方にサービスを提供することのできる接続タイプの同義語として多くの場合に、3GPPのコンテキストで使用されています。
Evolved Packet Core
進化したパケットコア
The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS system characterized by a higher-data-rate, lower-latency, packet-optimized system. The EPC comprises subcomponents such as the Mobility Management Entity (MME), Serving Gateway (SGW), Packet Data Network Gateway (PDN-GW), and Home Subscriber Server (HSS).
進化型パケットコア（EPC）は、高データレート、低レイテンシ、パケット最適化システムによって特徴付け3GPP GPRSシステムの進化です。 EPCは、ゲートウェイ（SGW）、パケットデータネットワークゲートウェイ（PDN-GW）、およびホーム加入者サーバ（HSS）となる、そのようなモビリティ管理エンティティ（MME）などのサブコンポーネントを含みます。
Evolved Packet System
進化型パケットシステム
The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS system characterized by a higher-data-rate, lower-latency, packet-optimized system that supports multiple Radio Access Technologies (RATs). The EPS comprises the EPC together with the Evolved Universal Terrestrial Radio Access (E-UTRA) and the Evolved Universal Terrestrial Radio Access Network (E-UTRAN).
発展型パケットシステム（EPS）は、複数の無線アクセス技術（RAT）をサポートし、より高いデータレート、低レイテンシ、パケット最適化システムによって特徴付け3GPP GPRSシステムの進化です。 EPSは、進化型ユニバーサル地上無線アクセス（E-UTRA）及び進化型ユニバーサル地上無線アクセスネットワーク（E-UTRAN）と一緒にEPCを含みます。
Evolved UTRAN
Ivolvdのfrippery
The Evolved UTRAN (E-UTRAN) is a communications network, sometimes referred to as 4G, and consists of eNodeBs (4G base stations), which make up the E-UTRAN. The E-UTRAN allows connectivity between the User Equipment and the core network.
進化型UTRAN（E-UTRAN）通信ネットワークでは、時々、4Gと呼ばれ、E-UTRANを構成するのeNodeB（4G基地局）から成ります。 E-UTRANは、ユーザ装置とコアネットワーク間の接続を可能にします。
GPRS Tunnelling Protocol
GPRSトンネリングプロトコル
The GPRS Tunnelling Protocol (GTP) [TS.29060] [TS.29274] [TS.29281] is a tunnelling protocol defined by 3GPP. It is a network-based mobility protocol and is similar to Proxy Mobile IPv6 (PMIPv6) [RFC5213]. However, GTP also provides functionality beyond mobility, such as in-band signaling related to Quality of Service (QoS) and charging, among others.
GPRSトンネリングプロトコル（GTP）[TS.29060] [TS.29274] [TS.29281]は、3GPPによって定義されたトンネリングプロトコルです。これは、ネットワークベースのモビリティプロトコルであり、プロキシ・モバイルIPv6（PMIPv6の）[RFC5213]と同様です。しかし、GTPはまた、とりわけ、サービス品質（QoS）に関連するシグナリングおよび充電インバンドとして、移動度を超えた機能を提供します。
GSM EDGE Radio Access Network
GSM EDGE無線アクセスネットワーク
The Global System for Mobile Communications (GSM) EDGE Radio Access Network (GERAN) is a communications network, commonly referred to as 2G or 2.5G, and consists of base stations and Base Station Controllers (BSCs), which make up the GSM EDGE radio access network. The GERAN allows connectivity between the User Equipment and the core network.
移動体通信用グローバルシステム（GSM）EDGE無線アクセスネットワーク（GERAN）は、一般に、2G又は2.5Gと呼ばれる通信ネットワークである、とGSM EDGE無線機を構成する基地局および基地局コントローラ（のBSC）から成りアクセスネットワーク。 GERANは、ユーザ装置とコアネットワーク間の接続を可能にします。
Gateway GPRS Support Node
ゲートウェイGPRSサポートノード
The Gateway GPRS Support Node (GGSN) is a gateway function in the GPRS that provides connectivity to the Internet or other PDNs. The host attaches to a GGSN identified by an APN assigned to it by an operator. The GGSN also serves as the topological anchor for addresses/prefixes assigned to the User Equipment.
ゲートウェイGPRSサポートノード（GGSN）は、インターネットまたは他のPDNへの接続を提供GPRSにおけるゲートウェイ機能です。ホストは、オペレータがそれに割り当てられたAPNによって識別GGSNに取り付けられます。 GGSNはまた、ユーザ機器に割り当てられたアドレス/プレフィックスのためのトポロジーのアンカーとして働きます。
General Packet Radio Service
一般パケット無線サービス
The General Packet Radio Service (GPRS) is a packet-oriented mobile data service available to users of the 2G and 3G cellular communication systems -- the GSM -- specified by 3GPP.
GSM - - 3GPPによって指定された汎用パケット無線サービス（GPRS）は、2Gおよび3Gセルラ通信システムのユーザに利用可能なパケット指向のモバイルデータサービスです。
High-Speed Packet Access
高速パケットアクセス
The High-Speed Packet Access (HSPA) and HSPA+ are enhanced versions of the Wideband Code Division Multiple Access (WCDMA) and UTRAN, thus providing more data throughput and lower latencies.
高速パケットアクセス（HSPA）とHSPA +は、このように複数のデータ・スループットと低いレイテンシを提供し、広帯域符号分割多元接続（WCDMA）及びUTRANのバージョンを高められます。
Home Location Register
ホーム・ロケーション・レジスタ
The Home Location Register (HLR) is a pre-Release-5 database (but is also used in Release-5 and later networks in real deployments) that contains subscriber data and information related to call routing. All subscribers of an operator, and the subscribers' enabled services, are provisioned in the HLR.
ホームロケーションレジスタ（HLR）はプレリリース-5データベースである（しかし、実際の展開でリリース-5以降のネットワークでも使用されている）コールルーティングに関連した加入者データおよび情報が含まれています。すべてのオペレータの加入者、および加入者の対応サービスは、HLRでプロビジョニングされています。
Home Subscriber Server
ホーム加入者サーバ
The Home Subscriber Server (HSS) is a database for a given subscriber and was introduced in 3GPP Release-5. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions.
ホーム加入者サーバ（HSS）は、所与の加入者のためのデータベースであり、3GPPリリース5で導入されました。これは、実際に通話/セッションを処理するネットワークエンティティをサポートするために、サブスクリプション関連情報を含むエンティティです。
Mobility Management Entity
モビリティ管理エンティティ
The Mobility Management Entity (MME) is a network element that is responsible for control-plane functionalities, including authentication, authorization, bearer management, layer-2 mobility, etc. The MME is essentially the control-plane part of the SGSN in the GPRS. The user-plane traffic bypasses the MME.
モビリティ管理エンティティ（MME）等の認証、認可、管理ベアラ、レイヤ2モビリティ、を含む制御プレーン機能、MMEのために責任があるネットワーク要素は、本質的に、GPRSにおけるSGSNの制御プレーンの一部であります。ユーザプレーントラフィックは、MMEをバイパスします。
Mobile Terminal
モバイル端末
The Mobile Terminal (MT) is the modem and the radio part of the Mobile Station (MS).
移動端末（MT）は、移動局（MS）のモデムと無線部です。
Public Land Mobile Network
公衆陸上モバイルネットワーク
The Public Land Mobile Network (PLMN) is a network that is operated by a single administration. A PLMN (and therefore also an operator) is identified by the Mobile Country Code (MCC) and the Mobile Network Code (MNC). Each (telecommunications) operator providing mobile services has its own PLMN.
公衆陸上モバイルネットワーク（PLMN）は、単回投与によって運営されているネットワークです。 PLMN（従って、オペレータ）は、モバイル国コード（MCC）およびモバイルネットワークコード（MNC）によって識別されます。モバイルサービスを提供する各（電気通信）事業者は、独自のPLMNを持っています。
Policy and Charging Control
ポリシーおよび課金制御
The Policy and Charging Control (PCC) framework is used for QoS policy and charging control. It has two main functions: flow-based charging, including online credit control; and policy control (e.g., gating control, QoS control, and QoS signaling). It is optional to 3GPP EPS but needed if dynamic policy and charging control by means of PCC rules based on user and services are desired.
ポリシー及び課金制御（PCC）フレームワークは、QoSポリシーおよび制御を充電するために使用されます。これは、2つの主要な機能があります：フローベースの課金、オンラインクレジット制御を含むが、およびポリシー制御（例えば、ゲーティング制御、QoS制御、およびQoSシグナリング）。これは、3GPP EPSのオプションが、ユーザおよびサービスに基づいて、PCC規則によって動的ポリシー及び課金制御が所望される場合に必要です。
Packet Data Network
パケット・データ・ネットワーク
The Packet Data Network (PDN) is a packet-based network that either belongs to the operator or is an external network such as the Internet or a corporate intranet. The user eventually accesses services in one or more PDNs. The operator's packet core networks are separated from packet data networks either by GGSNs or PDN Gateways (PDN-GWs).
パケットデータネットワーク（PDN）は、オペレータに属するか、またはインターネットなどの外部ネットワークまたは企業イントラネットのいずれかのパケットベースのネットワークです。ユーザーは、最終的には一の以上のPDNにサービスにアクセスします。オペレータのパケットコアネットワークは、パケットデータネットワークのいずれかからのGGSN又はPDNゲートウェイ（PDN-のGW）によって分離されています。
Packet Data Network Gateway
パケットデータネットワークゲートウェイ
The Packet Data Network Gateway (PDN-GW) is a gateway function in the Evolved Packet System (EPS), which provides connectivity to the Internet or other PDNs. The host attaches to a PDN-GW identified by an APN assigned to it by an operator. The PDN-GW also serves as the topological anchor for addresses/prefixes assigned to the User Equipment.
パケットデータネットワークゲートウェイ（PDN-GW）は、インターネットまたは他のPDNへの接続性を提供する発展型パケットシステム（EPS）におけるゲートウェイ機能です。ホストは、オペレータがそれに割り当てられたAPNによって識別PDN-GWに付着します。 PDN-GWはまた、ユーザ機器に割り当てられたアドレス/プレフィックスのためのトポロジーのアンカーとして働きます。
Packet Data Protocol Context
パケットデータプロトコルコンテキスト
A Packet Data Protocol (PDP) context is the equivalent of a virtual connection between the User Equipment (UE) and a PDN using a specific gateway.
パケットデータプロトコル（PDP）コンテキストは、特定のゲートウェイを使用して、ユーザ機器（UE）とPDNとの間の仮想接続のと等価です。
Packet Data Protocol Type
パケットデータプロトコルの種類
A Packet Data Protocol Type (PDP Type) identifies the used/allowed protocols within the PDP context. Examples are IPv4, IPv6, and IPv4v6 (dual-stack).
パケットデータプロトコルタイプ（PDPタイプ）は、PDPコンテキスト内で使用される/許可プロトコルを識別する。例としては、IPv4、IPv6、およびIPv4v6（デュアルスタック）です。
S4 Serving GPRS Support Node
S4は、サービングGPRSサポートノード
The S4 Serving GPRS Support Node (S4-SGSN) is compliant with a Release-8 (and onwards) SGSN that connects 2G/3G radio access networks to the EPC via new Release-8 interfaces like S3, S4, and S6d.
S4サービングGPRSサポートノード（S4-SGSN）がS3、S4、およびS6Dような新しいリリース-8インターフェースを介してEPCに2G / 3G無線アクセスネットワークを接続する（以降と）リリース8 SGSNに準拠しています。
Serving Gateway
サービングゲートウェイ
The Serving Gateway (SGW) is a gateway function in the EPS, which terminates the interface towards the E-UTRAN. The SGW is the Mobility Anchor point for layer-2 mobility (inter-eNodeB handovers). For each UE connected with the EPS, at any given point in time, there is only one SGW. The SGW is essentially the user-plane part of the GPRS's SGSN.
サービングゲートウェイ（SGW）は、E-UTRANに向かってインタフェースを終端EPSにおけるゲートウェイ機能、です。 SGWは、レイヤ2モビリティ（インターeNodeBのハンドオーバ）のためのモビリティ・アンカー・ポイントです。時間内の任意の所与の時点で、EPSに接続された各UEのために、唯一のSGWがあります。 SGWは、本質的にGPRSのSGSNのユーザプレーン部分です。
Serving GPRS Support Node
サービングGPRSサポートノード
The Serving GPRS Support Node (SGSN) is a network element that is located between the radio access network (RAN) and the gateway (GGSN). A per-UE point-to-point (p2p) tunnel between the GGSN and SGSN transports the packets between the UE and the gateway.
サービングGPRSサポートノード（SGSN）は、無線アクセスネットワーク（RAN）とゲートウェイ（GGSN）との間に位置するネットワーク要素です。 GGSNとSGSNとの間の単位のUEのポイントツーポイント（P2P）トンネルがUEとゲートウェイの間でパケットを搬送します。
Terminal Equipment
端末装置
The Terminal Equipment (TE) is any device/host connected to the Mobile Terminal (MT) offering services to the user. A TE may communicate to an MT, for example, over the Point to Point Protocol (PPP).
端末装置（TE）は、ユーザにサービスを提供する移動端末（MT）に接続された任意のデバイス/ホストです。 TEは、プロトコル（PPP）をポイント・ツー・ポイントの上、例えば、MTに通信することができます。
UE, MS, MN, and Mobile
UE、MS、MN、モバイル
The terms UE (User Equipment), MS (Mobile Station), MN (Mobile Node), and mobile refer to the devices that are hosts with the ability to obtain Internet connectivity via a 3GPP network. A MS is comprised of the Terminal Equipment (TE) and a Mobile Terminal (MT). The terms UE, MS, MN, and mobile are used interchangeably within this document.
用語は、UE（ユーザ機器）、MS（移動局）、MN（モバイルノード）、及びモバイルは、3GPPネットワークを介してインターネット接続を得る能力を有するホストであるデバイスを指します。 MSは、端末装置（TE）と移動端末（MT）から構成されています。用語UE、MS、MN、モバイルは、このドキュメント内で互換的に使用されます。
UMTS Terrestrial Radio Access Network
UMTS地上無線アクセスネットワーク
The Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) is a communications network, commonly referred to as 3G, and consists of NodeBs (3G base stations) and Radio Network Controllers (RNCs), which make up the UMTS radio access network. The UTRAN allows connectivity between the UE and the core network. The UTRAN is comprised of WCDMA, HSPA, and HSPA+ radio technologies.
ユニバーサル移動通信システムUMTS無線アクセスを構成する（UMTS）地上無線アクセスネットワーク（UTRAN）は、一般に、3Gと呼ばれる通信ネットワークであり、ノードB（3G基地局）と無線ネットワーク制御装置（RNC）から成り、通信網。 UTRANは、UEとコアネットワーク間の接続を可能にします。 UTRANは、WCDMA、HSPA、およびHSPA +の無線技術で構成されています。
User Plane
ユーザプレーン
The user plane refers to data traffic and the required bearers for the data traffic. In practice, IP is the only data traffic protocol used in the user plane.
ユーザプレーンは、データトラフィックとデータトラフィックのための必要なベアラを指します。実際には、IPは、ユーザプレーンで使用される唯一のデータトラフィックのプロトコルです。
Wideband Code Division Multiple Access
広帯域符号分割多元接続
The Wideband Code Division Multiple Access (WCDMA) is the radio interface used in UMTS networks.
広帯域符号分割多元接続（WCDMA）はUMTSネットワークで使用する無線インタフェースです。
eNodeB
eNodeB
The eNodeB is a base station entity that supports the Long-Term Evolution (LTE) air interface.
eNodeBは、ロングタームエボリューション（LTE）エアインターフェースをサポートする基地局エンティティです。
The Access Point Name (APN) essentially refers to a gateway in the 3GPP network. The 'complete' APN is expressed in a form of a Fully Qualified Domain Name (FQDN) and also piggybacked on the administration of the DNS namespace, thus effectively allowing the discovery of gateways using the DNS. The UE can choose to attach to a specific gateway in the packet core. The gateway provides connectivity to the Packet Data Network (PDN), such as the Internet. An operator may also include gateways that do not provide Internet connectivity but rather provide connectivity to a closed network providing a set of the operator's own services. A UE can be attached to one or more gateways simultaneously. The gateway in a 3GPP network is the GGSN or PDN-GW. Figure 1 illustrates the APN-based network connectivity concept.
アクセスポイント名（APN）は、本質的に、3GPPネットワークにおけるゲートウェイを指します。 「完全な」APNは、完全修飾ドメイン名（FQDN）の形で表現し、また効果的にDNSを使用して、ゲートウェイの発見を可能にする、DNS名前空間の投与にピギーバックされます。 UEは、パケットコアにおける特定のゲートウェイに接続することを選択できます。ゲートウェイは、インターネットなどのパケットデータネットワーク（PDN）への接続性を提供します。また、オペレータは、インターネット接続を提供するのではなく、操作者自身の一連のサービスを提供するクローズドネットワークへの接続を提供していないゲートウェイを含むことができます。 UEは、同時に1つ以上のゲートウェイに結合させることができます。 3GPPネットワーク内のゲートウェイはGGSN又はPDN-GWです。図1は、APNベースのネットワーク接続の概念を示す図です。
.--.
_(. `)
.--. +------------+ _( PDN `)_
_(Core`. |GW1 |====( Internet `)
+---+ ( NW )------|APN=internet| ( ` . ) )
[UE]~~~~|RAN|----( ` . ) )--+ +------------+ `--(_______)---'
^ +---+ `--(___.-' |
| | .--.
| | +----------+ _(.PDN`)
| +--|GW2 | _(Operator`)_
| |APN=OpServ|====( Services `)
UE is attached +----------+ ( ` . ) )
to GW1 and GW2 `--(_______)---'
simultaneously
Figure 1: User Equipment Attached to Multiple APNs Simultaneously
図1：同時に複数のAPNに付属のユーザ機器
A simplified 2G/3G GPRS architecture is illustrated in Figure 2. This architecture basically covers the GPRS core network from R99 to Release-7, and radio access technologies such as GSM (2G), EDGE (2G, often referred to as 2.5G), WCDMA (3G), and HSPA(+) (3G, often referred to as 3.5G). The architecture shares obvious similarities with the Evolved Packet System (EPS), as will be seen in Section 4. Based on Gn/Gp interfaces, the GPRS core network functionality is logically implemented on two network nodes -- the SGSN and the GGSN.
簡略2G / 3G GPRSアーキテクチャは図2に示されているこのアーキテクチャは、基本的にリリース-7のためにR99からGPRSコアネットワークを覆い、例えばGSM（2G）、EDGE（2G、しばしば2.5Gと呼ばれる）のような無線アクセス技術、WCDMA（3G）、およびHSPA（+）（3Gは、しばしば3.5Gと呼ばれます）。アーキテクチャ共有明らか発展型パケットシステム（EPS）との類似性、Gnの/ GPのインターフェイスに基づいて、セクション4で見られるように、GPRSコアネットワーク機能は、論理的に2つのネットワークノードに実装され - SGSNとGGSN。
3G
.--. .--.
Uu _( `. Iu +----+ +----+ _( `.
[UE]~~|~~~( UTRAN )--|---|SGSN|--|---|GGSN|--|----( PDN )
( ` . ) ) +----+ Gn +----+ Gi ( ` . ) )
`--(___.-' / | `--(___.-'
/ |
2G Gb-- |
.--. / |
_( `. / --Gp
[UE]~~|~~~( PDN )__/ |
Um ( ` . ) ) .--.
`--(___.-' _(. `)
_( [GGSN] `)_
( other `)
( ` . PLMN ) )
`--(_______)---'
Figure 2: Overview of the 2G/3G GPRS Logical Architecture
図2：2G / 3G GPRS論理アーキテクチャの概要
Gn/Gp: Interfaces that provide a network-based mobility service for a UE and are used between an SGSN and a GGSN. The Gn interface is used when the GGSN and SGSN are located inside one operator (i.e., a PLMN). The Gp-interface is used if the GGSN and the SGSN are located in different operator domains (i.e., a different PLMN). GTP is defined for the Gn/Gp interfaces (both GTP-C for the control plane and GTP-U for the user plane).
GN / GP：UEのためのネットワーク・ベースのモビリティサービスを提供し、SGSNとGGSNとの間で使用されるインタフェース。 GGSN及びSGSNは、1つのオペレータ（すなわち、PLMN）の内側に配置されている場合Gnインタフェースが使用されます。 GGSN及びSGSNは、異なるオペレータドメイン（すなわち、異なるPLMN）内に配置されている場合、GP-インタフェースが使用されます。 GTPはGnの/ GPインタフェース（制御プレーンとユーザプレーンのGTP-UのためのGTP-Cの両方）のために定義されています。
Gb: The Base Station System (BSS)-to-SGSN interface, which is used to carry information concerning packet data transmission and layer-2 mobility management. The Gb-interface is based on either Frame Relay or IP.
GB：パケットデータ伝送とレイヤ2モビリティ管理に関する情報を搬送するために使用される基地局システム（BSS）-to-SGSNインタフェース。ギガビット・インターフェースは、フレームリレーまたはIPのいずれかに基づいています。
Iu: The Radio Network System (RNS)-to-SGSN interface, which is used to carry information concerning packet data transmission and layer-2 mobility management. The user-plane part of the Iu-interface (actually the Iu-PS) is based on GTP-U. The control-plane part of the Iu-interface is based on the Radio Access Network Application Protocol (RANAP).
IU：パケットデータ伝送とレイヤ2モビリティ管理に関する情報を搬送するために使用される無線ネットワークシステム（RNS）-to-SGSNインタフェース。 Iuインタフェースのユーザプレーン部分（実際のIu-PS）は、GTP-Uに基づいています。 Iuインタフェースの制御プレーン部は、無線アクセスネットワークアプリケーションプロトコル（RANAP）に基づいています。
Gi: The interface between the GGSN and a PDN. The PDN may be an operator's external public or private packet data network, or an intra-operator packet data network.
GI：GGSNとPDNとの間のインターフェース。 PDNは、作業者の外部のパブリックまたはプライベートパケットデータネットワーク、またはオペレータ内のパケットデータネットワークであってもよいです。
Uu/Um: 2G or 3G radio interfaces between a UE and a respective radio access network.
UU /あの：UEと各無線アクセスネットワークとの間の2Gまたは3G無線インタフェース。
The SGSN is responsible for the delivery of data packets from and to the UE within its geographical service area when a direct tunnel option is not used. If the direct tunnel is used, then the user plane goes directly between the RNC (in the RNS) and the GGSN. The control-plane traffic always goes through the SGSN. For each UE connected with the GPRS, at any given point in time, there is only one SGSN.
直接トンネルオプションを使用しない場合、SGSNは、その地理的サービスエリア内のUEから及びへのデータパケットの配信の責任です。ダイレクトトンネルが使用される場合、ユーザプレーンは、（RNS）でRNCとGGSNとの間で直接進みます。コントロールプレーントラフィックは、常にSGSNを通過します。時間内の任意の所与の時点で、GPRSに接続された各UEのために、唯一のSGSNが存在します。
A PDP (Packet Data Protocol) context is an association between a UE represented by one IPv4 address and/or one /64 IPv6 prefix, and a PDN represented by an APN. Each PDN can be accessed via a gateway (typically a GGSN or PDN-GW). On the UE, a PDP context is equivalent to a network interface. A UE may hence be attached to one or more gateways via separate connections, i.e., PDP contexts. 3GPP GPRS supports PDP Types IPv4, IPv6, and since Release-9, PDP Type IPv4v6 (dual-stack) as well.
PDP（パケットデータプロトコル）コンテキストは、1つのIPv4アドレス、および/または1/64のIPv6プレフィックス、及びAPNで表されるPDN表されるUEとの間の関連付けです。各PDNゲートウェイ（典型的には、GGSN又はPDN-GW）を介してアクセスすることができます。 UEに、PDPコンテキストは、ネットワークインターフェースに相当します。 UEは、したがって、別個の接続、即ち、PDPコンテキストを介して1つまたは複数のゲートウェイに取り付けることができます。 3GPP GPRSにもPDPタイプのIPv4、IPv6、およびリリース・9以来、PDPタイプIPv4v6（デュアルスタック）をサポートしています。
Each primary PDP context has its own IPv4 address and/or one /64 IPv6 prefix assigned to it by the PDN and anchored in the corresponding gateway. The GGSN or PDN-GW is the first-hop router for the UE. Applications on the UE use the appropriate network interface (PDP context) for connectivity to a specific PDN. Figure 3 represents a high-level view of what a PDP context implies in 3GPP networks.
各プライマリPDPコンテキストは、対応するゲートウェイにPDNによってそれに割り当てられ、固定され、自身のIPv4アドレス、および/または1/64のIPv6プレフィックスを有しています。 GGSN又はPDN-GWは、UEのための最初のホップルータです。 UE上のアプリケーションは、特定のPDNへの接続のための適切なネットワークインターフェース（PDPコンテキスト）を使用します。図3は、PDPコンテキストは、3GPPネットワークにおいて意味何の高レベルのビューを表します。
Y
| +---------+ .--.
|--+ __________________________ | APNx in | _( `.
| |O______PDPc1_______________)| GGSN / |----(Internet)
| | | PDN-GW | ( ` . ) )
|UE| +---------+ `--(___.-'
| | _______________________ +---------+ .--.
| |O______PDPc2____________)| APNy in | _(Priv`.
+--+ | GGSN / |-------(Network )
| PDN-GW | ( ` . ) )
+---------+ `--(___.-'
Figure 3: PDP Contexts between the MS/UE and Gateway
図3：MS / UEとゲートウェイとの間のPDPコンテキスト
In the above figure, there are two PDP contexts at the MS/UE: the 'PDPc1' PDP context, which is connected to APNx, provides Internet connectivity, and the 'PDPc2' PDP context provides connectivity to a private IP network via APNy (as an example, this network may include operator-specific services, such as the MMS (Multimedia Messaging Service)). An application on the host, such as a web browser, would use the PDP context that provides Internet connectivity for accessing services on the Internet. An application such as a MMS would use APNy in the figure above, because the service is provided through the private network.
上記の図では、MS / UEに2つのPDPコンテキストがある：「PDPc1」PDPコンテキスト、APNxに接続されている、（インターネット接続を提供し、「PDPC2」PDPコンテキストはAPNy介して、プライベートIPネットワークへの接続を提供一例として、このネットワークは、MMS（マルチメディアメッセージングサービス））などのオペレータ固有のサービスを含んでもよいです。ホスト上のアプリケーションは、Webブラウザなど、インターネット上のサービスにアクセスするためのインターネット接続を提供してPDPコンテキストを使用します。サービスは、プライベートネットワークを介して提供されるので、このようなMMSなどのアプリケーションでは、上の図にAPNyを使用します。
In its most basic form, the EPS architecture consists of only two nodes on the user plane: a base station and a core network Gateway (GW). The basic EPS architecture is illustrated in Figure 4. The functional split of gateways allows operators to choose optimized topological locations of nodes within the network and enables various deployment models, including the sharing of radio networks between different operators. This also allows independent scaling, growth of traffic throughput, and control-signal processing.
基地局とコア・ネットワーク・ゲートウェイ（GW）：最も基本的な形態では、EPSアーキテクチャは、ユーザプレーン上の2つのノードのみで構成されています。基本EPSアーキテクチャは、ゲートウェイの機能分割は、オペレータが、ネットワーク内のノードの最適化されたトポロジー的位置を選択することを可能にし、異なるオペレータ間の無線ネットワークの共有など様々な展開モデルを、可能にする。図4に示されています。これはまた、独立したスケーリング、トラフィックのスループットの成長、および制御信号の処理を可能にします。
+--------+
| IP |
S1-MME +-------+ S11 |Services|
+----|----| MME |----|----+ +--------+
| | | | |SGi
| +-------+ | S5/ |
+----+ LTE-Uu +-------+ S1-U +-------+ S8 +-------+
|UE |----|---|eNodeB |---|-----------------| SGW |--|---|PDN-GW |
| |========|=======|=====================|=======|======| |
+----+ +-------+Dual-Stack EPS Bearer+-------+ +-------+
Figure 4: EPS Architecture for 3GPP Access
図4：3GPPアクセスのためのEPSアーキテクチャ
S5/S8: Provides user-plane tunnelling and tunnel management between the SGW and PDN-GW, using GTP (both GTP-U and GTP-C) or PMIPv6 [RFC5213] [TS.23402] as the network-based mobility management protocol. The S5 interface is used when the PDN-GW and SGW are located inside one operator (i.e., a PLMN). The S8-interface is used if the PDN-GW and the SGW are located in different operator domains (i.e., a different PLMN).
S5 / S8：ネットワーク・ベースのモビリティ管理プロトコルとして[TS.23402] GTP（GTP-Uの両方とGTP-C）又はPMIPv6の[RFC5213]を使用して、SGWとPDN-GWとの間でユーザプレーントンネリングおよびトンネル管理を提供。 PDN-GWとSGWは、1つのオペレータ（すなわち、PLMN）の内側に位置しているときにS5インタフェースが使用されます。 PDN-GWとSGWが異なるオペレータドメイン（すなわち、異なるPLMN）に配置されている場合にS8インタフェースが使用されます。
S11: Reference point for the control-plane protocol between the MME and SGW, based on GTP-C (GTP control plane) and used, for example, during the establishment or modification of the default bearer.
S11：デフォルトベアラの確立又は修正中に、例えば、MMEとSGWとの間の制御プレーンプロトコル、GTP-C（GTP制御プレーン）に基づいて使用される、基準点。
S1-U: Provides user-plane tunnelling and inter-eNodeB path switching during handover between the eNodeB and SGW, using GTP-U (GTP user plane).
S1-U：GTP-U（GTPユーザプレーン）を使用して、ユーザプレーントンネリングとeNodeBとSGW間ハンドオーバ時のスイッチング間のeNodeBの経路を提供します。
S1-MME: Reference point for the control-plane protocol between the eNodeB and MME.
S1-MME：eNodeBとMME間の制御プレーンプロトコルの基準点。
SGi: The interface between the PDN-GW and the PDN. The PDN may be an operator-external public or private packet data network or an intra-operator packet data network.
SGiを：PDN-GWとPDNとの間のインターフェイス。 PDNは、オペレータ外部パブリックまたはプライベートパケットデータネットワークまたはイントラオペレータパケット・データ・ネットワークであってもよいです。
A PDN connection is an association between a UE represented by one IPv4 address and/or one /64 IPv6 prefix, and a PDN represented by an APN. The PDN connection is the EPC equivalent of the GPRS PDP context. Each PDN can be accessed via a gateway (a PDN-GW). The PDN is responsible for the IP address/prefix allocation to the UE. On the UE, a PDN connection is equivalent to a network interface. A UE may hence be attached to one or more gateways via separate connections, i.e., PDN connections. 3GPP EPS supports PDN Types IPv4, IPv6, and IPv4v6 (dual-stack) since the beginning of EPS, i.e., since Release-8.
PDN接続は、1つのIPv4アドレス、および/または1/64のIPv6プレフィックスで表されるUE、およびAPNで表されるPDNとの間の関連付けです。 PDN接続は、GPRS PDPコンテキストのEPCと同等です。各PDNゲートウェイ（PDN-GW）を介してアクセスすることができます。 PDNは、UEにIPアドレス/プレフィックスの割り当てを担当しています。 UEに、PDN接続は、ネットワークインターフェースに相当します。 UEは、したがって、別個の接続、すなわち、PDN接続を介して1つ以上のゲートウェイに取り付けることができます。 3GPP EPSはリリース-8以降、すなわち、EPSの初めからPDNタイプのIPv4、IPv6、およびIPv4v6（デュアルスタック）をサポートしています。
Each PDN connection has its own IP address/prefix assigned to it by the PDN and anchored in the corresponding gateway. In the case of the GTP-based S5/S8 interface, the PDN-GW is the first-hop router for the UE, and in the case of PMIPv6-based S5/S8, the SGW is the first-hop router. Applications on the UE use the appropriate network interface (PDN connection) for connectivity.
各PDN接続は、自身のIPアドレス/プレフィックスがPDNによってそれに割り当てられ、対応するゲートウェイに固定有します。 GTPベースのS5 / S8インタフェースの場合には、PDN-GWは、UEのための最初のホップルータである、とのPMIPv6ベースのS5 / S8の場合、SGWは、最初のホップルータです。 UE上のアプリケーションは、接続のための適切なネットワークインターフェース（PDN接続）を使用します。
The logical concept of a bearer has been defined to be an aggregate of one or more IP flows related to one or more services. An EPS bearer exists between the UE and the PDN-GW and is used to provide the same level of packet-forwarding treatment to the aggregated IP flows constituting the bearer. Services with IP flows requiring different packet-forwarding treatment would therefore require more than one EPS bearer. The UE performs the binding of the uplink IP flows to the bearer, while the PDN-GW performs this function for the downlink packets.
ベアラの論理的な概念は、1つ以上のサービスに関連する1つのまたは複数のIPフローの集合であると定義されています。 EPSベアラは、UEとPDN-GWとの間に存在し、ベアラを構成するフロー集約IPのパケット転送処理の同じレベルを提供するために使用されます。 IPを持つサービスは、したがって、複数のEPSベアラを必要とするであろう異なるパケット転送処理を必要と流れます。 UEは、PDN-GWは、ダウンリンク・パケットは、この機能を実行しながら、IPは、ベアラに流れるアップリンクの結合を行います。
In order to always provide low latency on connectivity, a default bearer will be provided at the time of startup, and an IPv4 address and/or IPv6 prefix gets assigned to the UE (this is different from GPRS, where UEs are not automatically connected to a PDN and therefore do not get an IPv4 address and/or IPv6 prefix assigned until they activate their first PDP context). This default bearer will be allowed to carry all traffic that is not associated with a dedicated bearer. Dedicated bearers are used to carry traffic for IP flows that have been identified to require specific packet-forwarding treatment. They may be established at the time of startup -- for example, in the case of services that require always-on connectivity and better QoS than that provided by the default bearer. The default bearer and the dedicated bearer(s) associated to it share the same IP address(es)/prefix.
常時接続で低レイテンシを提供するために、デフォルトベアラは、起動時に提供され、IPv4アドレス及び/又はIPv6プレフィックスがUEに割り当てられます（これは、UEが自動的に接続されていないGPRS、異なりますPDNしたがって、彼らは彼らの最初のPDPコンテキストをアクティブにするまでのIPv4アドレスおよび/またはIPv6プレフィックスが割り当てられ得ることはありません）。このデフォルトベアラは、専用ベアラに関連付けられていないすべてのトラフィックを運ぶために許可されます。専用ベアラは、特定のパケット転送処理を必要とするように同定されているIPフローのトラフィックを伝送するために使用されています。接続とデフォルトベアラによって提供されるものよりも優れたQoSに常に必要とするサービスの場合には、例えば - これらは、起動時に設定することができます。デフォルトベアラと、それに関連した専用ベアラ（複数可）は、同じIPアドレス（複数可）/プレフィックスを共有します。
An EPS bearer is referred to as a Guaranteed Bit Rate (GBR) bearer if dedicated network resources related to a GBR value that is associated with the EPS bearer are permanently allocated (e.g., by an admission control function in the eNodeB) at bearer establishment/modification. Otherwise, an EPS bearer is referred to as a non-GBR bearer. The default bearer is always non-GBR, with the resources for the IP flows not guaranteed at the eNodeB, and with no admission control. However, the dedicated bearer can be either GBR or non-GBR. A GBR bearer has a GBR and Maximum Bit Rate (MBR), while more than one non-GBR bearer belonging to the same UE shares an Aggregate MBR (AMBR). Non-GBR bearers can suffer packet loss under congestion, while GBR bearers are immune to such losses as long as they honor the contracted bit rates.
EPSベアラが保証ビットレート（GBR）と呼ばベアラされた場合、ベアラ確立時EPSに関連しているベアラ恒久的（例えば、eノードBにおけるアドミッション制御機能によって）割り当てられたGBR値に関する専用ネットワーク・リソース/変形。そうでない場合は、EPSベアラは非GBRベアラと呼ばれます。デフォルトベアラは、IPのためのリソースと、常に非GBRでのeNodeBで保証、および無許可制御でない流れています。しかし、専用ベアラはGBRまたは非GBRのいずれかになります。複数の非GBRベアラが同一のUE共有集約MBR（AMBR）に所属しながら、GBRベアラは、GBR及び最大ビットレート（MBR）を有しています。 GBRベアラがいる限り、彼らは契約のビットレートを称えるような損失に免疫がある一方、非GBRベアラは、輻輳の下でパケット損失を被ることができます。
The UE's IPv4 address configuration is always performed during PDP context/EPS bearer setup procedures (on layer 2). DHCPv4-based [RFC2131] address configuration is supported by the 3GPP specifications, but is not used on a wide scale. The UE must always support address configuration as part of the bearer setup signaling, since DHCPv4 is optional for both UEs and networks.
UEのIPv4アドレスの設定は、常に（層2上）PDPコンテキスト/ EPSベアラセットアップ手順中に実行されます。 DHCPv4のベース[RFC2131]アドレス構成は、3GPP仕様によってサポートされているが、広い規模で使用されていません。 DHCPv4のがのUEとネットワークの両方のためのオプションであるので、UEは常に、ベアラ設定シグナリングの一部として、アドレス設定をサポートしなければなりません。
The 3GPP standards also specify a 'deferred IPv4 address allocation' on a PMIPv6-based dual-stack IPv4v6 PDN connection at the time of connection establishment, as described in Section 4.7.1 of [TS.23402]. This has the advantage of a single PDN connection for IPv6 and IPv4, along with deferring IPv4 address allocation until an application needs it. The deferred address allocation is based on the use of DHCPv4 as well as appropriate UE-side implementation-dependent triggers to invoke the protocol.
【TS.23402]のセクション4.7.1に記載したように3GPP規格はまた、コネクション確立時のPMIPv6ベースデュアルスタックIPv4v6 PDNコネクションの「繰延IPv4アドレス割当」を指定します。これは、それを必要とするアプリケーションまでのIPv4アドレスの割り当てを遅らせるとともに、IPv6とIPv4のための単一のPDN接続の利点を有します。遅延アドレスの割り当ては、プロトコルを呼び出すためのDHCPv4の使用、ならびに適切なUE側の実装に依存するトリガーに基づいています。
IPv6 Stateless Address Autoconfiguration (SLAAC), as specified in [RFC4861] and [RFC4862], is the only supported address configuration mechanism. Stateful DHCPv6-based address configuration [RFC3315] is not supported by 3GPP specifications. On the other hand, stateless DHCPv6 service to obtain other configuration information is supported [RFC3736]. This implies that the M-bit is always zero and that the O-bit may be set to one in the Router Advertisement (RA) sent to the UE.
IPv6のステートレスアドレス自動設定（SLAAC）は、[RFC4861]及び[RFC4862]で指定されるように、唯一のサポートアドレス構成メカニズムです。ステートフルDHCPv6のベースアドレス構成[RFC3315]は3GPP仕様によってサポートされていません。一方、ステートレスDHCPv6サービスは、[RFC3736]をサポートされている他の構成情報を取得します。これは、Mビットは常にゼロであり、O-ビットがUEに送信されたルータ広告（RA）内の1つに設定することができることをことを意味します。
The 3GPP network allocates each default bearer a unique /64 prefix, and uses layer-2 signaling to suggest to the UE an Interface Identifier that is guaranteed not to conflict with the gateway's Interface Identifier. The UE must configure its link-local address using this Interface Identifier. The UE is allowed to use any Interface Identifier it wishes for the other addresses it configures. There is no restriction, for example, on using privacy extensions for SLAAC [RFC4941] or other similar types of mechanisms. However, there are network drivers that fail to pass the Interface Identifier to the stack and instead synthesize their own Interface Identifier (usually a Media Access Control (MAC) address equivalent). If the UE skips the Duplicate Address Detection (DAD) and also has other issues with the Neighbor Discovery protocol (see Section 5.4), then there is a
3GPPネットワークは、一意/ 64プレフィックスベアラ各デフォルトを割り当て、UEにゲートウェイのインタフェース識別子と競合しないことが保証されているインタフェース識別子を示唆するレイヤ2シグナリングを使用します。 UEは、このインタフェース識別子を使用して、そのリンクローカルアドレスを設定する必要があります。 UEは、構成の他のアドレスのためにそれが望む任意のインタフェース識別子を使用することができます。制限はSLAAC [RFC4941]または機構の他の同様のタイプのプライバシー拡張を使用して、例えば、存在しません。しかし、自分自身のインタフェース識別子（通常はメディアアクセス制御（MAC）アドレスに相当）を合成スタックにインタフェース識別子を渡して、代わりに失敗したネットワークドライバがあります。 UEは、重複アドレス検出（DAD）をスキップしても、近隣探索プロトコルとその他の問題がある場合、そこにある（5.4節参照）
small theoretical chance that the UE will configure exactly the same link-local address as the GGSN/PDN-GW. The address collision may then cause issues in IP connectivity -- for instance, the UE not being able to forward any packets to the uplink.
UEは、GGSN / PDN-GWと全く同じリンクローカルアドレスを設定することを小さな理論チャンス。アドレス衝突は、IP接続に問題が発生する可能性があり - 例えば、UEは、アップリンクに任意のパケットを転送することができません。
In the 3GPP link model, the /64 prefix assigned to the UE cannot be used for on-link determination (because the L-bit in the Prefix Information Option (PIO) in the RA must always be set to zero). If the advertised prefix is used for SLAAC, then the A-bit in the PIO must be set to one. Details of the 3GPP link-model and address configuration are provided in Section 11.2.1.3.2a of [TS.29061]. More specifically, the GGSN/PDN-GW guarantees that the /64 prefix is unique for the UE. Therefore, there is no need to perform any DAD on addresses the UE creates (i.e., the 'DupAddrDetectTransmits' variable in the UE could be zero). The GGSN/PDN-GW is not allowed to generate any globally unique IPv6 addresses for itself using the /64 prefix assigned to the UE in the RA.
（RAのプレフィックス情報オプション（PIO）のLビットは常にゼロに設定しなければならないので）、3GPPリンクモデルでは、UEに割り当てられた/ 64プレフィックスはオンリンク決意するために使用することができません。アドバタイズされたプレフィックスがSLAACのために使用されている場合は、PIOでのAビットが1に設定する必要があります。 3GPPリンクモデルとアドレス設定の詳細については、[TS.29061]のセクション11.2.1.3.2aに設けられています。より具体的には、/ 64プレフィックスがUEのために一意であることをGGSN / PDN-GWを保証します。したがって、UEは、作成したアドレス上の任意のDAD（すなわち、UEにおける「DupAddrDetectTransmits」変数がゼロであってもよい）を実行する必要はありません。 GGSN / PDN-GWは、RAにUEに割り当てられた/ 64プレフィックスを使用して自身のための任意のグローバルに一意のIPv6アドレスを生成することができません。
The current 3GPP architecture limits the number of prefixes in each bearer to a single /64 prefix. If the UE finds more than one prefix in the RA, it only considers the first one and silently discards the others [TS.29061]. Therefore, multi-homing within a single bearer is not possible. Renumbering without closing the layer-2 connection is also not possible. The lifetime of the /64 prefix is bound to the lifetime of the layer-2 connection even if the advertised prefix lifetime is longer than the layer-2 connection lifetime.
現在の3GPPアーキテクチャは、単一の/ 64プレフィックスに各ベアラにおけるプレフィクスの数を制限します。 UEは、RAに複数の接頭辞が見つかった場合、それは最初のものだけを考慮し、サイレント他[TS.29061]を破棄する。したがって、単一のベアラ内マルチホーミングは不可能です。レイヤ2接続を閉じずに再番号付けすることも可能ではありません。 / 64プレフィックスの寿命は、広告を出して、プレフィックスの有効期間は、レイヤ2接続の寿命より長い場合でも、レイヤ2接続の寿命にバインドされています。
IPv6 prefix delegation is a part of Release-10 and is not covered by any earlier releases. However, the /64 prefix allocated for each default bearer (and to the UE) may be shared to the local area network by the UE implementing Neighbor Discovery proxy (ND proxy) [RFC4389] functionality.
IPv6プレフィックス委任をリリース-10の一部であり、任意の以前のリリースで覆われていません。しかし、/ 64各デフォルトベアラのために割り当てられたプレフィックス（及びUE）が近隣探索プロキシ（NDプロキシ）[RFC4389]機能を実装するUEによってローカルエリアネットワークに共有されてもよいです。
The Release-10 prefix delegation uses the DHCPv6-based prefix delegation [RFC3633]. The model defined for Release-10 requires aggregatable prefixes, which means the /64 prefix allocated for the default bearer (and to the UE) must be part of the shorter delegated prefix. DHCPv6 prefix delegation has an explicit limitation, described in Section 12.1 of [RFC3633], that a prefix delegated to a requesting router cannot be used by the delegating router (i.e., the PDN-GW in this case). This implies that the shorter 'delegated prefix' cannot be given to the requesting router (i.e., the UE) as such but has to be delivered by the delegating router (i.e., the PDN-GW) in such a way that the /64 prefix allocated to the default bearer is not part of the 'delegated prefix'. An option to exclude a prefix from delegation [PD-EXCLUDE] prevents this problem.
リリース-10プレフィックス委譲は、DHCPv6のベースのプレフィックス委譲[RFC3633]を使用しています。 RELEASE-10のために定義されたモデルは、デフォルトベアラ（及びUE）が短い委譲されたプレフィックスの一部でなければならないために割り当てられた/ 64プレフィックスを意味集約プレフィックスを必要とします。 DHCPv6のプレフィックス委譲を要求ルータに委譲されたプレフィックスが委任ルータによって使用することができないことを、[RFC3633]のセクション12.1で説明明示的な制限を有する（すなわち、PDN-GWこの場合）。これは、短い「委譲されたプレフィックスが」要求ルータに与えることができないことを意味する（すなわち、UE）のようなそのような方法で、委任ルータ（すなわち、PDN-GW）によって送達されなければならないことを/ 64プレフィックスデフォルトベアラに割り当てられたが「委任プレフィックス」の一部ではありません。代表団からプレフィックスを除外するためのオプションが[PD-EXCLUDE]この問題を防ぐことができます。
The 3GPP link between the UE and the next-hop router (e.g., the GGSN) resembles a point-to-point (p2p) link, which has no link-layer addresses [RFC3316], and this has not changed from the 2G/3G GPRS to the EPS. The UE IP stack has to take this into consideration. When the 3GPP PDP context appears as a PPP interface/link to the UE, the IP stack is usually prepared to handle the Neighbor Discovery protocol and the related Neighbor Cache state machine transitions in an appropriate way, even though Neighbor Discovery protocol messages contain no link-layer address information. However, some operating systems discard Router Advertisements on their PPP interface/link as a default setting. This causes SLAAC to fail when the 3GPP PDP context gets established, thus stalling all IPv6 traffic.
UEとネクストホップルータ（例えば、GGSN）との間の3GPPリンクには、リンク層アドレスを有していないポイントツーポイント（P2P）リンク、[RFC3316]に似ているが、これは2Gから変化していません/ EPSへの3G GPRS。 UE IPスタックは、これを考慮する必要があります。 3GPP PDPコンテキストは、UEへのPPPインタフェース/リンクとして表示されたら、IPスタックは、近隣探索プロトコルメッセージがないリンクが含まれていないにもかかわらず、通常、適切な方法で近隣探索プロトコルおよび関連する近隣キャッシュステートマシン遷移を扱うために用意されアドレス情報-layer。ただし、一部のオペレーティングシステムでは、デフォルト設定として、そのPPPインターフェース/リンク上でルータ広告を捨てます。これにより、すべてのIPv6トラフィックを失速、3GPP PDPコンテキストが確立されますときSLAACが失敗します。
Currently, several operating systems and their network drivers can make the 3GPP PDP context appear as an IEEE 802 interface/link to the IP stack. This has a few known issues, especially when the IP stack is made to believe that the underlying link has link-layer addresses. First, the Neighbor Advertisement sent by a GGSN as a response to a Neighbor Solicitation triggered by address resolution might not contain a Target Link-Layer Address option (see Section 4.4 of [RFC4861]). It is then possible that the address resolution never completes when the UE tries to resolve the link-layer address of the GGSN, thus stalling all IPv6 traffic.
現在、複数のオペレーティングシステムおよび3GPP PDPコンテキストを作ることができ、ネットワークドライバは、IPスタックにIEEE 802インターフェイス/リンクとして表示されます。これは、IPスタックが根底にあるリンクは、リンク層アドレスを持っていることを信じるように作られている場合は特に、いくつかの既知の問題があります。アドレス解決によってトリガ近隣要請に対する応答がターゲットリンク層アドレスオプションが含まれていない可能性がありますようGGSNによって送信された第1の、近隣広告（[RFC4861]のセクション4.4を参照）。 UEは、このように、すべてのIPv6トラフィックを失速、GGSNのリンク層アドレスを解決しようとすると、アドレス解決が完了しないことが可能です。
Second, the GGSN may simply discard all Neighbor Solicitation messages triggered by address resolution (as Section 2.4.1 of [RFC3316] is sometimes misinterpreted as saying that responding to address resolution and next-hop determination is not needed). As a result, the address resolution never completes when the UE tries to resolve the link-layer address of the GGSN, thus stalling all IPv6 traffic. There is little that can be done about this in the GGSN, assuming the neighbor-discovery implementation already does the right thing. But the UE stacks must be able to handle address resolution in the manner that they have chosen to represent the interface. In other words, if they emulate IEEE 802 interfaces, they also need to process Neighbor Discovery messages correctly.
第二に、GGSNは、単にアドレス解決によってトリガ全て近隣要請メッセージを破棄してもよい（[RFC3316]のセクション2.4.1として時々応答する解像度と次ホップ決定が必要とされない対処するというとして誤って解釈されます）。 UEは、このように、すべてのIPv6トラフィックを失速、GGSNのリンク層アドレスを解決しようとしたときにその結果、アドレス解決が完了したことはありません。近隣探索の実装は、すでに正しいことをすると仮定すると、GGSNにこのことについて行うことができることはほとんどないです。しかし、UEスタックは、彼らがインタフェースを表現するために選択した方法でアドレス解決を処理できなければなりません。彼らはIEEE 802インターフェイスをエミュレートする場合は、他の言葉では、彼らはまた、正しく近隣探索メッセージを処理する必要があります。
3GPP standards prior to Release-8 provide IPv6 access for cellular devices with PDP contexts of type IPv6 [TS.23060]. For dual-stack access, a PDP context of type IPv6 is established in parallel to the PDP context of type IPv4, as shown in Figures 5 and 6. For IPv4-only service, connections are created over the PDP context of type IPv4, and for IPv6-only service, connections are created over the PDP context of type IPv6. The two PDP contexts of different type may use the same APN (and the gateway); however, this aspect is not explicitly defined in standards. Therefore, cellular device and gateway implementations from different vendors may have varying support for this functionality.
3GPP規格以前のリリース-8に対するIPv6 [TS.23060]タイプのPDPコンテキストを有する携帯機器のIPv6アクセスを提供します。デュアルスタックアクセスのため、タイプのIPv6のPDPコンテキストが型のIPv4のPDPコンテキストに並列に確立されているIPv4のみのサービスのために図5および6に示すように、接続は、型のIPv4のPDPコンテキスト上に作成され、そしてIPv6のみのサービスのため、接続はタイプのIPv6のPDPコンテキストを介して作成されています。異なるタイプの2つのPDPコンテキストが同じAPN（ゲートウェイ）を使用することができます。しかし、この点は明確に規格で定義されていません。したがって、異なるベンダーからの携帯デバイスとゲートウェイの実装は、この機能をサポートして変化させることであってもよいです。
Y .--.
| _(IPv4`.
|---+ +---+ +---+ ( PDN )
| D |~~~~~~~//-----| |====| |====( ` . ) )
| S | IPv4 context | S | | G | `--(___.-'
| | | G | | G | .--.
| U | | S | | S | _(IPv6`.
| E | IPv6 context | N | | N | ( PDN )
|///|~~~~~~~//-----| |====|(s)|====( ` . ) )
+---+ +---+ +---+ `--(___.-'
Figure 5: Dual-Stack (DS) User Equipment Connecting to Both IPv4 and IPv6 Internet Using Parallel IPv4-Only and IPv6-Only PDP Contexts
図5：パラレルIPv4のみとIPv6専用PDPコンテキストを使用して、IPv4とIPv6インターネットの両方に接続するデュアルスタック（DS）、ユーザ機器
Y
|
|---+ +---+ +---+
| D |~~~~~~~//-----| |====| | .--.
| S | IPv4 context | S | | G | _( DS `.
| | | G | | G | ( PDN )
| U | | S | | S |====( ` . ) )
| E | IPv6 context | N | | N | `--(___.-'
|///|~~~~~~~//-----| |====| |
+---+ +---+ +---+
Figure 6: Dual-Stack User Equipment Connecting to Dual-Stack Internet Using Parallel IPv4-Only and IPv6-Only PDP Contexts
図6：パラレルIPv4のみとIPv6のみのPDPコンテキストを使用してデュアルスタックインターネットに接続するデュアルスタックユーザ機器
The approach of having parallel IPv4 and IPv6 types of PDP contexts open is not optimal, because two PDP contexts require double the signaling and consume more network resources than a single PDP context. In Figure 6, the IPv4 and IPv6 PDP contexts are attached to the same GGSN. While this is possible, the dual-stack MS may be attached to different GGSNs in the scenario where one GGSN supports IPv4 PDN connectivity while another GGSN provides IPv6 PDN connectivity.
2つのPDPコンテキストが二重シグナリングを必要とし、単一のPDPコンテキストよりも多くのネットワークリソースを消費するので、開いたPDPコンテキストの平行IPv4とIPv6タイプを有するのアプローチは、最適ではありません。図6に、IPv4とIPv6のPDPコンテキストが同じGGSNに取り付けられています。これが可能であるが、デュアルスタックMSは、他のGGSNは、IPv6 PDN接続性を提供し、一方のGGSNがIPv4 PDN接続をサポートシナリオで別のGGSNに結合させることができます。
Since 3GPP Release-8, the powerful concept of a dual-stack type of PDN connection and EPS bearer has been introduced [TS.23401]. This enables parallel use of both IPv4 and IPv6 on a single bearer (IPv4v6), as illustrated in Figure 7, and makes dual stack simpler than in earlier 3GPP releases. As of Release-9, GPRS network nodes also support dual-stack (IPv4v6) PDP contexts.
3GPPリリース8は、PDNコネクション及びEPSベアラのデュアルスタックタイプの強力な概念は、[TS.23401】導入されています。これは、図7に示すように、単一のベアラ（IPv4v6）上のIPv4とIPv6の両方の並列使用を可能にし、以前の3GPPリリースよりもデュアルスタックが簡単になります。リリース-9のとおり、GPRSネットワーク・ノードは、デュアルスタック（IPv4v6）PDPコンテキストをサポートしています。
Y
|
|---+ +---+ +---+
| D | | | | P | .--.
| S | | | | D | _( DS `.
| | IPv4v6 (DS) | S | | N | ( PDN )
| U |~~~~~~~//-----| G |====| - |====( ` . ) )
| E | bearer | W | | G | `--(___.-'
|///| | | | W |
+---+ +---+ +---+
Figure 7: Dual-Stack User Equipment Connecting to Dual-Stack Internet Using a Single IPv4v6 PDN Connection
図7：シングルIPv4v6 PDN接続を使用したデュアルスタックインターネットに接続するデュアルスタックユーザ機器
The following is a description of the various PDP contexts/PDN bearer types that are specified by 3GPP:
以下は、3GPPによって指定される様々なPDPコンテキスト/ PDNベアラタイプについての説明です。
1. For 2G/3G access to the GPRS core (SGSN/GGSN) pre-Release-9, there are two IP PDP Types: IPv4 and IPv6. Two PDP contexts are needed to get dual-stack connectivity.
GPRSコアに2G / 3Gアクセス1.（SGSN / GGSN）プレリリース-9、2つのIP PDPタイプがある：IPv4とIPv6が。二つのPDPコンテキストは、デュアルスタック接続を取得するために必要とされています。
2. For 2G/3G access to the GPRS core (SGSN/GGSN), starting with Release-9, there are three IP PDP Types: IPv4, IPv6, and IPv4v6. A minimum of one PDP context is needed to get dual-stack connectivity.
IPv4、IPv6、およびIPv4v6：GPRSコア（SGSN / GGSN）と2G / 3Gアクセス2.は、RELEASE-9で始まる3つのIP PDPタイプがあります。 1つのPDPコンテキストの最小値は、デュアルスタック接続を取得するために必要とされます。
3. For 2G/3G access to the EPC (PDN-GW via S4-SGSN), starting with Release-8, there are three IP PDP Types: IPv4, IPv6, and IPv4v6 (which gets mapped to the PDN connection type). A minimum of one PDP context is needed to get dual-stack connectivity.
（S4-SGSNを介してPDN-GW）EPCに2G / 3Gアクセス3.は、リリース-8で始まる3つのIP PDPタイプがあります（PDNコネクションタイプにマッピングされる）はIPv4、IPv6、およびIPv4v6。 1つのPDPコンテキストの最小値は、デュアルスタック接続を取得するために必要とされます。
4. For LTE (E-UTRAN) access to the EPC, starting with Release-8, there are three IP PDN Types: IPv4, IPv6, and IPv4v6. A minimum of one PDN connection is needed to get dual-stack connectivity.
IPv4、IPv6、およびIPv4v6：LTE（E-UTRAN）EPCへのアクセス4.は、リリース8で始まる3つのIP PDNタイプがあります。 1つのPDNコネクションの最小値は、デュアルスタック接続を取得するために必要とされます。
The PDN connection establishment process is specified in detail in 3GPP specifications. Figure 8 illustrates the high-level process and signaling involved in the establishment of a PDN connection.
PDNコネクション確立処理は、3GPP仕様書に詳細に指定されています。図8は、高レベルのプロセスを示し、PDN接続の確立に関与するシグナル。
UE eNodeB/ MME SGW PDN-GW HSS/
| BS | | | AAA
| | | | | |
|---------->|(1) | | | |
| |---------->|(1) | | |
| | | | | |
|/---------------------------------------------------------\|
| Authentication and Authorization |(2)
|\---------------------------------------------------------/|
| | | | | |
| | |---------->|(3) | |
| | | |---------->|(3) |
| | | | | |
| | | |<----------|(4) |
| | |<----------|(4) | |
| |<----------|(5) | | |
|/---------\| | | | |
| RB setup |(6) | | | |
|\---------/| | | | |
| |---------->|(7) | | |
|---------->|(8) | | | |
| |---------->|(9) | | |
| | | | | |
|============= Uplink Data =========>==========>|(10) |
| | | | | |
| | |---------->|(11) | |
| | | | | |
| | |<----------|(12) | |
| | | | | |
|<============ Downlink Data =======<===========|(13) |
| | | | | |
Figure 8: Simplified PDN Connection Setup Procedure in Release-8
図8：リリース-8で簡素化されたPDN接続のセットアップ手順
1. The UE (i.e., the MS) requires a data connection and hence decides to establish a PDN connection with a PDN-GW. The UE sends an "Attach" request (layer-2) to the base station (BS). The BS forwards this Attach request to the MME.
1. UE（すなわち、MS）は、データ接続を必要とし、したがってPDN-GWとPDN接続を確立することを決定します。 UEは、基地局（BS）に「アタッチ」要求（レイヤ2）を送信します。 BSは、転送し、このMMEへの要求を取り付けます。
2. Authentication of the UE with the Authentication, Authorization, and Accounting (AAA) server/HSS follows. If the UE is authorized to establish a data connection, the process continues with the following steps:
2.認証とUEの認証、許可、アカウンティング（AAA）サーバ/ HSSは以下の通りです。 UEは、データ接続を確立することを許可された場合、プロセスは、次の手順を続行します：
3. The MME sends a "Create Session" request message to the SGW. The SGW forwards the Create Session request to the PDN-GW. The SGW knows the address of the PDN-GW to which it forwards the Create Session request as a result of this information having been obtained by the MME during the authentication/authorization phase.
3. MMEは、SGWに、「セッションの作成」要求メッセージを送信します。 SGWは、PDN-GWへのセッションを作成し、要求を転送します。 SGWは、認証/認可フェーズ中にMMEによって得られた情報の結果として作成セッション要求を転送するためのPDN-GWのアドレスを知っています。
The UE IPv4 address and/or IPv6 prefix gets assigned during this
step. If a subscribed IPv4 address and/or IPv6 prefix is
statically allocated for the UE for this APN, then the MME
passes this previously allocated address information to the SGW
and eventually to the PDN-GW in the Create Session request
message. Otherwise, the PDN-GW manages the address assignment
to the UE (there is another variation to this step where IPv4
address allocation is delayed until the UE initiates a DHCPv4
exchange, but this is not discussed here).
4. The PDN-GW creates a PDN connection for the UE and sends a Create Session response message to the SGW from which the session request message was received. The SGW forwards the response to the corresponding MME that originated the request.
4. PDN-GWは、UEのためPDN接続を作成し、セッション要求メッセージを受信したSGWへのセッションを作成応答メッセージを送信します。 SGWは、要求を発信し、対応するMMEへの応答を転送します。
5. The MME sends the "Attach Accept/Initial Context Setup" request message to the eNodeB/BS.
5. MMEは、eNodeB / BSに要求メッセージ「/初期コンテキストセットアップを受け入れる取り付け」を送信します。
6. The radio bearer (RB) between the UE and the eNodeB is reconfigured based on the parameters received from the MME. (See Note 1 below.)
前記UEとeNodeBの間の無線ベアラ（RB）は、MMEから受信したパラメータに基づいて再構成されています。 （下記の注記1を参照。）
7. The eNodeB sends an "Initial Context" response message to the MME.
7. eNodeBはMMEに「初期コンテキスト」の応答メッセージを送信します。
8. The UE sends a "Direct Transfer" message, which includes the "Attach Complete" signal, to the eNodeB.
8. UEは、eNodeBに、「アタッチ完了」信号を含む「直接転送」メッセージを送信します。
12. The SGW responds with a Modify Bearer response message. At this time, the downlink connection is also ready.
12. SGWは、ベアラ変更応答メッセージで応答します。このとき、ダウンリンク接続も準備ができています。
13. The UE can now start receiving downlink packets, including possible SLAAC-related IPv6 packets.
13. UEは現在可能SLAAC関連IPv6パケットを含むダウンリンクパケットを受信開始することができます。
The type of PDN connection established between the UE and the PDN-GW can be any of the types described in the previous section. The dual-stack PDN connection, i.e., the one that supports both IPv4 and IPv6 packets, is the default connection that will be established if no specific PDN connection type is specified by the UE in Release-8 networks.
UEとPDN-GWとの間で確立されたPDN接続のタイプは、前のセクションで説明したタイプのいずれかとすることができます。デュアルスタックPDNコネクション、すなわち、IPv4とIPv6の両方のパケットをサポートするものは、いかなる特定のPDNコネクションタイプがリリース8のネットワークでUEによって指定されていない場合に確立されるデフォルトの接続です。
Note 1: The UE receives the PDN Address Information Element [TS.24301] at the end of radio bearer setup messaging. This information element contains only the Interface Identifier of the IPv6 address. In the case of the GPRS, the PDP Address Information Element [TS.24008] would contain a complete IPv6 address. However, the UE must ignore the IPv6 prefix if it receives one in the message (see Section 11.2.1.3.2a of [TS.29061]).
注1：UEは、PDNセットアップメッセージ、無線ベアラの終了時に情報要素[TS.24301]アドレスを受信します。この情報要素は、IPv6アドレスの唯一のインタフェース識別子が含まれています。 GPRSの場合、PDPアドレス情報要素は、[TS.24008]完全なIPv6アドレスが含まれます。それは、メッセージ（[TS.29061]のセクション11.2.1.3.2a参照）の一方を受信した場合は、UEは、IPv6プレフィックスを無視しなければなりません。
3GPP discussed at length various approaches to support mobility between a Release-8 LTE network and a pre-Release-9 2G/3G network without an S4-SGSN for the new dual-stack bearers. The chosen approach for mobility is as follows, in short: if a UE is allowed to do handovers between a Release-8 LTE network and a pre-Release-9 2G/3G network without an S4-SGSN while having open PDN connections, only single-stack bearers are used. Essentially, this indicates the following deployment options:
3GPPは、長さに新しいデュアルスタックベアラのためのS4-SGSNなしRELEASE-8 LTEネットワークとプレリリース-9 2G / 3Gネットワーク間のモビリティをサポートするために様々なアプローチを議論しました。要するに、次のように移動性のために選ばれたアプローチがある：UEがオープンPDN接続を有しながらS4-SGSNなしRELEASE-8 LTEネットワークとプレリリース-9 2G / 3Gネットワーク間のハンドオーバを行うことを許可されている場合、唯一シングルスタックベアラが使用されています。基本的に、これは、次の展開オプションを示します。
1. If a network knows a UE may do handovers between a Release-8 LTE network and a pre-Release-9 2G/3G network without an S4-SGSN, then the network is configured to provide only single-stack bearers, even if the UE requests dual-stack bearers.
1.ネットワークは、UEは、S4-SGSNなしRELEASE-8 LTEネットワークとプレリリース-9 2G / 3Gネットワークとの間でハンドオーバを行う場合、ネットワークは単一スタックベアラを提供するように構成されている、としてもよい知っている場合UEは、デュアルスタックベアラを要求します。
2. If the network knows the UE does handovers only between a Release-8 LTE network and a Release-9 2G/3G network or a pre-Release-9 network with an S4-SGSN, then the network is configured to provide the UE with dual-stack bearers on request. The same also applies for LTE-only deployments.
2.ネットワークがUEのみリリース-8 LTEネットワークおよびリリース-9 2G / 3Gネットワーク又はS4-SGSNとのプレリリース-9ネットワーク間のハンドオーバを行う知っている場合、ネットワークは、UEを提供するように構成されていますリクエストに応じてデュアルスタックベアラと。同じことがまた、LTE-のみの展開に適用されます。
When a network operator and their roaming partners have upgraded their networks to Release-8, it is possible to use the new IPv4v6 dual-stack bearers. A Release-8 UE always requests a dual-stack bearer, but accepts what is assigned by the network.
ネットワークオペレータ及びそのローミングパートナーが-8をリリースする彼らのネットワークをアップグレードした場合は、新しいIPv4v6デュアルスタックベアラを使用することが可能です。リリース-8 UEは、常に、デュアルスタックベアラを要求したが、ネットワークによって割り当てられているものを受け入れます。
3GPP networks can natively transport IPv4 and IPv6 packets between the UE and the gateway (GGSN or PDN-GW) as a result of establishing either a dual-stack PDP context or parallel IPv4 and IPv6 PDP contexts.
3GPPネットワークはネイティブデュアルスタックPDPコンテキストまたは並列IPv4とIPv6のPDPコンテキストのいずれかを確立することの結果として、UEとゲートウェイ（GGSN又はPDN-GW）との間のIPv4およびIPv6パケットを輸送することができます。
Current deployments of 3GPP networks primarily support IPv4 only. These networks can be upgraded to also support IPv6 PDP contexts. By doing so, devices and applications that are IPv6 capable can start utilizing IPv6 connectivity. This will also ensure that legacy devices and applications continue to work with no impact. As newer devices start using IPv6 connectivity, the demand for actively used IPv4 connections is expected to slowly decrease, helping operators with a transition to IPv6. With a dual-stack approach, there is always the potential to fall back to IPv4. A device that may be roaming in a network wherein IPv6 is not supported by the visited network could fall back to using IPv4 PDP contexts, and hence the end user would at least get some connectivity. Unfortunately, the dual-stack approach as such does not lower the number of used IPv4 addresses. Every dual-stack bearer still needs to be given an IPv4 address, private or public. This is a major concern with dual-stack bearers concerning IPv6 transition. However, if the majority of active IP communication has moved over to IPv6, then in the case of Network Address Translation from IPv4 to IPv4 (NAT44), the number of active NAT44-translated IPv4 connections can still be expected to gradually decrease and thus give some level of relief regarding NAT44 function scalability.
3GPPネットワークの現在の展開は主に、IPv4のみをサポートしています。これらのネットワークはまた、IPv6のPDPコンテキストをサポートするようにアップグレードすることができます。そうすることで、IPv6対応しているデバイスやアプリケーションは、IPv6接続を利用開始することができます。これはまた、レガシーデバイスとアプリケーションは影響を与えずに作業を続けていることを確認します。新しいデバイスがIPv6接続を使用して開始すると、積極的に使用したIPv4接続用の需要は、IPv6への移行をオペレータに支援し、徐々に減少すると予想されます。デュアルスタックアプローチにより、常にバックのIPv4に落ちる可能性があります。 IPv6が訪問先ネットワークによってサポートされていない前記ネットワーク内でローミングすることができる装置がバックのIPv4 PDPコンテキストを使用することに落ちることができ、したがって、エンドユーザは、少なくともいくつかの接続を得ることになります。残念ながら、のようなデュアルスタックアプローチが使用されたIPv4アドレスの数を低下させません。すべてのデュアルスタックベアラはまだプライベートまたはパブリックIPv4アドレスを指定する必要があります。これは、IPv6への移行に関するデュアルスタックベアラとの主要な関心事です。アクティブなIP通信の大部分がIPv6に上に移動した場合は、その後のIPv4（NAT44）にIPv4からネットワークアドレス変換の場合には、アクティブNAT44翻訳IPv4接続の数は、依然として徐々に減少し、従って与えることが期待できますNAT44機能のスケーラビリティに関する救済のいくつかのレベル。
As the networks evolve to support Release-8 EPS architecture and the dual-stack PDP contexts, newer devices will be able to leverage such capability and have a single bearer that supports both IPv4 and IPv6. Since IPv4 and IPv6 packets are carried as payload within GTP between the MS and the gateway (GGSN/PDN-GW), the transport-network capability in terms of whether it supports IPv4 or IPv6 on the interfaces between the eNodeB and SGW or between the SGW and PDN-GW is immaterial.
ネットワークがリリース-8 EPSアーキテクチャとデュアルスタックPDPコンテキストをサポートするように進化しているので、新しいデバイスは、このような機能を活用し、IPv4とIPv6の両方をサポートする単一ベアラを持つことができるようになります。 IPv4およびIPv6パケットがMSとゲートウェイ（GGSN / PDN-GW）、それがeNodeBとSGW又は間の界面上でIPv4またはIPv6をサポートしているかどうかの観点からトランスポートネットワーク機能との間のGTP内にペイロードとして運ばれるのでSGWとPDN-GWは、重要ではありません。
Given the shortage of globally routable public IPv4 addresses, operators tend to assign private IPv4 addresses [RFC1918] to UEs when they establish an IPv4-only PDP context or an IPv4v6 PDN context. About 16 million UEs can be assigned a private IPv4 address that is unique within a domain. However, for many operators, the number of subscribers is greater than 16 million. The issue can be dealt with by assigning overlapping RFC 1918 IPv4 addresses to UEs. As a result, the IPv4 address assigned to a UE within the context of a single operator realm would no longer be unique. This has the obvious and known issues of NATed IP connections in the Internet. Direct UE-to-UE connectivity becomes complicated; unless the UEs are within the same private address range pool and/or anchored to the same gateway, referrals using IP addresses will have issues, and so forth. These are generic issues and not only a concern of the EPS. However, 3GPP as such does not have any mandatory language concerning NAT44 functionality in the EPC. Obvious deployment choices apply also to the EPC:
グローバルにルーティング可能なパブリックIPv4アドレスの不足を考えると、事業者は、彼らがIPv4のみのPDPコンテキストまたはIPv4v6 PDNコンテキストを確立する際のUEにプライベートIPv4アドレス[RFC1918]を割り当てる傾向にあります。約1600万のUEは、ドメイン内で一意のプライベートIPv4アドレスを割り当てることができます。しかし、多くのオペレータのために、加入者数1600万以上です。問題は、UEに重複RFC 1918 IPv4アドレスを割り当てることで対処することができます。結果として、単一のオペレータレルムのコンテキスト内でUEに割り当てられたIPv4アドレスはもはや固有でないであろう。これは、インターネットでのNAT変換IP接続の明白なと既知の問題があります。直接UE-に-UE接続が複雑になります。 UEが同じプライベートアドレス範囲のプール内にある場合を除き、および/または同じゲートウェイへのアンカー、などの問題があり、かつますIPアドレスを使って紹介。これらは、一般的な問題やEPSのない唯一の懸念されています。しかし、などの3GPPは、EPCにNAT44機能に関する任意の必須の言語を持っていません。明白な展開の選択肢は、EPCにも適用されます。
1. Very large network deployments are partitioned, for example, based on geographical areas. This partitioning allows overlapping IPv4 address ranges to be assigned to UEs that are in different areas. Each area has its own pool of gateways that are dedicated to a certain overlapping IPv4 address range (also referred to as a zone). Standard NAT44 functionality allows for communication from the [RFC1918] private zone to the Internet. Communication between zones requires special arrangement, such as using intermediate gateways (e.g., a Back-to-Back User Agent (B2BUA) in the case of SIP).
1.非常に大規模なネットワーク展開は、地理的領域に基づいて、例えば、分割されています。この分割は、IPv4アドレスが異なる領域にあるUEに割り当てられる範囲の重複を可能にします。各領域は、特定の重複IPv4アドレス範囲（また、ゾーンと呼ばれる）に専用されているゲートウェイの独自のプールがあります。標準NAT44機能は、インターネットへの[RFC1918]プライベートゾーンから通信を可能にします。ゾーン間の通信は、（SIPの場合には、例えば、バックツーバックユーザエージェント（B2BUA））中間ゲートウェイを使用するなどの特別な装置を必要とします。
2. A UE attaches to a gateway as part of the Attach process. The number of UEs that a gateway supports is on the order of 1 to 10 million. Hence, all of the UEs assigned to a single gateway can be assigned private IPv4 addresses. Operators with large subscriber bases have multiple gateways, and hence the same [RFC1918] IPv4 address space can be reused across gateways. The IPv4 address assigned to a UE is unique within the scope of a single gateway.
2. A UEは、アタッチプロセスの一部として、ゲートウェイに取り付けられます。ゲートウェイがサポートしているUEの数は、100万〜10程度です。したがって、単一のゲートウェイに割り当てられているUEの全ては、プライベートIPv4アドレスを割り当てることができます。大加入者ベースを持つ演算子は、複数のゲートウェイを有し、したがって同じ[RFC1918] IPv4アドレス空間は、ゲートウェイで再利用することができます。 UEに割り当てられたIPv4アドレスは、単一のゲートウェイの範囲内で一意です。
3. New services requiring direct connectivity between UEs should be built on IPv6. Possible existing IPv4-only services and applications requiring direct connectivity can be ported to IPv6.
UE間の直接接続を必要とする3.新サービスがIPv6の上に構築されなければなりません。直接接続を必要とする可能性のある既存のIPv4のみのサービスとアプリケーションは、IPv6に移植することができます。
The various reference points of the 3GPP architecture, such as S1-U, S5, and S8, are based on either GTP or PMIPv6. The underlying transport for these reference points can be IPv4 or IPv6. GTP has been able to operate over IPv6 transport (optionally) since R99, and PMIPv6 has supported IPv6 transport since its introduction in Release-8. The user-plane traffic between the UE and the gateway can use either IPv4 or IPv6. These packets are essentially treated as payload by GTP/PMIPv6 and transported accordingly, with no real attention paid (at least from a routing perspective) to the information contained in the IPv4 or IPv6 headers. The transport links between the eNodeB and the SGW, and the link between the SGW and PDN-GW, can be migrated to IPv6 without any direct implications to the architecture.
例えばS1-U、S5およびS8のような3GPPアーキテクチャの種々の基準点は、GTPまたはPMIPv6のいずれかに基づいています。これらの基準点のための基礎となるトランスポートは、IPv4またはIPv6であることができます。 GTPは、R99以降のIPv6トランスポート（オプション）で動作することができた、とのPMIPv6リリース-8でのその導入以来、IPv6トランスポートをサポートしています。 UEとゲートウェイの間のユーザプレーントラフィックは、IPv4またはIPv6のいずれかを使用することができます。本当の注意を払わないと、これらのパケットは、IPv4またはIPv6ヘッダに含まれる情報に（少なくともルーティングの観点から）、本質的にGTP /のPMIPv6によってペイロードとして扱われ、それに応じて搬送されます。 eNodeBとSGWと、SGWとPDN-GWとの間のリンクとの間のトランスポートリンクは、アーキテクチャへの直接影響することなく、IPv6へ移行することができます。
Currently, the inter-operator (for 3GPP technology) roaming networks are all IPv4 only (see Inter-PLMN Backbone Guidelines [GSMA.IR.34]). Eventually, these roaming networks will also get migrated to IPv6, if there is a business reason for that. The migration period can be prolonged considerably, because the 3GPP protocols always tunnel user-plane traffic in the core network, and as described earlier, the transport-network IP version is not in any way tied to the user-plane IP version. Furthermore, the design of the inter-operator roaming networks is such that the user-plane and transport-network IP addressing schemes are completely separated from each other. The inter-operator roaming network itself is also completely separated from the Internet. Only those core network nodes that must be connected to the inter-operator roaming networks are actually visible there, and are able to send and receive (tunneled) traffic within the inter-operator roaming networks. Obviously, in order for the roaming to work properly, the operators have to agree on supported protocol versions so that the visited network does not, for example, unnecessarily drop user-plane IPv6 traffic.
現在、（3GPP技術の）オペレータ間のローミングネットワークは、すべてのIPv4のみ（インターPLMNバックボーンのガイドライン[GSMA.IR.34]を参照してください）です。そのため、ビジネス上の理由がある場合に最終的には、これらのローミングネットワークは、IPv6へ移行されます。移行期間は、コアネットワーク内の3GPPプロトコルため常にトンネルユーザプレーントラフィック、かなり長く、そして先に記載されているようにすることができる、トランスポート・ネットワークのIPバージョンは、ユーザ・プレーンIPのバージョンに関連付けられどのような方法ではありません。また、オペレータ間のローミングネットワークの設計は、ユーザプレーンとトランスポートネットワークのIPアドレス方式を完全に互いに分離されているようなものです。オペレータ間のローミングネットワーク自体は、インターネットから完全に分離されています。オペレータ間のローミングネットワークに接続されなければならないだけコアネットワークノードが実際に表示され、及びオペレータ間のローミングネットワーク内（トンネリング）トラフィックを送受信することが可能です。明らかに、ローミングが適切に機能するためには、事業者は、訪問先ネットワークは、例えば、不必要にユーザプレーンIPv6トラフィックをドロップしないように、サポートされているプロトコルのバージョンに同意する必要があります。
Operating dual-stack networks does imply cost and complexity to a certain extent. However, these factors are mitigated by the assurance that legacy devices and services are unaffected, and there is always a fallback to IPv4 in case of issues with the IPv6 deployment or network elements. The model also enables operators to develop operational experience and expertise in an incremental manner.
デュアルスタックネットワークを操作すると、ある程度のコストと複雑さを意味するものではありません。しかし、これらの要因は、レガシーデバイスとサービスが影響を受けず、およびIPv6の展開やネットワーク要素の問題の場合はIPv4へのフォールバックが常にあることを保証することによって軽減されています。モデルは、インクリメンタル方式で運用経験と専門知識を開発する事業者を可能にします。
Running dual-stack networks requires the management of multiple IP address spaces. Tracking of UEs needs to be expanded, since it can be identified by either an IPv4 address or an IPv6 prefix. Network elements will also need to be dual-stack capable in order to support the dual-stack deployment model.
デュアルスタックネットワークを実行すると、複数のIPアドレス空間の管理が必要となります。それはIPv4アドレスまたはIPv6プレフィックスのいずれかで識別することができますので、UEの追跡は、拡大する必要があります。ネットワーク要素は、デュアルスタック展開モデルをサポートするためにできるデュアルスタックする必要があります。
Deployment and migration cases (see Section 6.1) for providing dual-stack capability may mean doubled resource usage in an operator's network. This is a major concern against providing dual-stack connectivity using techniques discussed in Section 6.1. Also, handovers between networks with different capabilities in terms of whether or not networks are capable of dual-stack service may prove difficult for users to comprehend and for applications/services to cope with. These facts may add other than just technical concerns for operators when planning to roll out dual-stack service offerings.
デュアルスタック機能を提供するための展開と移行ケース（セクション6.1を参照）オペレータのネットワークで倍増し、リソースの使用状況を意味するかもしれません。これは、6.1節で述べた技術を使用して、デュアルスタック接続を提供に対する主要な関心事です。また、かどうかネットワークの面で異なる機能を持つネットワーク間のハンドオーバは、デュアルスタックサービスが可能なユーザーが理解するためとに対処するためのアプリケーション/サービスのために難しいかもしれ。デュアルスタックサービスの提供を展開することを計画したときにこれらの事実は、オペレータのためだけの技術的な懸念事項以外の追加することもできます。
It is possible to allocate IPv6-only bearers to UEs in 3GPP networks. The IPv6-only bearer has been part of the 3GPP specification since the beginning. In 3GPP Release-8 (and later), it was defined that a dual-stack UE (or when the radio equipment has no knowledge of the UE IP stack's capabilities) must first attempt to establish a dual-stack bearer and then possibly fall back to a single-stack bearer. A Release-8 (or later) UE with an IPv6-only stack can directly attempt to establish an IPv6-only bearer. The IPv6-only behavior is up to subscription provisioning or PDN-GW configuration, and the fallback scenarios do not necessarily cause additional signaling.
3GPPネットワーク内のUEへのIPv6専用ベアラを割り当てることが可能です。 IPv6のみのベアラが初めから3GPP仕様の一部となっています。 3GPPリリース-8（以降）には、デュアルスタックUE（または無線設備は、UEのIPスタックの能力の知識を持たない）最初のデュアルスタックベアラを確立しようとし、その後、おそらくフォールバックしなければならないことを規定しましたシングルスタックベアラへ。 IPv6のみのスタックとリリース-8（またはそれ以降）UEは、直接IPv6専用ベアラを確立することを試みることができます。 IPv6のみの挙動は、サブスクリプション・プロビジョニングまたはPDN-GWの設定次第で、フォールバックシナリオは、必ずしも追加の信号が発生することはありません。
Although the bullets below introduce IPv6-to-IPv4 address translation and specifically discuss NAT64 technology [RFC6144], the current 3GPP Release-8 architecture does not describe the use of address translation or NAT64. It is up to a specific deployment whether address translation is part of the network or not. The following are some operational aspects to consider for running a network with IPv6-only bearers:
弾丸は以下のIPv6からIPv4アドレス変換を導入し、具体的にNAT64技術[RFC6144]を議論するが、現在の3GPPリリース-8アーキテクチャは、アドレス変換やNAT64の使用を記載していません。これは、アドレス変換は、ネットワークの一部であるかどうかを特定の展開次第です。 IPv6のみのベアラとのネットワークを実行するために考慮すべきいくつかの運用面を以下に示します。
o The UE must have an IPv6-capable stack and a radio interface capable of establishing an IPv6 PDP context or PDN connection.
O UEは、IPv6対応のスタックとIPv6 PDPコンテキスト又はPDN接続を確立することが可能な無線インタフェースを有していなければなりません。
o The GGSN/PDN-GW must be IPv6 capable in order to support IPv6 bearers. Furthermore, the SGSN/MME must allow the creation of a PDP Type or PDN Type of IPv6.
O GGSN / PDN-GWは、IPv6ベアラをサポートするために可能なIPv6のなければなりません。また、SGSN / MMEはPDPタイプまたはIPv6のPDNタイプの作成を可能にしなければなりません。
o Many of the common applications are IP version agnostic and hence would work using an IPv6 bearer. However, applications that are IPv4 specific would not work.
O一般的なアプリケーションの多くは、IPバージョンとらわれないので、IPv6のベアラを使用して動作します。しかし、IPv4の具体的なアプリケーションは動作しません。
o Inter-operator roaming is another aspect that causes issues, at least during the ramp-up phase of the IPv6 deployment. If the visited network to which outbound roamers attach does not support PDP/PDN Type IPv6, then there needs to be a fallback option. The fallback option in this specific case is mostly up to the UE to implement. Several cases are discussed in the following sections.
Oオペレータ間のローミングは、少なくともIPv6の展開のランプアップフェーズの間に、問題の原因となる別の態様です。アウトバウンドローミングが添付先の訪問先ネットワークは、PDP / PDNタイプIPv6をサポートしていない場合は、フォールバックオプションが必要です。この特定のケースでは、フォールバックオプションは、主に実装するためのUE次第です。いくつかの例は次のセクションで説明されています。
o If and when a UE using an IPv6-only bearer needs access to the IPv4 Internet/network, some type of translation from IPv6 to IPv4 has to be deployed in the network. NAT64 (or DNS64) is one solution that can be used for this purpose and works for a certain set of protocols (read TCP, UDP, and ICMP, and when applications actually use DNS for resolving names to IP addresses).
O場合及びUE用いてIPv6専用ベアラがIPv4インターネット/ネットワークへのアクセスを必要はIPv6からIPv4のへの変換のいくつかの種類がネットワークに配備されなければなりません。 NAT64（またはDNS64）（TCP、UDP、およびICMPを読んで、アプリケーションが実際にIPアドレスに名前解決にDNSを使用する場合）は、この目的のために使用することができる1つのソリューションであり、プロトコルの特定のセットのために動作します。
Roaming was briefly touched upon in Sections 8.2 and 8.4. While there is interest in offering roaming service for IPv6-enabled UEs and subscriptions, not all visited networks are prepared for IPv6 outbound roamers:
ローミングを簡単にセクション8.2および8.4に触れました。 IPv6対応のUEとサブスクリプションのためのローミングサービスを提供することに関心があるが、すべてではない訪問先ネットワークは、IPv6の発信ローミングのために用意されています。
o The visited-network SGSN does not support the IPv6 PDP context or IPv4v6 PDP context types. These should mostly concern pre-Release-9 2G/3G networks without an S4-SGSN, but there is no definitive rule, as the deployed feature sets vary depending on implementations and licenses.
O-訪問ネットワークSGSNは、IPv6 PDPコンテキストまたはIPv4v6 PDPコンテキストの種類をサポートしていません。これらは、S4-SGSNなしのほとんどが懸念プレリリース - 9 2G / 3Gネットワークをする必要がありますが、展開の機能セットが実装およびライセンスによって異なりとして決定的なルールは、ありません。
o The visited network might not be commercially ready for IPv6 outbound roamers, while everything might work technically at the user-plane level. This would lead to "revenue leakage", especially from the visited operator's point of view (note that the use of a visited-network GGSN/PDN-GW does not really exist today in commercial deployments for data roaming).
すべては、ユーザプレーンレベルで技術的に働くかもしれないが訪問したネットワークO、IPv6の発信ローミングのための商業的に準備ができていない可能性があります。これは、特にビューの訪問オペレータの視点から、「収入の漏れ」をもたらすことになる（訪問先ネットワークの使用はGGSN / PDN-GWは、実際のデータローミングのための商用展開で、今日存在しないことに注意してください）。
It might be in the interest of operators to prohibit roaming selectively within specific visited networks until IPv6 roaming is in place. 3GPP does not specify a mechanism whereby IPv6 roaming is prohibited without also disabling IPv4 access and other packet services. The following options for disabling IPv6 access for roaming subscribers could be available in some network deployments:
これは、IPv6ローミングが所定の位置になるまで、特定の訪問先ネットワーク内に選択ローミング禁止する事業者の利益になるかもしれません。 3GPPは、IPv6ローミングもIPv4のアクセスやその他のパケットサービスを無効にせず禁止されていることにより、機構が指定されていません。ローミング加入者のためのIPv6アクセスを無効にするには、以下のオプションは、いくつかのネットワーク展開で利用できるようにできます。
o Policy and Charging Control (PCC) [TS.23203] functionality and its rules, for example, could be used to cause bearer authorization to fail when a desired criteria is met. In this case, that would be PDN/PDP Type IPv6/IPv4v6 and a specific visited network. The rules can be provisioned either in the home network or locally in the visited network.
Oポリシー及び課金制御（PCC）TS.23203]機能とそのルールは、例えば、所望の基準が満たされたとき、ベアラ認証が失敗させるために使用することができます。この場合には、それは、PDN / PDPタイプのIPv6 / IPv4v6と特定訪問先ネットワークであろう。ルールは、ホームネットワークまたはローカルに訪問先ネットワークのいずれかでプロビジョニングできます。
o Some Home Location Register (HLR) and Home Subscriber Server (HSS) subscriber databases allow prohibiting roaming in a specific (visited) network for a specified PDN/PDP Type.
いくつかのホームロケーションレジスタ（HLR）とホーム加入者サーバ（HSS）は、加入者データベースoを特定してローミング禁止することができ、指定PDN / PDPタイプのネットワーク（訪問）を。
The obvious problems are that these solutions are not mandatory, are not unified across networks, and therefore also lack a well-specified fallback mechanism from the UE's point of view.
明白な問題は、これらのソリューションは、ネットワーク間で統一されていない、必須ではありませんということであり、したがって、ビューのUEの視点からだけでなく、指定されたフォールバックメカニズムを欠いています。
It is obvious that as operators start to incrementally deploy the EPS along with the existing UTRAN/GERAN, handovers between different radio technologies (inter-RAT handovers) become inevitable. In the case of inter-RAT handovers, 3GPP supports the following IP addressing scenarios:
事業者は、増分既存のUTRAN / GERANと一緒にEPSを展開し始めとして、異なる無線技術（RAT間ハンドオーバ）間のハンドオーバが必然的になることは明らかです。 RAT間ハンドオーバの場合には、3GPPは、以下のIPアドレス指定のシナリオをサポートしています。
o The E-UTRAN IPv4v6 bearer has to map one to one to the UTRAN/GERAN IPv4v6 bearer.
O E-UTRAN IPv4v6ベアラは、UTRAN / GERAN IPv4v6ベアラに1対1でマッピングしなければなりません。
o The E-UTRAN IPv6 bearer has to map one to one to the UTRAN/GERAN IPv6 bearer.
O E-UTRANのIPv6ベアラは、UTRAN / GERANのIPv6ベアラに1対1でマッピングしなければなりません。
o The E-UTRAN IPv4 bearer has to map one to one to the UTRAN/GERAN IPv4 bearer.
O E-UTRANのIPv4ベアラは、UTRAN / GERANのIPv4ベアラに1対1でマッピングしなければなりません。
Other types of configurations are not standardized. The above rules essentially imply that the network migration has to be planned and subscriptions provisioned based on the lowest common denominator, if inter-RAT handovers are desired. For example, if some part of the UTRAN cannot serve anything but IPv4 bearers, then the E-UTRAN is also forced to provide only IPv4 bearers. Various combinations of subscriber provisioning regarding IP versions are discussed further in Section 8.7.
他のタイプの構成は、標準化されていません。上記の規則は、本質的に、ネットワークの移行がインターRATハンドオーバが望まれる場合、最小公分母に基づいて計画とサブスクリプションがプロビジョニングされなければならないことを暗示します。例えば、UTRANの一部は、E-UTRANはまた、IPv4のみベアラを提供することを余儀なくされたIPv4ベアラが、何かを果たすことができない場合。 IPバージョンに関する加入者プロビジョニングの様々な組み合わせは、セクション8.7でさらに議論されています。
8.7. Provisioning of IPv6 Subscribers and Various Combinations during Initial Network Attachment
8.7. 初期のネットワーク接続時のIPv6の加入者と様々な組み合わせのプロビジョニング
Subscribers' provisioned PDP/PDN Types have multiple configurations. The supported PDP/PDN Type is provisioned per each APN for every subscriber. The following PDN Types are possible in the HSS for a Release-8 subscription [TS.23401]:
加入者のプロビジョニングPDP / PDNの種類は、複数の構成を持っています。サポートされているPDP / PDNタイプは、すべての加入者に対して各APNごとにプロビジョニングされます。以下のPDNの種類は[TS.23401]リリース-8サブスクリプションのHSSが可能です。
o IPv4v6 PDN Type (note that the IPv4v6 PDP Type does not exist in an HLR and Mobile Application Part (MAP) [TS.29002] signaling prior to Release-9).
O IPv4v6 PDNタイプ（IPv4v6 PDPタイプがHLRに存在し、モバイルアプリケーションパート（MAP）[TS.29002]リリース-9を前にシグナリングしないことに留意されたいです）。
o IPv6-only PDN Type.
O IPv6のみPDNタイプ。
o IPv4-only PDN Type.
O IPv4のみPDNタイプ。
o IPv4_or_IPv6 PDN Type (note that the IPv4_or_IPv6 PDP Type does not exist in an HLR or MAP signaling. However, an HLR may have multiple APN configurations of different PDN Types; these configurations would effectively achieve the same functionality).
O IPv4_or_IPv6 PDNタイプ（IPv4_or_IPv6 PDPタイプは、HLRまたはMAPシグナリングに存在しないことに注意してくださいしかし、HLRは異なるPDNタイプの複数のAPNの構成を有することができる;これらの構成は、実質的に同じ機能を達成するであろう）。
A Release-8 dual-stack UE must always attempt to establish a PDP/PDN Type IPv4v6 bearer. The same also applies when the modem part of the UE does not have exact knowledge of whether the UE operating system IP stack is dual-stack capable or not. A UE that is IPv6-only capable must attempt to establish a PDP/PDN Type IPv6 bearer. Last, a UE that is IPv4-only capable must attempt to establish a PDN/PDP Type IPv4 bearer.
リリース-8デュアルスタックは、UEは常にPDP / PDNタイプIPv4v6ベアラを確立することを試みなければなりません。 UEの変復調部は、UEのオペレーティング・システムのIPスタックが可能かどうかデュアルスタックであるかどうかの正確な知識を持っていない場合も同様。 IPv6のみが可能であるUEは、PDP / PDNタイプのIPv6ベアラを確立することを試みなければなりません。最後に、IPv4のみが可能であるUEは、PDN / PDPタイプのIPv4ベアラを確立することを試みなければなりません。
In a case where the PDP/PDN Type requested by a UE does not match what has been provisioned for the subscriber in the HSS (or HLR), the UE possibly falls back to a different PDP/PDN Type. The network (i.e., the MME or the S4-SGSN) is able to inform the UE during network attachment signaling as to why it did not get the requested PDP/PDN Type. These response/cause codes are documented in [TS.24008] for requested PDP Types and [TS.24301] for requested PDN Types:
UEによって要求されたPDP / PDNタイプは、HSS（又はHLR）に加入者のためにプロビジョニングされたものと一致しない場合には、UEは、おそらくバック異なるPDP / PDNタイプに落ちます。ネットワーク（すなわち、MME又はS4-SGSN）は、要求されたPDP / PDNタイプを取得していない理由として、ネットワーク接続シグナリング中にUEに通知することが可能です。これらの応答/原因コードは、要求されたPDPタイプと[TS.24301]要求されたPDNのタイプのために[TS.24008]に記載されています：
o (E)SM cause #50 "PDN/PDP type IPv4 only allowed".
"のみ許可PDN / PDPタイプのIPv4" ＃50原因O（E）SM。
o (E)SM cause #51 "PDN/PDP type IPv6 only allowed".
"のみ許可PDN / PDPタイプのIPv6" ＃51原因O（E）SM。
o (E)SM cause #52 "single address bearers only allowed".
O（E）SM原因＃52 "のみ許可され、単一のアドレスベアラ"。
The above response/cause codes apply to Release-8 and onwards. In pre-Release-8 networks, the response/cause codes that are used vary, depending on the vendor, unfortunately.
上記応答/原因コードがリリース-8へと以降を適用します。プレリリース-8のネットワークでは、使用される応答/原因コードは、残念ながら、ベンダーに依存して、変わります。
Possible fallback cases when the network deploys MMEs and/or S4-SGSNs include (as documented in [TS.23401]):
ネットワークはのMMEおよび/またはS4-のSGSNを展開可能なフォールバックケース（[TS.23401]に記載される）が挙げられます。
o Requested and provisioned PDP/PDN Types match => requested.
O要求およびプロビジョニングPDP / PDNタイプ一致=>要求されました。
o Requested IPv4v6 and provisioned IPv6 => IPv6, and a UE receives an indication that an IPv6-only bearer is allowed.
O IPv4v6を要求とIPv6 => IPv6をプロビジョニングし、そしてUEはIPv6専用ベアラが許可されているという指示を受信します。
o Requested IPv4v6 and provisioned IPv4 => IPv4, and the UE receives an indication that an IPv4-only bearer is allowed.
O IPv4v6を要請し、IPv4 => IPv4のプロビジョニング、およびUEは、IPv4専用ベアラが許可されているという指示を受信します。
o Requested IPv4v6 and provisioned IPv4_or_IPv6 => IPv4 or IPv6 is selected by the MME/S4-SGSN based on an unspecified criteria. The UE may then attempt to establish, based on the UE implementation, a parallel bearer of a different PDP/PDN Type.
O IPv4v6を要求しIPv4_or_IPv6 => IPv4またはIPv6のプロビジョニングは、不特定の基準に基づいて、MME / S4-SGSNによって選択されます。その後、UEは、UEの実装、異なるPDP / PDNタイプの平行ベアラに基づいて、確立しようと試みることができます。
o Other combinations cause the bearer establishment to fail.
O他の組み合わせは、ベアラ確立が失敗する原因。
In addition to PDP/PDN Types provisioned in the HSS, it is also possible for a PDN-GW (and an MME/S4-SGSN) to affect the final selected PDP/PDN Type:
HSSでプロビジョニングPDP / PDNタイプに加えて、PDN-GW（及びMME / S4-SGSN）最終的に選択PDP / PDNタイプに影響を与えることも可能です。
o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4 or IPv6. If the MME operator had included the "Dual Address Bearer" flag in the bearer establishment signaling, then the UE would have received an indication that an IPv6-only or IPv4-only bearer is allowed.
O IPv4v6を要求し、PDN-GW => IPv4またはIPv6内IPv4またはIPv6を構成しました。 MMEオペレータは、ベアラ確立シグナリングに「デュアルアドレスベアラ」フラグが含まれていた場合、UEは、IPv6のみ、またはIPv4専用ベアラが許可されているという指示を受けたであろう。
o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4 or IPv6. If the MME operator had not included the "Dual Address Bearer" flag in the bearer establishment signaling, then the UE may have attempted to establish, based on the UE implementation, a parallel bearer of a different PDP/PDN Type.
O IPv4v6を要求し、PDN-GW => IPv4またはIPv6内IPv4またはIPv6を構成しました。 MMEオペレータは、ベアラ確立シグナリングに「デュアルアドレスベアラ」フラグが含まれていなかった場合、UEは、UEの実装に基づいて、確立するために異なるPDP / PDNタイプの平行ベアラを試みたかもしれません。
An SGSN that does not understand the requested PDP Type is supposed to handle the requested PDP Type as IPv4. If for some reason an MME does not understand the requested PDN Type, then the PDN Type is handled as IPv6.
要求されたPDPタイプを理解していないSGSNは、IPv4のように要求されたPDPタイプを処理することになっています。何らかの理由でMMEが要求されたPDNの種類を理解していない場合には、PDNの種類は、IPv6として扱われます。
This document does not introduce any security-related concerns. Section 5 of [RFC3316] already contains an in-depth discussion of IPv6-related security considerations in 3GPP networks prior to Release-8. This section discusses a few additional security concerns to take into consideration.
このドキュメントは、セキュリティ関連の懸念を導入していません。 [RFC3316]のセクション5は、既にリリース-8を前に3GPPネットワークにおけるIPv6関連のセキュリティの考慮事項の詳細な議論が含まれています。このセクションでは、考慮すべきいくつかの追加のセキュリティ上の問題について説明します。
In 3GPP access, the UE and the network always perform a mutual authentication during the network attachment [TS.33102] [TS.33401]. Furthermore, each time a PDP context/PDN connection gets created, a new connection, a modification of an existing connection, and an assignment of an IPv6 prefix or an IP address can be authorized against the PCC infrastructure [TS.23203] and/or PDN's AAA server.
3GPPアクセスでは、UEとネットワークが常に[TS.33401] [TS.33102]ネットワーク接続の間で相互認証を行います。また、PDPコンテキスト/ PDN接続が作成されるたびに、新たな接続、既存の接続の修正、及びIPv6プレフィックスの割当またはIPアドレスがPCCインフラに対して許可することができる[TS.23203]及び/又はPDNのAAAサーバ。
The wireless part of the 3GPP link between the UE and the (e)NodeB as well as the signaling messages between the UE and the MME/SGSN can be protected, depending on the regional regulation and the operator's deployment policy. User-plane traffic can be confidentiality protected. The control plane is always at least integrity and replay protected, and may also be confidentiality protected. The protection within the transmission part of the network depends on the operator's deployment policy [TS.33401].
UEおよび（e）ノードB、ならびにUE及びMME / SGSNの間のシグナリングメッセージ間の3GPPリンクの無線部は、地域の規制とオペレータの配備ポリシーに応じて、保護することができます。ユーザプレーントラフィックは、機密性を保護することができます。コントロールプレーンは常に、少なくとも整合性とリプレイ保護され、また、機密性を保護することができます。ネットワークの送信部内の保護は、オペレータの配備方針[TS.33401]に依存します。
Several of the on-link and neighbor-discovery-related attacks can be mitigated due to the nature of the 3GPP point-to-point link model, and the fact that the UE and the first-hop router (PDN-GW/GGSN or SGW) are the only nodes on the link. For off-link IPv6 attacks, the 3GPP EPS is as vulnerable as any IPv6 system.
上リンク及び隣接発見関連攻撃3GPPポイントツーポイントリンクモデルの性質、及び事実に起因緩和することができるいくつかのそのUEと第ホップルータ（PDN-GW / GGSN又はSGW）は、リンク上のノードのみです。オフリンクIPv6の攻撃のために、3GPP EPSは、任意のIPv6システムのように脆弱です。
There have also been concerns that the UE IP stack might use permanent subscriber identities, such as an International Mobile Subscriber Identity (IMSI), as the source for the IPv6 address Interface Identifier. This would be a privacy threat and would allow tracking of subscribers. Therefore, the use of an IMSI (or any identity defined by [TS.23003]) as the Interface Identifier is prohibited [TS.23401]. However, there is no standardized method to block such misbehaving UEs.
また、UE IPスタックがIPv6アドレスインタフェース識別子のソースとして、そのような国際移動加入者識別（IMSI）などの永久的な加入者識別を、使用するかもしれないという懸念がありました。これはプライバシーの脅威になると、加入者の追跡を可能にします。したがって、インタフェース識別子としてIMSI（または[TS.23003]によって定義された同一性）の使用は、[TS.23401]禁止されています。しかしながら、このような不正動作するUEをブロックする標準化方法は存在しません。
The 3GPP network architecture and specifications enable the establishment of IPv4 and IPv6 connections through the use of appropriate PDP context types. The current generation of deployed networks can support dual-stack connectivity if the packet core network elements, such as the SGSN and GGSN, have that capability. With Release-8, 3GPP has specified a more optimal PDP context type that enables the transport of IPv4 and IPv6 packets within a single PDP context between the UE and the gateway.
3GPPネットワーク・アーキテクチャおよび仕様は、適切なPDPコンテキストタイプを使用することによって、IPv4とIPv6の接続の確立を可能にします。例えばSGSNとGGSNのようなパケット・コア・ネットワーク・エレメントは、その能力を持っている場合、展開ネットワークの現在の世代は、デュアルスタックの接続をサポートすることができます。リリース8で、3GPPは、UEとゲートウェイとの間の単一のPDPコンテキスト内のIPv4およびIPv6パケットの輸送を可能にする、より最適なPDPコンテキストタイプを指定しています。
As devices and applications are upgraded to support IPv6, they can start leveraging the IPv6 connectivity provided by the networks while maintaining the ability to fall back to IPv4. Enabling IPv6 connectivity in the 3GPP networks by itself will provide some degree of relief to the IPv4 address space, as many of the applications and services can start to work over IPv6. However, without comprehensive testing of current widely used applications and solutions for their ability to operate over IPv6 PDN connections, an IPv6-only access would cause disruptions.
デバイスやアプリケーションがIPv6をサポートするようにアップグレードされているとして、彼らは、IPv4にフォールバックする機能を維持しながら、ネットワークが提供するIPv6接続を利用し始めることができます。アプリケーションやサービスの多くは、IPv6上で作業を開始できるよう、それ自体で3GPPネットワークにおけるIPv6接続を有効にすると、IPv4アドレス空間への救済のいくつかの学位を提供します。しかし、IPv6のPDN接続を介して動作する能力のための現在の広く使われているアプリケーションやソリューションの包括的なテストを行わずに、IPv6のみのアクセスは、混乱を引き起こします。
The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, Zhenqiang Li, Mikael Abrahamsson, James Woodyatt, Wes George, Martin Thomson, Russ Mundy, Cameron Byrne, Ales Vizdal, Frank Brockners, Adrian Farrel, Stephen Farrell, Paco Cortes, and Jari Arkko for their reviews and comments on this document.
著者はShabnamスルタナ、スリGundavelli、ホイ鄧小、Zhenqiangリー、ミカエルAbrahamsson、ジェームズWoodyatt、ウェス・ジョージ、マーティン・トムソン、ラス・マンディ、キャメロン・バーン、アレスVizdal、フランクBrockners、エードリアンファレル、スティーブン・ファレル、パコ・コルテス、とヤリに感謝しますこのドキュメントの彼らのレビューとコメントのためのArkko。
[GSMA.IR.34] GSMA, "Inter-PLMN Backbone Guidelines", GSMA PRD IR.34.4.9, March 2010.
[GSMA.IR.34] GSMA、 "インターPLMNバックボーンガイドライン"、GSMA PRD IR.34.4.9、2010年3月。
[PD-EXCLUDE] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", Work in Progress, December 2011.
[PD-EXCLUDE] Korhonen、J.、編、Savolainenの、T.、クリシュナン、S.、およびO. Troanは、 "プレフィックスはDHCPv6のプレフィックス委譲ベースのオプションを除外"、進歩、2011年12月作業。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 2003.
[RFC3316] Arkko、J.、Kuijpers、G.、ソリマン、H.、Loughney、J.、およびJ. Wiljakka、 "いくつかの第二および第三世代の細胞宿主のためのインターネット・プロトコル・バージョン6（IPv6）"、RFC 3316年4月2003。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O.とR. Droms、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] Droms、R.、 "IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス"、RFC 3736、2004年4月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389]ターラー、D.、Talwar、M.、およびC.パテル、 "近隣探索プロキシ（NDプロキシ）"、RFC 4389、2006年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten氏、T.、Draves、R.、およびS.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
【Ramphsi 5213] gundavelli、S。、ら、Leunji、K.、Devarapalliは、VEの、Chaudhuriの、K.、およびb。パティル、 "プロキシ・モバイル・20 6"、rphak 5213 2008年8月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144]ベーカー、F.はLi、X.、バオ、C.、およびK.陰陽 "のIPv4 / IPv6変換のためのフレームワーク"、RFC 6144、2011年4月。
[TR.23975] 3GPP, "IPv6 Migration Guidelines", 3GPP TR 23.975 11.0.0, June 2011.
[TR.23975] 3GPP、 "IPv6の移行時の注意事項"、3GPP TR 23.975 11.0.0、2011年6月。
[TS.23003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 10.3.0, September 2011.
[TS.23003] 3GPP、 "ナンバリング、アドレッシングおよび識別"、3GPP TS 23.003 10.3.0、2011年9月。
[TS.23060] 3GPP, "General Packet Radio Service (GPRS); Service description; Stage 2", 3GPP TS 23.060 8.14.0, September 2011.
[TS.23060] 3GPP、 "汎用パケット無線サービス（GPRS）;サービスの説明;ステージ2"、3GPP TS 23.060 8.14.0、2011年9月。
[TS.23203] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 8.12.0, June 2011.
[TS.23203] 3GPP、 "ポリシーおよび課金制御アーキテクチャ"、3GPP TS 23.203 8.12.0、2011年6月。
[TS.23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 10.5.0, September 2011.
[TS.23401] 3GPP、 "汎用パケット無線サービス（GPRS）発展型ユニバーサル地上無線アクセスネットワーク（E-UTRAN）アクセスのための機能強化"、3GPP TS 23.401 10.5.0、2011年9月。
[TS.23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402 10.5.0, September 2011.
[TS.23402] 3GPP、 "非3GPPのためのアーキテクチャの拡張アクセス"、3GPP TS 23.402 10.5.0、2011年9月。
[TS.24008] 3GPP, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3", 3GPP TS 24.008 8.14.0, June 2011.
[TS.24008] 3GPP、 "移動無線インタフェースレイヤ3仕様;コアネットワークプロトコル;ステージ3"、3GPP TS 24.008 8.14.0、2011年6月。
[TS.24301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3", 3GPP TS 24.301 8.10.0, June 2011.
【TS.24301] 3GPP、 "進化型パケットシステム（EPS）用ノンアクセス・ストラタム（NAS）プロトコル;ステージ3"、3GPP TS 24.301 8.10.0 2011年6月。
[TS.29002] 3GPP, "Mobile Application Part (MAP) specification", 3GPP TS 29.002 9.6.0, September 2011.
[TS.29002] 3GPP、 "モバイルアプリケーションパート（MAP）の仕様"、3GPP TS 29.002 9.6.0、2011年9月。
[TS.29060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface", 3GPP TS 29.060 8.15.0, September 2011.
【TS.29060] 3GPP、 "汎用パケット無線サービス（GPRS）; GPRSトンネリングプロトコル（GTP）Gnの及びGpのインターフェースを横切って"、3GPP TS 29.060 8.15.0、2011年9月。
[TS.29061] 3GPP, "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)", 3GPP TS 29.061 8.8.0, September 2011.
[TS.29061] 3GPP、3GPP TS 29.061 8.8.0、2011年9月 "公衆陸上モバイルネットワーク（PLMN）パケットベースのサービスをサポートし、パケットデータネットワーク（PDN）とのインターワーキング"。
[TS.29274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 8.10.0, June 2011.
【TS.29274] 3GPP、 "3GPP進化型パケットシステム（EPS）、発展型汎用パケット無線サービス（GPRS）コントロールプレーンのトンネリングプロトコル（GTPv2-C）;ステージ3"、3GPP TS 29.274 8.10.0 2011年6月。
[TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, September 2011.
[TS.29281] 3GPP、 "汎用パケット無線システム（GPRS）トンネリングプロトコルのユーザプレーン（GTPv1-U）"、3GPP TS 29.281 10.3.0、2011年9月。
[TS.33102] 3GPP, "3G security; Security architecture", 3GPP TS 33.102 10.0.0, December 2010.
[TS.33102] 3GPP、 "3Gセキュリティ;セキュリティアーキテクチャ"、3GPP TS 33.102 10.0.0、2010年12月。
[TS.33401] 3GPP, "3GPP System Architecture Evolution (SAE); Security architecture", 3GPP TS 33.401 10.2.0, September 2011.
[TS.33401] 3GPP、 "3GPPシステムアーキテクチャエボリューション（SAE）;セキュリティアーキテクチャ"、3GPP TS 33.401 10.2.0、2011年9月。
Authors' Addresses
著者のアドレス
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo FINLAND
Jouni Korhonen（編集）、ノキアシーメンスネットワークスLinnoitustie 6 FI-02600エスポーフィンランド
EMail: jouni.nospam@gmail.com
メールアドレス：jouni.nospam@gmail.com
Jonne Soininen Renesas Mobile Porkkalankatu 24 FI-00180 Helsinki FINLAND
Jonne SoininenルネサスモバイルPorkkalankatu 24 FI-00180ヘルシンキフィンランド
EMail: jonne.soininen@renesasmobile.com
メールアドレス：jonne.soininen@renesasmobile.com
Basavaraj Patil Nokia 6021 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキア6021接続のドライブアーヴィング、TX 75039 USA
EMail: basavaraj.patil@nokia.com
メールアドレス：basavaraj.patil@nokia.com
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere FINLAND
テームSavolainenのノキアHermiankatu 12 D FI-33720タンペレフィンランド
EMail: teemu.savolainen@nokia.com
メールアドレス：teemu.savolainen@nokia.com
Gabor Bajko Nokia 323 Fairchild Drive 6 Mountain View, CA 94043 USA
ガボールBajko 6ノキア323フェアチャイルドドライブマウンテンビュー、CA 94043 USA
EMail: gabor.bajko@nokia.com
メールアドレス：gabor.bajko@nokia.com
Kaisu Iisakkila Renesas Mobile Porkkalankatu 24 FI-00180 Helsinki FINLAND
KAISU IisakkilaルネサスモバイルPorkkalankatu 24 FI-00180ヘルシンキフィンランド
EMail: kaisu.iisakkila@renesasmobile.com
メールアドレス：kaisu.iisakkila@renesasmobile.com