[要約] RFC 6459は、3GPP Evolved Packet System（EPS）におけるIPv6の実装に関するガイドラインです。このRFCの目的は、3GPPネットワークでのIPv6の効果的な導入と運用を支援することです。
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)
第3世代パートナーシッププロジェクト（3GPP）進化したパケットシステム（EPS）のIPv6
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）展開されています。第3世代パートナーシッププロジェクト（3GPP）ネットワークアーキテクチャに基づいてネットワークを展開したオペレーターは、インターネットレジストリで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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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サポートは、仕様の最初のリリース以来、第3世代パートナーシッププロジェクト（3GPP）基準の一部です（リリース99）。このサポートは、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.
3GPPネットワークアーキテクチャは、2000年初頭に確定したリリース99以来の時代に進化し続けています。3GPPアーキテクチャの最新バージョン、進化したパケットシステム（EPS） - 一般にシステムアーキテクチャエボリューション（SAE）と呼ばれる、長期進化（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.
このドキュメントでは、3GPPネットワークアーキテクチャ、特に3G一般パケットラジオサービス（GPRS）およびEPSのIPベアラーのコンテキストでのIP接続の確立について説明します。3GPP仕様の現在のセットに従って、IPv6がどのようにサポートされているかの概要を提供します。単一のネットワークドメイン内のプライベート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
IETFは、IPv6への移行に利用できる一連のツールとメカニズムを指定しました。IPv4からIPv6への移行中のデュアルスタックネットワークの操作に加えて、遷移の2つの代替カテゴリはカプセル化と翻訳です。IETFは、展開シナリオに基づいて移行を有効にするための追加のソリューションを指定し続けています。
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:
オペレーター/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.
1. IPv4のみのスタックを持つレガシーデバイスとホストは、インターネットとサービスへの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:
2. デュアルスタックのデバイスは、IPv6またはIPv4を介してインターネットにアクセスできます。IPv6またはIPv4を使用する選択は、次の能力に依存します。
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).
Evolved Packet Core（EPC）は、高データレートの低い低下、パケット最適化されたシステムを特徴とする3GPP GPRSシステムの進化です。EPCは、モビリティ管理エンティティ（MME）、サービングゲートウェイ（SGW）、パケットデータネットワークゲートウェイ（PDN-GW）、ホーム加入者サーバー（HSS）などのサブコンポーネントで構成されています。
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は、EPCと進化した普遍的な陸生無線アクセス（E-UTRA）および進化した普遍的な陸生無線アクセスネットワーク（E-UTRAN）とともに構成されています。
Evolved UTRAN
ユトランの進化
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.
進化したユトラン（E-UTRAN）は通信ネットワークであり、4Gと呼ばれることもあり、E-UTRANを構成するeNodebs（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は、サービスの品質（QO）や充電などに関連する帯域内シグナル伝達など、モビリティを超えた機能を提供します。
GSM EDGE Radio Access Network
GSMエッジラジオアクセスネットワーク
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）エッジラジオアクセスネットワーク（GERAN）は、一般に2Gまたは2.5Gと呼ばれる通信ネットワークであり、GSMエッジラジオを構成するベースステーションとベースステーションコントローラー（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.
General Packet Radio Service（GPRS）は、3GPPで指定された2Gおよび3Gセルラー通信システム（GSM）のユーザーが利用できるパケット指向のモバイルデータサービスです。
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.
Home Location Register（HLR）は、Pre-Release-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.
Home Subscriber Server（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.
Public Land Mobile Network（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）は、オペレーターに属するか、インターネットや企業イントラネットなどの外部ネットワークであるパケットベースのネットワークです。ユーザーは最終的に1つ以上のPDNでサービスにアクセスします。オペレーターのパケットコアネットワークは、GGSNSまたはPDNゲートウェイ（PDN-GWS）によってパケットデータネットワークから分離されています。
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.
Packet Data Network Gateway（PDN-GW）は、進化したパケットシステム（EPS）のゲートウェイ関数であり、インターネットまたは他のPDNへの接続を提供します。ホストは、オペレーターによって割り当てられた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インターフェイスを介して2G/3G無線アクセスネットワークをEPCに接続するリリース-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）は、EPSのゲートウェイ関数であり、E-UTRANに向かってインターフェイスを終了します。SGWは、レイヤー-2モビリティ（エノデブ間携帯電話）のモビリティアンカーポイントです。EPSに接続されている各UEについて、特定の時点で、SGWは1つだけです。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）は、Radio Access Network（RAN）とGateway（GGSN）の間にあるネットワーク要素です。GGSNとSGSNの間のPEOR-POINT-to-Point（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）に接続された任意のデバイス/ホストです。たとえば、ポイントツーポイントプロトコル（PPP）を介して、TEは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.
Universal Mobile Telecommunications System（UMTS）地上ラジオアクセスネットワーク（UTRAN）は、一般に3Gと呼ばれる通信ネットワークであり、Nodebs（3Gベースステーション）とラジオネットワークコントローラー（RNC）で構成され、UMTS無線アクセスを構成します。通信網。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に示します。このアーキテクチャは、基本的にGPRSコアネットワークをR99からリリース-7、およびGSM（2G）、Edge（2G、2.5Gと呼ばれることが多い）などの無線アクセステクノロジーをカバーしています。、WCDMA（3G）、およびHSPA（）（3G、3.5gと呼ばれることが多い）。セクション4で見られるように、アーキテクチャは、進化したパケットシステム（EPS）と明らかな類似性を共有しています。GN/GPインターフェイスに基づいて、GPRSコアネットワーク機能は、SGSNとGGSNの2つのネットワークノードに論理的に実装されています。
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-C、ユーザープレーンではGTP-Uの両方）。
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：ベースステーションシステム（BSS）-SGSNインターフェイス。これは、パケットデータ送信とレイヤー-2モビリティ管理に関する情報を運ぶために使用されます。GBインターフェイスは、フレームリレーまたは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：ラジオネットワークシステム（RNS）-SGSNインターフェイス。これは、パケットデータ送信とレイヤー-2モビリティ管理に関する情報を運ぶために使用されます。IUインターフェイスのユーザー平面部分（実際にはIU-PS）はGTP-Uに基づいています。IUインターフェイスのコントロールプレーン部分は、Radio Access Network Application Protocol（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/UM：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からのデータパケットの配信を担当します。直接トンネルを使用すると、ユーザープレーンはRNC（RNS）とGGSNの間に直接移動します。コントロールプレーントラフィックは常にSGSNを通過します。GPRSに接続されている各UEについて、任意の時点で、SGSNは1つだけです。
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（Packet Data Protocol）コンテキストは、1つのIPv4アドレスと /または1 /64 IPv6プレフィックスで表されるUEと、APNで表されるPDNとの関連です。各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は、3GPPネットワークでPDPコンテキストが意味するものの高レベルビューを表しています。
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コンテキストがあります。APNXに接続されている「PDPC1」PDPコンテキストがインターネット接続を提供し、「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.
最も基本的な形式では、EPSアーキテクチャは、ユーザープレーンの2つのノードのみで構成されています。ベースステーションとコアネットワークゲートウェイ（GW）です。基本的な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：GTP（GTP-UとGTP-Cの両方）またはPMIPV6 [RFC5213] [Ts.23402]をネットワークベースのモビリティ管理プロトコルとして使用して、SGWとPDN-GWの間でユーザー面トンネルとトンネル管理を提供します。。S5インターフェイスは、PDN-GWとSGWが1つの演算子（つまり、PLMN）内にあるときに使用されます。S8インターフェイスは、PDN-GWとSGWが異なる演算子ドメイン（つまり、異なるPLMN）に配置されている場合に使用されます。
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：GTP-C（GTPコントロールプレーン）に基づいて、MMEとSGWの間のコントロールプレーンプロトコルの基準点で、たとえばデフォルトのベアラーの確立や変更中に使用されます。
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間のハンドオーバー中にユーザー面トンネルとエノデブ間パスの切り替えを提供します。
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
PDN接続は、1つのIPv4アドレスと /または1つの /64 IPv6プレフィックスで表されるUEと、APNで表されるPDNとの関連です。PDN接続は、GPRS PDPコンテキストに相当するEPCです。各PDNは、ゲートウェイ（PDN-GW）を介してアクセスできます。PDNは、UEへのIPアドレス/プレフィックス割り当てを担当します。UEでは、PDN接続はネットワークインターフェイスに相当します。したがって、ueは別々に1つ以上のゲートウェイに取り付けられる可能性があります
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接続。3GPP EPSは、EPSの開始以来、PDNタイプIPv4、IPv6、およびIPv4v6（デュアルスタック）をサポートしています。つまり、リリース-8以降。
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接続には、PDNによって割り当てられ、対応するゲートウェイに固定されている独自のIPアドレス/プレフィックスがあります。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は、Uplink IPフローのバインディングをベアラーに実行し、PDN-GWはダウンリンクパケットに対してこの関数を実行します。
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に割り当てられます（これはGPRSとは異なり、UEは自動的に接続されていません。PDNであるため、最初のPDPコンテキストがアクティブになるまでIPv4アドレスおよび/またはIPv6プレフィックスが割り当てられていません）。このデフォルトのベアラーは、専用のベアラーに関連付けられていないすべてのトラフィックを運ぶことができます。専用の担い手は、特定のパケットに反している治療を必要とするために特定されたIPフローのトラフィックを運ぶために使用されます。それらは、スタートアップの時点で確立される場合があります。たとえば、デフォルトのベアラーが提供するものよりも、常に接続性とより良いQoSを必要とするサービスの場合。デフォルトのベアラーとそれに関連する専用のベアラーは、同じIPアドレス（ES）/プレフィックスを共有します。
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
EPSベアラーは、EPSベアラーに関連付けられているGBR値に関連する専用ネットワークリソースが永続的に割り当てられている場合（例えば、ENODEBのAndionment Control Functionによって）、BEARERESTING/ INSTILLISTING/で永続的に割り当てられている場合、保証されたビットレート（GBR）ベアラーと呼ばれます。変形。それ以外の場合、EPSベアラーは非GBRベアラーと呼ばれます。デフォルトのベアラーは常に非GBRであり、IPフローのリソースはENODEBで保証されておらず、入場制御がありません。ただし、専用のベアラーは、GBRまたは非GBRのいずれかです。GBRベアラーはGBRと最大ビットレート（MBR）を持っていますが、同じUEに属する複数の非GBRベアラーが集計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.
（AMBR）。非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アドレス構成は、PDPコンテキスト/EPSベアラーのセットアップ手順（レイヤー2）で常に実行されます。DHCPV4ベースの[RFC2131]アドレス構成は、3GPP仕様によってサポートされていますが、幅広い規模では使用されません。DHCPV4はUESとネットワークの両方でオプションであるため、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.
3GPP標準は、[Ts.23402]のセクション4.7.1で説明されているように、接続確立時に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.
[RFC4861]および[RFC4862]で指定されているIPv6ステートレスアドレスAutoconfiguration（SLAAC）は、唯一のサポートされているアドレス構成メカニズムです。Stateful DHCPV6ベースのアドレス構成[RFC3315]は、3GPP仕様によってサポートされていません。一方、他の構成情報を取得するためのStateless DHCPV6サービスがサポートされています[RFC3736]。これは、Mビットが常にゼロであり、OビットがUEに送信されるルーター広告（RA）のOBITに設定される可能性があることを意味します。
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プレフィックスを割り当て、レイヤー2シグナル伝達を使用して、Gatewayのインターフェイス識別子と競合しないことが保証されているインターフェイス識別子をUEに提案します。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.
3GPPリンクモデルでは、UEに割り当てられた /64プレフィックスをリンクの決定に使用することはできません（RAのプレフィックス情報オプション（PIO）のLビットは常にゼロに設定する必要があります）。広告されたプレフィックスがSLAACに使用されている場合、PIOのAビットを1に設定する必要があります。3GPPリンクモデルとアドレス構成の詳細は、[Ts.29061]のセクション11.2.1.3.2aに記載されています。より具体的には、GGSN /PDN-GWは、 /64プレフィックスがUEにユニークであることを保証します。したがって、UEが作成するアドレスでお父さんを実行する必要はありません（つまり、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）は、UE実装近隣ディスカバリープロキシ（NDプロキシ）[RFC4389]機能を実装することにより、ローカルエリアネットワークに共有できます。
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で定義されたモデルには、集計可能なプレフィックスが必要です。つまり、デフォルトのベアラーに割り当てられた /64プレフィックス（およびUE）は、より短い委任されたプレフィックスの一部でなければなりません。DHCPV6プレフィックス委任には、[RFC3633]のセクション12.1で説明されている明示的な制限があります。要求ルーターに委任されたプレフィックスは、委任ルーター（つまり、この場合はPDN-GW）で使用できません。これは、より短い「委任されたプレフィックス」を要求するルーター（つまり、UE）に指定できないが、 /64プレフィックスのような方法で委任ルーター（つまり、PDN-GW）によって配信される必要があることを意味しますデフォルトのベアラーに割り当てられたものは、「委任されたプレフィックス」の一部ではありません。委任[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とNext-Hopルーター（GGSNなど）の間の3GPPリンクは、リンク層アドレスがない[RFC3316]を持たないポイントツーポイント（P2P）リンクに似ており、これは2G/から変更されていません。EPSへの3G GPRS。UE IPスタックはこれを考慮する必要があります。3GPP PDPコンテキストがUEへのPPPインターフェイス/リンクとして表示される場合、IPスタックは通常、近隣ディスカバリープロトコルと適切な方法で隣接キャッシュ状態マシンを処理するために準備されています。 - レイヤーアドレス情報。ただし、一部のオペレーティングシステムは、PPPインターフェイス/リンクのルーター広告をデフォルト設定として破棄します。これにより、3GPP PDPコンテキストが確立されるとSLAACが失敗し、すべてのIPv6トラフィックが失速します。
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コンテキストをIEEE 802インターフェイス/IPスタックへのリンクとして表示することができます。これには、特にIPスタックが基礎となるリンクにリンク層アドレスがあると信じるように作られている場合、いくつかの既知の問題があります。まず、アドレス解決によってトリガーされた近隣勧誘への応答としてGGSNによって送信された近隣広告には、ターゲットリンク層アドレスオプションが含まれていない場合があります（[RFC4861]のセクション4.4を参照）。その後、UEがGGSNのリンク層アドレスを解決しようとすると、アドレス解像度が完了しない可能性があり、すべてのIPv6トラフィックが失速します。
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がGGSNのリンク層アドレスを解決しようとすると、アドレス解像度が完了しないため、すべてのIPv6トラフィックが失速します。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,
リリース-8の前の3GPP標準は、タイプIPv6 [Ts.23060]のPDPコンテキストを持つセルラーデバイスのIPv6アクセスを提供します。デュアルスタックアクセスの場合、図5および6に示すように、タイプIPv6のPDPコンテキストがタイプIPv4のPDPコンテキストと並行して確立されます。IPv4のみのサービスの場合、IPv4タイプのPDPコンテキストで接続が作成されます。
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.
また、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コンテキストがシグナルを2倍にする必要があり、単一のPDPコンテキストよりも多くのネットワークリソースを消費するため、並列IPv4およびIPv6タイプのPDPコンテキストを開くというアプローチは最適ではありません。図6では、IPv4およびIPv6 PDPコンテキストが同じGGSNに接続されています。これは可能ですが、デュアルスタックMSは、1つのGGSNがIPv4 PDN接続をサポートし、別のGGSNがIPv6 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：単一のIPv4v6PDN接続を使用してデュアルスタックインターネットに接続するデュアルスタックユーザー機器
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.
1. GPRSコア（SGSN/GGSN）PRE-RELEASE-9への2G/3Gアクセスには、2つのIP PDPタイプがあります：IPv4とIPv6。デュアルスタック接続を取得するには、2つの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.
2. GPRSコア（SGSN/GGSN）への2G/3Gアクセスの場合、リリース-9から始まるには、IPv4、IPv6、およびIPv4v6の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.
3. リリース-8から始まるEPC（S4-SGSN経由のPDN-GW）への2G/3Gアクセスの場合、IPv4、IPv6、およびIPv4v6（PDN接続タイプにマッピングされる）の3つのIP PDPタイプがあります。デュアルスタック接続を取得するには、最低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.
4. EPCへのLTE（E-UTRAN）アクセスの場合、リリース-8から始まるには、IPv4、IPv6、およびIPv4v6の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. 認証、承認、および会計（AAA）サーバー/HSSを使用したUEの認証が続きます。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に「Create Session」要求メッセージを送信します。SGWは、CREATEセッション要求をPDN-GWに転送します。SGWは、認証/認証フェーズ中にMMEによって取得された結果として、CREATEセッション要求を転送する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).
UE IPv4アドレスおよび/またはIPv6プレフィックスは、このステップ中に割り当てられます。サブスクライブされたIPv4アドレスおよび/またはIPv6プレフィックスがこのAPNのUEに対して静的に割り当てられている場合、MMEはこの以前に割り当てられたアドレス情報をSGWに渡し、最終的には作成セッション要求メッセージでPDN-GWに渡します。それ以外の場合、PDN-GWはUEへのアドレス割り当てを管理します（UEがDHCPV4交換を開始するまでIPv4アドレス割り当てが遅延するこのステップには別のバリエーションがありますが、これはここでは説明されていません）。
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.)
6. 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に含まれます。
9. The eNodeB forwards the Attach Complete message to the MME.
9. eNodeBは、完全なメッセージをMMEに添付します。
10. The UE can now start sending uplink packets to the PDN GW.
10. UEは、PDN GWにアップリンクパケットの送信を開始できるようになりました。
11. The MME sends a "Modify Bearer" request message to the SGW.
11. MMEは、SGWに「BEARER」要求メッセージを送信します。
12. The SGW responds with a Modify Bearer response message. At this time, the downlink connection is also ready.
12. SGWは、Bearer Responseメッセージを変更して応答します。この時点で、ダウンリンク接続も準備ができています。
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パケットの両方をサポートする接続は、リリース-8ネットワークのUEによって特定のPDN接続タイプが指定されていない場合に確立されるデフォルト接続です。
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アドレスが含まれます。ただし、UEは、メッセージ内のIPv6プレフィックスを受信する場合は無視する必要があります（[Ts.29061]のセクション11.2.1.3.2aを参照）。
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なしで、リリース8 LTEネットワークとPre-Release-9 2G/3Gネットワーク間のモビリティをサポートするためのさまざまなアプローチについて説明しました。要するに、モビリティのための選択されたアプローチは次のとおりです。UEがリリース8 LTEネットワークとPre-Release-9 2G/3Gネットワークの間でS4-SGSNを使用せずにPDN接続を開いている間にのみ、Handoversを実行することを許可されている場合にのみ、シングルスタックベアラーが使用されます。基本的に、これは次の展開オプションを示します。
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がリリース-8 LTEネットワークとS4-SGSNを使用しないPre-Release-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とGATEWAY（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からIPv4（NAT44）へのネットワークアドレス変換の場合、アクティブな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）の間のGTP内のペイロードとして運ばれるため、ENODEBとSGW間のIPv4またはIPv6をサポートするか、またはSGW間のインターフェイスでIPv4またはIPv6をサポートするかどうかの観点から、トランスポートネットワーク機能は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コンテキストを確立するときに、プライベートIPv4アドレス[RFC1918]をUESに割り当てる傾向があります。ドメイン内で一意のプライベートIPv4アドレスを割り当てることができます。ただし、多くのオペレーターの場合、加入者の数は1600万を超えています。この問題は、UESに重複するRFC 1918 IPv4アドレスを割り当てることで対処できます。その結果、単一の演算子領域のコンテキスト内でUEに割り当てられたIPv4アドレスは、もはや一意ではありません。これには、インターネット内のNated IP接続の明白で既知の問題があります。直接的なUE-o-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. UEは、接続プロセスの一部としてゲートウェイに接続します。ゲートウェイがサポートするUEの数は、1〜1000万件のオーダーです。したがって、単一のゲートウェイに割り当てられたすべての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.
3. UE間の直接接続を必要とする新しいサービスは、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のいずれかを使用できます。これらのパケットは本質的にGTP/PMIPv6によってペイロードとして扱われ、それに応じて輸送され、IPv4またはIPv6ヘッダーに含まれる情報に（少なくともルーティングの観点から）実際の注意はありません。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アドレススペースの管理が必要です。UEの追跡は、IPv4アドレスまたはIPv6プレフィックスのいずれかで識別できるため、拡張する必要があります。ネットワーク要素は、デュアルスタックの展開モデルをサポートするために、デュアルスタックに能力がある必要があります。
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を参照）は、オペレーターのネットワークでのリソースの使用量が2倍になった場合があります。これは、セクション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ネットワークでIPv6のみのベアラーをUESに割り当てることができます。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-to-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タイプまたはPDNタイプのIPv6の作成を許可する必要があります。
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 IPv6のみのベアラーを使用してUEがIPv4インターネット/ネットワークにアクセスする必要がある場合、IPv6からIPv4への何らかの翻訳をネットワークに展開する必要があります。NAT64（またはDNS64）は、この目的に使用できる1つのソリューションであり、特定のプロトコル（TCP、UDP、およびICMPを読み取り、アプリケーションが実際にIPアドレスに名前を解決するためにDNSを使用する場合）で動作します。
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を使用しないPre-Release-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は、IPv4アクセスやその他のパケットサービスを無効にすることなく、IPv6ローミングが禁止されるメカニズムを指定しません。ローミングサブスクライバーの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.
o 一部のホームロケーションレジスタ（HLR）およびホームサブスクライバーサーバー（HSS）サブスクライバーデータベースにより、指定された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を段階的に展開し始めると、異なる無線技術（ラット間のハンドオーバー）間の握手が避けられないことは明らかです。ラット間の携帯電話の場合、3GPPは次のIPアドレス指定シナリオをサポートしています。
o The E-UTRAN IPv4v6 bearer has to map one to one to the UTRAN/GERAN IPv4v6 bearer.
o E-Utran IPv4v6ベアラーは、1対1をUtran/Geran IPv4v6ベアラーにマッピングする必要があります。
o The E-UTRAN IPv6 bearer has to map one to one to the UTRAN/GERAN IPv6 bearer.
o E-Utran IPv6ベアラーは、1対1をUtran/Geran IPv6ベアラーにマッピングする必要があります。
o The E-UTRAN IPv4 bearer has to map one to one to the UTRAN/GERAN IPv4 bearer.
o E-Utran IPv4ベアラーは、1対1をUtran/Geran IPv4ベアラーにマッピングする必要があります。
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の一部がIPv4ベアラー以外は何も提供できない場合、E-UTRANは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ごとにプロビジョニングされます。リリース-8サブスクリプション[Ts.23401]のHSSでは、次のPDNタイプが可能です。
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タイプは、リリース-9の前にHLRおよびモバイルアプリケーションパーツ（MAP）[Ts.29002]シグナル伝達に存在しないことに注意してください）。
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）は、ネットワークアタッチメントシグナリング中にUEに要求されたPDP/PDNタイプを取得しなかった理由を通知することができます。これらの応答/原因コードは、要求されたPDPタイプの[Ts.24008]および要求されたPDNタイプの[Ts.24301]で文書化されています。
o (E)SM cause #50 "PDN/PDP type IPv4 only allowed".
o （e）SM原因＃50 "PDN/PDPタイプIPv4のみが許可されています」。
o (E)SM cause #51 "PDN/PDP type IPv6 only allowed".
o （e）SM原因＃51「PDN/PDPタイプIPv6のみが許可されています」。
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および以降に適用されます。Pre-Release-8ネットワークでは、使用される応答/原因コードは、残念ながらベンダーによって異なります。
Possible fallback cases when the network deploys MMEs and/or S4-SGSNs include (as documented in [TS.23401]):
ネットワークがMMEおよび/またはS4-SGSNSを展開する場合のフォールバックケースには（[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 PDN-GW => IPv4またはIPv6でIPv46を要求し、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 PDN-GW => IPv4またはIPv6でIPv46を要求し、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は、要求されたPDPタイプをIPv4として処理することになっています。何らかの理由で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.33102] [Ts.33401]。さらに、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
UEと（E）NodeBの間の3GPPリンクのワイヤレス部分、およびUEとMME/SGSNの間のシグナリングメッセージは、地域規制とオペレーターの展開ポリシーに応じて保護できます。ユーザー平面トラフィックは、機密性保護されています。コントロールプレーンは常に少なくとも完全性とリプレイです
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].
保護されており、保護された機密性もあります。ネットワークの送信部分内の保護は、オペレーターの展開ポリシー[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とFirst-Hopルーター（PDN-GW/GGSNまたはGGSNまたはSGW）は、リンク上の唯一のノードです。Off-Link 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アドレスインターフェイス識別子のソースとして、国際的なモバイルサブスクライバーID（IMSI）などの永続的なサブスクライバーIDを使用する可能性があるという懸念もあります。これはプライバシーの脅威であり、加入者の追跡を可能にします。したがって、界面識別子としてのIMSI（または[Ts.23003]によって定義されたアイデンティティ）の使用は禁止されています[Ts.23401]。ただし、このような不正行為をブロックする標準化された方法はありません。
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接続のレバレバリングを開始できます。3GPPネットワークでIPv6接続を有効にすることで、多くのアプリケーションとサービスが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.
著者は、シャブナム・スルタナ、スリ・ガンダヴェッリ、フイ・デン、ゼンキアン・リー、ミカエル・アブラハムソン、ジェームズ・ウッディアット、ウェス・ジョージ、マーティン・トムソン、ラス・マンディ、キャメロン・バーン、エール・ヴィズダル、フランク・ブロックナー、エイドリアン・ファレル、ステフェン・ファレル、パコ・コルテス、ジェイジャこのドキュメントに関するレビューとコメントについてArkko。
[GSMA.IR.34] GSMA, "Inter-PLMN Backbone Guidelines", GSMA PRD IR.34.4.9, March 2010.
[GSMA.IR.34] GSMA、「Inter-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.、Ed。、Savolainen、T.、Krishnan、S。、およびO. Troan、「DHCP6ベースのプレフィックス委任のプレフィックス除外オプション」、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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6のダイナミックホスト構成プロトコル」、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.、Soliman、H.、Loughney、J。、およびJ. Wiljakka、「インターネットプロトコルバージョン6（IPv6）2番目および第3世代のセルラー宿主のための」、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、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[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] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、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. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「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、「進化した普遍的な陸生ラジオアクセスネットワーク（E-UTRAN）アクセスのための一般的なパケットラジオサービス（GPRS）強化」、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、「Evolved Packet System（EPS）、ステージ3 "、3GPP TS 24.301 8.10.0、2011年6月のための非アクセスストラタム（NAS）プロトコル。
[TS.29002] 3GPP, "Mobile Application Part (MAP) specification", 3GPP TS 29.002 9.6.0, September 2011.
[Ts.29002] 3GPP、「モバイルアプリケーションパート（マップ）仕様」、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、「General Packet Radio Service（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、「パケットベースのサービスとパケットデータネットワーク（PDN）をサポートするパブリックランドモバイルネットワーク（PLMN）間の相互作用」、3GPP TS 29.061 8.8.0、2011年9月。
[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 Evolved Packet System（EPS）; Evolved General Packet Radio Service（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（編集者）Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo Finland
EMail: jouni.nospam@gmail.com
Jonne Soininen Renesas Mobile Porkkalankatu 24 FI-00180 Helsinki FINLAND
Jonne Soininen Renesas Mobile Porkkalankatu 24 FI-00180 Helsinki Finland
EMail: jonne.soininen@renesasmobile.com
Basavaraj Patil Nokia 6021 Connection Drive Irving, TX 75039 USA
Basavaraj Patil Nokia 6021 Connection Drive Irving、TX 75039 USA
EMail: basavaraj.patil@nokia.com
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere FINLAND
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland
EMail: teemu.savolainen@nokia.com
Gabor Bajko Nokia 323 Fairchild Drive 6 Mountain View, CA 94043 USA
Gabor Bajko Nokia 323 Fairchild Drive 6 Mountain View、CA 94043 USA
EMail: gabor.bajko@nokia.com
Kaisu Iisakkila Renesas Mobile Porkkalankatu 24 FI-00180 Helsinki FINLAND
Kaisu iisakkila Renesas Mobile Porkkalankatu 24 FI-00180 Helsinki Finland
EMail: kaisu.iisakkila@renesasmobile.com