7.2 Message Format
29.2443GPPInterface between the Control Plane and the User Plane nodesRelease 17TS
7.2.1 General
The format of a PFCP message is depicted in Figure 7.2.1-1.
|
Bits |
||||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
|
1 to m |
PFCP message header |
|||||||||
|
m+1 to n |
Zero or more Information Element(s) |
|||||||||
Figure 7.2.1-1: PFCP Message Format
A PFCP message shall contain the PFCP message header and may contain subsequent information element(s) dependent on the type of message.
7.2.1A PFCP messages bundled in one UDP/IP packet
When applying PFCP messages bundling (see clause 6.5), PFCP messages shall be bundled in one UDP/IP packet as depicted in Figure 7.2.1A-1.
|
Bits |
||||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
|
1 to m |
PFCP message 1 header |
|||||||||
|
m+1 to n |
Zero or more Information Element(s) |
|||||||||
|
n+1 to p |
PFCP message 2 header |
|||||||||
|
p+1 to q |
Zero or more Information Element(s) |
|||||||||
|
… |
… |
|||||||||
|
… |
… |
|||||||||
|
r to s |
PFCP message N header |
|||||||||
|
s+1 to u |
Zero or more Information Element(s) |
|||||||||
Figure 7.2.1A-1: PFCP messages bundled in one UDP/IP packet
Each bundled PFCP message shall contain its PFCP message header and may contain subsequent information element(s) dependent on the type of message.
The FO" (Follow On) flag in the PFCP message header of each PFCP message bundled in the UDP/IP packet, except the last PFCP message, shall be set to "1" to indicate that another PFCP message follows in the UDP/IP packet. See clause 7.2.2.
7.2.2 Message Header
7.2.2.1 General Format
PFCP messages use a variable length header. The message header length shall be a multiple of 4 octets. Figure 7.2.2.1-1 illustrates the format of the PFCP Header.
|
Bits |
|||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
|
1 |
Version |
Spare |
Spare |
FO |
MP |
S |
|||
|
2 |
Message Type |
||||||||
|
3 |
Message Length (1st Octet) |
||||||||
|
4 |
Message Length (2nd Octet) |
||||||||
|
m to k(m+7) |
If S flag is set to "1", then SEID shall be placed into octets 5-12. Otherwise, SEID field is not present at all. |
||||||||
|
n to (n+2) |
Sequence Number |
||||||||
|
(n+3) |
Spare |
||||||||
Figure 7.2.2.1-1: General format of PFCP Header
Where:
– if S = 0, SEID field is not present, k = 0, m = 0 and n = 5;
– if S = 1, SEID field is present, k = 1, m = 5 and n = 13.
The usage of the PFCP header is defined in clause 7.2.2.4.
Octet 1 bits shall be encoded as follows:
– Bit 1 represents the SEID flag (T).
– Bit 2 represents the "MP" flag (see clause 7.2.2.4.1).
– Bit 3 represents the "FO" flag (see clause 7.2.2.4.1).
– Bit 4 to 5 are spare, the sender shall set them to "0" and the receiving entity shall ignore them.
– Bits 6-8 represent the Version field.
7.2.2.2 PFCP Header for Node Related Messages
The PFCP message header for the node related messages shall not contain the SEID field, but shall contain the Sequence Number field, followed by one spare octet as depicted in figure 7.2.2.2-1. The spare bits shall be set to zero by the sender and ignored by the receiver. For the Version Not Supported Response message, the Sequence Number may be set to any number and shall be ignored by the receiver.
|
Bits |
|||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
|
1 |
Version |
Spare |
Spare |
FO=0 |
MP=0 |
S=0 |
|||
|
2 |
Message Type |
||||||||
|
3 |
Message Length (1st Octet) |
||||||||
|
4 |
Message Length (2nd Octet) |
||||||||
|
5 |
Sequence Number (1st Octet) |
||||||||
|
6 |
Sequence Number (2nd Octet) |
||||||||
|
7 |
Sequence Number (3rd Octet) |
||||||||
|
8 |
Spare |
||||||||
Figure 7.2.2.2-1: PFCP Message Header for node related messages
7.2.2.3 PFCP Header for Session Related Messages
The PFCP message header, for session related messages, shall contain the SEID and Sequence Number fields followed by one spare octet. The PFCP header is depicted in figure 7.2.2.3-1. The spare bits shall be set to zero by the sender and ignored by the receiver.
|
Bits |
|||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
|
1 |
Version |
Spare |
Spare |
FO |
MP |
S=1 |
|||
|
2 |
Message Type |
||||||||
|
3 |
Message Length (1st Octet) |
||||||||
|
4 |
Message Length (2nd Octet) |
||||||||
|
5 |
Session Endpoint Identifier (1st Octet) |
||||||||
|
6 |
Session Endpoint Identifier (2nd Octet) |
||||||||
|
7 |
Session Endpoint Identifier (3rd Octet) |
||||||||
|
8 |
Session Endpoint Identifier (4th Octet) |
||||||||
|
9 |
Session Endpoint Identifier (5th Octet) |
||||||||
|
10 |
Session Endpoint Identifier (6th Octet) |
||||||||
|
11 |
Session Endpoint Identifier (7th Octet) |
||||||||
|
12 |
Session Endpoint Identifier (8th Octet) |
||||||||
|
13 |
Sequence Number (1st Octet) |
||||||||
|
14 |
Sequence Number (2nd Octet) |
||||||||
|
15 |
Sequence Number (3rd Octet) |
||||||||
|
16 |
Message Priority |
Spare |
|||||||
Figure 7.2.2.3-1: PFCP message Header for session related messages
7.2.2.4 Usage of the PFCP Header
7.2.2.4.1 General
The format of the PFCP header is specified in clause 7.2.2.
The usage of the PFCP header shall be as defined below.
The first octet of the header shall be used is the following way:
– Bit 1 represents the "S" flag, which indicates if SEID field is present in the PFCP header or not. If the "S" flag is set to "0", then the SEID field shall not be present in the PFCP header. If the "S" flag is set to "1", then the SEID field shall immediately follow the Length field, in octets 5 to 12. Apart from the node related messages, in all PFCP messages the value of the "S" flag shall be set to "1".
– Bit 2 represents the "MP" flag. If the "MP" flag is set to "1", then bits 8 to 5 of octet 16 shall indicate the relative priority of the PFCP message. It shall be encoded as the binary value of the Message Priority and it may take any value between 0 and 15, where 0 corresponds to the highest priority and 15 the lowest priority.
– Bit 3 represents the "FO" (Follow On) flag. If the "FO" flag is set to "1", then another PFCP message follows in the UDP/IP packet (see clauses 6.5 and 7.2.1A).
– Bit 4 is a spare bit. The sending entity shall set it to "0" and the receiving entity shall ignore it.
– Bit 5 is a spare bit. The sending entity shall set it to "0" and the receiving entity shall ignore it.
– Bits 6 to 8, which represent the PFCP version, shall be set to decimal 1 ("001").
The usage of the fields in octets 2 – n of the header shall be as specified below.
– Octet 2 represents the Message type field, which shall be set to the unique value for each type of control plane message. Message type values are specified in Table 7.3-1 "Message types".
– Octets 3 to 4 represent the Message Length field. This field shall indicate the length of the message in octets excluding the mandatory part of the PFCP header (the first 4 octets). The SEID (if present) and the Sequence Number shall be included in the length count. The format of the Length field of information elements is specified in clause 8.2 "Information Element Format".
– When S=1, Octets 5 to 12 represent the Session Endpoint Identifier (SEID) field. This field shall unambiguously identify a session endpoint in the receiving Packet Forward Control entity. The Session Endpoint Identifier is set by the sending entity in the PFCP header of all control plane messages to the SEID value provided by the corresponding receiving entity (CP or UP function). If a peer’s SEID is not available the SEID field shall be present in a PFCP header, but its value shall be set to "0", "Conditions for sending SEID=0 in PFCP header".
NOTE: The SEID in the PFCP header of a message is set to the SEID value provided by the corresponding receiving entity regardless of whether the source IP address of the request message and the IP Destination Address provided by the receiving entity for subsequent request messages are the same or not.
– Octets 13 to 15 represent PFCP Sequence Number field.
7.2.2.4.2 Conditions for Sending SEID=0 in PFCP Header
If a peer’s SEID is not available, the SEID field shall still be present in the header and its value shall be set to "0" in the following messages:
– PFCP Session Establishment Request message on Sxa/Sxb/Sxc/N4;
– If a node receives a message for which it has no session, i.e. if SEID in the PFCP header is not known, it shall respond with "Session context not found" cause in the corresponding response message to the sender, the SEID used in the PFCP header in the response message shall be then set to "0";
– If a node receives a request message containing protocol error, e.g. Mandatory IE missing, which requires the receiver to reject the message as specified in clause 7.6, it shall reject the request message. For the response message, the node should look up the remote peer’s SEID and accordingly set SEID in the PFCP header and the message cause code. As an implementation option, the node may not look up the remote peer’s SEID and set the PFCP header SEID to "0" in the response message. However in this case, the cause value shall not be set to "Session not found".
– When the UP function sends PFCP Session Report Request message over N4 towards another SMF or another PFCP entity in the SMF as specified in clause 5.22.2 and clause 5.22.3.
7.2.3 Information Elements
7.2.3.1 General
The format of PFCP Information Elements are defined in clause 8.2.
7.2.3.2 Presence Requirements of Information Elements
IEs within PFCP messages shall be specified with one of the following presence requirement:
– Mandatory: this means that the IE shall be included by the sending entity, and that the receiver diagnoses a "Mandatory IE missing" error when detecting that the IE is not present. A response including a "Mandatory IE missing" cause, shall include the type of the missing IE.
– Conditional: this means that:
– the IE shall be included by sending entity if the conditions specified are met;
– the receiver shall check the conditions as specified in the corresponding message type description, based on the parameter combination in the message and/or on the state of the receiving node, to infer if a conditional IE shall be expected. Only if a receiver has sufficient information, if a conditional IE, which is necessary for the receiving entity to complete the procedure, is missing, then the receiver shall abort the procedure.
– Conditional-Optional: this means that:
– the IE shall be included by a sending entity complying with the version of the specification, if the conditions specified in the relevant protocol specification are met. An entity, which is at an earlier version of the protocol and therefore is not up-to-date, cannot send this IE;
– the receiver need not check the presence of the IE in the message. If the receiver checks the presence of the Conditional-Optional IE, then the IE’s absence shall not trigger any of the error handling procedures. The handling of an absence or erroneous such IEs shall be treated as Optional IEs as specified in clause 7.6.
– Optional: this means that:
– the IE shall be included as a service option. Therefore, the IE may be included or not in a message. The handling of an absent optional IE, or an erroneous optional IE is specified in clause 7.6.
For conditional IEs, the clause describing the PFCP message explicitly defines the conditions under which the inclusion of each IE becomes mandatory or optional for that particular message. These conditions shall be defined so that the presence of a conditional IE only becomes mandatory if it is critical for the receiving entity. The definition might reference other protocol specifications for final terms used as part of the condition.
For grouped IEs, the presence requirement of the embedded IE shall follow the rules:
– If the grouped IE is Mandatory within a given message: the presence requirements of individual embedded IEs are as stated within the Mandatory grouped IE for the given message;
– if the grouped IE is Conditional within a given message: if the embedded IE in the grouped IE is Mandatory or Conditional, this embedded IE is viewed as Conditional IE by the receiver. If the embedded IE in the grouped IE is Conditional-Optional, this embedded IE is viewed as Optional IE by the receiver. If the embedded IE in the grouped IE is Optional, this embedded IE is viewed as Optional IE by the receiver;
– if the grouped IE is Conditional-Optional within a given message: if the embedded IE in the grouped IE is Mandatory or Conditional, this embedded IE is viewed as Conditional-Optional IE by the receiver. If the embedded IE in the grouped IE is Conditional-Optional, this embedded IE is viewed as Optional IE by the receiver. If the embedded IE in the grouped IE is Optional, this embedded IE is viewed as Optional IE by the receiver;
– if the grouped IE is Optional within a given message: all embedded IEs in the grouped IE are viewed as Optional IEs by the receiver.
In all of the above cases, appropriate error handling as described in clause 7.6 shall be applied for protocol errors of the embedded IEs.
Only the Cause IE at message level shall be included in the response if the Cause contains a value that indicates that the request is not accepted, regardless of whether there are other mandatory or conditional IEs defined for a given response message. The following are exceptions:
– the Node ID and Offending IE shall be included as per the requirements specified for the corresponding response message;
– the Load Control Information, Overload Control Information and the Failed Rule ID IEs may be included in a PFCP session related message.
If the Cause IE at Grouped IE level contains a value that indicates that the Grouped IE is not handled correctly, the other IEs in this Grouped IE, other than the Cause IE, may not be included.
7.2.3.3 Grouped Information Elements
A Grouped IE is an IE which may contain other IEs.
Grouped IEs have a length value in the TLV encoding, which includes the added length of all the embedded IEs. Overall coding of a grouped IE with 4 octets long IE header is defined in clause 8.2. Each IE within a grouped IE also shall also contain 4 octets long IE header.
Grouped IEs are not marked by any flag or limited to a specific range of IE type values. The clause describing an IE in this specification shall explicitly state if it is a Grouped IE.
NOTE: Each entry into each Grouped IE creates a new scope level. Exit from the grouped IE closes the scope level. The PFCP message level is the top most scope.
If more than one grouped IEs of the same type, but for a different purpose are sent within the same message level, these IEs shall have different IE types.
If more than one grouped IEs of the same type and for the same purpose are sent within the same message level, these IEs shall have exactly the same IE type to represent a list.
Assigning the same IE type to grouped IEs which don’t have the same content is not recommended, even if these grouped IEs are in different message levels.
7.2.3.4 Information Element Type
An IE in a PFCP message or Grouped IE is identified by its IE Type and described by a specific row in the corresponding tables in clause 7.
If several IEs with the same Type are included in a PFCP message or Grouped IE, they represent a list for the corresponding IE name.
An IE Type value uniquely identifies a specific IE.
One IE type value is specified for Vendor Specific IEs.