ETSI GS NGP 005 V1.1.1 (2017-04)

Next Generation Protocol (NGP); Next Generation Protocol Requirements

DGS/NGP-005

General Information

• Status: Published
• Publication Date: 27-Apr-2017
• Technical Committee: NGP - Next Generation Protocols
• Current Stage: 12 - Completion
• Due Date: 02-May-2017
• Completion Date: 28-Apr-2017

Standards Content (Sample)

ETSI GS NGP 005 V1.1.1 (2017-04)






GROUP SPECIFICATION
Next Generation Protocols (NGP);
Next Generation Protocol Requirements
Disclaimer
The present document has been produced and approved by the Next Generation Protocols (NGP) ETSI Industry Specification
Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

---------------------- Page: 1 ----------------------
2 ETSI GS NGP 005 V1.1.1 (2017-04)



Reference
DGS/NGP-005
Keywords
core network, cyber security, IoT, mobility,
network, QoE, reliability, security, service, use
case

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2017.
All rights reserved.

TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI GS NGP 005 V1.1.1 (2017-04)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 6
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Overview . 7
5 General Requirements . 7
5.1 Business Case . 7
5.2 Migration . 8
5.3 Technical . 8
6 Issue Specific Requirements . 9
6.1 Addressing . 9
6.2 Security . 10
6.3 Mobility . 12
6.4 Multi-Access Support, (including FMC) . 13
6.5 Context Awareness . 14
6.6 Performance (including Content Enablement) . 16
6.7 Network Virtualisation . 17
6.8 IoT Support . 18
6.9 Energy Efficiency . 18
6.10 MEC . 19
6.11 Mission Critical Services . 19
6.12 Drones and Autonomous Vehicles and Connected Vehicles . 20
6.13 Ultra Reliable Low Latency Communications . 20
Annex A (informative): Authors & contributors . 21
History . 22


ETSI

---------------------- Page: 3 ----------------------
4 ETSI GS NGP 005 V1.1.1 (2017-04)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Next Generation
Protocols (NGP).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI

---------------------- Page: 4 ----------------------
5 ETSI GS NGP 005 V1.1.1 (2017-04)
1 Scope
The scope of the present document is to specify the minimum set of key requirements for the Next Generation Protocols
(NGP), Industry Specific Group (ISG).
The present document addresses requirements in the following areas:
• Business Case and Techno-Economics
• Migration
• General Technical Requirements
• Addressing
• Security
• Mobility
• Multi-Access Support (including FMC)
• Context Awareness
• Performance (including Content Enablement)
• Network Virtualisation
• IoT Support
• Energy Efficiency
• e-Commerce
• MEC
• Mission Critical Services
• Drones and Autonomous Vehicles and Connected Vehicles
• Ultra Reliable Low Latency Communications
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS NGP 001: "Next Generation Protocol (NGP); Scenario Definitions".
NOTE: ETSI NGP references are available at http://www.etsi.org/deliver/etsi_gs/NGP/.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI GS NGP 005 V1.1.1 (2017-04)
[2] ETSI TS 122 280: "Technical Specification Group Services and System Aspects; Mission Critical
Services Common Requirements (MCCoRe); Stage 1".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] 3GPP TR 23.799: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Study on Architecture for Next Generation System".
[i.2] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; Vocabulary for 3GPP Specifications (3GPP
TR 21.905)".
[i.3] 3GPP TR 22.862: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Feasibility Study on New Services and Markets Technology Enablers for
Critical Communications; Stage 1".
NOTE: ETSI standards are available at http://www.etsi.org/standards.
[i.4] Recommendation ITU-R M.2083-0: "Framework and overall objectives of the future development
of IMT for 2020 and beyond".
[i.5] ETSI GS NFV 001: "Network Functions Virtualisation (NFV); Use Cases".
[i.6] 3GPP TR 37.868: "3rd Generation Partnership Project; Technical Specification Group Radio
Access Network; Study on RAN Improvements for Machine-type Communications".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions applying to scenarios that include mobile network
architectures given in ETSI GS NGP 001 [1], ETSI TR 121 905 [i.2] and 3GPP TR 23.799 [i.1] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS NGP 001 [1], ETSI TR 121 905 [i.2] and
the following apply.
AN Access Network
FPGA Field Programmable Gate Array
GGC General Group Communications
IC Integrated Circuit
IOC Information Object Class
LTE Long Term Evolution
NOTE: Cellular standard.
MCS Mission Critical Services
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GS NGP 005 V1.1.1 (2017-04)
MEC Mobile Edge Computing
NOTE: ETSI, ISG specified.
MPS Multimedia Priority Service
NFV Network Function Virtualisation
NGP Next Generation Protocol
NG-UE Next Generation User Equipment
NOTE: Beyond LTE.
NIC Network Interface Card
PGW PDN Gateway
NOTE: In LTE system.
SDN Software Defined Networking
SGSDS Smart Grid System with Distributed Sensors
SGW Serving Gateway
NOTE: In LTE system.
SPC Substation Protection and Control
TFT Traffic Flow Template
NOTE: E.g. as defined for 3GPP LTE.
UE User Equipment for LTE
URLLC Ultra Reliable Low Latency Communications
VM Virtual Machine
4 Overview
The Next Generation Protocols (NGP), ISG aims to review the future landscape of Internet Protocols, identify and
document future requirements and trigger follow up activities to drive a vision of a considerably more efficient Internet
that is far more attentive to user demand and more responsive whether towards humans, machines or things.
ETSI GS NGP 001 [1], Scenarios Descriptions specification, lists the key agreed networking and internetworking issues
for multi-access communications at present and provides examples of current scenarios where these issues are
exemplified. ETSI GS NGP 001 [1] further provides recommendations, on a per issue basis, targeted at applicable next
generation SDOs: ITU-T, IEEE, IETF and 3GPP in their consideration of future networking and internetworking
protocol architecture definitions.
The present document progresses the requirements decomposition process one further stage to define key requirements
for NGP.
The present document provides key general NGP requirements, in clause 5 and NGP issue specific requirements, in
clause 6.
5 General Requirements
5.1 Business Case
[Gen-BC-01] The NGP architecture shall be 25 % more energy efficient across end-user devices, servers, fixed
transmission and access technologies and wireless and/or cellular access technologies as compared
to existing IPv4/v6 protocol based architectures.
NOTE 1: This performance measure should be based on network wide measurements and devices connecting with
reference access technologies current at the time of specification as follows: LTE-A, Rel-12, Wi-Fi™
802.11ac and Ethernet 100 Mbit/s FE.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GS NGP 005 V1.1.1 (2017-04)
[Gen-BC-02] The NGP architecture shall be 30 % more spectrally efficient when transporting NGP across the
access technology as compared to transporting existing IPv4/v6 protocol based architectures and
considering all over-air impacting facets.
[Gen-BC-03] The NGP architecture shall be at least 25 % more header efficient than existing IPv4/v6 protocol
based architectures.
[Gen-BC-04] The NGP architecture shall be at least 10 % more bitwise efficient per packet than existing
IPv4/v6 protocol based architectures for the same application transport.
NOTE 2: The scope of Gen-BC-02x requirements is from the UE or NG-UE to the edge of Operator Domain
connecting to the Internet or other external PDN.
NOTE 3: Gen-BC-02(x) performance measures should be based on reference radio-based access technologies
current at the time of specification as follows: LTE-A, Rel-12, Wi-Fi™ 802.11ac.
[Gen-BC-05] The NGP architecture shall be able to be cost effectively implemented into existing user device
operating systems with no additional processor or memory requirements, as compared to IPv4/6
implementations.
® ®
NOTE 4: Current key user device, operating systems should include Android™, iOS and Windows .
[Gen-BC-06] The NGP architecture shall be able to be cost effectively implemented into existing user server
operating systems with no additional processor or memory requirements, as compared to IPv4/6
implementations.
NOTE 5: Current key server operating systems should include Linux® variants and Windows®.
[Gen-BC-07] The NGP architecture shall be able to be cost effectively implemented into network interface
software and hardware, with no additional processor or memory requirements. as compared to
IPV4/6 implementations.
NOTE 6: Current implementations should include: Custom Integrated Circuits (IC), Field Programmable Gate
Array (FPGA) technology solutions and software defined, Network Interface Cards (NIC).
5.2 Migration
[Gen-Mig-01] The NGP architecture shall be able to provide peer to peer communications between a next
generation access communications device and the edge of that access network or networks with no
increase in setup delay as compared to existing IPv4/v6 protocol based architectures, for the issues
described in ETSI ETSI ETSI GS NFV 001 [i.5] and when operating over LTE-A, Rel-12 access
technology.
NOTE 1: An access communications device may include an evolved 3GPP UE, server or IoT device and the access
network may include millimetric radio, cellular, wireless and/or fixed connectivity.
NOTE 2: Access efficiency in this context may be: spectrum efficiency, bitwise efficiency, or byte efficiency of the
protocol.
[Gen-Mig-02] The NGP architecture shall be able to interwork to the existing IPv4 and IPv6 protocol.
[Gen-Mig-03] The NGP architecture shall be able to support transmission of the 3GPP TR 23.799 [i.1] defined
interfaces: NG1, NG2, NG3 NG4 and NG6, interfaces at layer 3.
5.3 Technical
[Gen-Tech-01] NGP shall support multi-level mutual authentication between peers.
NOTE 1: Authentication is operated between peer entities.
NOTE 2. Authentication among applications only involves the applications, not NGP.
NOTE 3: Authentication within NGP is among the entities supporting NGP itself.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GS NGP 005 V1.1.1 (2017-04)
NOTE 4: NGP should require the authentication of all members of a given layer.
[Gen-Tech-02] NGP shall not allow third parties (other than those authorized by law, such as national security
agencies) to discover the identity of entities that are communicating with each other.
[Gen-Tech-03] NGP shall provide stakeholder based confidentiality for user data.
[Gen-Tech-04] NGP shall provide stakeholder based confidentiality for protocol control.
NOTE 5: For Gen-Tech-03x: A stakeholder would typically include N x communicating peers.
NOTE 6: For Gen-Tech-03x: A stakeholder agreement could optionally include an N+1 party as well as the peers
(e.g. Operator and/or Lawful Intercept party.
6 Issue Specific Requirements
6.1 Addressing
[Iss-Addr-01] In a multi-access and multi-layer, context aware NGP environment future protocols should address
ID and Addressing aspects separately.
NOTE 1: For example Network Communications Protocol Address, Usage IDs, Session/Service-IDs and
Application Naming are distinctly operated.
[Iss-Addr-02] Application-ID shall not change during mobility and multi-homing link state changes.
NOTE 2: This requirement is essential in order to maintain application instances during mobility.
NOTE 3: See NGP definition of 'Application Process' and 'Identity' in ETSI GS NGP 001[1].
[Iss-Addr-03] NGP should minimize addressing updates in future protocols for mobility and multi-homing.
During mobility events, addressing may change but should be minimized.
[Iss-Addr-04] NGP addressing should support at least the following communication models: client-client,
client-server (push and/or pull) and server-server models and multi-protocol versions thereof.
[Iss-Addr-05] NGP should be designed to minimize multi-address mappings.
NOTE 4: For example the inefficiencies associated with extensive use of NAT today including: NFV
implementations, Device-to-Device capabilities (D2D), etc.
[Iss-Addr-06] NGP shall minimize the use of "well-known" ports.
[Iss-Addr-07] NGP shall include an addressing strategy that scales.
NOTE 5: This means that an addressing scheme that includes every entity on the planet does not need to include the
full address length in the packet header all of the time for local communication, but has to accommodate
the case for an entity to address another entity on the other side of the world when required.
Table 1 captures a set of KPIs that can be used to compare the merits of different addressing schemes.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI GS NGP 005 V1.1.1 (2017-04)
Table 1: KPIs for Assessment of Addressing Requirements
KPI Name Description Related to Measured feature Units Example Values
requirements for IPv4 (CIDR)
Scalability of Measures how many different [Iss-Addr-07] Address space size Integer value 2^32
address space entities can be uniquely
addressed
[Iss-Addr-07]
Address Measures how many bits on Header overhead Integer value Always 32
encoding the wire are required to due to addressing
efficiency encode the address
information
Aggregation Measures how well address [Iss-Addr-07] Size of forwarding Order of Up to 32 levels of
capabilities assignment follows the tables in routers as magnitude addressing
underlying "network topology" a function of O(f(x)), where x hierarchy.
in order to facilitate addressed entities is # of addressed Forwarding
aggregation in the network entities efficiency
depends on
allocation policy
Identity Checks if applications can be [Iss-Addr-01] Application identity Binary value False
[Iss-Addr-02]
decoupled from assigned independent separated from
addressing identifiers which are loosely network addressing
coupled to network addresses
(via directories/mapping
systems).
Cost of mobility Measures the overhead of [Iss-Addr-03] Extra entries in Order of Depends on
supporting mobility as the forwarding tables magnitude mobility
extra state required in the per mobility event O(f(x)), where x management
network due to mobility is # of mobility protocol in use,
events events usually requires
setup of tunnels
per mobility event

6.2 Security
[Iss-Sec-01] NGP should decouple data transfer and layer management (also known as control plane) protocols
from security functions (authentication, key agreement, access control, integrity verification,
encryption) except where this would defeat other NGP security requirements. NGP should provide
clear integration points for each type of security function.
NOTE 1: It is anticipated that the decoupling described in Iss-Sec-01 will facilitate rather than defeat most other
security requirements.
[Iss-Sec-02] NGP shall adopt data transfer protocols that decouple port-id from connection-endpoint-id.
[Iss-Sec-03] NGP shall not use well-known ports.
[Iss-Sec-04] Applications should protect the confidentiality and integrity of their communication.
NOTE 2: Most security experts agree that the best encryption architecture should operate between peer
applications.
NOTE 3: Operating peer application encryption greatly reduces the security problem for the network to primarily
authenticating members of some layers, and protecting against traffic analysis at higher communication
layers.
[Iss-Sec-05] Each protocol layer should offer an API that allows the layer above to request the properties of the
network service it wants (bound on packet loss and delay, in-order delivery of data, etc.).
NOTE 4: NGP assumes that each layer and/ or the protocols in each layer should take the necessary security
measures to protect their data without relying on the lower layer.
NOTE 5: This is to avoid making network service requirements implicit (as today) and having the network layers
have to do DPI or similar to infer application requirements (which becomes very hard or infeasible if the
application uses end-to-end encryption).
ETSI

---------------------- Page: 10 ----------------------
11 ETSI GS NGP 005 V1.1.1 (2017-04)
[Iss-Sec-06] Protocol layers should have good layer management and administration that provides the statistics
needed for security.
NOTE 6: It is important to use different Information Object Classes (IOC) for different protocols.
NOTE 7: NGP needs a control structure that enables a layer to select different IoCs to be presented per layer.
[Iss-Sec-07] NGP should provide Optimization meta-data that enables both of the following options for
delivery outside of the secure user data transport part of each packet:
a) Can be based on a 'pull' meta-data system.
b) Can be provided as a separate Meta-Data mechanism for which entities can offer
information to, 'push' meta-data.
NOTE 8: The Optimisation Meta-Data capability is a mechanism required for NGP that is specifically designed for
shipping context information around for an operator or user to optimize their user QoE or Network
performance outside of user data security mechanisms.
NOTE 9: It is acknowledged that 'pull' mechanisms are simple to realise but may be slow to respond, which is why
a 'push' mechanism is included as well.
NOTE 10: Despite the Optimization Meta-Data scheme being outside the User Data Payload security mechanisms, it
may optionally have its own dedicated security mechanism.
[Iss-Sec-08] Coordination of meta-data across virtualised components in "network slices" should be supported
by NGP to meet the goal of information being available where needed and only where needed.
NOTE 11: Next Generation solutions will be operating over heterogeneous networks and with varying network
requirements. This creates a drive towards building network functions as slices, created out of a number
of sub-components or sub-functions.
[Iss-Sec-09] Security monitoring should be a built-in part of NGP.
NOTE 12: Security assessments and standards often include references to security monitoring (frequent checking on
security-related/impacting functions).
[Iss-Sec-10] NGPs shall support situations where location meta-data is a part of network audit or where it is
required to be delivered for business purposes.
NOTE 13: To operate these audit cases, NGP functional implementations should be able to make a clear assessment
of the situations where location meta-data needs to be propagated and where it should remain private or
be obscured.
NOTE 14: Location based data can contain considerable personal or sensitive information. Location based
information should not be transferred or made available without a proper assessment of the privacy
implications.
[Iss-Sec-11] NGP should support an Identity Service mechanism.
NOTE 15: Currently there are identity security vulnerabilities in IPv4/6.
NOTE 16: An NGP Identity Service should include identity logging/checking/validation and ongoing management.
NOTE 17: Consideration is needed for NGP in the setup of ID servers for Users operating NGP and/or Resource
Registration (RR) for logical entities operating NGP.
NOTE 18: Examples of ID based entities include ID servers for entities such as VNFs from the NFV space, or a
register of Certified IoT devices or IoT Gateways.
[Iss-Sec-12] IoT Gateways shall be investigated as part of the secure Identity services provided in NGP.
NOTE 19: As latency requirements get tighter, the pressure for edge-based decision-making will increase.
NOTE 20: Gateways can have an important role in facilitating secure edge-based computing, potentially enabling
better security and/or more effective use of meta-data.
ETSI

---------------------- Page: 11 ----------------------
12 ETSI GS NGP 005 V1.1.1 (2017-04)
[Iss-Sec-13] The NGP ID Service mechanism(s), should add Identity security but not be prohibitively
expensive, be scalable and provide failsafe mechanisms according to potential threat level and
scope.
NOTE 21: NGP needs to address a range of scalable ID capabilities and recommend according failsafe mechanisms
per threat level.
NOTE 22: There is a balance of security versus cost and complexity to be considered in satisfying this
recommendation, so it is recommended that the NGP evolves to scalable security and ID system where
cheap and large scale edge devices have some level of ID check.
[Iss-Sec-14] Efficient extensions for MANO and SDN controller protocols should be provided to administer
them across Tenant and Multi-Tenant environments in a secure manner including the following
security mechanisms:
a) mandatory two-way authentication by traceable ID;
b)
...