Content for TR 29.820 Word version: 17.0.0
PFCP was first developed in Rel-14 to support CP and UP separation feature in EPC. From Rel-15 onwards PFCP has been reused for the interface between SMF and UPF (i.e. N4 interface) in 5GC. Open interoperability is one of the essential requirements of PFCP. Example scenarios requiring PFCP open interoperability can be:
Vertical market is one important use case of 5G, where UPF can be deployed locally on the customer side, while the SMF is centrally deployed on the operator side, therefore the interoperability between SMF and UPF is mandatory.
PDU session continuity when the UE moves between different SMF serving areas is supported by I-SMF and PFCP IEs are signalled over N16a, thus the interoperability regarding PFCP between the SMF and the I-SMF is mandatory.
This Technical Report aims to study the key issues which impact the interoperability of PFCP and potential solutions to resolve the issues.
The present document identifies the scenarios where the PFCP interoperability needs to be further enhanced for existing function and specifies the corresponding requirements, identifies the key issues which impact the PFCP interoperability, analyses potential solutions to address the key issues.
PFCP used in 4G (e.g. on Sxa, Sxb, Sxc interfaces) and 5G (e.g. on N4, N16a interfaces) are both within scope of the study.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
: "Vocabulary for 3GPP Specifications".
: "Architecture enhancements for control and user plane separation of EPC nodes; Stage 2".
: "Interface between the Control Plane and the User Plane Nodes; Stage 3".
: "Procedures for the 5G System; Stage 2".
: "System architecture for the 5G System (5GS); Stage 2".
Layer Two Tunneling Protocol "L2TP"
Layer Two Tunneling Protocol - Version 3 (L2TPv3)
Remote Authentication Dial In User Service (RADIUS)
RADIUS Attributes for Tunnel Protocol Support
: "Network Domain Security (NDS); IP network layer security"
: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3".
Datagram Transport Layer Security Version 1.2
: "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)"
: "5G System; Interworking between 5G Network and external Data Networks; Stage 3"
Diameter Network Access Server Application
The Transport Layer Security (TLS) Protocol Version 1.2
The Transport Layer Security (TLS) Protocol Version 1.3
For the purposes of the present document, the terms given in TR 21.905
and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905
A node with a Control Plane function (see TS 23.214
and TS 23.502
) supporting one or more PFCP entities. A Control Plane function, i.e. a Control Plane Node, is identified by the Node ID, that is set to either an FQDN or an IP address.
A node with a User Plane function (see TS 23.214
and TS 23.502
) supporting one or more PFCP entities. A User Plane function, i.e. a User Plane Node, is identified by the Node ID, that is set to either a FQDN or an IP address.
For the purposes of the present document, the following symbols apply:
For the purposes of the present document, the abbreviations given in TR 21.905
and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905
Packet Forwarding Control Protocol
Session Management Function
User Plane Function
Besides the scenarios addressed by TS 23.214
and TS 29.244
, the study shall especially take following scenarios into account:
Scenario#1: multiple UP functions are controlled by one CP function, where the UP functions are from different vendors.
Scenario#2: one UP function is controlled by multiple CP functions, where the CP functions are from different vendors.
Scenario#3: multiple UP functions are controlled by a set of CP functions, where the UP functions are from different vendors and the CP functions are from same vendor.
Scenario#4: multiple UP functions are controlled by a set of CP functions, where the UP functions are shared by several network slices.
Scenario#5: the UP function(s) are deployed on the customer side while the CP function(s) are deployed on the operator side.
Scenario#6: CP function and UP function are implemented/developed as virtualized/container based NF.
The following requirements shall be considered during the study:
Requirement#1: the study shall try to avoid multiple options which may cause interoperability issues.
Requirement#2: the study shall identify the potential issues when the UP functions are deployed on the customer side and determine if specific extensions are required to address them.
Requirement#3: the study may consider protocol extensions for the widely used features that are not supported by PFCP, provided the corresponding stage 2 requirements are defined, or they do not require stage 2 requirements.
Requirement#4: For use cases where multiple CP functions not part of an NF set are considered, proposals shall take into account that each CP function may not support the same functionality.
Requirement#5: For use cases where multiple UP functions are considered, proposals shall take into account that each UP function may not support the same functionality.