[要約] RFC 9269は、ICNを4Gモバイルネットワークに統合する実験シナリオを提供し、ICNの潜在的な利点を評価することを目的としています。ICNは、IPトランスポートに代わる可能性があり、ネットワーク層のマルチキャストやローカルキャッシュを活用した最適化されたデータ配信などの機能を提供します。
Internet Research Task Force (IRTF) P. Suthar
Request for Comments: 9269 Google Inc.
Category: Informational M. Stolic
ISSN: 2070-1721 A. Jangam, Ed.
Cisco Systems Inc.
D. Trossen
Huawei Technologies
R. Ravindran
F5 Networks
August 2022
Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks
4Gモバイルネットワークでの情報中心ネットワーキング（ICN）統合の実験シナリオ
Abstract
概要
A 4G mobile network uses IP-based transport for the control plane to establish the data session at the user plane for the actual data delivery. In the existing architecture, IP-based unicast is used for the delivery of multimedia content to a mobile terminal, where each user is receiving a separate stream from the server. From a bandwidth and routing perspective, this approach is inefficient. Evolved multimedia broadcast and multicast service (eMBMS) provides capabilities for delivering contents to multiple users simultaneously, but its deployment is very limited or at an experimental stage due to numerous challenges. The focus of this document is to list the options for using Information-Centric Networking (ICN) in 4G mobile networks and elaborate the experimental setups for its further evaluation. The experimental setups discussed provide guidance for using ICN either natively or with an existing mobility protocol stack. With further investigations based on the listed experiments, ICN with its inherent capabilities such as network-layer multicast, anchorless mobility, security, and optimized data delivery using local caching at the edge may provide a viable alternative to IP transport in 4G mobile networks.
4Gモバイルネットワークは、制御プレーンのIPベースのトランスポートを使用して、実際のデータ配信のためにユーザープレーンでデータセッションを確立します。既存のアーキテクチャでは、IPベースのユニキャストがマルチメディアコンテンツのモバイル端末への配信に使用されます。そこでは、各ユーザーがサーバーから別のストリームを受信しています。帯域幅とルーティングの観点から、このアプローチは非効率的です。進化したマルチメディアブロードキャストおよびマルチキャストサービス（EMBMS）は、複数のユーザーに同時にコンテンツを配信する機能を提供しますが、その展開は非常に限られているか、多くの課題により実験段階にあります。このドキュメントの焦点は、4Gモバイルネットワークで情報中心ネットワーク（ICN）を使用するオプションをリストし、さらに評価のために実験セットアップを詳しく説明することです。議論された実験セットアップは、ICNをネイティブまたは既存のモビリティプロトコルスタックで使用するためのガイダンスを提供します。リストされた実験に基づいたさらなる調査により、ネットワーク層マルチキャスト、アンカーのないモビリティ、セキュリティ、およびエッジでのローカルキャッシュを使用した最適化されたデータ配信などの固有の機能を備えたICNは、4GモバイルネットワークでのIPトランスポートに代わる実行可能な代替品を提供する場合があります。
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 Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）の情報中心のネットワーキング研究グループのコンセンサスを表しています。IRSGによって公開されることが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9269.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9269で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction
2. 3GPP Terminology and Concepts
3. 4G Mobile Network Architecture
3.1. Network Overview
3.2. Mobile Network Quality of Service
3.3. Data Transport Using IP
3.4. Virtualized Mobile Networks
4. Data Transport Using ICN
5. Experimental Scenarios for ICN Deployment
5.1. General Considerations
5.2. Scenarios of ICN Integration
5.3. Integration of ICN in 4G Control Plane
5.4. Integration of ICN in 4G User Plane
5.4.1. Dual Transport (IP/ICN) Mode in Mobile Terminal
5.4.2. Using ICN in Mobile Terminal
5.4.3. Using ICN in eNodeB
5.4.4. Using ICN in Packet Core Gateways (SGW/PGW)
5.5. An Experimental Test Setup
6. Expected Outcomes from Experimentation
6.1. Feeding into ICN Research
6.2. Use of Results Beyond Research
7. IANA Considerations
8. Security and Privacy Considerations
8.1. Security Considerations
8.2. Privacy Considerations
9. Summary
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
4G mobile technology is built as an all-IP network using routing protocols (OSPF, IS-IS, BGP, etc.) to establish network routes. The stickiness of an IP address to a device is the key to getting connected to a mobile network. The same IP address is maintained through the session until the device gets detached or moves to another network.
4Gモバイルテクノロジーは、ネットワークルートを確立するために、ルーティングプロトコル（OSPF、IS-IS、BGPなど）を使用してAll-IPネットワークとして構築されています。デバイスへのIPアドレスの粘着性は、モバイルネットワークに接続するための鍵です。デバイスが取り外されるか、別のネットワークに移動するまで、セッションを通じて同じIPアドレスが維持されます。
Key protocols used in 4G networks are the General Packet Radio Service Tunneling Protocol (GTP), DIAMETER, and other protocols that are built on top of IP. One of the biggest challenges with IP-based routing in 4G is that it is not optimized for data transport. As an alternative to IP routing, this document presents and lists the possible options for integration of Information-Centric Networking (ICN) in 3GPP 4G mobile networks, offering an opportunity to leverage inherent ICN capabilities such as in-network caching, multicast, anchorless mobility management, and authentication. This document also discusses how those options affect mobile providers and end users.
4Gネットワークで使用される主要なプロトコルは、IPの上に構築された一般的なパケットラジオサービストンネリングプロトコル（GTP）、直径、およびその他のプロトコルです。4GのIPベースのルーティングに関する最大の課題の1つは、データトランスポートに最適化されていないことです。IPルーティングの代替として、このドキュメントは、3GPP 4Gモバイルネットワークで情報中心ネットワーク（ICN）を統合するための可能なオプションを提示し、リストし、ネットワーク内キャッシュ、マルチキャスト、アンカーモビリティなどの固有のICN機能を活用する機会を提供します。管理、および認証。このドキュメントでは、これらのオプションがモバイルプロバイダーとエンドユーザーにどのように影響するかについても説明します。
The goal of the proposed experiments is to present possibilities to create simulated environments for evaluation of the benefits of ICN protocol deployment in a 4G mobile network in different scenarios that have been analyzed in this document. The consensus of the Information-Centric Networking Research Group (ICNRG) is to publish this document in order to facilitate experiments to show deployment options and qualitative and quantitative benefits of ICN protocol deployment in 4G mobile networks.
提案された実験の目標は、このドキュメントで分析されたさまざまなシナリオで4GモバイルネットワークでのICNプロトコル展開の利点を評価するためのシミュレートされた環境を作成する可能性を提示することです。情報中心のネットワーキング研究グループ（ICNRG）のコンセンサスは、4GモバイルネットワークでのICNプロトコル展開の展開オプションと定性的および定量的利益を示す実験を促進するために、このドキュメントを公開することです。
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. An APN identifies the packet data network (PDN) with which a mobile data user wants to communicate. In addition to identifying a PDN, an APN may also be used to define the type of service, QoS, and other logical entities inside a Gateway General Packet Radio Service Support Node (GGSN) or a Packet Data Network Gateway (PGW).
アクセスポイント名：アクセスポイント名（APN）は、完全に適格なドメイン名（FQDN）であり、オペレーターのネットワーク内の一連のゲートウェイに解決します。APNは、モバイルデータユーザーが通信したいパケットデータネットワーク（PDN）を識別します。PDNを識別することに加えて、APNを使用して、ゲートウェイ一般パケットラジオサービスサポートノード（GGSN）またはパケットデータネットワークゲートウェイ（PGW）内のサービスの種類、QoS、およびその他の論理エンティティを定義することもできます。
Control Plane: The control plane carries signaling traffic and is responsible for routing between the eNodeB and the Mobile Management Entity (MME), the MME and the Home Subscriber Server (HSS), the MME and the Mobile Gateways (SGW/PGW), etc. Control plane signaling is required to authenticate and authorize the mobile terminal and establish a mobility session with Mobile Gateways (SGW/PGW). Control plane functions also include system configuration and management.
コントロールプレーン：コントロールプレーンは信号トラフィックを運び、ENODEBとモバイル管理エンティティ（MME）、MMEとホームサブスクライバーサーバー（HSS）、MMEおよびモバイルゲートウェイ（SGW/PGW）などのルーティングを担当します。。モバイル端末を認証および承認し、モバイルゲートウェイ（SGW/PGW）とのモビリティセッションを確立するには、制御プレーンシグナリングが必要です。制御プレーン機能には、システム構成と管理も含まれます。
Dual Address PDN/PDP Type: 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 IPv4 and IPv6 simultaneously.
デュアルアドレスPDN/PDPタイプ：デュアルアドレスパケットデータネットワーク/パケットデータプロトコル（PDN/PDP）タイプ（IPv4v6）は、3GPPコンテキストで使用されます。同時にIPv4とIPv6。
eNodeB: The eNodeB is a base station entity that supports the Long Term Evolution (LTE) air interface.
ENODEB：ENODEBは、長期進化（LTE）エアインターフェイスをサポートするベースステーションエンティティです。
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 some subcomponents of the EPS core such as MME, Mobile Gateways (SGW/ PGW), and HSS.
進化したパケットコア：Evolved Packet Core（EPC）は、高データレートの低い低下、パケット最適化されたシステムを特徴とする3GPP GPRSシステムの進化です。EPCは、MME、モバイルゲートウェイ（SGW/ PGW）、HSSなどのEPSコアの一部のサブコンポーネントで構成されています。
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 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 it consists of an eNodeB (4G base stations). The E-UTRAN allows connectivity between the User Equipment and the core network.
進化したUtran：進化したUtran（E-UTRAN）は、4Gと呼ばれる通信ネットワークであり、ENODEB（4Gベースステーション）で構成されています。E-UTRANは、ユーザー機器とコアネットワーク間の接続を可能にします。
Gateway GPRS Support Node: The Gateway GPRS Support Node (GGSN) is a gateway function in the GPRS and 3G network that provides connectivity to the Internet or other PDNs. The host attaches to a GGSN identified by an APN that is assigned to it by an operator. The GGSN also serves as the topological anchor for addresses/ prefixes assigned to the User Equipment.
ゲートウェイGPRSサポートノード：ゲートウェイGPRSサポートノード（GGSN）は、インターネットまたは他のPDNへの接続を提供するGPRSおよび3Gネットワークのゲートウェイ関数です。ホストは、オペレーターによって割り当てられた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.
一般的なパケットラジオサービス：一般的なパケットラジオサービス（GPRS）は、3GPPで指定された2Gおよび3Gセルラー通信システム（GSM）のユーザーが利用できるパケット指向のモバイルデータサービスです。
GPRS Tunneling Protocol: The GPRS Tunneling Protocol (GTP) [TS29.060] [TS29.274] [TS29.281] is a tunneling protocol defined by 3GPP. It is a network-based mobility protocol that works similarly to Proxy Mobile IPv6 (PMIPv6). However, GTP also provides functionality beyond mobility, such as in-band signaling related to QoS and charging, among others.
GPRSトンネルプロトコル：GPRSトンネルプロトコル（GTP）[TS29.060] [TS29.274] [TS29.281]は、3GPPで定義されたトンネリングプロトコルです。これは、プロキシモバイルIPv6（PMIPV6）と同様に機能するネットワークベースのモビリティプロトコルです。ただし、GTPは、QoSに関連する帯域内シグナルや充電など、モビリティを超えた機能を提供します。
Home Subscriber Server: The Home Subscriber Server (HSS) [TS29.336] is a database for a given subscriber and was introduced in 3GPP Release 5. It is the entity containing subscription-related information to support the network entities that handle calls/ sessions.
ホームサブスクライバーサーバー：Home Subscriber Server（HSS）[TS29.336]は、特定のサブスクライバーのデータベースであり、3GPPリリース5で導入されました。。
Mobile Terminal/User Equipment: The terms User Equipment (UE), Mobile Station (MS), Mobile Node (MN), and mobile refer to the devices that are hosts with the ability to obtain Internet connectivity via a 3GPP network. An MS comprises the Terminal Equipment (TE) and an MT. The terms MT, MS, MN, and mobile are used interchangeably within this document.
モバイルターミナル/ユーザー機器：ユーザー機器（UE）、モバイルステーション（MS）、モバイルノード（MN）、およびモバイルという用語は、3GPPネットワークを介してインターネット接続を取得できるホストであるデバイスを指します。MSは、ターミナル機器（TE）とMTを含む。MT、MS、MN、およびモバイルという用語は、このドキュメント内で同じ意味で使用されます。
Mobility Management Entity: The Mobility Management Entity (MME) is a network element responsible for control plane functionalities, including authentication, authorization, bearer management, Layer 2 mobility, and so on. 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をバイパスします。
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 by either GGSNs or PGWs.
パケットデータネットワーク：パケットデータネットワーク（PDN）は、オペレーターに属するか、インターネットやコーポレートイントラネットなどの外部ネットワークであるパケットベースのネットワークです。ユーザーは最終的に1つ以上のPDNでサービスにアクセスします。オペレーターのパケットコアネットワークは、GGSNまたはPGWSによってパケットデータネットワークから分離されています。
Packet Data Network Gateway: The Packet Data Network Gateway (PGW) is a gateway function in the EPS, which provides connectivity to the Internet or other PDNs. The host attaches to a PGW identified by an APN that is assigned to it by an operator. The PGW also serves as the topological anchor for addresses/prefixes assigned to the User Equipment.
パケットデータネットワークゲートウェイ：パケットデータネットワークゲートウェイ（PGW）は、EPSのゲートウェイ関数であり、インターネットまたは他のPDNへの接続を提供します。ホストは、オペレーターによって割り当てられたAPNによって識別されたPGWに取り付けられます。PGWは、ユーザー機器に割り当てられたアドレス/プレフィックスのトポロジカルアンカーとしても機能します。
Packet Data Protocol Context: A Packet Data Protocol (PDP) context is the equivalent of a virtual connection between the mobile terminal (MT) and a PDN using a specific gateway.
パケットデータプロトコルコンテキスト：パケットデータプロトコル（PDP）コンテキストは、特定のゲートウェイを使用したモバイル端子（MT）と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（デュアルスタック）です。
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 (for example, 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ポリシーと充電制御に使用されます。フローベースの充電（オンラインクレジットコントロールを含む）とポリシーコントロール（たとえば、ゲーティングコントロール、QoSコントロール、QoSシグナリング）の2つの主な機能があります。これは3GPP EPSにはオプションですが、ユーザーとサービスに基づいたPCCルールによる動的ポリシーと充電制御が望まれる場合に必要です。
Public Land Mobile Network: The Public Land Mobile Network (PLMN) is a network operated by a single administration. A PLMN (and therefore also an operator) is identified by the Mobile Country Code (MCC) and the Mobile Network Code (MNC). Each (telecommunications) operator providing mobile services has its own PLMN.
パブリックランドモバイルネットワーク：パブリックランドモバイルネットワーク（PLMN）は、単一の管理者が運営するネットワークです。PLMN（したがってオペレーター）は、モバイルカントリーコード（MCC）とモバイルネットワークコード（MNC）によって識別されます。モバイルサービスを提供する各（通信）オペレーターには、独自のPLMNがあります。
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 mobile terminal connected with the EPS, there is only one SGW at any given point in time. The SGW is essentially the user-plane part of the GPRS's SGSN.
サービングゲートウェイ：サービングゲートウェイ（SGW）は、EPSのゲートウェイ関数であり、E-UTRANに向かってインターフェイスを終了します。SGWは、レイヤー2のモビリティ（エノデブ間携帯電話）のモビリティアンカーポイントです。EPSに接続されている各モバイル端末について、特定の時点でSGWは1つだけです。SGWは、基本的にGPRSのSGSNのユーザー面の部分です。
Serving GPRS Support Node: The Serving GPRS Support Node (SGSN) is a network element located between the Radio Access Network (RAN) and the gateway (GGSN). A per-MT point-to-point (P2P) tunnel between the GGSN and SGSN transports the packets between the mobile terminal and the gateway.
サービングGPRSサポートノード：サービングGPRSサポートノード（SGSN）は、Radio Access Network（RAN）とGateway（GGSN）の間にあるネットワーク要素です。GGSNとSGSNの間の1-MTポイントツーポイント（P2P）トンネルは、モバイル端子とゲートウェイの間でパケットを輸送します。
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はユーザープレーンで使用される唯一のデータトラフィックプロトコルです。
This section provides a high-level overview of typical 4G mobile network architecture and the key functions related to the possibility of its use with ICN technology.
このセクションでは、典型的な4Gモバイルネットワークアーキテクチャの高レベルの概要と、ICNテクノロジーでの使用の可能性に関連する重要な機能を説明します。
4G mobile networks are designed to use IP transport for communication among different elements such as the eNodeB, MME, SGW, PGW, HSS, Policy and Charging Rule Function (PCRF), etc. [GRAYSON]. For backward compatibility with 3G, it has support for legacy circuit switch features such as voice and SMS through transitional CS fallback and flexible IP Multimedia Subsystems (IMS) deployment. For each mobile device attached to the radio (eNodeB), there is a separate overlay tunnel (GTP) between the eNodeB and Mobile Gateways (i.e., SGW/PGW).
4Gモバイルネットワークは、ENODEB、MME、SGW、PGW、HSS、ポリシーおよび充電ルール関数（PCRF）などのさまざまな要素間の通信にIPトランスポートを使用するように設計されています[Grayson]。3Gとの後方互換性のために、トランジショナルCSフォールバックと柔軟なIPマルチメディアサブシステム（IMS）展開を介した音声やSMSなどのレガシー回路スイッチ機能をサポートしています。ラジオに接続された各モバイルデバイス（ENODEB）には、ENODEBとモバイルゲートウェイ（つまり、SGW/PGW）の間には別のオーバーレイトンネル（GTP）があります。
When any mobile terminal is powered up, it attaches to a mobile network based on its configuration and subscription. After a successful attachment procedure, the mobile terminal registers with the mobile core network using IPv4 and/or IPv6 addresses based on request and capabilities offered by Mobile Gateways.
モバイル端末が電源を入れている場合、構成とサブスクリプションに基づいてモバイルネットワークに接続します。添付ファイル手順が成功した後、モバイル端末は、モバイルゲートウェイが提供する要求と機能に基づいてIPv4および/またはIPv6アドレスを使用してモバイルコアネットワークを使用してレジスタします。
The GTP tunnel is used to carry user traffic between gateways and mobile terminals, therefore using the unicast delivery for any data transfer. It is also important to understand the overhead of GTP and IPsec protocols. All mobile backhaul traffic is encapsulated using a GTP tunnel, which has overhead of 8 bytes on top of IP and UDP [NGMN]. Additionally, if IPsec is used for security (which is often required if the Service Provider is using a shared backhaul), it adds overhead based on the IPsec tunneling model (tunnel or transport) as well as the encryption and authentication header algorithm used. If we consider an Advanced Encryption Standard (AES) encryption as an example, the overhead can be significant [OLTEANU], particularly for smaller payloads.
GTPトンネルは、ゲートウェイとモバイル端子間のユーザートラフィックを運ぶために使用されるため、データ転送にユニキャスト配信を使用します。また、GTPおよびIPSECプロトコルのオーバーヘッドを理解することも重要です。すべてのモバイルバックホールトラフィックは、IPおよびUDP [NGMN]の上に8バイトのオーバーヘッドがあるGTPトンネルを使用してカプセル化されています。さらに、IPSECがセキュリティに使用されている場合（サービスプロバイダーが共有バックホールを使用している場合に必要なことが多い）、IPSECトンネルモデル（トンネルまたは輸送）と使用される暗号化と認証ヘッダーアルゴリズムに基づいてオーバーヘッドを追加します。例として、高度な暗号化標準（AES）暗号化を考慮すると、特に小さいペイロードの場合、オーバーヘッドは重要な[Olteanu]になる可能性があります。
+-------+ Diameter +-------+
| HSS |------------| SPR |
+-------+ +-------+
| |
+------+ +------+ S4 | +-------+
| 3G |---| SGSN |----------------|------+ +------| PCRF |
^ |NodeB | | |---------+ +---+ | | +-------+
+-+ | +------+ +------+ S3 | | S6a | |Gxc |
| | | +-------+ | | |Gx
+-+ | +------------------| MME |------+ | | |
MT v | S1MME +-------+ S11 | | | |
+----+-+ +-------+ +-------+
|4G/LTE|------------------------------| SGW |-----| PGW |
|eNodeB| S1U +-------+ +--| |
+------+ | +-------+
+---------------------+ | |
S1U GTP Tunnel traffic | +-------+ | |
S2a GRE Tunnel traffic |S2A | ePDG |-------+ |
S2b GRE Tunnel traffic | +-------+ S2B |SGi
SGi IP traffic | | |
+---------+ +---------+ +-----+
| Trusted | |Untrusted| | CDN |
|non-3GPP | |non-3GPP | +-----+
+---------+ +---------+
| |
+-+ +-+
| | | |
+-+ +-+
MT MT
Figure 1: 4G Mobile Network Overview
図1：4Gモバイルネットワークの概要
If we consider the combined impact of GTP, IPsec, and unicast traffic, the data delivery is not efficient because of overhead. The IETF has developed various header compression algorithms to reduce the overhead associated with IP packets. Some techniques are RObust Header Compression (ROHC) and Enhanced Compression RTP (ECRTP) so that the impact of overhead created by GTP, IPsec, etc., is reduced to some extent [BROWER]. For commercial mobile networks, 3GPP has adopted different mechanisms for header compression to achieve efficiency in data delivery [TS25.323]; those solutions can be adapted to other data protocols too such as ICN [RFC9139] [TLVCOMP].
GTP、IPSEC、およびユニキャストトラフィックの合計影響を考慮すると、オーバーヘッドのため、データ配信は効率的ではありません。IETFは、IPパケットに関連するオーバーヘッドを減らすために、さまざまなヘッダー圧縮アルゴリズムを開発しました。いくつかの手法は、堅牢なヘッダー圧縮（ROHC）と強化された圧縮RTP（ECRTP）であるため、GTP、IPSECなどによって作成されたオーバーヘッドの影響はある程度削減されます[ブロワー]。商用モバイルネットワークの場合、3GPPはヘッダー圧縮のさまざまなメカニズムを採用して、データ配信の効率を実現しています[TS25.323]。これらのソリューションは、ICN [RFC9139] [TLVComp]など、他のデータプロトコルにも適応できます。
During the mobile terminal attachment procedure, a default bearer is created for each mobile terminal and it is assigned to the default Access Point Name (APN), which provides the default transport. For any QoS-aware application, one or more new dedicated bearers are established between an eNodeB and a Mobile Gateway. A dedicated bearer can be requested by either a mobile terminal or a Mobile Gateway based on the direction of the first data flow. There are many bearers (logical paths) established between an eNodeB and a Mobile Gateway for each mobile terminal catering to a different data flow simultaneously.
モバイル端子アタッチメント手順では、デフォルトのベアラーが各モバイル端末に対して作成され、デフォルトのアクセスポイント名（APN）に割り当てられ、デフォルトのトランスポートが提供されます。QoS-Awareアプリケーションの場合、EnodeBとモバイルゲートウェイの間に1つ以上の新しい専用ベアラーが確立されます。最初のデータフローの方向に基づいて、モバイル端末またはモバイルゲートウェイのいずれかによって、専用の担い手を要求できます。エノデブとモバイル端末のモバイルゲートウェイの間に、異なるデータフローを同時にケータリングするモバイルゲートウェイの間に多くのベアラー（論理パス）が確立されています。
While all traffic within a certain bearer receives the same treatment, QoS parameters supporting these requirements can be very granular in different bearers. These values vary for the control, management, and user traffic, and can be very different depending on application key parameters such as latency, jitter (important for voice and other real-time applications), packet loss, and queuing mechanism (strict priority, low latency, fair, and so on).
特定のベアラー内のすべてのトラフィックは同じ処理を受けますが、これらの要件をサポートするQoSパラメーターは、異なるベアラーで非常に詳細になります。これらの値は、制御、管理、ユーザーのトラフィックによって異なり、レイテンシ、ジッター（音声およびその他のリアルタイムアプリケーションにとって重要）、パケット損失、およびキューイングメカニズムなどのアプリケーションの重要なパラメーターによって非常に異なる場合があります（厳密な優先順位、低レイテンシー、フェアなど）。
Implementation of QoS for mobile networks is done at two stages: 1) content prioritization/marking and transport marking and 2) congestion management. From the transport perspective, QoS is defined at Layer 2 as Class of Service (CoS) and at Layer 3 as Differentiated Services (DS). The mapping of the Differentiated Services Code Point (DSCP) to CoS takes place at Layer 2/3 switching and routing elements. 3GPP has a specified QoS Class Identifier (QCI), which represents different types of content and equivalent mappings to the DSCP at the transport layer [TS23.401]. However, this requires manual configuration at different elements and is therefore prone to possible misconfigurations.
モバイルネットワーク用のQoSの実装は、1）コンテンツの優先順位付け/マーキングとトランスポートマーキング、2）混雑管理の2つの段階で行われます。輸送の観点から見ると、QOSはレイヤー2でサービスのクラス（COS）として、レイヤー3で区別サービス（DS）として定義されます。Dishided Services Code Point（DSCP）のCOSへのマッピングは、レイヤー2/3のスイッチングおよびルーティング要素で行われます。3GPPには、指定されたQoSクラス識別子（QCI）があります。これは、輸送層[TS23.401]のDSCPへの異なるタイプのコンテンツと同等のマッピングを表します。ただし、これにはさまざまな要素での手動構成が必要であるため、誤った誤解が発生する傾向があります。
In summary, QoS configuration in mobile networks for user-plane traffic requires synchronization of parameters among different platforms. Normally, QoS in IP is implemented using DiffServ, which uses hop-by-hop QoS configuration at each router. Any inconsistency in IP QoS configuration at routers in the forwarding path can result in a poor subscriber experience (e.g., a packet classified as high priority can go to a lower-priority queue). By deploying ICN, we intend to enhance the subscriber experience using policy-based configuration, which can be associated with the named contents [ICNQoS] at the ICN forwarder. Further investigation is underway to understand how QoS in ICN [QoS-ICN] can be implemented with reference to the ICN QoS guidelines [RFC9064] to meet the QoS requirements [RFC4594].
要約すると、ユーザー平面トラフィック用のモバイルネットワークのQoS構成には、異なるプラットフォーム間のパラメーターの同期が必要です。通常、IPのQOは、各ルーターでホップバイホップQoS構成を使用するDiffServを使用して実装されます。転送パスのルーターでのIP QOS構成の矛盾は、サブスクライバーエクスペリエンスが不十分になる可能性があります（たとえば、優先度が高いと分類されたパケットは、より低い優先順位のキューに移動できます）。ICNを展開することにより、ICNフォワーダーの名前付きコンテンツ[ICNQOS]に関連付けることができるポリシーベースの構成を使用してサブスクライバーエクスペリエンスを強化する予定です。QOS要件[RFC4594]を満たすために、ICN QOSガイドライン[RFC9064]を参照してICN [QOS-ICN]のQOS [QOS-ICN]をどのように実装できるかを理解するためのさらなる調査が進行中です。
The data delivered to mobile devices is sent in unicast semantic inside the GTP tunnel from an eNodeB to a PDN gateway (PGW) as described in 3GPP specifications [TS23.401]. While the technology exists to address the issue of possible multicast delivery, there are many difficulties related to multicast protocol implementations on the RAN side of the network. By using eMBMS [EMBMS], multicast routing can be enabled in mobile backhaul between an eNodeB and Mobile Gateways (SGW/PGW); however, for radio interface it requires broadcast, which implies that we need a dedicated radio channel. Implementation of eMBMS in RAN is still lagging behind due to complexities related to client mobility, handovers, and the fact that the potential gain to Service Providers may not justify the investment, which explains the prevalence of unicast delivery in mobile networks. Techniques to handle multicast (such as LTE-B or eMBMS) have been designed to handle pre-planned content delivery, such as live content, which contrasts user behavior today, largely based on a content (or video) on-demand model.
モバイルデバイスに配信されるデータは、3GPP仕様[TS23.401]で説明されているように、GTPトンネル内のUnicastセマンティックでGTPトンネル内でPDNゲートウェイ（PGW）に送信されます。テクノロジーは、可能なマルチキャスト配信の問題に対処するために存在しますが、ネットワークのRAN側でのマルチキャストプロトコルの実装に関連する多くの困難があります。 EMBMS [EMBM]を使用することにより、ENODEBとモバイルゲートウェイ（SGW/PGW）の間のモバイルバックホールでマルチキャストルーティングを有効にできます。ただし、無線インターフェイスの場合、放送が必要であり、これは専用の無線チャネルが必要であることを意味します。 RANでのEMBMの実装は、クライアントのモビリティ、携帯電話、およびサービスプロバイダーへの潜在的な利益が投資を正当化しない可能性があるという事実により、まだ遅れています。これは、モバイルネットワークでのユニキャスト配信の有病率を説明しています。マルチキャスト（LTE-BやEMBMなど）を処理する手法は、主にコンテンツ（またはビデオ）オンデマンドモデルに基づいて、今日のユーザーの動作を対比するライブコンテンツなど、事前に計画されたコンテンツ配信を処理するように設計されています。
To ease the burden on the bandwidth of the Service Gateway interface (SGi), caching is introduced in a similar manner as with many enterprises. In mobile networks, whenever possible, cached data is delivered. Caching servers are placed at a centralized location, typically in the Service Provider's Data Center, or in some cases lightly distributed in packet core locations with the PGW nodes close to the Internet and IP services access (SGi). This is a very inefficient concept because traffic must traverse the entire backhaul path for the data to be delivered to the end user. Other issues, such as out-of-order delivery, contribute to this complexity and inefficiency, which needs to be addressed at the application level.
Service Gateway Interface（SGI）の帯域幅の負担を容易にするために、キャッシュは多くの企業と同様の方法で導入されます。モバイルネットワークでは、可能な限り、キャッシュされたデータが配信されます。キャッシュサーバーは、通常、サービスプロバイダーのデータセンターにある集中場所に配置されます。場合によっては、インターネットおよびIPサービスアクセス（SGI）に近いPGWノードを持つパケットコアの場所に軽く配布されます。これは非常に非効率的な概念です。これは、トラフィックがエンドユーザーに配信されるためにバックホールパス全体を横断する必要があるためです。秩序外配達などのその他の問題は、アプリケーションレベルで対処する必要があるこの複雑さと非効率性に貢献しています。
The Mobile Gateways deployed in a major Service Provider network are based on either dedicated hardware or commercial off-the-shelf (COTS) x86 technology. With the adoption of Mobile Virtual Network Operators (MVNOs), public safety networks, and enterprise mobility networks, elastic mobile core architecture is needed. By deploying the mobile packet core on a COTS platform, using a Network Function Virtualization Infrastructure (NFVI) framework and end-to-end orchestration, new deployments can be simplified to provide optimized total cost of ownership (TCO).
主要なサービスプロバイダーネットワークに展開されているモバイルゲートウェイは、専用のハードウェアまたは市販の既製（COTS）X86テクノロジーのいずれかに基づいています。モバイル仮想ネットワークオペレーター（MVNO）、公共セーフティネットワーク、およびエンタープライズモビリティネットワークの採用には、弾力性のあるモバイルコアアーキテクチャが必要です。COTSプラットフォームにモバイルパケットコアを展開することにより、ネットワーク機能仮想化インフラストラクチャ（NFVI）フレームワークとエンドツーエンドオーケストレーションを使用して、新しい展開を簡素化して、最適化された総所有コスト（TCO）を提供できます。
While virtualization is growing, and many mobile providers use a hybrid architecture that consists of dedicated and virtualized infrastructures, the control and data planes are still the same. There is also work underway to separate the control and user plane for the network to scale better. Virtualized mobile networks and network slicing with control and user-plane separation provide a mechanism to evolve the GTP-based architecture towards an OpenFlow with signaling based on Software-Defined Networking (SDN) for 4G and proposed 5G core. Some early architecture work for 5G mobile technologies provides a mechanism for control and user-plane separation and simplifies the mobility call flow by introducing OpenFlow-based signaling [ICN5G]. This has been considered by 3GPP [EPCCUPS] and is also described in [SDN5G].
仮想化が成長しており、多くのモバイルプロバイダーは、専用および仮想化されたインフラストラクチャで構成されるハイブリッドアーキテクチャを使用していますが、制御面とデータプレーンは依然として同じです。また、ネットワークがより良いスケーリングを行うための制御とユーザープレーンを分離するための作業も進行中です。コントロールとユーザー平面分離を備えた仮想化されたモバイルネットワークとネットワークスライスは、4Gのソフトウェア定義ネットワーク（SDN）と5Gコアの提案に基づくシグナリングを備えたOpenFlowに向けてGTPベースのアーキテクチャを進化させるメカニズムを提供します。5Gモバイルテクノロジーのいくつかの初期アーキテクチャ作業は、制御とユーザー面の分離のメカニズムを提供し、OpenFlowベースのシグナリング[ICN5G]を導入することにより、モビリティコールフローを簡素化します。これは3GPP [EPCCUPS]によって考慮されており、[SDN5G]でも説明されています。
For mobile devices, the edge connectivity is between a mobile terminal and a router or mobile edge computing (MEC) [MECSPEC] element. Edge computing has the capability of processing client requests and segregating control and user traffic at the edge of radio rather than sending all requests to the Mobile Gateway.
モバイルデバイスの場合、エッジ接続はモバイル端子とルーターまたはモバイルエッジコンピューティング（MEC）[MECSPEC]要素の間です。Edge Computingには、すべてのリクエストをモバイルゲートウェイに送信するのではなく、クライアント要求を処理し、ラジオのエッジでコントロールとユーザートラフィックを分離する機能があります。
+----------+
| Content +----------------------------------------+
| Publisher| |
+---+---+--+ |
| | +--+ +--+ +--+ |
| +--->|R1|------------>|R2|---------->|R4| |
| +--+ +--+ +--+ |
| | Cached |
| v content |
| +--+ at R3 |
| +========|R3|---+ |
| # +--+ | |
| # | |
| v v |
| +-+ +-+ |
+---------------| |-------------| |-------------+
+-+ +-+
Consumer-1 Consumer-2
Mobile Terminal Mobile Terminal
===> Content flow from cache
---> Content flow from publisher
Figure 2: ICN Architecture
図2：ICNアーキテクチャ
Edge computing transforms a Radio Access Network into an intelligent service edge capable of delivering services directly from the edge of the network while providing the best possible performance to the client. Edge computing can be an ideal candidate for implementing ICN forwarders in addition to its usual function of managing mobile termination. In addition to edge computing, other transport elements, such as routers, can work as ICN forwarders.
エッジコンピューティングは、ラジオアクセスネットワークをネットワークのエッジから直接提供できるインテリジェントサービスエッジに変換しながら、クライアントに可能な限り最高のパフォーマンスを提供します。エッジコンピューティングは、モバイル終了を管理する通常の機能に加えて、ICNフォワーダーを実装するための理想的な候補になる可能性があります。エッジコンピューティングに加えて、ルーターなどの他の輸送要素は、ICNフォワーダーとして機能します。
Data transport using ICN is different than IP-based transport as it introduces uniquely named-data as a core design principle. Communication in ICN takes place between the content provider (producer) and the end user (consumer), as described in Figure 2.
ICNを使用したデータ輸送は、コアデザインの原則として一意に名前が付けられたDataを導入するため、IPベースのトランスポートとは異なります。図2で説明するように、ICNの通信はコンテンツプロバイダー（プロデューサー）とエンドユーザー（コンシューマー）の間で行われます。
Every node in a physical path between a client and a content provider is called the ICN forwarder or router. It can route the request intelligently and cache content so it can be delivered locally for subsequent requests from any other client. For mobile networks, transport between a client and a content provider consists of a radio network + mobile backhaul and IP core transport + Mobile Gateways + Internet + Content Delivery Network (CDN).
クライアントとコンテンツプロバイダーの間の物理パス内のすべてのノードは、ICNフォワーダーまたはルーターと呼ばれます。リクエストをインテリジェントにルーティングし、コンテンツをキャッシュすることができ、他のクライアントからの後続のリクエストのためにローカルに配信できます。モバイルネットワークの場合、クライアントとコンテンツプロバイダー間のトランスポートは、ラジオネットワークモバイルバックホールとIPコアトランスポートモバイルゲートウェイインターネットコンテンツ配信ネットワーク（CDN）で構成されています。
To understand the suitability of ICN for mobile networks, we will discuss the ICN framework by describing its protocol architecture and different types of messages; this will be helpful when considering how to use ICN in mobile networks to deliver content more efficiently. ICN uses two types of packets called "interest packet" and "data packet" as described in Figure 3.
モバイルネットワークのICNの適合性を理解するために、そのプロトコルアーキテクチャとさまざまなタイプのメッセージを説明することにより、ICNフレームワークについて説明します。これは、モバイルネットワークでICNを使用してコンテンツをより効率的に配信する方法を検討する場合に役立ちます。ICNは、図3に記載されているように、「利息パケット」と「データパケット」と呼ばれる2種類のパケットを使用します。
+------------------------------------+
Interest | +------+ +------+ +------+ | +-----+
+-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN |
| | | +------+ +------+ +------+ | +-----+
+-+ | | Add | Drop | | Forward
MT <--------+ Intf v Nack v |
Data | |
+------------------------------------+
+------------------------------------+
+-+ | Forward +------+ | +-----+
| | <-------------------------------------| PIT |<---------| CDN |
+-+ | | Cache +--+---+ | Data +-----+
MT | +--v---+ | |
| | CS | v |
| +------+ Discard |
+------------------------------------+
Figure 3: ICN Interest, Data Packet, and Forwarder
図3：ICNの関心、データパケット、フォワーダー
In a 4G network, when a mobile device wants to receive certain content, it will send an Interest message to the closest eNodeB. Interest packets follow the TLV format [RFC8609] and contain mandatory fields such as the name of the content and content-matching restrictions (KeyIdRestr and ContentObjectHashRestr) expressed as a tuple [RFC8569]. The content-matching tuple uniquely identifies the matching data packet for the given Interest packet. Another attribute called "HopLimit" is used to detect looping Interest messages.
4Gネットワークでは、モバイルデバイスが特定のコンテンツを受信したい場合、最も近いENODEBに興味のメッセージを送信します。関心パケットは、TLV形式[RFC8609]に従い、コンテンツの名前やコンテンツマッチング制限（KeyIdRestrおよびContentObjectHashRestr）などの必須フィールド[RFC8569]を含んでいます。コンテンツマッチングタプルは、指定された関心パケットの一致するデータパケットを一意に識別します。「Hoplimit」と呼ばれる別の属性は、ループの関心メッセージを検出するために使用されます。
An ICN router will receive an Interest packet and lookup if a request for such content has arrived earlier from another client. If so, it may be served from the local cache; otherwise, the request is forwarded to the next-hop ICN router. Each ICN router maintains three data structures: Pending Interest Table (PIT), Forwarding Information Base (FIB), and Content Store (CS). The Interest packet travels hop by hop towards the content provider. Once the Interest packet reaches the content provider, it will return a data packet containing information such as content name, signature, and the actual data.
ICNルーターは、そのようなコンテンツのリクエストが別のクライアントから早く届いた場合、興味のあるパケットとルックアップを受け取ります。もしそうなら、それはローカルキャッシュから提供されるかもしれません。それ以外の場合、リクエストは次のホップICNルーターに転送されます。各ICNルーターは、保留中の関心テーブル（PIT）、転送情報ベース（FIB）、およびコンテンツストア（CS）の3つのデータ構造を維持しています。関心のあるパケットは、ホップがコンテンツプロバイダーに向かってホップを移動します。関心のあるパケットがコンテンツプロバイダーに到達すると、コンテンツ名、署名、実際のデータなどの情報を含むデータパケットが返されます。
The data packet travels in reverse direction following the same path taken by the Interest packet, maintaining routing symmetry. Details about algorithms used in PIT, FIB, CS, and security trust models are described in various resources [CCN]; here, we have explained the concept and its applicability to the 4G network.
データパケットは、関心パケットによって取られた同じパスに従って逆方向に移動し、ルーティング対称性を維持します。PIT、FIB、CS、およびセキュリティトラストモデルで使用されるアルゴリズムの詳細は、さまざまなリソース[CCN]で説明されています。ここでは、4Gネットワークへの概念とその適用性について説明しました。
In 4G mobile networks, both user and control plane traffic have to be transported from the edge to the mobile packet core via IP transport. The evolution of the existing mobile packet core using Control and User Plane Separation (CUPS) [TS23.714] enables flexible networking and operations by distributed deployment and the independent scaling of control plane and user-plane functions while not affecting the functionality of existing nodes subject to this split.
4Gモバイルネットワークでは、ユーザーとコントロールプレーンの両方のトラフィックを、IPトランスポートを介してエッジからモバイルパケットコアに輸送する必要があります。コントロールとユーザープレーン分離（CUP）[TS23.714]を使用した既存のモバイルパケットコアの進化により、既存のノードの機能に影響を与えずに、分散型展開とコントロールプレーン機能の独立したスケーリングにより、柔軟なネットワークと操作が可能になります。この分割の対象。
In this section, we analyze the potential impact of ICN on control and user-plane traffic for centralized and disaggregated CUPS-based mobile network architecture. We list various experimental options and opportunities to study the feasibility of the deployment of ICN in 4G networks. The proposed experiments would help the network and original equipment manufacturer (OEM) designers to understand various issues, optimizations, and advantages of the deployment of ICN in 4G networks.
このセクションでは、CUPSベースのモバイルネットワークアーキテクチャの集中化および分解された集中化されたモバイルネットワークアーキテクチャに対するコントロールおよびユーザー面トラフィックに対するICNの潜在的な影響を分析します。4GネットワークでのICNの展開の実現可能性を研究するためのさまざまな実験オプションと機会をリストします。提案された実験は、ネットワークおよびオリジナルの機器メーカー（OEM）設計者が、4GネットワークでのICNの展開のさまざまな問題、最適化、および利点を理解するのに役立ちます。
In the CUPS architecture, there is an opportunity to shorten the path for user-plane traffic by deploying offload nodes closer to the edge [OFFLOAD]. With this major architecture change, a User Plane Function (UPF) node is placed close to the edge so traffic no longer needs to traverse the entire backhaul path to reach the EPC. In many cases, where feasible, the UPF can be collocated with the eNodeB, which is also a business decision based on user demand. Placing a Publisher close to the offload site, or at the offload site, provides for a significant improvement in user experience, especially with latency-sensitive applications. This capability allows for the introduction of ICN and amplifies its advantages.
Cupsアーキテクチャでは、エッジに近いオフロードノードを展開することにより、ユーザープレーントラフィックのパスを短縮する機会があります[オフロード]。この主要なアーキテクチャの変更により、ユーザープレーン機能（UPF）ノードがエッジの近くに配置されるため、EPCに到達するためにバックホールパス全体を通過するためにトラフィックが必要になります。多くの場合、実行可能な場合、UPFはENODEBと協力することができます。これは、ユーザーの需要に基づくビジネス上の決定でもあります。パブリッシャーをオフロードサイトの近くに配置するか、オフロードサイトに配置すると、特に遅延に敏感なアプリケーションで、ユーザーエクスペリエンスの大幅な改善が提供されます。この機能により、ICNの導入が可能になり、その利点が増幅されます。
The integration of ICN provides an opportunity to further optimize the existing data transport in 4G mobile networks. The various opportunities from the coexistence of ICN and IP transport in the mobile network are somewhat analogous to the deployment scenarios when IPv6 was introduced to interoperate with IPv4 except, with ICN, the whole IP stack can be replaced. We have reviewed [RFC6459] and analyzed the impact of ICN on control plane signaling and user-plane data delivery. In general, ICN can be used natively by replacing IP transport (IPv4 and IPv6) or as an overlay protocol. Figure 4 describes a proposal to modify the existing transport protocol stack to support ICN in a 4G mobile network.
ICNの統合により、4Gモバイルネットワークの既存のデータトランスポートをさらに最適化する機会が提供されます。モバイルネットワークでのICNとIPトランスポートの共存からのさまざまな機会は、IPv6がIPv4と相互運用するために導入されたときに展開シナリオに多少類似しています。[RFC6459]をレビューし、コントロールプレーンのシグナル伝達とユーザー面データ配信に対するICNの影響を分析しました。一般に、ICNはIP輸送（IPv4およびIPv6）を交換するか、オーバーレイプロトコルとして交換することでネイティブに使用できます。図4は、4GモバイルネットワークでICNをサポートするために既存のトランスポートプロトコルスタックを変更する提案を説明しています。
+----------------+ +-----------------+
| ICN App (new) | |IP App (existing)|
+---------+------+ +-------+---------+
| |
+---------+----------------+---------+
| Transport Convergence Layer (new) |
+------+---------------------+-------+
| |
+------+------+ +------+-------+
|ICN function | | IP function |
| (New) | | (Existing) |
+------+------+ +------+-------+
| |
(```). (```).
( ICN '`. ( IP '`.
( Cloud ) ( Cloud )
` __..'+' ` __..'+'
Figure 4: IP/ICN Convergence Scenarios
図4：IP/ICN収束シナリオ
As shown in Figure 4, for applications (running either in the mobile terminal or in the content provider system) to use the ICN transport option, we propose a new transport convergence layer (TCL). The TCL helps determine the type of transport (such as ICN or IP) as well as the type of radio interface (LTE, Wi-Fi, or both) used to send and receive traffic based on preference (e.g., content location, content type, content publisher, congestion, cost, or QoS). It helps configure and determine the type of connection (native IP or ICN) or the overlay mode (ICNoIP or IPoICN) between application and the protocol stack (IP or ICN).
図4に示すように、アプリケーション（モバイル端末またはコンテンツプロバイダーシステムで実行）の場合、ICNトランスポートオプションを使用するには、新しい輸送収束層（TCL）を提案します。TCLは、好みに基づいてトラフィックを送信および受信するために使用されるラジオインターフェイス（LTE、Wi-Fi、またはその両方）のタイプ（ICNやIPなど）のタイプ（LTE、Wi-Fi、またはその両方）を決定するのに役立ちます（例：コンテンツの場所、コンテンツタイプ、、コンテンツパブリッシャー、混雑、コスト、またはQO）。アプリケーションとプロトコルスタック（IPまたはICN）の間で、接続のタイプ（ネイティブIPまたはICN）またはオーバーレイモード（ICNOIPまたはIPOICN）を構成および決定するのに役立ちます。
Combined with the existing IP function, the ICN function provides support for native ICN and/or the dual transport (ICN/IP) functionality. See Section 5.4.1 for elaborate descriptions of these functional layers.
既存のIP関数と組み合わせて、ICN関数は、ネイティブICNおよび/またはデュアルトランスポート（ICN/IP）機能のサポートを提供します。これらの機能層の詳細な説明については、セクション5.4.1を参照してください。
The TCL can use several mechanisms for transport selection. It can use a per-application configuration through a management interface, possibly a user-facing setting realized through a user interface, like those used to select cellular over Wi-Fi. In another option, it might use a software API, which an adapted IP application could use to specify the type of transport option (such as ICN) to take advantage of its benefits.
TCLは、輸送選択にいくつかのメカニズムを使用できます。管理インターフェイスを介してアプリケーションごとの構成を使用できます。これは、Wi-Fiでセルラーを選択するために使用されるように、ユーザーインターフェイスを介して実現されるユーザー向け設定です。別のオプションでは、ソフトウェアAPIを使用する場合があります。これは、適応したIPアプリケーションがその利点を活用するためにトランスポートオプションの種類（ICNなど）を指定するために使用できる場合があります。
Another potential application of TCL is in an implementation of network slicing with a local slice management capability or through an interface to an external slice manager via an API [GALIS]. This solution can enable network slicing for IP and ICN transport selection from the mobile terminal itself. The TCL could apply slice settings to direct certain applications traffic over one slice and others over another slice, determined by some form of a 'slicing policy'. The slicing policy can be obtained externally from the slice manager or configured locally on the mobile terminal.
TCLのもう1つの潜在的なアプリケーションは、ローカルスライス管理機能を使用したネットワークスライスの実装、またはAPI [GALIS]を介して外部スライスマネージャーへのインターフェイスを介して実装されています。このソリューションにより、モバイル端末自体からのIPおよびICNトランスポート選択のネットワークスライスを可能にすることができます。TCLは、スライス設定を適用して、ある形の「スライスポリシー」によって決定される、1つのスライスと他のスライスに特定のアプリケーショントラフィックを指示することができます。スライスポリシーは、スライスマネージャーから外部から取得するか、モバイル端末でローカルで構成できます。
From the perspective of applications either on the mobile terminal or at a content provider, the following options are possible for potential use of ICN natively and/or with IP.
モバイルターミナルまたはコンテンツプロバイダーのいずれかのアプリケーションの観点から、ICNをネイティブに使用し、/またはIPで使用するために、次のオプションが可能です。
IP over IP (IPoIP): In this scenario, the mobile terminal applications are tightly integrated with the existing IP transport infrastructure. The TCL has no additional function because packets are forwarded directly using an IP protocol stack, which sends packets over the IP transport.
IP Over IP（IPOIP）：このシナリオでは、モバイル端末アプリケーションが既存のIPトランスポートインフラストラクチャと密接に統合されています。TCLには追加の機能はありません。これは、IPプロトコルスタックを使用してパケットが直接転送され、IPトランスポートにパケットを送信するためです。
ICN over ICN (ICNoICN): Similar to case 1, ICN applications tightly integrate with the ICN transport infrastructure. The TCL has no additional responsibility because packets are forwarded directly using the native ICN protocol stack, which sends packets over the ICN transport.
ICNオーバーICN（ICNOICN）：ケース1と同様に、ICNアプリケーションはICNトランスポートインフラストラクチャと密接に統合します。TCLには追加の責任はありません。これは、パケットがICNトランスポート上にパケットを送信するネイティブICNプロトコルスタックを使用して直接転送されるためです。
ICN over IP (ICNoIP): In this scenario, the underlying IP transport infrastructure is not impacted (that is, ICN is implemented as an IP overlay between mobile terminal and content provider). IP routing is used from the Radio Access Network (eNodeB) to the mobile backhaul, the IP core, and the Mobile Gateway (SGW/PGW). The mobile terminal attaches to the Mobile Gateway (SGW/PGW) using an IP address. Also, the data transport between Mobile Gateway (SGW/PGW) and content publisher uses IP. The content provider can serve content using either IP or ICN, based on the mobile terminal request.
ICN Over IP（ICNOIP）：このシナリオでは、基礎となるIPトランスポートインフラストラクチャが影響を受けません（つまり、ICNはモバイル端末とコンテンツプロバイダーの間のIPオーバーレイとして実装されます）。IPルーティングは、ラジオアクセスネットワーク（ENODEB）からモバイルバックホール、IPコア、モバイルゲートウェイ（SGW/PGW）に使用されます。モバイル端子は、IPアドレスを使用してモバイルゲートウェイ（SGW/PGW）に取り付けられます。また、モバイルゲートウェイ（SGW/PGW）とコンテンツパブリッシャーの間のデータ輸送はIPを使用します。コンテンツプロバイダーは、モバイル端末要求に基づいて、IPまたはICNを使用してコンテンツを提供できます。
One of the approaches to implement ICN in mobile backhaul networks is described in [MBICN]. It implements a General Tunneling Protocol - User Plane (GTP-U) extension header option to encapsulate ICN payload in a GTP tunnel. However, as this design runs ICN as an IP overlay, the mobile backhaul can be deployed using native IP. The proposal describes a mechanism where the GTP-U tunnel can be terminated by hairpinning the packet before it reaches the SGW if an ICN-enabled node is deployed in the mobile backhaul (that is, between eNodeB and SGW). This could be useful when an ICN data packet is stored in the ICN node (such as repositories and caches) in the tunnel path so that the ICN node can reply without going all the way through the mobile core. While a GTP-U extension header is used to carry mobile-terminal-specific ICN payload, they are not visible to the transport, including the SGW. On the other hand, the PGW can use the mobile terminal-specific ICN header extension and ICN payload to set up an uplink transport towards a content provider in the Internet. In addition, the design assumes a proxy function at the edge to perform ICN data retrieval on behalf of a non-ICN end device.
モバイルバックホールネットワークにICNを実装するアプローチの1つは、[MBICN]で説明されています。 GTPトンネルにICNペイロードをカプセル化するために、一般的なトンネルプロトコル - ユーザープレーン（GTP -U）拡張ヘッダーオプションを実装します。ただし、この設計はIPオーバーレイとしてICNを実行するため、モバイルバックホールはネイティブIPを使用して展開できます。提案は、ICN対応ノードがモバイルバックホールに展開されている場合（EnodeBとSGWの間）、GTP-UトンネルをSGWに到達する前にパケットをヘアピニングすることで終了できるメカニズムについて説明しています。これは、ICNノード（リポジトリやキャッシュなど）にトンネルパスのICNノード（リポジトリやキャッシュなど）に保存され、ICNノードがモバイルコアを通過せずに返信できる場合に役立ちます。 GTP-U拡張ヘッダーは、モバイル末端固有のICNペイロードを運ぶために使用されますが、SGWを含む輸送には見えません。一方、PGWは、モバイル端末固有のICNヘッダー拡張機能とICNペイロードを使用して、インターネットのコンテンツプロバイダーにアップリンクトランスポートを設定できます。さらに、設計は、非ICNエンドデバイスに代わってICNデータ取得を実行するために、エッジでプロキシ関数を想定しています。
IP over ICN (IPoICN): [IPoICN] provides an architectural framework for running IP as an overlay over the ICN protocol. Implementing IP services over ICN provides an opportunity to leverage the benefits of ICN in the transport infrastructure while there is no impact on end devices (MT and access network) as they continue to use IP. IPoICN, however, will require an interworking function (IWF) (and Border Gateway) to translate various transport primitives. The IWF function will provide a mechanism for protocol translation between IPoICN and the native IP. After reviewing [IPoICN], we understand and interpret that ICN is implemented in the transport natively; however, IP is implemented in MT, the eNodeB, and the Mobile Gateway (SGW/PGW), which is also called a network attach point (NAP).
IP over ICN（IPOICN）：[IPOICN]は、ICNプロトコル上のオーバーレイとしてIPを実行するためのアーキテクチャフレームワークを提供します。ICNを介してIPサービスを実装することは、IPを使用し続けるため、End Devices（MTおよびAccess Network）に影響がない間、トランスポートインフラストラクチャでのICNの利点を活用する機会を提供します。ただし、IPOICNでは、さまざまな輸送プリミティブを翻訳するために、インターワーキング関数（IWF）（および境界ゲートウェイ）が必要です。IWF関数は、IPOICNとネイティブIPの間のプロトコル翻訳のメカニズムを提供します。[IPOICN]をレビューした後、ICNが輸送にネイティブに実装されていることを理解して解釈します。ただし、IPはMT、ENODEB、およびモバイルゲートウェイ（SGW/PGW）に実装されており、ネットワークアタッチポイント（NAP）とも呼ばれます。
For this, said NAP receives an incoming IP or HTTP packet (the latter through TCP connection termination) and publishes the packet under a suitable ICN name (i.e., the hash over the destination IP address for an IP packet or the hash over the FQDN of the HTTP request for an HTTP packet) to the ICN network. In the HTTP case, the NAP maintains a pending request mapping table to map returning responses to the terminated TCP connection.
このために、NAPは着信IPまたはHTTPパケット（TCP接続終端を介して後者）を受け取り、適切なICN名（つまり、IPパケットの宛先IPアドレスのハッシュまたはFQDN上のハッシュを介してハッシュを公開します。ICNネットワークへのHTTPパケットのHTTP要求）。HTTPの場合、NAPは保留中の要求マッピングテーブルを維持し、終了したTCP接続に対する返信応答をマップします。
Hybrid ICN (hICN): An alternative approach to implement ICN over IP is provided in Hybrid ICN [HICN]. It describes a novel approach to integrate ICN into IPv6 without creating overlays with a new packet format as an encapsulation. hICN addresses the content by encoding a location-independent name in an IPv6 address. It uses two name components, name prefix and name suffix, that identify the source of data and the data segment within the scope of the name prefix, respectively.
ハイブリッドICN（HICN）：ICNを介したICNを実装するための代替アプローチは、ハイブリッドICN [HICN]で提供されます。カプセル化として新しいパケット形式を使用してオーバーレイを作成することなく、ICNをIPv6に統合するための新しいアプローチを説明しています。HICNは、IPv6アドレスで場所に依存しない名前をエンコードすることにより、コンテンツをアドレス指定します。2つの名前コンポーネント、名前の接頭辞と名前の接尾辞を使用して、それぞれ名のプレフィックスの範囲内でデータのソースとデータセグメントを識別します。
At the application layer, hICN maps the name into an IPv6 prefix and, thus, uses IP as transport. As long as the name prefixes, which are routable IP prefixes, point towards a mobile GW (PGW or local breakout, such as CUPS), there are potentially no updates required to any of the mobile core gateways (for example, SGW/ PGW). The IPv6 backhaul routes the packets within the mobile core. hICN can run in the mobile terminal, the eNodeB, the mobile backhaul, or the mobile core. Finally, as hICN itself uses IPv6, it cannot be considered as an alternative transport layer.
アプリケーションレイヤーで、HICNは名前をIPv6プレフィックスにマッピングするため、IPをトランスポートとして使用します。ルーティング可能なIPプレフィックスである名前のプレフィックスがモバイルGW（PGWまたはCUPなどのローカルブレイクアウト）を指している限り、モバイルコアゲートウェイ（たとえば、SGW/ PGWなど）に必要な更新が必要な可能性があります。。IPv6バックホールは、モバイルコア内のパケットをルーティングします。HICNは、モバイルターミナル、ENODEB、モバイルバックホール、またはモバイルコアで実行できます。最後に、HICN自体がIPv6を使用するため、代替輸送層と見なすことはできません。
In this section, we analyze signaling messages that are required for different procedures, such as attach, handover, tracking area update, and so on. The goal of this analysis is to see if there are any benefits to replacing IP-based protocols with ICN for 4G signaling in the current architecture. It is important to understand the concept of point of attachment (POA). When a mobile terminal connects to a network, it has the following POAs:
このセクションでは、添付、ハンドオーバー、追跡エリアの更新など、さまざまな手順に必要なシグナリングメッセージを分析します。この分析の目標は、現在のアーキテクチャで4Gシグナル伝達のIPベースのプロトコルをICNに置き換えることに何らかの利点があるかどうかを確認することです。アタッチメントポイント（POA）の概念を理解することが重要です。モバイル端末がネットワークに接続すると、次のポアがあります。
1. eNodeB managing location or physical POA
1. ENODEBの管理場所または物理POAの管理
2. Authentication and Authorization (MME, HSS) managing identity or authentication POA
2. 認証と承認（MME、HSS）IDまたは認証POAの管理
3. Mobile Gateways (SGW/PGW) managing logical or session management POA
3. モバイルゲートウェイ（SGW/PGW）論理またはセッション管理POAの管理
In the current architecture, IP transport is used for all messages associated with the control plane for mobility and session management. IP is embedded very deeply into these messages utilizing TLV syntax for carrying additional attributes such as a Layer 3 transport. The physical POA in the eNodeB handles both mobility and session management for any mobile terminal attached to a 4G network. The number of mobility management messages between different nodes in a 4G network per the signaling procedure is shown in Table 1.
現在のアーキテクチャでは、モビリティとセッション管理のためにコントロールプレーンに関連付けられたすべてのメッセージにIPトランスポートが使用されています。IPは、レイヤー3トランスポートなどの追加の属性を運ぶためにTLV構文を使用してこれらのメッセージに非常に深く埋め込まれています。ENODEBの物理POAは、4Gネットワークに接続されたモバイル端末のモビリティとセッション管理の両方を処理します。信号手順ごとに4Gネットワーク内の異なるノード間のモビリティ管理メッセージの数を表1に示します。
Normally, two types of mobile terminals attach to the 4G network: SIM based (which needs a 3GPP mobility protocol for authentication) or non-SIM based (which connects to Wi-Fi networks). Both device types require authentication. For non-SIM based devices, Authentication, Authorization, and Accounting (AAA) is used for authentication. We do not propose to change mobile terminal authentication or mobility management messaging for user data transport using ICN. A separate study would be required to analyze the impact of ICN on mobility management messages, structures, and flows. We are merely analyzing the viability of implementing ICN as a transport for control plane messages.
通常、2種類のモバイル端子が4Gネットワークに接続します：SIMベース（認証には3GPPモビリティプロトコルが必要です）または非SIMベース（Wi-Fiネットワークに接続）。両方のデバイスタイプには認証が必要です。非SIMベースのデバイスの場合、認証（AAA）が認証に使用されます。ICNを使用したユーザーデータトランスポートのモバイル端末認証またはモビリティ管理メッセージを変更することは提案していません。モビリティ管理メッセージ、構造、およびフローに対するICNの影響を分析するには、別の研究が必要です。ICNをコントロールプレーンメッセージの輸送として実装する実行可能性を分析するだけです。
It is important to note that if MME and HSS do not support ICN transport, they still need to support a mobile terminal capable of dual transport or native ICN. When a mobile terminal initiates an attach request using the identity as ICN, MME must be able to parse that message and create a session. MME forwards mobile terminal authentication to HSS, so HSS must be able to authenticate an ICN-capable mobile terminal and authorize Create Session [TS23.401].
MMEとHSSがICNトランスポートをサポートしていない場合、デュアルトランスポートまたはネイティブICNが可能なモバイル端末をサポートする必要があることに注意することが重要です。モバイル端末がICNとしてIDを使用して添付要求を開始する場合、MMEはそのメッセージを解析してセッションを作成できる必要があります。MMEはモバイル端末認証をHSSに転送するため、HSSはICN対応のモバイル端末を認証し、セッションの作成[TS23.401]を認証できる必要があります。
+===========================+=====+=====+=====+=====+======+
| 4G Signaling Procedures | MME | HSS | SGW | PGW | PCRF |
+===========================+=====+=====+=====+=====+======+
| Attach | 10 | 2 | 3 | 2 | 1 |
+---------------------------+-----+-----+-----+-----+------+
| Additional default bearer | 4 | 0 | 3 | 2 | 1 |
+---------------------------+-----+-----+-----+-----+------+
| Dedicated bearer | 2 | 0 | 2 | 2 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| Idle-to-connect | 3 | 0 | 1 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| Connect-to-Idle | 3 | 0 | 1 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| X2 handover | 2 | 0 | 1 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| S1 handover | 8 | 0 | 3 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| Tracking area update | 2 | 2 | 0 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| Total | 34 | 2 | 14 | 6 | 3 |
+---------------------------+-----+-----+-----+-----+------+
Table 1: Signaling Messages in 4G Gateways
表1：4Gゲートウェイのシグナリングメッセージ
Anchorless mobility [ALM] provides a fully decentralized solution that is control plane agnostic to handle producer mobility in ICN. Mobility management at the Layer 3 makes its access agnostic and transparent to the end device or the application. The solution discusses handling mobility without having to depend on core network functions (e.g., MME); however, a location update to the core network may still be required to support legal compliance requirements such as lawful intercept and emergency services. These aspects are open for further study.
Anchorless Mobility [ALM]は、ICNの生産者のモビリティを処理するためのコントロールプレーンの不可知論者である完全に分散化されたソリューションを提供します。レイヤー3のモビリティ管理により、アクセスが不可知論的で透過的で、エンドデバイスまたはアプリケーションに透過的になります。このソリューションでは、コアネットワーク関数（MMEなど）に依存することなく、モビリティの取り扱いについて説明します。ただし、合法的な傍受や緊急サービスなどの法的コンプライアンス要件をサポートするには、コアネットワークの場所の更新が必要になる場合があります。これらの側面は、さらなる研究のために開かれています。
One of the advantages of ICN is in the caching and reusing of the content, which does not apply to the transactional signaling exchange. After analyzing 4G signaling call flows [TS23.401] and message interdependencies (see Table 1), our recommendation is that it is not beneficial to use ICN for control plane and mobility management functions. Among the features of ICN design, Interest aggregation and content caching are not applicable to control plane signaling messages. Control plane messages are originated and consumed by the applications, and they cannot be shared.
ICNの利点の1つは、コンテンツのキャッシングと再利用にあり、これはトランザクションシグナリング交換には適用されません。4Gシグナリングコールフロー[TS23.401]とメッセージ相互依存性を分析した後（表1を参照）、コントロールプレーンおよびモビリティ管理機能にICNを使用することは有益ではないということです。ICN設計の機能の中で、関心の集合とコンテンツキャッシュは、制御プレーンの信号メッセージに適用できません。コントロールプレーンのメッセージは、アプリケーションによって発信および消費され、共有できません。
We will consider Figure 1 when discussing different mechanisms to integrate ICN in mobile networks. In Section 5.2, we discussed generic experimental setups of ICN integration. In this section, we discuss the specific options of possible use of native ICN in the 4G user plane. The following options are considered:
モバイルネットワークにICNを統合するためのさまざまなメカニズムを議論する際には、図1を検討します。セクション5.2では、ICN統合の一般的な実験セットアップについて説明しました。このセクションでは、4GユーザープレーンでネイティブICNを使用する可能性のある特定のオプションについて説明します。次のオプションが考慮されます。
1. Using Dual transport (IP/ICN) mode in mobile terminal
1. モバイルターミナルでデュアルトランスポート（IP/ICN）モードを使用する
2. Using ICN in mobile terminal
2. モバイル端子でICNを使用します
3. Using ICN in eNodeB
3. ENODEBでICNを使用します
4. Using ICN in Mobile Gateways (SGW/PGW)
4. モバイルゲートウェイでICNを使用（SGW/PGW）
The control and user-plane communications in 4G mobile networks are specified in 3GPP documents [TS23.203] and [TS23.401]. It is important to understand that a mobile terminal can be either consumer (receiving content) or publisher (pushing content for other clients). The protocol stack inside the mobile terminal (MT) is complex because it must support multiple radio connectivity access to eNodeB(s).
4Gモバイルネットワークのコントロールおよびユーザープレーン通信は、3GPPドキュメント[TS23.203]および[TS23.401]で指定されています。モバイルターミナルは、消費者（コンテンツを受信）またはパブリッシャー（他のクライアントのコンテンツをプッシュする）のいずれかであることを理解することが重要です。モバイル端子（MT）内のプロトコルスタックは、ENODEBへの複数の無線接続アクセスをサポートする必要があるため、複雑です。
Figure 5 provides a high-level description of a protocol stack, where IP is used at two layers: (1) user-plane communication and (2) UDP encapsulation. User-plane communication takes place between the Packet Data Convergence Protocol (PDCP) and Application layer, whereas UDP encapsulation is at the GTP protocol stack.
図5は、プロトコルスタックの高レベルの説明を示しています。ここで、IPは2つのレイヤーで使用されます。（1）ユーザー面通信と（2）UDPカプセル化。UDPカプセル化はGTPプロトコルスタックにあるのに対し、ユーザー面通信はパケットデータコンバージェンスプロトコル（PDCP）とアプリケーションレイヤー間で行われます。
The protocol interactions and impact of supporting the tunneling of an ICN packet into IP or supporting ICN natively are described in Figures 5 and 6, respectively.
ICNパケットのIPへのトンネリングまたはICNをネイティブにサポートするプロトコルの相互作用と影響については、それぞれ図5と6に説明します。
+--------+ +--------+
| App | | CDN |
+--------+ +--------+
|Transp. | | | | |Transp. |
|Converg.|.|..............|...............|............|.|Converge|
+--------+ | | | +--------+ | +--------+
| |.|..............|...............|.| |.|.| |
| ICN/IP | | | | | ICN/IP | | | ICN/IP|
| | | | | | | | | |
+--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
| |.|.| | |.|.| | |.|.| | | | | |
| PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 |
+--------+ | +----------+ | +-----------+ | +-----+ | | | |
| RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| |
+--------+ | +----------+ | +-----------+ | +-----+ | | | |
| MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | |
+--------+ | +----------+ | +-----------+ | +--------+ | +--------+
| L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 |
+--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
MT | BS (eNodeB) | SGW | PGW |
Uu S1U S5/S8 SGi
Figure 5: Dual Transport (IP/ICN) Mode in a Mobile Terminal
図5：モバイルターミナルのデュアルトランスポート（IP/ICN）モード
The protocols and software stack used inside 4G-capable mobile terminals support both 3G and 4G software interworking and handover. 3GPP Rel.13 specifications and onward describe the use of IP and non-IP protocols to establish logical/session connectivity. We can leverage the non-IP protocol-based mechanism to deploy an ICN protocol stack in the mobile terminal as well as in an eNodeB and Mobile Gateways (SGW/PGW). The following paragraphs describe per-layer considerations of supporting the tunneling of ICN packets into IP or supporting ICN natively.
4G対応のモバイルターミナル内で使用されるプロトコルとソフトウェアスタックは、3Gおよび4Gソフトウェアの両方のインターワーキングとハンドオーバーをサポートしています。3GPP REL.13仕様と以降、IPおよび非IPプロトコルの使用を説明して、論理/セッションの接続性を確立します。非IPプロトコルベースのメカニズムを活用して、モバイル端末とENODEBおよびモバイルゲートウェイ（SGW/PGW）にICNプロトコルスタックを展開できます。次の段落では、ICNパケットのIPへのトンネリングをサポートするか、ICNをネイティブにサポートする層ごとの考慮事項について説明しています。
1. An existing application layer can be modified to provide options for a new ICN-based application and existing IP-based applications. The mobile terminal can continue to support existing IP-based applications or can develop new applications to support native ICN, ICNoIP, or IPoICN-based transport. The application layer can be provided with an option of selecting either ICN or IP transport, as well as radio interface, to send and receive data traffic.
1. 既存のアプリケーションレイヤーを変更して、新しいICNベースのアプリケーションと既存のIPベースのアプリケーションのオプションを提供できます。モバイル端末は、既存のIPベースのアプリケーションを引き続きサポートしたり、ネイティブICN、ICNOIP、またはIPOICNベースのトランスポートをサポートする新しいアプリケーションを開発できます。アプリケーションレイヤーには、データトラフィックを送信および受信するために、ICNまたはIPトランスポートと無線インターフェイスのいずれかを選択するオプションを提供できます。
Our proposal is to provide an Application Programming Interface (API) to the application developers so they can choose either ICN or IP transport for exchanging the traffic with the network. As mentioned in Section 5.2, the TCL function handles the interaction of applications with multiple transport options.
私たちの提案は、アプリケーション開発者にアプリケーションプログラミングインターフェイス（API）を提供して、ネットワークと交換するためにICNまたはIPトランスポートを選択できるようにすることです。セクション5.2で述べたように、TCL関数は、アプリケーションと複数の輸送オプションの相互作用を処理します。
2. The transport convergence layer helps determine the type of transport (such as ICN, hICN, or IP) and type of radio interface (LTE, Wi-Fi, or both) used to send and receive traffic. The application layer can make the decision to select a specific transport based on preference such as content location, content type, content publisher, congestion, cost, QoS, and so on. There can be an API to exchange parameters required for transport selection. Southbound interactions of the TCL will be either to IP or to ICN at the network layer.
2. 輸送収束層は、トラフィックの送信と受信に使用されるトランスポート（ICN、HICN、またはIPなど）と無線インターフェイスの種類（LTE、Wi-Fi、またはその両方）を決定するのに役立ちます。アプリケーションレイヤーは、コンテンツの場所、コンテンツタイプ、コンテンツパブリッシャー、混雑、コスト、QOなどの選好に基づいて特定のトランスポートを選択することを決定できます。輸送の選択に必要なAPIを交換するパラメーターを使用することができます。TCLの南行きの相互作用は、IPまたはネットワークレイヤーでのICNのいずれかです。
When selecting the IPoICN mode, the TCL is responsible for receiving an incoming IP or HTTP packet and publishing the packet to the ICN network under a suitable ICN name (that is, the hash over the destination IP address for an IP packet or the hash over the FQDN of the HTTP request for an HTTP packet).
IPOICNモードを選択するとき、TCLは着信IPまたはHTTPパケットを受信し、適切なICN名の下でICNネットワークにパケットを公開する責任があります（つまり、IPパケットの宛先IPアドレスのハッシュまたはハッシュオーバーHTTPパケットのHTTP要求のFQDN）。
In the HTTP case, the TCL can maintain a pending request mapping table to map, returning responses to the originating HTTP request. The common API will provide a "connection" abstraction for this HTTP mode of operation, returning the response over said connection abstraction (akin to the TCP socket interface) while implementing a reliable transport connection semantic over the ICN from the mobile terminal to the receiving mobile terminal or the PGW. If the HTTP protocol stack remains unchanged, therefore utilizing the TCP protocol for transfer, the TCL operates in local TCP termination mode, retrieving the HTTP packet through said local termination.
HTTPの場合、TCLは保留中のリクエストマッピングテーブルをマッピングして維持し、発信元のHTTP要求に対する応答を返します。一般的なAPIは、このHTTP操作モードの「接続」抽象化を提供し、モバイル端末から受信モバイルまでのICNを介して信頼できるトランスポート接続の意味を実装しながら、上記の接続抽象化（TCPソケットインターフェイスに似ています）に対する応答を返します。端末またはPGW。HTTPプロトコルスタックが変更されていない場合、したがってTCPプロトコルを転送に使用している場合、TCLはローカルTCP終了モードで動作し、その局所終了を通じてHTTPパケットを取得します。
+----------------+ +-----------------+
| ICN App (new) | |IP App (existing)|
+---------+------+ +-------+---------+
| |
+---------+----------------+---------+
| Transport Convergence Layer (new) |
+------+---------------------+-------+
| |
+------+------+ +------+-------+
|ICN function | | IP function |
| (New) | | (Existing) |
+------+------+ +------+-------+
| |
+------+---------------------+-------+
| PDCP (updated to support ICN) |
+-----------------+------------------+
|
+-----------------+------------------+
| RLC (Existing) |
+-----------------+------------------+
|
+-----------------+------------------+
| MAC Layer (Existing) |
+-----------------+------------------+
|
+-----------------+------------------+
| Physical L1 (Existing) |
+------------------------------------+
Figure 6: Dual Stack ICN Protocol Interactions
図6：デュアルスタックICNプロトコル相互作用
3. The ICN function (forwarder) is proposed to run in parallel to the existing IP layer. The ICN forwarder forwards the ICN packets such as an Interest packet to an eNodeB or a response "data packet" from an eNodeB to the application.
3. ICN関数（転送者）は、既存のIPレイヤーと並行して実行することが提案されています。ICNフォワーダーは、関心パケットなどのICNパケットをENODEBに転送したり、eNodeBからアプリケーションに「データパケット」を応答します。
4. For the dual-transport scenario, when a mobile terminal is not supporting ICN as transport, the TCL can use the IP underlay to tunnel the ICN packets. The ICN function can use the IP interface to send Interest and Data packets for fetching or sending data, respectively. This interface can use the ICN overlay over IP.
4. デュアル輸送シナリオの場合、モバイル端末がトランスポートとしてICNをサポートしていない場合、TCLはIPアンダーレイを使用してICNパケットをトンネルします。ICN関数は、IPインターフェイスを使用して、それぞれデータを取得または送信するために関心とデータパケットを送信できます。このインターフェイスは、IPを介してICNオーバーレイを使用できます。
5. To support ICN at the network layer in the mobile terminal, the PDCP layer should be aware of ICN capabilities and parameters. PDCP is located in the Radio Protocol Stack in the LTE Air interface, between the IP (Network layer) and Radio Link Control Layer (RLC). PDCP performs the following functions [TS36.323]:
5. モバイル端子のネットワークレイヤーでICNをサポートするには、PDCPレイヤーがICN機能とパラメーターを認識する必要があります。PDCPは、LTE Airインターフェイスの無線プロトコルスタック、IP（ネットワークレイヤー）と無線リンク制御レイヤー（RLC）の間にあります。PDCPは次の機能を実行します[TS36.323]：
1. Data transport by listening to the upper layer, formatting, and pushing down to the RLC
1. 上層層を聴き、フォーマットし、RLCに押し下げることによるデータ輸送
2. Header compression and decompression using ROHC
2. ROHCを使用したヘッダー圧縮と減圧
3. Security protections such as ciphering, deciphering, and integrity protection
3. 暗号化、解読、整合性の保護などのセキュリティ保護
4. Radio layer messages associated with sequencing, packet drop detection and retransmission, and so on.
4. シーケンス、パケットドロップの検出と再送信などに関連付けられた無線層メッセージ。
6. No changes are required for the lower layer such as RLC, Media Access Control (MAC), and Physical (L1) as they are not IP aware.
6. RLC、メディアアクセス制御（MAC）、物理（L1）などの下層には、IP認識ではないため、変更は必要ありません。
One key point to understand in this scenario is that ICN is deployed as an overlay on top of IP.
このシナリオで理解すべき重要なポイントの1つは、ICNがIPの上にオーバーレイとして展開されることです。
We can implement ICN natively in the mobile terminal by modifying the PDCP layer in 3GPP protocols. Figure 7 provides a high-level protocol stack description where ICN can be used at the following different layers:
3GPPプロトコルでPDCPレイヤーを変更することにより、モバイル端子にICNをネイティブに実装できます。図7は、以下の異なるレイヤーでICNを使用できる高レベルのプロトコルスタック説明を示しています。
1. User-plane communication
1. ユーザー平面通信
2. Transport layer
2. 輸送層
ICN transport would be a substitute for the GTP protocol. The removal of the GTP protocol stack is a significant change in the mobile architecture and requires a thorough study mainly because it is used not just for routing but for mobility management functions such as billing, mediation, and policy enforcement.
ICNトランスポートは、GTPプロトコルの代わりになります。GTPプロトコルスタックの削除は、モバイルアーキテクチャの大きな変化であり、主にルーティングだけでなく、請求、調停、政策施行などのモビリティ管理機能に使用されるため、徹底的な調査が必要です。
The implementation of ICN natively in the mobile terminal leads to a changed communication model between the mobile terminal and eNodeB. Also, we can avoid tunneling the user-plane traffic from an eNodeB to the mobile packet core (SGW/PGW) through a GTP tunnel.
モバイル端末にネイティブにICNを実装すると、モバイル端末とENODEBの間の通信モデルが変更されます。また、GTPトンネルを介して、ENODEBからモバイルパケットコア（SGW/PGW）へのユーザープレーントラフィックのトンネルを避けることができます。
For native ICN use, an application can be configured to use an ICN forwarder, and it does not need the TCL layer. Also, to support ICN at the network layer, the existing PDCP layer may need to be changed to be aware of ICN capabilities and parameters.
ネイティブICN使用の場合、アプリケーションをICNフォワーダーを使用するように構成でき、TCLレイヤーは必要ありません。また、ネットワークレイヤーでICNをサポートするには、ICN機能とパラメーターを認識するために既存のPDCPレイヤーを変更する必要がある場合があります。
The native implementation can provide new opportunities to develop new use cases leveraging ICN capabilities such as seamless mobility, mobile terminal to mobile terminal content delivery using a radio network without traversing the Mobile Gateways, and more.
ネイティブの実装は、シームレスモビリティ、モバイルゲートウェイを横断せずにラジオネットワークを使用したモバイル端末からモバイル端末のコンテンツ配信などのICN機能を活用する新しいユースケースを開発する新しい機会を提供できます。
+--------+ +--------+
| App | | CDN |
+--------+ +--------+
|Transp. | | | | | |Transp. |
|Converge|.|..............|..............|..............|.|Converge|
+--------+ | | | | +--------+
| |.|..............|..............|..............|.| |
| ICN/IP | | | | | | |
| | | | | | | |
+--------+ | +----+-----+ | +----------+ | +----------+ | | ICN/IP |
| |.|.| | | | | | | | | | | |
| PDCP | | |PDCP| ICN |.|.| ICN |.|.| ICN |.|.| |
+--------+ | +----+ | | | | | | | | | |
| RLC |.|.|RLC | | | | | | | | | | |
+--------+ | +----------+ | +----------+ | +----------+ | +--------+
| MAC |.|.| MAC| L2 |.|.| L2 |.|.| L2 |.|.| L2 |
+--------+ | +----------+ | +----------+ | +----------+ | +--------+
| L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 |
+--------+ | +----+-----+ | +----------+ | +----------+ | +--------+
MT | BS(eNodeB) | SGW | PGW |
Uu S1u S5/S8 SGi
Figure 7: Using Native ICN in Mobile Terminal
図7：モバイルターミナルでネイティブICNを使用します
The eNodeB is a physical point of attachment for the mobile terminal where radio protocols are converted into IP transport protocols for dual transport/overlay and native ICN, respectively (see Figures 6 and 7). When a mobile terminal performs an attach procedure, it will be assigned an identity as either IP or dual transport (IP and ICN) or ICN endpoint. A mobile terminal can initiate data traffic using any of the following options:
ENODEBは、ラジオプロトコルがそれぞれデュアルトランスポート/オーバーレイとネイティブICNのためにIPトランスポートプロトコルに変換されるモバイル端末のアタッチメントの物理的ポイントです（図6および7を参照）。モバイル端子が添付手順を実行すると、IPまたはデュアルトランスポート（IPおよびICN）またはICNエンドポイントのいずれかとしてIDが割り当てられます。モバイル端末は、次のオプションのいずれかを使用してデータトラフィックを開始できます。
1. Native IP (IPv4 or IPv6)
1. ネイティブIP（IPv4またはIPv6）
2. Native ICN
2. ネイティブICN
3. Dual transport IP (IPv4/IPv6) and ICN
3. デュアルトランスポートIP（IPv4/IPv6）およびICN
The mobile terminal encapsulates a user data transport request into the PDCP layer and sends the information on the air interface to the eNodeB, which in turn receives the information and, using PDCP [TS36.323], de-encapsulates the air-interface messages and converts them to forward-to-core Mobile Gateways (SGW/PGW). As shown in Figure 8, to support ICN natively in an eNodeB, it is proposed to provide TCL capabilities in an eNodeB (similar to as provided in MT), which provides the following functions:
モバイル端末は、ユーザーデータトランスポートリクエストをPDCPレイヤーにカプセル化し、エアインターフェイスの情報をENODEBに送信します。これにより、情報が受信され、PDCP [TS36.323]を使用して、エアインターフェイスメッセージをエンコールし、それらをフォワードツーコアモバイルゲートウェイ（SGW/PGW）に変換します。図8に示すように、eNodeBでICNをネイティブにサポートするために、次の機能を提供するENODEB（MTで提供されているように）でTCL機能を提供することが提案されています。
1. It decides the forwarding strategy for a user data request coming from the mobile terminal. The strategy can decide based on preference indicated by the application, such as congestion, cost, QoS, and so on.
1. これは、モバイル端末からのユーザーデータ要求の転送戦略を決定します。戦略は、輻輳、コスト、QOなど、アプリケーションで示される好みに基づいて決定できます。
2. It uses an eNodeB to provide an open API to external management systems in order to provide eNodeB the capability to program the forwarding strategies.
2. ENODEBを使用して、外部管理システムにオープンAPIを提供し、ENODEBに転送戦略をプログラムする機能を提供します。
+---------------+ |
| MT request | | ICN +---------+
+---->| content using |--+--- transport -->| |
| |ICN protocol | | | |
| +---------------+ | | |
| | | |
| +---------------+ | | |
+-+ | | MT request | | IP |To mobile|
| |-+---->| content using |--+--- transport -->| GW |
+-+ | | IP protocol | | |(SGW/PGW)|
MT | +---------------+ | | |
| | | |
| +---------------+ | | |
| | MT request | | Dual stack | |
+---->| content using |--+--- IP+ICN -->| |
|IP/ICN protocol| | transport +---------+
+---------------+ |
eNodeB S1u
Figure 8: Integration of Native ICN in eNodeB
図8：ENODEBでのネイティブICNの統合
3. The eNodeB can be upgraded to support three different types of transport: IP, ICN, and dual transport IP+ICN towards Mobile Gateways, as depicted in Figure 8. It is also proposed to deploy IP and/or ICN forwarding capabilities into an eNodeB for efficient transfer of data between the eNodeB and Mobile Gateways. The following are choices for forwarding a data request towards Mobile Gateways:
3. ENODEBをアップグレードして、図8に示すように、IP、ICN、およびデュアルトランスポートIP ICNをモバイルゲートウェイに向けて3つの異なるタイプのトランスポートをサポートできます。ENODEBとモバイルゲートウェイ間のデータの転送。以下は、モバイルゲートウェイにデータ要求を転送するための選択肢です。
1. Assuming the eNodeB is IP enabled and the MT requests an IP transfer, the eNodeB forwards data over IP.
1. ENODEBがIP有効であり、MTがIP転送を要求すると仮定すると、ENODEBはIPよりもデータを転送します。
2. Assuming the eNodeB is ICN enabled and the MT requests an ICN transfer, the eNodeB forwards data over ICN.
2. ENODEBがICN有効であり、MTがICN転送を要求すると仮定すると、ENODEBはICNでデータを転送します。
3. Assuming the eNodeB is IP enabled and the MT requests an ICN transfer, the eNodeB overlays ICN on IP and forwards user-plane traffic over IP.
3. ENODEBがIP有効であり、MTがICN転送を要求すると仮定すると、ENODEBオーバーレイICNがIPでICNをオーバーレイし、IPよりもユーザープレーントラフィックを転送します。
4. Assuming the eNodeB is ICN enabled and the MT requests an IP transfer, the eNodeB overlays IP on ICN and forwards user-plane traffic over ICN [IPoICN].
4. ENODEBがICN有効であり、MTがIP転送を要求すると仮定すると、ENODEBはICN上のIPオーバーレイIPとICN [IPOICN]を介してユーザー平面トラフィックを転送します。
Mobile Gateways (a.k.a. Evolved Packet Core (EPC)) include SGW and PGW, which perform session management for MT from the initial attach to disconnection. When MT is powered on, it performs Network-Access-Stratum (NAS) signaling and attaches to PGW after successful authentication. PGW is an anchoring point for MT and is responsible for service creations, authorization, maintenance, and so on. The entire functionality is managed using an IP address(es) for MT.
モバイルゲートウェイ（A.K.A. Evolved Packet Core（EPC））には、SGWとPGWが含まれ、最初のアタッチから切断までMTのセッション管理を実行します。MTが電源を入れると、ネットワークアクセスストラタム（NAS）シグナル伝達を実行し、認証が成功した後にPGWに付着します。PGWはMTのアンカーポイントであり、サービスの作成、承認、メンテナンスなどを担当しています。機能全体は、MTのIPアドレス（ES）を使用して管理されます。
To implement ICN in EPC, the following functions are proposed:
EPCにICNを実装するには、次の機能が提案されています。
1. Insert ICN attributes in the session management layer for additional functionality with IP stack. The session management layer is used for performing attach procedures and assigning logical identity to users. After successful authentication by HSS, MME sends a Create Session Request (CSR) to SGW and SGW to PGW.
1. IPスタックを使用して追加の機能について、セッション管理レイヤーにICN属性を挿入します。セッション管理レイヤーは、添付手順を実行し、ユーザーに論理IDを割り当てるために使用されます。HSSによる認証が成功した後、MMEはSGWにCreate Session Request（CSR）を送信し、SGWにPGWに送信します。
2. When MME sends a Create Session Request message (Step 12 in [TS23.401]) to SGW or PGW, it includes a Protocol Configuration Option (PCO) Information Element (IE) containing MT capabilities. We can use PCO IE to carry ICN-related capabilities information from MT to PGW. This information is received from MT during the initial attach request in MME. Details of available TLV, which can be used for ICN, are given in subsequent sections. MT can support native IP, ICN+IP, or native ICN. IP is referred to as both IPv4 and IPv6 protocols.
2. MMEがCREATEセッション要求メッセージ（[TS23.401]のステップ12）をSGWまたはPGWに送信すると、MT機能を含むプロトコル構成オプション（PCO）情報要素（IE）が含まれます。PCO IEを使用して、MTからPGWにICN関連の機能情報を運ぶことができます。この情報は、MMEでの最初の添付要求中にMTから受信されます。ICNに使用できる利用可能なTLVの詳細は、後続のセクションに記載されています。MTは、ネイティブIP、ICN IP、またはネイティブICNをサポートできます。IPは、IPv4およびIPv6プロトコルの両方と呼ばれます。
3. For ICN+IP-capable MT, PGW assigns the MT both an IP address and ICN identity. MT selects either of the identities during the initial attach procedures and registers with the network for session management. For ICN-capable MT, it will provide only ICN attachment. For native IP-capable MT, there is no change.
3. ICN IP対応MTの場合、PGWはMTにIPアドレスとICN IDの両方を割り当てます。MTは、セッション管理のためのネットワークで最初の添付手順と登録中にIDのいずれかを選択します。ICN対応MTの場合、ICNアタッチメントのみを提供します。ネイティブIP対応MTの場合、変更はありません。
4. To support ICN-capable attach procedures and use ICN for user-plane traffic, PGW needs to have full ICN protocol stack functionalities. Typical ICN capabilities include functions such as CS, PIT, FIB capabilities, and so on. If MT requests ICN in PCO IE, then PGW registers MT with ICN names. For ICN forwarding, PGW caches content locally using CS functionality.
4. ICN対応手順をサポートし、ユーザープレーントラフィックにICNを使用するには、PGWが完全なICNプロトコルスタック機能を持つ必要があります。典型的なICN機能には、CS、PIT、FIB機能などの機能が含まれます。MTがPCO IEでICNを要求する場合、PGWはMTをICN名で登録します。ICN転送の場合、PGWはCS機能を使用してローカルにコンテンツをキャッシュします。
5. PCO IE as described in [TS24.008] (see Figure 10.5.136 on page 656 and Table 10.5.154 on page 659) provides details for different fields.
5. [TS24.008]で説明されているPCO IE（656ページの図10.5.136および659ページの表10.5.154を参照）は、さまざまなフィールドの詳細を示しています。
1. Octet 3 (configuration protocols define PDN types), which contains details about IPv4, IPv6, both IPv4 and IPv6, or ICN.
1. Octet 3（構成プロトコルはPDNタイプを定義します）。これには、IPv4、IPv6、IPv4とIPv6の両方、またはICNの両方の詳細が含まれています。
2. Any combination of Octet 4 to Z can be used to provide additional information related to ICN capability. It is most important that PCO IE parameters are matched between MT and Mobile Gateways (SGW/PGW) so they can be interpreted properly and the MT can attach successfully.
2. Octet 4とZの任意の組み合わせを使用して、ICN機能に関連する追加情報を提供できます。PCO IEパラメーターをMTとモバイルゲートウェイ（SGW/PGW）の間で一致させることが最も重要であるため、それらを適切に解釈し、MTを正常に接続できます。
6. The ICN functionalities in SGW and PGW should be matched with MT and the eNodeB because they will exchange ICN protocols and parameters.
6. SGWおよびPGWのICN機能は、ICNプロトコルとパラメーターを交換するため、MTおよびENODEBと一致する必要があります。
7. Mobile Gateways (SGW/PGW) will also need ICN forwarding and caching capability. This is especially important if CUPS is implemented. User Plane Function (UPF), comprising the SGW and PGW user plane, will be located at the edge of the network and close to the end user. ICN-enabled gateway means that this UPF would serve as a forwarder and should be capable of caching, as is the case with any other ICN-enabled node.
7. モバイルゲートウェイ（SGW/PGW）には、ICN転送とキャッシュ機能も必要です。これは、カップが実装されている場合に特に重要です。SGWおよびPGWユーザープレーンを含むユーザープレーン機能（UPF）は、ネットワークの端にあり、エンドユーザーの近くに配置されます。ICN対応ゲートウェイとは、このUPFがフォワーダーとして機能し、他のICN対応ノードの場合のように、キャッシュできる必要があることを意味します。
8. The transport between PGW and CDN provider can be either IP or ICN. When MT is attached to PGW with ICN identity and communicates with an ICN-enabled CDN provider, it will use ICN primitives to fetch the data. On the other hand, for an MT attached with an ICN identity, if PGW must communicate with an IP-enabled CDN provider, it will have to use an ICN-IP interworking gateway to perform conversion between ICN and IP primitives for data retrieval. In the case of CUPS implementation with an offload close to the edge, this interworking gateway can be collocated with the UPF at the offload site to maximize the path optimization. Further study is required to understand how this ICN-to-IP (and vice versa) interworking gateway would function.
8. PGWとCDNプロバイダー間の輸送は、IPまたはICNのいずれかです。MTがICNアイデンティティでPGWに接続され、ICN対応CDNプロバイダーと通信すると、ICNプリミティブを使用してデータを取得します。一方、ICNアイデンティティに接続されたMTの場合、PGWがIP対応のCDNプロバイダーと通信する必要がある場合、ICN-IPインターワーキングゲートウェイを使用して、データ取得のためにICNとIPプリミティブ間の変換を実行する必要があります。エッジに近いオフロードを備えたCUPS実装の場合、このインターワーキングゲートウェイをOffloadサイトのUPFとコロケートして、パス最適化を最大化できます。このICNからIP（およびその逆）のインターワーキングゲートウェイがどのように機能するかを理解するには、さらなる研究が必要です。
This section proposes an experimental lab setup and discusses the open issues and questions that use of the ICN protocol is intended to address. To further test the modifications proposed in different scenarios, a simple lab can be set up, as shown in Figure 9.
このセクションでは、実験的なラボのセットアップを提案し、ICNプロトコルの使用が対処することを目的としたオープンな問題と質問について説明します。さまざまなシナリオで提案されている変更をさらにテストするために、図9に示すように、簡単なラボを設定できます。
+------------------------------------------+
| +-----+ +------+ (```). +------+ | (````). +-----+
| | SUB |-->| EMU |--(x-haul'.-->| EPC |--->( PDN ).-->| CDN |
| +-----+ +------+ `__..'' +------+ | `__...' +-----+
+------------------------------------------+
4G Mobile Network Functions
Figure 9: Native ICN Deployment Lab Setup
図9：ネイティブICN展開ラボのセットアップ
The following test scenarios can be set up with deployment based on Virtual Machine (VM):
次のテストシナリオは、仮想マシン（VM）に基づいて展開するとセットアップできます。
1. SUB: An ICN-simulated client (using ndnSIM) - a client application on a workstation requesting content.
1. サブ：ICNシミュレーションクライアント（NDNSIMを使用） - コンテンツを要求するワークステーション上のクライアントアプリケーション。
2. EMU: Test unit emulating an eNodeB. This is a test node allowing for UE attachment and routing traffic subsequently from the Subscriber to the Publisher.
2. EMU：ENODEBをエミュレートするテストユニット。これは、サブスクライバーからパブリッシャーにその後トラフィックをルーティングできるようにするテストノードです。
3. EPC: Evolved Packet Core in a single instance (such as Open5GCore [Open5GCore]).
3. EPC：単一のインスタンスで進化したパケットコア（Open5GCore [Open5GCore]など）。
4. CDN: Content delivery by a Publisher server.
4. CDN：パブリッシャーサーバーによるコンテンツ配信。
For the purpose of this testing, ICN-emulating code can be inserted in the test code in EMU to emulate an ICN-capable eNodeB. An example of the code to be used is NS3 in its LTE model. The effect of such traffic on EPC and CDN can be observed and documented. In a subsequent phase, EPC code supporting ICN can be tested when available.
このテストの目的のために、ICN対応コードをEMUのテストコードに挿入して、ICN対応のENODEBをエミュレートできます。使用するコードの例は、LTEモデルのNS3です。EPCおよびCDNに対するこのようなトラフィックの影響は、観察および文書化できます。後続のフェーズでは、ICNをサポートするEPCコードを使用可能な場合はテストできます。
Another option is to simulate the UE/eNodeB and EPC functions using NS3's LTE [NS3LTE] and EPC [NS3EPC] models, respectively. The LTE model includes the LTE Radio Protocol stack, which resides entirely within the UE and the eNodeB nodes. This capability provides the simulation of UE and eNodeB deployment use cases. Similarly, the EPC model includes core network interfaces, protocols, and entities, which reside within the Mobile Gateways (SGW/PGW), and MME nodes and partially within the eNodeB nodes.
別のオプションは、それぞれNS3のLTE [NS3LTE]およびEPC [NS3EPC]モデルを使用してUE/ENODEBおよびEPC関数をシミュレートすることです。LTEモデルには、LTE無線プロトコルスタックが含まれており、UEおよびENODEBノード内に完全に存在します。この機能は、UEおよびENODEB展開ユースケースのシミュレーションを提供します。同様に、EPCモデルには、モバイルゲートウェイ（SGW/PGW）内に存在するコアネットワークインターフェイス、プロトコル、およびエンティティが含まれ、MMEノードと部分的にENODEBノード内に含まれます。
Even with its current limitations (such as IPv4 only, lack of integration with ndnSIM, and no support for UE idle state), LTE simulation may be a very useful tool. In any case, both control and user-plane traffic should be tested independently according to the deployment model discussed in Section 5.4.
現在の制限（IPv4のみ、NDNSIMとの統合の欠如、UEアイドル状態のサポートがないなど）があっても、LTEシミュレーションは非常に有用なツールかもしれません。いずれにせよ、セクション5.4で説明した展開モデルに従って、コントロールトラフィックとユーザー面トラフィックの両方を個別にテストする必要があります。
The experimentation explained in Section 5 can be categorized in three broader scopes as follows. Note that further research and study is required to fully understand and document the impact.
セクション5で説明されている実験は、次のように3つの広いスコープに分類できます。影響を完全に理解し、文書化するには、さらなる研究と研究が必要であることに注意してください。
Architecture scope: to study the aspect of use of ICN at the user plane to reduce the complexities in current transport protocols while also evaluating its use in the control plane.
アーキテクチャの範囲：ユーザープレーンでのICNの使用の側面を研究して、現在の輸送プロトコルの複雑さを減らしながら、コントロールプレーンでの使用を評価します。
Performance scope: to evaluate the gains through multicast, caching, and other ICN features.
パフォーマンス範囲：マルチキャスト、キャッシュ、その他のICN機能を通じて利益を評価する。
Deployment scope: to check the viability of ICN inclusion in the 3GPP protocol stack and in real-world deployments.
展開範囲：3GPPプロトコルスタックおよび実際の展開におけるICNインクルージョンの実行可能性を確認する。
Specifically, we have identified the following open questions, from the architectural and performance perspective, that the proposed experiments with ICN implementation scenarios in 4G mobile networks could address in further research:
具体的には、4GモバイルネットワークでのICN実装シナリオを使用した提案された実験がさらなる研究で対処できるという、アーキテクチャおよびパフォーマンスの観点から、次の未解決の質問を特定しました。
1. Efficiency gains in terms of the amount of traffic in multicast scenarios (i.e., quantify the possible gains along different use cases) and latency for cached content, mainly in the CDN use case.
1. マルチキャストシナリオのトラフィック量（つまり、異なるユースケースに沿った可能性のあるゲインを定量化する）と、主にCDNユースケースのキャッシュコンテンツの遅延の観点から効率の向上。
2. How the new transport would coexist or replace the legacy transport protocols (e.g., IPv4, IPv6, MPLS, RSVP, etc.) and related services (e.g., bandwidth management, QoS handling, etc.).
2. 新しいトランスポートが、レガシートランスポートプロトコル（IPv4、IPv6、MPLS、RSVPなど）および関連サービス（帯域幅管理、QOSハンドリングなど）を共存または交換する方法。
3. To what extent the simplification in the IP-based transport protocols will be achieved. The multiple overlays (e.g., the MPLS, VPN, Virtual Private LAN Service (VPLS), Ethernet VPN, etc.) of services in the current IP-based transport adds to the complexity on top of basic IP transport. This makes the troubleshooting extremely challenging.
3. IPベースのトランスポートプロトコルの単純化がどの程度達成されますか。現在のIPベースのトランスポートのサービスの複数のオーバーレイ（MPLS、VPN、仮想プライベートLANサービス（VPLS）、イーサネットVPNなど）は、基本的なIPトランスポートの複雑さに追加されます。これにより、トラブルシューティングが非常に困難になります。
4. How the new transport can become service aware such that it brings in more simplicity in the system.
4. 新しいトランスポートがどのようにサービスになることができるか、システムがよりシンプルになるようになります。
5. Confirm how (in)adequate ICN implementation would be in the control plane (which this document discourages). Given that the 5G system, as specified in [TS23.501] (Appendix G.4), encourages the use of name-based routing in the (5G) control plane for realizing the 5G-specific service-based architecture for control plane services (so-called network function service), it would be worthwhile to investigate whether the 4G control plane would benefit similarly from such use or whether specific 4G architectural constraints would prevent ICN from providing any notable benefit.
5. 適切なICN実装がコントロールプレーンでどのように（このドキュメントが阻止されるか）を確認してください。[TS23.501]（付録G.4）で指定されている5Gシステムは、コントロールプレーンサービス用の5G固有のサービスベースのアーキテクチャを実現するための（5G）制御プレーンでの名前ベースのルーティングの使用を奨励していることを考えると、（いわゆるネットワーク機能サービス）、4Gコントロールプレーンがそのような使用から同様に利益を得るかどうか、または特定の4Gアーキテクチャの制約がICNが顕著な利益をもたらさないかどうかを調査する価値があります。
With the experiments and their outcomes outlined in this document, we believe that this technology is ready for a wider use and adoption, providing additional insights. Specifically, we expect to study the following:
このドキュメントで概説されている実験とその結果により、この技術はより幅広い使用と採用の準備ができており、追加の洞察を提供していると考えています。具体的には、以下を研究することを期待しています。
1. Viability of ICN inclusion in the 3GPP protocol stack, i.e., investigating how realistic it would be to modify the stack, considering the scenarios explained in Section 5.4, and completing the user session without feature degradation.
1. 3GPPプロトコルスタックへのICN包含の生存率、つまり、セクション5.4で説明されているシナリオを考慮して、機能の劣化なしでユーザーセッションを完了することを考慮して、スタックを変更することがどれほど現実的かを調査します。
2. Viability of utilizing solutions in greenfield deployments, i.e., deploying the ICN-based extensions and solutions proposed in this document in greenfield 4G deployments in order to assess real-world benefits when doing so.
2. Greenfieldの展開でソリューションを利用することの実行可能性、つまり、Greenfield 4Gの展開でこのドキュメントで提案されているICNベースの拡張機能とソリューションを展開して、実際の利点を評価するために展開します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This section will cover some security and privacy considerations in mobile and 4G networks because of the introduction of ICN.
このセクションでは、ICNの導入により、モバイルおよび4Gネットワークでのセキュリティとプライバシーの考慮事項について説明します。
To ensure only authenticated mobile terminals are connected to the network, 4G mobile networks implement various security mechanisms. From the perspective of using ICN in the user plane, the following security aspects need to be taken care of:
認証されたモバイル端子のみがネットワークに接続されていることを確認するために、4Gモバイルネットワークはさまざまなセキュリティメカニズムを実装します。ユーザープレーンでICNを使用するという観点から、次のセキュリティの側面を処理する必要があります。
1. MT authentication and authorization
1. MT認証と承認
2. Radio or air interface security
2. ラジオまたはエアインターフェイスセキュリティ
3. Denial-of-service attacks on the Mobile Gateway; services are either by the MT or by external entities in the Internet
3. モバイルゲートウェイでのサービス拒否攻撃。サービスは、MTまたはインターネット内の外部エンティティによるものです
4. Content poisoning in either transport or servers
4. 輸送またはサーバーのいずれかのコンテンツ中毒
5. Content cache pollution attacks
5. コンテンツキャッシュ汚染攻撃
6. Secure naming, routing, and forwarding
6. 命名、ルーティング、転送を確保します
7. Application security
7. アプリケーションセキュリティ
Security over the LTE air interface is provided through cryptographic techniques. When MT is powered up, it performs a key exchange between the MT's Universal Mobile Telecommunications System Subscriber Identity Module (USIM) and HSS/Authentication Center using NAS messages, including ciphering and integrity protections between MT and MME. Details for secure MT authentication, key exchange, ciphering, and integrity protection messages are given in the 3GPP call flow [TS23.401]. With ICN, we are modifying the protocol stack for the user plane and not the control plane. The NAS signaling is exchanged between MT and Mobile Gateways, e.g., MME, using the control plane; therefore, there is no adverse impact of ICN on MT.
LTE AIRインターフェイスを介したセキュリティは、暗号化技術を通じて提供されます。MTが電源を入れると、MTとMMEの間の暗号化や整合性保護を含むNASメッセージを使用して、MTのUniversal Mobile Telecommunications System Subscriber IDモジュール（USIM）とHSS/認証センターとの間の重要な交換を実行します。安全なMT認証、キー交換、暗号化、および整合性保護メッセージの詳細は、3GPPコールフロー[TS23.401]に記載されています。ICNを使用すると、コントロールプレーンではなく、ユーザープレーンのプロトコルスタックを変更しています。NASシグナル伝達は、MTとモバイルゲートウェイ、たとえばMMEの間でコントロールプレーンを使用して交換されます。したがって、MTに対するICNの悪影響はありません。
4G uses IP transport in its mobile backhaul (between an eNodeB and the core network). In case of provider-owned backhaul, the Service Provider may require implementing a security mechanism in the backhaul network. The native IP transport continues to leverage security mechanisms such as Internet Key Exchange (IKE) and the IP Security (IPsec) protocol. More details of mobile backhaul security are provided in 3GPP network security specifications [TS33.310] and [TS33.320]. When a mobile backhaul is upgraded to support dual transport (IP+ICN) or native ICN, it is required to implement security techniques that are deployed in the mobile backhaul. When ICN forwarding is enabled on mobile transport routers, we need to deploy security practices based on [RFC7476] and [RFC7927].
4Gは、モバイルバックホール（ENODEBとコアネットワークの間）でIPトランスポートを使用します。プロバイダーが所有するバックホールの場合、サービスプロバイダーはバックホールネットワークにセキュリティメカニズムを実装する必要がある場合があります。ネイティブIPトランスポートは、インターネットキーエクスチェンジ（IKE）やIPセキュリティ（IPSEC）プロトコルなどのセキュリティメカニズムを引き続き活用しています。モバイルバックホールセキュリティの詳細は、3GPPネットワークセキュリティ仕様[TS33.310]および[TS33.320]に記載されています。モバイルバックホールがデュアルトランスポート（IPN）またはネイティブICNをサポートするためにアップグレードされた場合、モバイルバックホールに展開されているセキュリティ手法を実装する必要があります。モバイルトランスポートルーターでICN転送が有効になっている場合、[RFC7476]および[RFC7927]に基づいてセキュリティプラクティスを展開する必要があります。
4G Mobile Gateways (SGW/PGW) perform some key functions such as content-based online/offline billing and accounting, deep packet inspection (DPI), and lawful interception (LI). When ICN is deployed in the user plane, we need to integrate ICN security for sessions between MT and the gateway. If we encrypt user-plane payload metadata, then it might be difficult to perform routing based on contents and it may not work because we need decryption keys at every forwarder to route the content. The content itself can be encrypted between publisher and consumer to ensure privacy. Only the user with the right decryption key shall be able to access the content. We need further research for ICN impact on LI, online/offline charging, and accounting.
4Gモバイルゲートウェイ（SGW/PGW）コンテンツベースのオンライン/オフライン請求と会計、ディープパケット検査（DPI）、および合法的な傍受（LI）などのいくつかの重要な機能を実行します。ICNがユーザープレーンに展開されている場合、MTとGateway間のセッションのICNセキュリティを統合する必要があります。ユーザー平面ペイロードメタデータを暗号化すると、コンテンツに基づいてルーティングを実行することは困難である可能性があり、コンテンツをルーティングするためにすべてのフォワーダーで復号化キーが必要であるため機能しない可能性があります。コンテンツ自体をパブリッシャーと消費者の間で暗号化して、プライバシーを確保できます。適切な復号化キーを持つユーザーのみがコンテンツにアクセスできるものとします。LI、オンライン/オフラインの充電、会計へのICNの影響に関するさらなる研究が必要です。
In 4G networks, there are two main privacy issues [MUTHANA]:
4Gネットワークでは、2つの主要なプライバシーの問題があります[Muthana]：
1. User Identity Privacy Issues. The main privacy issue within 4G is the exposure of the International Mobile Subscriber Identity (IMSI). The IMSI can be intercepted by adversaries. Such attacks are commonly referred to as "IMSI catching".
1. ユーザーIDプライバシーの問題。4G内の主なプライバシーの問題は、国際的なモバイル加入者ID（IMSI）の露出です。IMSIは敵によって傍受することができます。このような攻撃は、一般に「IMSIキャッチング」と呼ばれます。
2. Location Privacy Issues. IMSI catching is closely related to the issue of location privacy. Knowing the IMSI of a user allows the attacker to track the user's movements and create a profile about the user and thus breach the user's location privacy.
2. 場所のプライバシーの問題。IMSIキャッチングは、場所のプライバシーの問題と密接に関連しています。ユーザーのIMSIを知ることで、攻撃者はユーザーの動きを追跡し、ユーザーに関するプロフィールを作成し、ユーザーの場所のプライバシーを侵害することができます。
In any network, caching implies a trade-off between network efficiency and privacy. The activity of users is exposed to the scrutiny of cache owners with whom they may not have any relationship. By monitoring the cache transactions, an attacker could obtain significant information related to the objects accessed, topology, and timing of the requests [RFC7945]. Privacy concerns are amplified by the introduction of new network functions such as information lookup and network storage, and different forms of communication [FOTIOU]. Privacy risks in ICN can be broadly divided in the following categories [TOURANI]:
どのネットワークでも、キャッシュはネットワークの効率とプライバシーのトレードオフを意味します。ユーザーのアクティビティは、関係がない可能性のあるキャッシュ所有者の精査にさらされています。キャッシュトランザクションを監視することにより、攻撃者は、アクセスされたオブジェクト、トポロジ、およびリクエストのタイミングに関連する重要な情報を取得できます[RFC7945]。プライバシーの懸念は、情報検索やネットワークストレージ、さまざまな形式の通信[FOTIOU]などの新しいネットワーク機能の導入により増幅されます。ICNのプライバシーリスクは、次のカテゴリ[Tourani]で広く分割できます。
1. Timing attack
1. タイミング攻撃
2. Communication monitoring attack
2. 通信監視攻撃
3. Censorship and anonymity attack
3. 検閲と匿名攻撃
4. Protocol attack
4. プロトコル攻撃
5. Naming-signature privacy
5. 命名署名プライバシー
The introduction of TCL effectively enables ICN at the application and/or transport layer depending on the scenario described in Section 5. Enabling ICN in 4G networks is expected to increase efficiency by taking advantage of ICN's inherent characteristics. This approach would potentially leave some of the above-mentioned privacy concerns open as a consequence of using ICN transport and ICN inherent privacy vulnerabilities.
TCLの導入により、セクション5で説明したシナリオに応じて、アプリケーションおよび/または輸送層でICNを効果的に可能にします。4GネットワークでICNを有効にすると、ICNの固有の特性を活用することで効率が向上すると予想されます。このアプローチは、ICNトランスポートとICN固有のプライバシーの脆弱性を使用した結果として、上記のプライバシー懸念の一部を開いたままにする可能性があります。
1. IPoIP (Section 5.2) would not be affected as TCL has no role in it, and ICN does not apply.
1. IPOIP（セクション5.2）は、TCLには役割がなく、ICNが適用されないため、影響を受けません。
2. The ICNoICN scenario (Section 5.2) has increased risk of a privacy attack, and that risk is applicable to the ICN protocol in general rather than specifically to the 4G implementation. Since this scenario describes communication over ICN transport, every forwarder in the path could be a potential risk for a privacy attack.
2. ICNOICNシナリオ（セクション5.2）は、プライバシー攻撃のリスクを高め、そのリスクは4G実装ではなく、一般的にICNプロトコルに適用できます。このシナリオはICNトランスポートを介した通信を説明しているため、パス内のすべてのフォワーダーがプライバシー攻撃の潜在的なリスクになる可能性があります。
3. The ICNoIP scenario (Section 5.2) uses IP for transport, so the only additional ICN-related potential privacy risk areas are the endpoints (consumer and publisher) where, at the application layer, content is being served.
3. ICNOIPシナリオ（セクション5.2）はトランスポートにIPを使用しているため、ICN関連の追加の潜在的なプライバシーリスク領域のみは、アプリケーションレイヤーでコンテンツが提供されているエンドポイント（消費者および出版社）です。
4. The IPoICN scenario (Section 5.2) could have potentially increased risk due to possible vulnerability of the forwarders in the path of ICN transport.
4. IPOICNシナリオ（セクション5.2）は、ICN輸送の経路におけるフォワーダーの脆弱性の可能性により、潜在的にリスクを高める可能性があります。
Privacy issues already identified in 4G remain a concern if ICN is
introduced in any of the scenarios described earlier and compounds to
the new ICN-related privacy issues. Many research papers have been
published that propose solutions to the privacy issues listed above.
For LTE-specific privacy issues, some of the proposed solutions
[MUTHANA] are IMSI encryption by an MT; mutual authentication;
concealing the real IMSI within a random bit stream of certain size
where only the subscriber and HSS could extract the respective IMSI;
IMSI replacement with a changing pseudonym that only the HSS server
can map to the UE's IMSI; and others. Similarly, some of the
proposed ICN-specific privacy concerns mitigation methods, applicable
where ICN transport is introduced as specified earlier in this
section, include the following [FOTIOU]:
* Delay for the first, or first k, interests on edge routers (timing attack)
* 最初の、または最初のkの遅延、エッジルーターの関心（タイミング攻撃）
* Creating a secure tunnel or clients flagging the requests as non-cacheable for privacy (communication monitoring attack)
* プライバシーのキャッシュ不可としてリクエストにフラグを立てる安全なトンネルまたはクライアントの作成（通信監視攻撃）
* Encoding interest by mixing the content and cover file or using a hierarchical DNS-based brokering model (censorship and anonymity attack)
* コンテンツとカバーファイルをミキシングするか、階層的なDNSベースのブローカーモデルを使用して関心をエンコードする（検閲と匿名攻撃）
* Use of rate-limiting requests for a specific namespace (protocol attack)
* 特定の名前空間のレート制限要求の使用（プロトコル攻撃）
* Cryptographic content hash-based naming or digital identity in an overlay network (naming-signature privacy)
* 暗号化コンテンツハッシュベースのネーミングまたはオーバーレイネットワーク内のデジタルアイデンティティ（ネーミングシグネチュアプライバシー）
Further research in this area is needed. Detailed discussion of privacy is beyond the scope of this document.
この分野でのさらなる研究が必要です。プライバシーの詳細な議論は、このドキュメントの範囲を超えています。
In this document, we have discussed 4G networks and the experimental setups to study the advantages of the potential use of ICN for efficient delivery of contents to mobile terminals. We have discussed different options to try and test ICN and dependencies such as ICN functionalities and changes required in different 4G network elements. In order to further explore potential use of ICN, one can devise an experimental setup consisting of 4G network elements and deploy ICN data transport in the user plane. Different options can be overlay, dual transport (IP + ICN), hICN, or natively (by integrating ICN with CDN, eNodeB, SGW, PGW, and a transport network). Note that, for the scenarios discussed above, additional study is required for lawful interception, billing/mediation, network slicing, and provisioning APIs.
このドキュメントでは、4Gネットワークと実験セットアップについて説明して、モバイル端子にコンテンツを効率的に配信するためのICNの潜在的な使用の利点を研究しました。さまざまな4Gネットワーク要素に必要なICN機能や変更などのICNと依存関係を試してみようとするさまざまなオプションについて説明しました。ICNの潜在的な使用をさらに調査するために、4Gネットワーク要素で構成される実験セットアップを考案し、ユーザープレーンにICNデータトランスポートを展開できます。さまざまなオプションがオーバーレイ、デュアルトランスポート（IP ICN）、HICN、またはネイティブに（ICNをCDN、ENODEB、SGW、PGW、および輸送ネットワークと統合することにより）などです。上記のシナリオでは、合法的な傍受、請求/調停、ネットワークスライス、およびAPIのプロビジョニングには追加の研究が必要であることに注意してください。
Edge Computing [CHENG] provides capabilities to deploy functionalities such as CDN caching and mobile user plane functions (UPFs) [TS23.501]. Recent research for delivering real-time video content [MPVCICN] using ICN has also been proven to be efficient [NDNRTC] and can be used towards realizing the benefits of using ICN in an eNodeB, edge computing, Mobile Gateways (SGW/PGW), and CDN. The key aspect for ICN is in its seamless integration in 4G and 5G networks with tangible benefits so we can optimize content delivery using a simple and scalable architecture. The authors will continue to explore how ICN forwarding in edge computing could be used for efficient data delivery from the mobile edge.
エッジコンピューティング[Cheng]は、CDNキャッシュやモバイルユーザープレーン機能（UPFS）[TS23.501]などの機能を展開する機能を提供します。ICNを使用してリアルタイムビデオコンテンツ[MPVCICN]を配信するための最近の研究も効率的であることが証明されており[NDNRTC]、ENODEB、エッジコンピューティング、モバイルゲートウェイ（SGW/PGW）でICNを使用する利点を実現することができます。およびCDN。ICNの重要な側面は、具体的な利点を持つ4Gおよび5Gネットワークでのシームレスな統合であるため、シンプルでスケーラブルなアーキテクチャを使用してコンテンツ配信を最適化できます。著者は、モバイルエッジからの効率的なデータ配信にエッジコンピューティングでのICN転送をどのように使用できるかを引き続き検討します。
Based on our study of control plane signaling, it is not beneficial to deploy ICN with existing protocols unless further changes are introduced in the control protocol stack itself.
コントロールプレーンシグナル伝達の研究に基づいて、コントロールプロトコルスタック自体にさらなる変更が導入されない限り、既存のプロトコルでICNを展開することは有益ではありません。
As a starting step towards use of ICN in the user plane, it is proposed to incorporate protocol changes in MT, an eNodeB, and SGW/ PGW for data transport. ICN has inherent capabilities for mobility and content caching, which can improve the efficiency of data transport for unicast and multicast delivery. The authors welcome contributions and suggestions, including those related to further validations of the principles by implementing prototypes and/or proof of concepts in the lab and in the production environment.
ユーザープレーンでのICNの使用に向けた開始ステップとして、データ輸送のためにMT、ENODEB、およびSGW/ PGWにプロトコルの変更を組み込むことが提案されています。ICNには、モビリティとコンテンツキャッシュに固有の機能があり、ユニキャストとマルチキャスト配信のデータ輸送の効率を改善できます。著者は、研究室および生産環境でプロトタイプや概念実証を実装することにより、原則のさらなる検証に関連するものを含む、貢献と提案を歓迎します。
[TS24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3", 3GPP TS 24.008 17.7.0, June 2022, <https://www.3gpp.org/ftp/Specs/html-info/24008.htm>.
[TS24.008] 3GPP、「モバイル無線インターフェイスレイヤー3仕様、コアネットワークプロトコル、ステージ3 "、3GPP TS 24.008 17.7.0、2022年6月、<https://www.3gpp.org/ftp/specs/html-情報/24008.htm>。
[TS25.323] 3GPP, "Packet Data Convergence Protocol (PDCP) specification", 3GPP TS 25.323 17.0.0, April 2022, <https://www.3gpp.org/ftp/Specs/html-info/25323.htm>.
[TS25.323] 3GPP、「パケットデータコンバージェンスプロトコル（PDCP）仕様」、3GPP TS 25.323 17.0.0、2022年4月、<https://www.org/ftp/specs/html-info/25323.htm>。
[TS29.274] 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 17.6.0, June 2022, <https://www.3gpp.org/ftp/Specs/html-info/29274.htm>.
[TS29.274] 3GPP、 "3GPP Evolved Packet System（EPS）; Evolved General Packet Radio Service（GPRS）コントロールプレーン用のトンネルプロトコル（GTPV2-C）、ステージ3"、3GPP TS 29.274 17.6.0、6月2022年、<<<https://www.3gpp.org/ftp/specs/html-info/29274.htm>。
[TS29.281] 3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 17.3.0, June 2022, <https://www.3gpp.org/ftp/Specs/html-info/29281.htm>.
[TS29.281] 3GPP、「一般的なパケット無線システム（GPRS）トンネルプロトコルユーザープレーン（GTPV1-U）」、3GPP TS 29.281 17.3.0、2022年6月、<https://www.3gpp.org/ftp/specs/html-info/29281.htm>。
[TS36.323] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification", 3GPP TS 36.323 17.1.0, July 2022, <https://www.3gpp.org/ftp/Specs/html-info/36323.htm>.
[TS36.323] 3GPP、「普遍的な陸生無線アクセス（E-UTRA）;パケットデータコンバージェンスプロトコル（PDCP）仕様」、3GPP TS 36.323 17.1.0、<https：//www.3gpp.org/ftp/specs/html-info/36323.htm>。
[ALM] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L., Pau, G., and X. Zeng, "Anchor-Less Producer Mobility in ICN", ACM-ICN '15: Proceedings of the 2nd ACM Conference on Information-Centric Networking, pp. 189-190, DOI 10.1145/2810156.2812601, September 2015, <https://dl.acm.org/citation.cfm?id=2812601>.
[Alm]Augé、J.、Carofiglio、G.、Grassi、G.、Muscariello、L.、Pau、G。、およびX. Zeng、「Anchor-Less Producer Mobility in ICN」、ACM-ICN '15：Proceedings情報中心ネットワーキングに関する第2回ACM会議、pp。189-190、DOI 10.1145/2810156.2812601、2015年9月、<https://dl.acm.org/citation.cfm?id=2812601>。
[BROWER] Brower, E., Jeffress, L., Pezeshki, J., Jasani, R., and E. Ertekin, "Integrating Header Compression with IPsec", MILCOM 2006 - 2006 IEEE Military Communications conference, pp. 1-6, DOI 10.1109/MILCOM.2006.302503, October 2006, <https://ieeexplore.ieee.org/document/4086687>.
[Brower] Brower、E.、Jeffress、L.、Pezeshki、J.、Jasani、R.、およびE. Ertekin、「ヘッダー圧縮とIPSECとの統合」、Milcom 2006-2006 IEEE軍事コミュニケーション会議、pp。1-6、doi 10.1109/milcom.2006.302503、2006年10月、<https://ieeexplore.ieee.org/document/4086687>。
[CCN] FD.io, "Cicn", January 2020, <https://wiki.fd.io/index.php?title=Cicn&oldid=10316>.
[ccn] fd.io、 "cicn"、2020年1月、<https://wiki.fd.io/index.php?title=cicn&oldid=10316>。
[CHENG] Liang, C., Yu, R., and X. Zhang, "Information-centric network function virtualization over 5g mobile wireless networks", IEEE Network, Vol. 29, Issue 3, pp. 68-74, June 2015, <https://ieeexplore.ieee.org/document/7113228>.
[Cheng] Liang、C.、Yu、R。、およびX. Zhang、「5Gモバイルワイヤレスネットワークを超える情報中心のネットワーク関数仮想化」、IEEE Network、Vol。29、第3号、pp。68-74、2015年6月、<https://ieeexplore.ieee.org/document/7113228>。
[EMBMS] Zahoor, K., Bilal, K., Erbad, A., and A. Mohamed, "Service-Less Video Multicast in 5G: Enablers and Challenges", IEEE Network, Vol. 34, Issue 3, pp. 270-276, DOI 10.1109/MNET.001.1900435, June 2020, <https://ieeexplore.ieee.org/document/9105941>.
[Embms] Zahoor、K.、Bilal、K.、Erbad、A。、およびA. Mohamed、「5Gのサービスレスビデオマルチキャスト：イネーブラーと課題」、IEEE Network、Vol。34、Issue 3、pp。270-276、doi 10.1109/mnet.001.1900435、2020年6月、<https://ieeexplore.ieee.org/document/9105941>。
[EPCCUPS] Schmitt, P., Landais, B., and F. Yong Yang, "Control and User Plane Separation of EPC nodes (CUPS)", 3GPP, The Mobile Broadband Standard, July 2017, <https://www.3gpp.org/news-events/3gpp-news/1882-cups>.
[Epccups] Schmitt、P.、Landais、B。、およびF. Yong Yang、「EPCノードのコントロールとユーザープレーン分離（CUP）」、3GPP、モバイルブロードバンド標準、2017年7月、<https：// www。3gpp.org/news-events/3gpp-news/1882-cups>。
[FOTIOU] Fotiou, N. and G. Polyzos, "ICN privacy and name based security", ACM-ICN '14: Proceedings of the 1st ACM Conference on Information-Centric Networking, pp. 5-6, DOI 10.1145/2660129.2666711, September 2014, <https://dl.acm.org/doi/10.1145/2660129.2666711>.
[fotiou] fotiou、N。and G. polyzos、「ICNプライバシーとネームベースのセキュリティ」、ACM-ICN '14：情報中心ネットワーキングに関する第1回ACM会議の議事録、5-6ページ、DOI 10.1145/2660129.2666711、2014年9月、<https://dl.acm.org/doi/10.1145/2660129.2666711>。
[GALIS] Galis, A., Ed., Makhijani, K., Yu, D., and B. Liu, "Autonomic Slice Networking", Work in Progress, Internet-Draft, draft-galis-anima-autonomic-slice-networking-05, 26 September 2018, <https://datatracker.ietf.org/doc/html/ draft-galis-anima-autonomic-slice-networking-05>.
[Galis] Galis、A.、ed。、Makhijani、K.、Yu、D。、およびB. Liu、「自律的なスライスネットワーキング」、進行中の作業、インターネットドラフト、ドラフトガリス - アニマ - 自動スライス - ネットワーキング-05、2018年9月26日、<https://datatracker.ietf.org/doc/html/ draft-galis-anima-autonomic-slice-networking-05>。
[GRAYSON] Grayson, M., Shatzkamer, M., and S. Wainner, "IP Design for Mobile Networks", Cisco Press, Networking Technology series, ISBN 1-58705-826-X, June 2009, <https://www.ciscopress.com/store/ip-design-for-mobile-networks-9781587058264>.
[Grayson] Grayson、M.、Shatzkamer、M.、およびS. Wainner、「モバイルネットワークのIPデザイン」、Cisco Press、Networking Technologyシリーズ、ISBN 1-58705-826-X、2009年6月、<https：//www.ciscopress.com/store/ip-design-for-mobile-networks-9781587058264>。
[HICN] Muscariello, L., Carofiglio, G., Auge, J., and M. Papalini, "Hybrid Information-Centric Networking", Work in Progress, Internet-Draft, draft-muscariello-intarea-hicn-04, 20 May 2020, <https://datatracker.ietf.org/doc/html/ draft-muscariello-intarea-hicn-04>.
[Hicn] Mucsariello、L.、Carofiglio、G.、Auge、J。、およびM. Papalini、「Hybrid Information-Centric Networking」、Work in Progress、Internet-Draft、Draft-Muscariello-Intarea-Hicn-04、202020年5月、<https://datatracker.ietf.org/doc/html/ draft-muscariello-intarea-hicn-04>。
[ICN5G] Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G. White, "Enabling ICN in 3GPP's 5G NextGen Core Architecture", Work in Progress, Internet-Draft, draft-irtf-icnrg-5gc-icn-04, 10 January 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-5gc-icn-04>.
[ICN5G] Ravindran、R.、Suthar、P.、Trossen、D.、Wang、C。、およびG. White、「3GPPの5G NextGen Core ArchitectureでICNを有効にする」、進行中の作業、インターネットドラフト、ドラフト-ARTF-ICNRG-5GC-ICN-04、2021年1月10日、<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-5gc-itn-04>。
[ICNQoS] Al-Naday, M.F., Bontozoglou, A., Vassilakis, G., and M. J. Reed, "Quality of service in an information-centric network", 2014 IEEE Global Communications Conference, pp. 1861-1866, DOI 10.1109/GLOCOM.2014.7037079, December 2014, <https://ieeexplore.ieee.org/document/7037079>.
[ICNQOS] Al-Naday、M.F.、Bontozoglou、A.、Vassilakis、G.、およびM. J. Reed、「情報中心ネットワークにおけるサービス品質」、2014 IEEE Global Communications Conference、pp。1861-1866、doi 10.1109/Glocom.2014.7037079、2014年12月、<https://ieeexplore.ieee.org/document/7037079>。
[IPoICN] Trossen, D., Read, M. J., Riihijarvi, J., Georgiades, M., Fotiou, N., and G. Xylomenos, "IP over ICN - The better IP?", 2015 European Conference on Networks and Communications (EuCNC), pp. 413-417, DOI 10.1109/EuCNC.2015.7194109, June 2015, <https://ieeexplore.ieee.org/document/7194109>.
[Ipoicn] Trossen、D.、Read、M。J.、Riihijarvi、J.、Georgiades、M.、Fotiou、N。、およびG. Xylomenos、「IP IP over ICN -The Better IP？」（EUCNC）、pp。413-417、doi 10.1109/eucnc.2015.7194109、2015年6月、<https://ieeexplore.ieee.org/document/7194109>。
[MBICN] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino, "Scalable mobile backhauling via information-centric networking", The 21st IEEE International Workshop on Local and Metropolitan Area Networks, Beijing, pp. 1-6, DOI 10.1109/LANMAN.2015.7114719, April 2015, <https://ieeexplore.ieee.org/document/7114719>.
[MBICN] Carofiglio、G.、Gallo、M.、Muscariello、L。、およびD. Perino、「情報中心のネットワーキングを介したスケーラブルなモバイルバックホール」、21番目のIEEE国際ワークショップ、地元および大都市圏ネットワーク、北京、PP。1-6、doi 10.1109/lanman.2015.7114719、2015年4月、<https://ieeexplore.ieee.org/document/7114719>。
[MECSPEC] ETSI, "Mobile Edge Computing (MEC); Framework and Reference Architecture", ETSI GS MEC 003, Version 1.1.1, March 2016, <https://www.etsi.org/deliver/etsi_gs/ MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf>.
[MECSPEC] ETSI、「モバイルエッジコンピューティング（MEC）;フレームワークとリファレンスアーキテクチャ」、ETSI GS MEC 003、バージョン1.1.1、2016年3月、<https://www.etsi.org/deliver/etsi_gs/ mec/001_099999999999999999999999/003/01.01.01_60/gs_mec003v0101p.pdf>。
[MPVCICN] Jangam, A., Ravindran, R., Chakraborti, A., Wan, X., and G. Wang, "Realtime multi-party video conferencing service over information centric network", IEEE International Conference on Multimedia and Expo Workshops (ICMEW), Turin, Italy, pp. 1-6, DOI 10.1109/ICMEW.2015.7169810, June 2015, <https://ieeexplore.ieee.org/document/7169810>.
[MPVCICN] Jangam、A.、Ravindran、R.、Chakraborti、A.、Wan、X。、およびG. Wang、「情報中心ネットワーク上のリアルタイムマルチパーティビデオ会議サービス」、IEEE国際マルチメディアおよびエキスポワークショップ（ICMew）、トリノ、イタリア、pp。1-6、doi 10.1109/icmew.2015.7169810、2015年6月、<https://ieeexplore.ieee.org/document/7169810>。
[MUTHANA] Muthana, A. and M. Saeed, "Analysis of User Identity Privacy in LTE and Proposed Solution", International Journal of Computer Network and Information Security(IJCNIS), Vol. 9, Issue 1, pp. 54-63, DOI 10.5815/ijcnis.2017.01.07, January 2017, <https://www.mecs-press.org/ijcnis/ijcnis-v9-n1/ v9n1-7.html>.
[Muthana] Muthana、A。およびM. Saeed、「LTEおよび提案されたソリューションにおけるユーザーIDプライバシーの分析」、International Journal of Computer Network and Information Security（IJCNIS）、Vol。9、第1号、54-63ページ、DOI 10.5815/ijcnis.2017.01.07、2017年1月、<https://www.mecs-press.org/ijcnis/ijcnis-v9-n1/ v9n1-7.html>。
[NDNRTC] Gusev, P., Wang, Z., Burke, J., Zhang, L., Yoneda, T., Ohnishi, R., and E. Muramoto, "Real-Time Streaming Data Delivery over Named Data Networking", IEICE Transactions on Communications, Vol. E99.B, Issue 5, pp. 974-991, 10.5815/ijcnis.2017.01.07, May 2016, <https://doi.org/10.1587/transcom.2015AMI0002>.
[Ndnrtc] Gusev、P.、Wang、Z.、Burke、J.、Zhang、L.、Yoneda、T.、Ohnishi、R。、およびE. Muramoto、「名前付きデータネットワーキング上のリアルタイムストリーミングデータ配信」、IEICE Transactions on Communications、Vol。E99.B、Issue 5、pp。974-991、10.5815/ijcnis.2017.01.07、2016年5月、<https://doi.org/10.1587/transcom.2015ami0002>。
[NGMN] Robson, J., "Backhaul Provisioning for LTE-Advanced & Small Cells", Next Generation Mobile Networks, LTE-Advanced Transport Provisioning, Version 0.0.14, October 2015, <https://www.ngmn.org/wp-content/uploads/ Publications/2015/150929_NGMN_P-SmallCells_Backhaul_for_LTE-Advanced_and_Small_Cells.pdf>.
[Ngmn] Robson、J。、「LTE-Advanced＆Small Cellsのバックホールプロビジョニング」、Next Generation Mobile Networks、LTE-Advanced Transport Provisioning、バージョン0.0.14、2015年10月、<https://www.ngmn.org/wp-content/uploads/publications/2015/150929_ngmn_p-smallcells_backhaul_for_lte-advanced_and_small_cells.pdf>。
[NS3EPC] ns-3, "The EPC Model", July 2022, <https://www.nsnam.org/docs/models/html/lte-design.html#epc-model>.
[NS3EPC] NS-3、「EPCモデル」、2022年7月、<https://www.nsnam.org/docs/models/html/lte-design.html#epc-model>。
[NS3LTE] ns-3, "The LTE Model", July 2022, <https://www.nsnam.org/docs/models/html/lte-design.html#lte-model>.
[NS3LTE] NS-3、「LTEモデル」、2022年7月、<https://www.nsnam.org/docs/models/html/lte-design.html#lte-model>。
[OFFLOAD] Rebecchi, F., Dias de Amorim, M., Conan, V., Passarella, A., Bruno, R., and M. Conti, "Data Offloading Techniques in Cellular Networks: A Survey", IEEE Communications Surveys and Tutorials, Vol. 17, Issue 2, pp.580-603, DOI 10.1109/COMST.2014.2369742, November 2014, <https://ieeexplore.ieee.org/document/6953022>.
[オフロード] Rebecchi、F.、Dias de Amorim、M.、Conan、V.、Passarella、A.、Bruno、R.、およびM. Conti、「セルラーネットワークのデータオフロード技術：調査」、IEEE通信調査およびチュートリアル、Vol。17、第2号、pp.580-603、doi 10.1109/comst.2014.2369742、2014年11月、<https://ieeexplore.ieee.org/document/6953022>。
[OLTEANU] Olteanu, A. and P. Xiao, "Fragmentation and AES encryption overhead in very high-speed wireless LANs", Proceedings of the 2009 IEEE International Conference on Communications ICC'09, pp. 575-579, June 2009, <https://dl.acm.org/doi/10.5555/1817271.1817379>.
[Olteanu] Olteanu、A。and P. Xiao、「非常に高速ワイヤレスLANSでの断片化とAES暗号化オーバーヘッド」、2009年のIEEE Communications Communications ICC'09、pp。575-579、2009年6月、<<https://dl.acm.org/doi/10.5555/1817271.1817379>。
[Open5GCore] Open5GCore, "Open5GCore - 5G Core Network for Research, Testbeds and Trials", <https://www.open5gcore.org>.
[Open5GCore] Open5GCore、「Open5GCore -5G研究、テストベッド、トライアルのコアネットワーク」、<https://www.open5gcore.org>。
[QoS-ICN] Jangam, A., Ed., Suthar, P., and M. Stolic, "QoS Treatments in ICN using Disaggregated Name Components", Work in Progress, Internet-Draft, draft-anilj-icnrg-dnc-qos-icn-02, 9 March 2020, <https://datatracker.ietf.org/doc/html/draft-anilj-icnrg-dnc-qos-icn-02>.
[Qos-Icn] Jangam、A.、ed。、suthar、P。、およびM. Stolic、「分解した名前コンポーネントを使用したICNのQoS処理」、進行中の作業、インターネットドラフト、ドラフトアニルJ-ICNRG-DNC-QOS-ICN-02、2020年3月9日、<https://datatracker.ietf.org/doc/html/draft-anilj-icnrg-dnc-qos-icn-02>。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「Diffserv Service Classeの構成ガイドライン」、RFC 4594、DOI 10.17487/RFC4594、2006年8月、<https：//www.rfc-editor.org/info/rfc4594>。
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, <https://www.rfc-editor.org/info/rfc6459>.
[RFC6459] Korhonen、J.、Ed。、Soininen、J.、Patil、B.、Savolainen、T.、Bajko、G。、およびK. Iisakkila、「IPv6 in 3rd Generation Partnership Project（3GPP）Evolved Packet System（eps） "、rfc 6459、doi 10.17487/rfc6459、2012年1月、<https://www.rfc-editor.org/info/rfc6459>。
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, <https://www.rfc-editor.org/info/rfc7476>.
[RFC7476] Pentikousis、K.、Ed。、Ohlman、B.、Corujo、D.、Boggia、G.、Tyson、G.、Davies、E.、Molinaro、A。、およびS. Eum、 "Information-centricネットワーク：ベースラインシナリオ」、RFC 7476、DOI 10.17487/RFC7476、2015年3月、<https://www.rfc-editor.org/info/rfc7476>。
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.
[RFC7927] Kutscher、D.、Ed。、Eum、S.、Pentikousis、K.、Psaras、I.、Corujo、D.、Sauce、D.、Schmidt、T。、およびM. Waehlisch、「情報中心」ネットワーキング（ICN）研究課題」、RFC 7927、DOI 10.17487/RFC7927、2016年7月、<https://www.rfc-editor.org/info/rfc7927>。
[RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016, <https://www.rfc-editor.org/info/rfc7945>.
[RFC7945] Pentikousis、K.、Ed。、Ohlman、B.、Davies、E.、Spirou、S.、およびG. Boggia、「情報中心のネットワーキング：評価とセキュリティの考慮事項」、RFC 7945、DOI 10.17487/RFC79455、2016年9月、<https://www.rfc-editor.org/info/rfc7945>。
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.
[RFC8569] Mosko、M.、Solis、I。、およびC. Wood、「コンテンツ中心のネットワーキング（CCNX）セマンティクス」、RFC 8569、DOI 10.17487/RFC8569、2019年7月、<https：//www.rfc-editor.org/info/rfc8569>。
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.
[RFC8609] Mosko、M.、Solis、I。、およびC. Wood、「TLV形式のコンテンツ中心のネットワーキング（CCNX）メッセージ」、RFC 8609、DOI 10.17487/RFC8609、2019年7月、<https：// www。rfc-editor.org/info/rfc8609>。
[RFC9064] Oran, D., "Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols", RFC 9064, DOI 10.17487/RFC9064, June 2021, <https://www.rfc-editor.org/info/rfc9064>.
[RFC9064] Oran、D。、「CCNX様情報中心のネットワーキングプロトコルのQoSアーキテクチャの開発における考慮事項」、RFC 9064、DOI 10.17487/RFC9064、2021年6月、<https：//www.rfc-editor。org/info/rfc9064>。
[RFC9139] Gündoğan, C., Schmidt, T., Wählisch, M., Scherb, C., Marxer, C., and C. Tschudin, "Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)", RFC 9139, DOI 10.17487/RFC9139, November 2021, <https://www.rfc-editor.org/info/rfc9139>.
[RFC9139]Gündoğan、C.、Schmidt、T.、Wählisch、M.、Scherb、C.、Marxer、C.、およびC. Tschudin、「情報中心のネットワーキング（ICN）低電力のワイヤレス個人エリアネットワークへの適応（LowPans） "、RFC 9139、DOI 10.17487/RFC9139、2021年11月、<https://www.rfc-editor.org/info/rfc9139>。
[SDN5G] Page, J. and J. Dricot, "Software-defined networking for low-latency 5G core network", 2016 International Conference on Military Communications and Information Systems (ICMCIS), pp. 1-7, DOI 10.1109/ICMCIS.2016.7496561, May 2016, <https://ieeexplore.ieee.org/document/7496561>.
[SDN5G] Page、J。およびJ. Dricot、「低遅延5Gコアネットワークのソフトウェア定義ネットワーク」、2016年の軍事通信および情報システムに関する国際会議（ICMCIS）、pp。1-7、DOI 10.1109/ICMCIS。2016.7496561、2016年5月、<https://ieeexplore.ieee.org/document/7496561>。
[TLVCOMP] Mosko, M., "Header Compression for TLV-based Packets", ICNRG, Buenos Aires, IETF 95, April 2016, <https://datatracker.ietf.org/meeting/interim-2016-icnrg-02/materials/slides-interim-2016-icnrg-2-7>.
[TLVComp] Mosko、M。、「TLVベースのパケットのヘッダー圧縮」、ICNRG、Buenos Aires、IETF 95、2016年4月、<https://datatracker.ietf.org/meeting/interim-2016-icnrg-02/マテリアル/スライドInterim-2016-ICNRG-2-7>。
[TOURANI] Tourani, R., Misra, S., Mick, T., and G. Panwar, "Security, Privacy, and Access Control in Information-Centric Networking: A Survey", IEEE Communications Surveys and Tutorials, Vol. 20, Issue 1, pp. 566-600, DOI 10.1109/COMST.2017.2749508, September 2017, <https://ieeexplore.ieee.org/document/8027034>.
[Tourani] Tourani、R.、Misra、S.、Mick、T。、およびG. Panwar、「情報中心のネットワーキングにおけるセキュリティ、プライバシー、およびアクセス制御：調査」、IEEE通信調査およびチュートリアル、Vol。20、第1号、566-600ページ、DOI 10.1109/comst.2017.2749508、2017年9月、<https://ieeexplore.ieee.org/document/8027034>。
[TS23.203] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 17.2.0, December 2021, <https://www.3gpp.org/ftp/Specs/html-info/23203.htm>.
[TS23.203] 3GPP、「ポリシーおよび充電制御アーキテクチャ」、3GPP TS 23.203 17.2.0、2021年12月、<https://www.3gpp.org/ftp/specs/html-info/23203.htm>。
[TS23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 17.5.0, June 2022, <https://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
[TS23.401] 3GPP、「一般的なパケットラジオサービス（GPRS）進化した普遍的な陸生ラジオアクセスネットワーク（E-UTRAN）アクセスのための機能強化」、3GPP TS 23.401 17.5.0、<https：//www.3gpp。org/ftp/specs/html-info/23401.htm>。
[TS23.501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP TS 23.501 17.5.0, June 2022, <https://www.3gpp.org/ftp/Specs/html-info/23501.htm>.
[TS23.501] 3GPP、「5Gシステムのシステムアーキテクチャ（5GS）」、3GPP TS 23.501 17.5.0、2022年6月、<https://www.3gpp.org/ftp/specs/html-info/23501。htm>。
[TS23.714] 3GPP, "Study on Control Plane (CP) and User Plane (UP) separation of Evolved Packet Core (EPC) nodes", 3GPP TS 23.714 14.0.0, June 2016, <https://www.3gpp.org/ftp/Specs/html-info/23714.htm>.
[TS23.714] 3GPP、「進化したパケットコア（EPC）ノードのコントロールプレーン（CP）およびユーザープレーン（UP）分離に関する研究」、3GPP TS 23.714 14.0.0、2016年6月、<https：//www.3gpp.org/ftp/specs/html-info/23714.htm>。
[TS29.060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp interface", 3GPP TS 29.060 17.3.0, June 2022, <https://www.3gpp.org/ftp/Specs/html-info/29060.htm>.
[TS29.060] 3GPP、「一般的なパケットラジオサービス（GPRS）; GNおよびGPインターフェイス全体のGPRSトンネルプロトコル（GTP）、3GPP TS 29.060 17.3.0、2022年6月、<https://www.3gpp.org/ftp/specs/html-info/29060.htm>。
[TS29.336] 3GPP, "Home Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applications", 3GPP TS 29.336 17.13.1, March 2022, <https://www.3gpp.org/ftp/Specs/html-info/29336.htm>.
[TS29.336] 3GPP、「パケットデータネットワークとアプリケーションとのインターワーキングのためのホームサブスクライバーサーバー（HSS）直径インターフェイス」、3GPP TS 29.336 17.13.1、2022年3月、<https://www.3gpp.org/ftp/specss/html-info/29336.htm>。
[TS33.310] 3GPP, "Network Domain Security (NDS); Authentication Framework (AF)", 3GPP TS 33.310 17.3.0, June 2022, <https://www.3gpp.org/ftp/Specs/html-info/33310.htm>.
[TS33.310] 3GPP、「ネットワークドメインセキュリティ（NDS）;認証フレームワーク（AF）」、3GPP TS 33.310 17.3.0、2022年6月、<https://www.3gpp.org/ftp/specs/html-info/33310.htm>。
[TS33.320] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B (HeNB)", 3GPP TS 33.320 17.0.0, March 2022, <https://www.3gpp.org/ftp/Specs/html-info/33320.htm>.
[TS33.320] 3GPP、「ホームノードB（HNB）/ホーム進化ノードB（HENB）のセキュリティ」、3GPP TS 33.320 17.0.0、2022年3月、<https://www.3gpp.org/ftp/specs/html-info/33320.htm>。
Acknowledgements
謝辞
We thank all contributors, reviewers, and the chairs for their valuable time in providing comments and feedback that helped improve this document. We especially want to mention the following members of the IRTF Information-Centric Networking Research Group (ICNRG), listed in alphabetical order: Kashif Islam, Thomas Jagodits, Luca Muscariello, David R. Oran, Akbar Rahman, Martin J. Reed, Thomas C. Schmidt, and Randy Zhang.
この文書の改善に役立つコメントやフィードバックを提供する際に貴重な時間を提供してくれたすべての貢献者、レビュアー、椅子に感謝します。特に、アルファベット順にリストされているIRTF情報中心のネットワーキング研究グループ（ICNRG）の次のメンバーに言及したいと思います。。シュミット、ランディ・チャン。
The IRSG review was provided by Colin Perkins.
IRSGレビューはColin Perkinsによって提供されました。
Authors' Addresses
著者のアドレス
Prakash Suthar Google Inc. Mountain View, California 94043 United States of America Email: psuthar@google.com
Prakash Suthar Google Inc.マウンテンビュー、カリフォルニア94043アメリカ合衆国電子メール：psuthar@google.com
Milan Stolic Cisco Systems Inc. Naperville, Illinois 60540 United States of America Email: mistolic@cisco.com
Milan Stolic Cisco Systems Inc.イリノイ州ネーパービル60540アメリカ合衆国電子メール：mistolic@cisco.com
Anil Jangam (editor) Cisco Systems Inc. San Jose, California 95134 United States of America Email: anjangam@cisco.com
Anil Jangam（編集者）Cisco Systems Inc.カリフォルニア州サンノゼ95134アメリカ合衆国電子メール：anjangam@cisco.com
Dirk Trossen Huawei Technologies Riesstrasse 25 80992 Munich Germany Email: dirk.trossen@huawei.com
Dirk Trossen Huawei Technologies Riesstrasse 25 80992 Munich Germanyメール：dirk.trossen@huawei.com
Ravi Ravindran F5 Networks 3545 North First Street San Jose, California 95134 United States of America Email: r.ravindran@f5.com
Ravi Ravindran F5 Networks 3545 North First Street San Jose、California 95134アメリカ合衆国電子メール：r.ravindran@f5.com