<?xml version="1.0" encoding="US-ASCII"?>


<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ 
<!-- One method to get references from the online citation libraries. 
     There has to be one entity for each item to be referenced.  
     An alternate method (rfc include) is described in the references.
-->

<!ENTITY RFC2460 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC4861 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC6437 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6437.xml">
<!ENTITY RFC6438 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6438.xml">
<!ENTITY RFC6935 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6935.xml">
<!ENTITY RFC8200 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8200.xml">
<!-- <!ENTITY I-D.bogineni-dmm-optimized-mobile-user-plane SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bogineni-dmm-optimized-mobile-user-plane.xml">
-->
<!ENTITY RFC4364 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4664 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4664.xml">
<!ENTITY RFC8402 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml">
<!ENTITY RFC7157 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7157.xml">

]> 
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> 
<!-- used by XSLT processors --> 
<!-- For a complete list and description of processing instructions (PIs),  
      please see http://xml.resource.org/authoring/README.html. --> 
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. 
     (Here they are set differently than their defaults in xml2rfc v1.32) --> 
<?rfc strict="yes" ?> 
<!-- give errors regarding ID-nits and DTD validation --> 
<!-- control the table of contents (ToC) --> 
<?rfc toc="yes"?> 
<!-- generate a ToC --> 
<?rfc tocdepth="4"?> 
<!-- the number of levels of subsections in ToC. default: 3 --> 
<!-- control references --> 
<?rfc symrefs="yes"?> 
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> 
<?rfc sortrefs="yes" ?>

<!-- sort the reference entries alphabetically --> 
<!-- control vertical white space  
     (using these PIs as follows is recommended by the RFC Editor) --> 
<?rfc compact="yes" ?> 
<!-- do not start each main section on a new page --> 
<?rfc subcompact="no" ?> 
<!-- keep one blank line between list items --> 
<!-- end of list of popular I-D processing instructions --> 


<rfc category="info" docName="draft-ietf-dmm-5g-uplane-analysis-04">
  <!-- ***** FRONT MATTER ***** --> 




  <front>
    <title abbrev="draft-ietf-dmm-5g-uplane-analysis-04">
    User Plane Protocol and Architectural Analysis on 3GPP 5G System
    </title>



    <author fullname="Shunsuke Homma" initials="S." surname="Homma">
      <organization>NTT</organization>

      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>homma.shunsuke@lab.ntt.co.jp</email>
      </address>
    </author>


    <author fullname="Takuya Miyasaka" initials="T." surname="Miyasaka">
      <organization>KDDI Research</organization>

      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>ta-miyasaka@kddi-research.jp</email>
      </address>
    </author>
    
    <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
      <organization>SoftBank</organization>

      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>satoru.matsushima@g.softbank.co.jp</email>
      </address>
    </author>

<!--
    <author fullname="Takashi Ito" initials="T." surname="Ito">
      <organization>NTT docomo</organization>

      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>itoutakas@nttdocomo.com</email>
      </address>
    </author>
-->

    <author fullname="Daniel Voyer" initials="D." surname="Voyer">
      <organization>Bell Canada</organization>

      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>daniel.voyer@bell.ca</email>
      </address>
    </author>

    
    <date/>

    <area>Internet Area</area>

    <workgroup>DMM Working Group</workgroup>
    
    <keyword>I-D</keyword>

    <abstract>
        <t>
            This document analyzes the mobile user plane protocol and the
            architecture specified in 3GPP 5G documents. The analysis work is to
            clarify those specifications, extract protocol and architectural
            requirements and derive evaluation aspects for user plane protocols
            on IETF side. This work is corresponding to the User Plane Protocol
            Study work on 3GPP side.
        </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
        This document analyzes the mobile user plane protocol and the
        architecture specified by 3GPP 5G documents. The background of the work
        is that 3GPP requests through a liaison statement that the IETF to
        provide any information for the User Plane Protocol Study work in 3GPP
        <xref target="CP-180116-3GPP"/>. Justification and the objectives of the
        study can be found from <xref target="CP-173160-3GPP"/>.
      </t>

      <t>
        We understand that the current user plane protocol, <xref
        target="TS.29.281-3GPP">GTP-U</xref>, has been well developed in 3GPP,
        and deployed very widely as the successor of legacy network
        technologies, such as TDM circuit, or ATM virtual circuit. That GTP-U
        success seems based on IP overlay technique that is dramatically scaled
        compare to the previous ones because it successfully isolates mobile
        session states from the user plane transport network.
      </t>
      
      <t>
        Even after that big success, it is definitely worth that 3GPP has
        decided to revisit user plane which seems to response to IPv6 deployment
        growth and <xref target="IAB-Statement"/> that encourages
        the industry to develop strategies for IPv6-only operation. It can be
        seen from the justification section in <xref target="CP-173160-3GPP"/>.
      </t>
      
      <t>
        The study description mentions that the study would be based on Release
        16 requirement while only Release 15 specifications has been available
        now. However we believe that to provide adequate information for 3GPP,
        we need to clearly understand what the current user plane protocol is in
        Release 15, and architectural requirements for the user plane.
      </t>
      
      <t>
        As the liaison statement indicates 3GPP specifications related to user
        plane, those documents should be a good start point to clarify their
        specifications and to extract protocol and architectural requirements
        from them.
      </t>

      <section title="Current Status of Mobile User Plane for 5G">
        <t>
          3GPP RAN and CT4 decided to use GTP-U as the 5G user plane
          encapsulation protocol over N3 and N9 that respectively described
          in<xref target="TS.38.300-3GPP" /> and <xref target="TR.29.891-3GPP"
          />. N3 is an interface between RAN and UPF and N9 is an interface
          between different UPFs <xref target="TS.23.501-3GPP" />.
        </t>

        <t>
          In <xref target="TR.29.891-3GPP"/>, it captured user plane
          requirements and concluded that GTP-U is adopted for the user plane
          protocol. It seems that GTP-U was only option to be chose and it
          focused on how to carry 5G specific QoS information between UPF and
          access networks. That is described in section 5.2 and 11.2 of <xref
          target="TR.29.891-3GPP"/>. Another aspects of user plane requirements
          couldn't be found. 
        </t>
      </section>
        
      <section title="Our Way of Analysis Work">
        <t>
          First, we analyze <xref target="TS.29.281-3GPP"/> for clarifying it
          as the current user plane protocol in the 5G system. <xref
          target="TR.29.891-3GPP"/> describes how GTP-U is selected as the user
          plane protocol for 5G in 3GPP. Clarified characteristics of the
          protocol are described in <xref target="gtp-u"/>. 
        </t>
      
        <t>
          Then, to clarify what are required to the user plane protocol in
          architecture level, we analyze <xref target="TS.23.501-3GPP"/> as the
          5G system architecture specification. <xref target="TS.23.502-3GPP"/> is
          the specification of system procedures that helps us to understand how
          the system works in the architecture. <xref target="TS.23.503-3GPP"/> is
          also helpful to find the role of user plane in the architecture that
          influences user plane protocol. Extracted architectural requirements are
          described in <xref target="arch"/>.
        </t>

        <t>
          Based on the results of above, we identify some aspects where there
          might be gap between the current user plane protocol and the
          architectural requirements on which <xref target="TR.29.891-3GPP"/> does
          not discuss. That aspects are discussed <xref target="eval_aspects"/>.
          That's what we intend to be as a part of the reply to 3GPP. CT4 WG in 3GPP
          can utilize it as an input to evaluate the candidate protocols for user
          plane to the 5G system including the current protocol.
        </t>
<!--
        <t>
          <xref target="I-D.bogineni-dmm-optimized-mobile-user-plane"/> will
          provide the candidate protocols on IETF side to the 3GPP study.
        </t>
-->
      </section>
      
    </section>
      
    <section title="Terms and Abbreviations">

      <t>
        This section describes terms of functions and interfaces relevant to
        user plane protocol which we extract from the 3GPP specifications since
        this document focuses on user plane.
      </t>

      <t>
        In those specifications, there are so many unique terms and
        abbreviations in the 3GPP context which IETF community seems not
        familiar with. We will try to bring those terms with brief explanations
        to make sure common understanding for them.
      </t>

      
      <t>
        <list style="hanging">
        <t hangText="GTP:">
          GPRS Tunneling Protocol
        </t>
        
        <t hangText="GTP-U:">
          User Plane part of GTP
        </t>

        <t>
          Noted that GTP version 1 (GTPv1-U) is the user-plane protocol
          specification which is defined in <xref target="TS.29.281-3GPP" />.
          Unless there is no specific annotation, we refer GTP-U to GTPv1-U in
          this document.
        </t>

        <t hangText="PDU:">
          Protocol Data Unit of end-to-end user protocol packet.
        </t>
      
        <t>
          Noted that the PDU in 3GPP includes IP header in case that PDU session
          type is IPv4 or IPv6. In contrast, in IETF it is supposed that PDU is
          the payload of IP packet so that it doesn't include  IP/TCP/UDP header
          in end-to-end.
        </t>

        <t hangText="T-PDU:">
          Transport PDU.
        </t>

        <t hangText="G-PDU:">
          GTP encapsulated user Plane Data Unit.
        </t>
        
        <t>
          GTP-U has above two notions on PDU. T-PDU is a PDU that GTP-U header
          encapsulates. G-PDU is a PDU that includes GTP-U header. A G-PDU may
          include a T-PDU. G-PDU can be sent without T-PDU, but just with
          extension headers or TLV elements. It can be used for OAM related 
          operations.
        </t>

        <t hangText="PDU session:">
          Association between the UE and a Data Network that provides a PDU
          connectivity service.
        </t>

        <t hangText="Data Network (DN):">
          The network of operator services, Internet access or 3rd party services.
        </t>
        
        <t hangText="User Plane (UP):">
          Encapsulating user end-to-end PDU.
        </t>
        
        <t>
          In fact, we can't find exact text that defines UP in the architecture
          specification. However when we see the figure 8.3.1-1 in <xref
          target="TS.23.501-3GPP"/>, we specify UP as the layer right under PDU
          that directly encapsulates PDU. Underneath layers of UP are UP
          transport, such as IP/UDP, L2 and L1.
        </t>
        
        <t>
          However 3GPP is consistent to use the term user plane when they
          indicate that layer. In IETF, we can see the terms data plane, or
          forwarding plane as variations which often makes us tend to be
          confused in terminology.
        </t>

        <t hangText="QFI:">
          QoS Flow Identifier
        </t>
          
          
        <t hangText="UPF:">
          User Plane Function
        </t>
        
        <t hangText="SMF:">
          Session Management Function
        </t>
        
        <t>
          SMF is a control plane function which provides session management
          service that handling PDU sessions in the control plane. SMF allocates
          tunnels corresponding to the PDU sessions and configure the tunnel to
          the UPF.
        </t>

        <t hangText="PFCP:">
          Packet Forwarding Control Protocol
        </t>

        <t>
          PFCP is used on N4 interface between SMF and UPF to configure the
          rules of packet detection, forwarding action, QoS enforcement, usage
          report and buffering for each PDU session.
        </t>

        <t hangText="PDR:">
          Packet Detection Rule
        </t>

        <t hangText="FAR:">
          Fowarding Action Rule
        </t>

        <t hangText="RAN:">
          Radio Access Network
        </t>
        
        <t>
          Noted that UP protocol provides a RAN to connect UPF. But the UP
          protocol is not appeared on the air in the RAN.
        </t>

<!-- You can add terminologies which are important in this document -->

      </list>
      </t>
    </section>


    <section anchor="gtp-u" title="GTP-U Specification and Observation">
      <t>
        In this section we analyze the GTP-U specification and summarize
        clarified characteristic of GTP-U to see if GTP-U meets the requirements
        of 5G architecture for user plane in later section.
      </t>

      <section title="GTP-U Tunnel">
        <t>
          GTP-U is a tunneling protocol between given a pair of GTP-U tunnel endpoint nodes and
          encapsulates T-PDU from/to UE on top of IP/UDP. A Tunnel Endpoint Identifier (TEID) value allocated on
          each end point indicates which tunnel a particular T-PDU belongs to.
        </t>
        <t>
          The receiving endpoint individually allocate a TEID and the sender tunnel
          endpoint node encapsulates the IP packet from/to UE with the TEID which is 
          present in GTP-U header on top of IPv4 or IPv6, and UDP. That is described 
          in section 4.2.1 of <xref target="TS.29.281-3GPP" />.
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U is an unidirectional Point-to-Point tunneling protocol.
            </t>
          </list>
        </t>
        
        <t>
          <xref target="fig_Protocol-Stack"/> shows an example of GTP-U protocol stack
          for uplink (UL) and downlink (DL) traffic flow. Two GTP-U tunnels
          are required to form one bi-directional tunnel.
        </t>
        <t>
          <list style="hanging">
            <t hangText="UL:">
              From RAN to UPF1 (TEID=1), and from UPF1 to UPF2 (TEID=2)
            </t>
            <t hangText="DL:">
              From UPF2 to UPF1 (TEID=3), and from UPF1 to RAN (TEID=4)
            </t>
          </list>
        </t>
        <t>
          In 5GS, GTP-U tunnel is established at following interfaces to provide PDU Session between UE and 5GC.
          <list style="hanging">
            <t hangText="N3:">
              Between RAN and UPF
            </t>
            <t hangText="N9:">
              Between different UPFs
            </t>
          </list>
        </t>
        <t>
          GTP-U allows one tunnel endpoint node to send out a G-PDU to be
          received by multiple tunnel endpoints by utilizing IP multicast
          capability of underlay IP networks. That is described in section
          4.2.6 of <xref target="TS.29.281-3GPP" />. It looks GTP-U has
          Point-to-Multipoint (P2MP) tunneling capability. The P2MP tunneling
          is used for MBMS (Multimedia Broadcast Multicast Service) through
          GTP-U tunnel.
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U supports Point-to-Multipoint tunneling.
            </t>
          </list>
        </t>
        <t>
          UDP is utilized for GTP-U encapsulation and UDP destination port is
          2152 which is assigned by IANA. Allocation of UDP source port depends
          on sender tunnel endpoint node and GTP-U supports dynamic allocation
          of UDP source port for load balancing objective. The specification of
          this dynamic allocation is described in section 4.4.2.0 of <xref
          target="TS.29.281-3GPP" />, however specific procedure, e.g., 5-tuple
          hashing, is not described in the document and depends on the
          implementation of GTP-U tunnel endpoint node.
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U supports load balancing by using dynamic UDP source port
              allocation.
            </t>
          </list>
        </t>

        <figure anchor="fig_Protocol-Stack" title="Protocol Stack by GTPv1-U for Uplink and Downlink Traffic Flow">
          <artwork align="center"><![CDATA[
[Uplink]
    .-     .-+--------+ - - - - +--------+ - - - - +--------+
    |      | |Payload |         |Payload |         |Payload |
    | PDU <  +--------+         +--------+         +--------+
    |(3GPP)| |Inner IP|         |Inner IP|         |Inner IP|
    |      '-+--------+ - - - - +--------+ - - - - +--------+
    |        | GTP-U  |         | GTP-U  |         |   L2   |
    |        |(TEID=1)|         |(TEID=2)|         +--------+
GTP<         +--------+         +--------+         |   L1   |
Pkt |        |  UDP   |         |   UDP  |         +--------+
    |        +--------+         +--------+
    |        |Outer IP|         |Outer IP|
    |        +--------+         +--------+
    |        |   L2   |         |   L2   |
    |        +--------+         +--------+
    |        |   L1   |         |   L1   |
    '-       +--------+ - - - - +--------+

================   Traffic Direction  =======================>


[Downlink]
    .-     .-+--------+ - - - - +--------+ - - - - +--------+
    |      | |Payload |         |Payload |         |Payload |
    | PDU <  +--------+         +--------+         +--------+
    |(3GPP)| |Inner IP|         |Inner IP|         |Inner IP|
    |      '-+--------+ - - - - +--------+ - - - - +--------+
    |        | GTP-U  |         | GTP-U  |         |   L2   |
    |        |(TEID=4)|         |(TEID=3)|         +--------+
GTP<         +--------+         +--------+         |   L1   |
Pkt |        |  UDP   |         |   UDP  |         +--------+
    |        +--------+         +--------+
    |        |Outer IP|         |Outer IP|
    |        +--------+         +--------+
    |        |   L2   |         |   L2   |
    |        +--------+         +--------+
    |        |   L1   |         |   L1   |
    '-       +--------+ - - - - +--------+

<===============   Traffic Direction  ========================

      +-----+     N3    +------+     N9     +------+    N6
 -----+ RAN +-----------+ UPF1 +------------+ UPF2 +----------
      +-----+           +------+            +------+
]]></artwork>
        </figure>
        <t>
          IPv6 flow label <xref target="RFC6437"/> is also candidate method for 
          load balancing especially for IP-in-IPv6 tunnel <xref target="RFC6438"/> like GTP-U.
          GTP-U also supports dynamic allocation of IPv6 flow label for load balancing objective.
          The specification of this dynamic allocation is described in section 4.4.2.0 of 
          <xref target="TS.29.281-3GPP" />, however specific procedure, e.g., 5-tuple hashing, 
          is not described in the document and depends on the implementation of GTP-U tunnel endpoint node.
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U supports load balancing by using dynamic IPv6 flow label allocation.
            </t>
          </list>
        </t>
        
        <t>
          GTP-U supports both IPv4 and IPv6 as the underlying network layer 
          protocol. From Release 16, GTP-U updates their reference to IPv6 
          specification from <xref target="RFC2460"/> to <xref target="RFC8200"/> 
          which allows UDP zero checksum for the protocols that use UDP as 
          a tunnel encapsulation, such as GTP-U. As a result of the update, 
          GTP-U over IPv6 also supports the UDP zero checksum if the sender 
          and receiver tunnel endpoint node support the UDP zero checksum, 
          which is described in section 4.4.2.0 of <xref target="TS.29.281-3GPP" />.
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U supports UDP zero checksum.
            </t>
          </list>
        </t>
        
        <t>
          "Unnecessary fragmentation should be avoided" is recommended and to
          avoid the fragmentation operator should configure MTU size at UE <xref
          target="TS.29.281-3GPP" />. However, there's no reference and
          specification of Path MTU Discovery for IPv6 transport. If
          encapsulated IPv6 packet is too big on a network link between tunnel
          endpoint nodes, UE may not receive ICMPv6 Packet Too Big message and
          causes Path MTU Discovery black hole.
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U does not support to response ICMP PTB for Path MTU Discovery.
            </t>
          </list>
        </t>
        <t>
          Section 9.3 of <xref target="TS.23.060-3GPP"/> specifies advertisement of 
          inner IPv6 link MTU size for UE by IPv6 RA message <xref target="RFC4861"/>.
          However, this document doesn't specify a procedure to measure MTU size 
          in mobile network system and mobile network operator need to calculate MTU size 
          for UE like Annex C of <xref target="TS.23.060-3GPP"/>. If link MTU of a router 
          in a transport network is accidentally modified, UE cannot detect the event and 
          send packet with initial MTU size, which may cause service disruption due to MTU 
          exceed in the router link.
        </t>
      </section>

      <section anchor="gtp-u-header" title="GTP-U Header Format">
        <t>
          <xref target="fig_GTP-U_header" /> shows general and mandatory GTP-U
          header and <xref target="fig_GTP-U_Ext_header"/> shows extension GTP-U
          header.
        </t>

        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U supports sequence number option in the header, but it is not
              recommended to be used by almost GTP-U entities.
            </t>
          </list>
          GTP-U header has Sequence Number field to reorder incoming packets
          based on the sequence number. If Sequence Number Flag is set to '1' it
          indicates that Sequence Number Filed exists in GTP-U header and
          examined at receiving tunnel endpoint node to reorder incoming
          packets. However, the sequence number flag is set to '1' only for RAT
          HO procedure and sequence number flag should be set to '0' in normal
          case. Therefore, in normal case receiver tunnel endpoint node doesn't
          examine sequence number and can't reorder GTP-U packets based on the
          sequence number. This specification is described in section 5.1 of
          <xref target="TS.29.281-3GPP" />. In 3GPP, sequential delivery is required 
          only during handover procedure and is used by only RAN entities.
        </t>
        <figure anchor="fig_GTP-U_header" title="GTP-U Header">
        <artwork align="center"><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |P|R|E|S|N| Message Type  |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Tunnel Endpoint Identifier                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Sequence Number          | N-PDU Number  |  Next-Ext-Hdr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        
        <t>
          <list style="symbols">
            <t>Ver: Version field (Set to '1')</t>
            <t>P: Protocol Type (Set to '1')</t>
            <t>R: Reserved bit (Set to '0')</t>
            <t>E: Extension Header Flag (Set to '1' if extension header exists)</t>
            <t>S: Sequence Number Flag (Set to '1' if sequence number exists)</t>
            <t>N: N-PDU Number Flag (Set to '1' if N-PDU number exists)</t>
            <t>Message Type: Indicates the type of GTP-U message</t>
            <t>Length: Indicates the length in octets of the payload</t>
            <t>Tunnel Endpoint Identifier (TEID)</t>
            <t>Sequence Number: Indicates increasing sequence number for T-PDUs is
               transmitted via GTP-U tunnels</t>
            <t>N-PDU Number: It is used only for inter SGSN, 2G-3G handover case, etc.</t>
            <t>Next-Ext-Hdr: Indicates following extension header type</t>
          </list>
        </t>

        <figure anchor="fig_GTP-U_Ext_header" title="Extension GTP-U Header">
        <artwork align="center"><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Hdr Length|                                               |
+-+-+-+-+-+-+-+-+                                               |
|                  Extension Header Content                     |
.                                                               .
.                                               +-+-+-+-+-+-+-+-+
|                                               |  Next-Ext-Hdr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>
          <list style="symbols">
            <t>Ext-Hdr Length: Represents the length of the Extension header in
            units of 4 octets</t>
            <t>Extension Header Content: Contains 3GPP related information</t>
            <t>Next-Ext-Hdr: Indicates following extension header type</t>
          </list>
        </t>

        <t>
          The extension GTP-U header is a variable-length and extendable header
          and contains 3GPP specific information. Following list summarizes
          every extension header which is used for user plane protocol. These
          extension headers are defined in <xref target="TS.29.281-3GPP" />. In
          this list Next-Ext-Hdr is represented in binary.

          <list style="symbols">
            <t>
              No more extension headers (Next-Ext-Hdr = 00000000)
            </t>
            <t>
              Service Class Indicator (Next-Ext-Hdr = 00100000)
            </t>
            <t>
              UDP Port (Next-Ext-Hdr = 01000000)
            </t>
            <t>
              RAN Container (Next-Ext-Hdr = 10000001)
            </t>
            <t>
              Long PDCP PDU Number (Next-Ext-Hdr = 10000010)
            </t>
            <t>
              Xw RAN Container (Next-Ext-Hdr = 10000011)
            </t>
            <t>
              NR RAN Container (Next-Ext-Hdr = 10000100)
            </t>
            <t>
              PDU Session Container (Next-Ext-Hdr = 10000101)
            </t>
            <t>
              PDCP PDU Number (Next-Ext-Hdr = 11000000)
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U supports carrying QoS Identifiers transparently for Access
              Networks in an extension header.
            </t>
          </list>
          GTP-U is designed to carry 3GPP specific information with extension
          headers. 3GPP creates PDU Session Container extension header for NGRAN
          of 5G to carry QFI. It is described in section 5.2.2.7 of <xref
          target="TS.29.281-3GPP" />.
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U supports DSCP marking based on the QFI.
            </t>
          </list>
          DSCP marking on outer IPv4 or IPv6 shall be set by sender tunnel
          endpoint node based on the QFI. This specification is described in
          section 4.4.1 of <xref target="TS.29.281-3GPP" />.
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U does not specify extension header order.
            </t>
          </list>
          In general, multiple GTP-U extension headers are able to contained in one GTP-U
          packet and the order of those extension headers is not specified by 
          <xref target="TS.29.281-3GPP" />. Thereby the receiving endpoint can't predict exact
          position where the target extension headers are. This could impact on
          header lookup performance on the node.
        </t>
        <t>
          As for PDU Session Container extension header, there is a note in 
          <xref target="TS.29.281-3GPP" /> as "For a G-PDU with several Extension 
          Headers, the PDU Session Container should be the first Extension Header".
          This note was added at the version 15.3.0 of <xref target="TS.29.281-3GPP" />
          which is published on June 2018 in order to accelerate the processing of GTP-U packet at UPF and RAN.
          It is only one rule regarding the extension header order.
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U does not support to indicate next protocol type.
            </t>
          </list>
          When Next-Ext-Hdr is set to 0x00 it indicates that no more extension
          headers follow. As GTP is designed to indicate protocol types for
          T-PDU by control-plane signaling, GTP-U doesn't have
          Next-Protocol-Header field to indicate the T-PDU type in the header.
        </t>
      </section>


      <section title="Control Plane Protocol for GTP-U">
        <t>
          Control plane protocol for GTP-U signals TEID between tunnel endpoint
          nodes. GTPv2-C <xref target="TS.29.274-3GPP" /> is the original
          control plane protocol tied with GTP-U in previous generation
          architectures before CUPS (Control and User Plane Separation).
        </t>
        <t>
          3GPP decided to use extended PFCP (Packet Forwarding Control Protocol)
          <xref target="TS.29.244-3GPP" /> for N4 interface <xref
          target="TR.29.891-3GPP" /> to signal tunnel states from SMF to UPF.
        </t>
      </section>
      <section title="GTP-U message">
        <t>
          GTP-U supports in-band messaging to signal OAM. Currently GTP-U
          supports following messages <xref target="TS.29.281-3GPP" />.
          <list style="symbols">
            <t>
              Echo Request
            </t>
            <t>
              Echo Response
            </t>
            <t>
              Supported Extension Headers Notification
            </t>
            <t>
              Error Indication
            </t>
            <t>
              End Marker
            </t>
            </list>
          </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U supports active OAM as a path management message "Echo
              Request/Response".
            </t>
          </list>
          A GTP-U tunnel endpoint node sends a Echo Request message to another
          nodes for keep-alive and received node sends a Echo Response message
          to sender node as acknowledgment. Echo Request message and Echo
          Response message are described in section 7.2.1 and section 7.2.2 of
          <xref target="TS.29.281-3GPP" /> respectively. <xref
          target="TR.29.891-3GPP" /> recommends not to send Echo Request message
          more often than 60s on each path.
        </t>
        <t>
          Supported Extension Headers Notification message indicates a list of
          supported that tunnel endpoint node can support. This message is sent
          only in case a tunnel endpoint node receives GTP-U packet with
          unsupported extension header.
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U supports tunnel management messages "Error Indication".
            </t>
          </list>
          GTP-U has Error Indication message to notify that the receiving
          endpoint discard packets of which no session exist to the sending
          endpoint. Error Indication message is described in section 7.3.1 of
          <xref target="TS.29.281-3GPP" />.
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u-2">
            <t>
              GTP-U supports tunnel management messages "End Marker".
            </t>
          </list>
          GTP-U has End Marker message to indicate the end of the payload stream
          that needs to be sent on a GTP-U tunnel. End Marker message is
          described in section 7.3.2 of <xref target="TS.29.281-3GPP" />.
        </t>
      </section>
      <section title="Packet Format">
        <t>
          <xref target="fig_GTP_stack_example" /> shows a packet format example
          of GTP-U over IPv6 that carries an extension header for QFI and an
          IPv6 PDU. All values in the example are illustration purpose only. The
          encoding of PDU Session Container for QFI refers to <xref
          target="TS.38.415-3GPP" />.
        </t>
        <t>
          Outer IPv6 Header's DSCP value(EF) in <xref target="fig_GTP_stack_example" />
          is marked at sender tunnel endpoint node based on QFI value which is contained
          in GTP-U Extension Header (PDU Session Container).
        </t>
        <figure anchor="fig_GTP_stack_example" title="GTP-U Protocol Stack Example">
          <artwork align="center"><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Outer IPv6 Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|     DSCP=EF   |               Flow Label              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Payload Length       | NxtHdr=17(UDP)|    Hop Limit  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                   Source IPv6 Address                         +
|                        2001:db8:1:1::1                        |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+              Destination IPv6 Address                         +
|                        2001:db8:1:2::1                        |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Outer UDP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Source Port = xxxx        |         Dest Port = 2152      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         UDP Length            |    UDP Checksum (Non-zero)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

GTP-U header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1 |1|0|1|0|0|     0xff      |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           TEID = 1654                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Sequence Number = 0        |N-PDU Number=0 |NextExtHdr=0x85|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

GTP-U Extension Header (PDU Session Container)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ExtHdrLen=2  |Type=0 |0|0|   |0|0|   QFI     | PPI |  Spare  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Padding                    |NextExtHdr=0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Inner IPv6 Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|     DSCP=0    |               Flow Label              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Payload Length       |    NexttHdr   |    Hop Limit  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                   Source IPv6 Address                         +
|                        2001:db8:2:1::1                        |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+              Destination IPv6 Address                         +
|                        2001:db8:3:1::1                        |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
.                        TCP/UDP/etc., Data                     .
.                                                               .
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
      </section>
      <section anchor="gtp-u-summary" title="Observations Summary">
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              An unidirectional Point-to-Point tunneling protocol.
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Supports Point-to-Multipoint tunneling.
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Supports load balancing by using dynamic UDP port allocation.
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Does not support IPv6 flow label for load balancing in case of
              IPv6 transport.
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              UDP zero checksum is not available in case of IPv6 transport.
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Does not support to response ICMP PTB for Path MTU Discovery.
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Supports sequence number option and sequence number flag in the
              header, but it is not recommended to be used by almost GTP-U
              entities.
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Supports carrying QoS Identifiers transparently for Access
              Networks in extension headers.
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Supports DSCP marking based on the QFI.
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Does not specify the rule for the extension header order.
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Does not support an indication of next-header type.
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Supports active OAM as a path management message "Echo
              Request/Response".
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Supports tunnel management messages "Error Indication".
            </t>
          </list>
        </t>
        <t>
          <list style="format [GTP-U-%d]:" counter="gtp-u">
            <t>
              Supports tunnel management messages "End Marker".
            </t>
          </list>
        </t>
      </section>
    </section>


    <section anchor="arch" title="5GS Architectural Requirements for User Plane Protocols">

      <section anchor="archi-overview" title="Overview of 5G System Architecture">
      <t>
        The 5G system is designed for applying to diverse devices and services due to factors 
        such as the diffusion of IoT devices, and the UP protocol is required to have capabilities for
        satisfying their requirements.  
      </t>
      
      <t>
        As a principle of the 5G system, User Plane (UP) functions are separated
        from the Control Plane (CP) functions for allowing independent
        scalability, evolution and flexible deployments.
      </t>
      
      <t>
        Network slicing is also one of the fundamental concepts of the 5G system,
        and it provides logical network separation. In terms of user plane, multiple
        network slices can be comprised of UPFs on top of same physical network
        resources. Allocated resources and structures may be differentiated
        among the slices by which the required features or capabilities.
      </t>
      
      <t>
        The 3GPP 5G architecture <xref target="TS.23.501-3GPP"/> defines
        slice types which are eMBB, URLLC and MIoT from Rel-15. In addition
        to that, V2X slice type is defined from Rel-16.
      </t>
      
      <t>
        The architecture overview is shown in <xref
        target="fig_3GPP-5GS-ARCH"/>. The details of functions are described in
        <xref target="TS.23.501-3GPP"/>.  A UPF handles UP paths on N3, N9 and N6 interface, 
        and the setup is controlled by SMF via N4 interface. A UP path will be manipulated 
        based on application requirements for the PDU session corresponding to the path.  
        An SMF is also capable to receive information regarding routing path with API from 
        AF via NEF, PCF, and SMF.
      </t>
      
<!--
        User plane path and applied functions
        for a tunnel will be manipulated based on application requirements that
        the PDU session corresponding to the tunnel. These tunnels are available to be handled
        by other authorized functions through the control plane.
      </t>
-->

      <figure anchor="fig_3GPP-5GS-ARCH" title="5GS Architecture and
      Service-based Interfaces">
        <artwork><![CDATA[



   +-----+  +-----+  +-----+     +-----+  +-----+  +-----+
   |NSSF |  | NEF |  | NRF |     | PCF |  | UDM |  | AF  |
   +--+--+  +--+--+  +--+--+     +--+--+  +--+--+  +--+--+
 Nnssf|    Nnef|    Nnrf|       Npcf|    Nudm|        |Naf
   ---+--------+--+-----+--+--------+--+-----+--------+-
             Nausf|    Namf|       Nsmf|
               +--+--+  +--+--+     +--+-------+
               |AUSR |  | AMF |     |    SMF   |
               +-----+  ++-+--+     +--+-----+-+ 
                        /  |           |      \
Control Plane        N1/   |N2         |N4     \N4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
User Plane           /     |           |         \
                 +--++  +--+--+ N3  +--+--+ N9  +-+---+ N6 +-----+
                 |UE +--+(R)AN+-----+ UPF +-----+ UPF +----+ DN  |
                 +---+  +-----+     +--+--+     +-----+    +-----+
                                       |N6
                                    +--+--+
                                    | DN  |
                                    +-----+

       ]]></artwork>
      </figure>

      <t>
        This document mainly focuses on requirements for N9 interface as
        relevant to UP protocol of 5G system.
      </t>
         
      <section anchor="UPF-Func" title="UPF Functionalities">
        <t>
          UPF has a role to handle UP traffic, and provides functionalities to 
          look up user data traffic and enforce the appropriate policies to it. 
        </t>
        
        <t>
          The followings are defined as UPF functionalities defined in the
          section 6.2.3 of <xref target="TS.23.501-3GPP"/>
          <list style="symbols">
            <t>Anchor point for Intra-/Inter-RAT mobility (when applicable).</t>
            <t>External PDU Session point of interconnect to Data Network.</t>
            <t>Packet routing and forwarding (e.g. support of Uplink classifier to
               route traffic flows to an instance of a data network, support of
               Branching point to support multi-homed PDU Session).</t>
            <t>Packet inspection (e.g. Application detection based on service
               data flow template and the optional PFDs received from the SMF in
               addition).</t>
            <t>User Plane part of policy rule enforcement, e.g. Gating,
               Redirection, Traffic steering).</t>
            <t>Lawful intercept (UP collection).</t>
            <t>Traffic usage reporting.</t>
            <t>QoS handling for user plane, e.g. UL/DL rate enforcement,
               Reflective QoS marking in DL.</t>
            <t>Uplink Traffic verification (SDF to QoS Flow mapping).</t>
            <t>Transport level packet marking in the uplink and downlink.</t>
            <t>Downlink packet buffering and downlink data notification triggering.</t>
            <t>Sending and forwarding of one or more "end marker" to the source 
               NG-RAN node.</t>
            <t>ARP proxying and / or IPv6 Neighbour Solicitation Proxying for the 
               Ethernet PDUs.</t>
            <t>Packet duplication in downlink direction and elimination in
               uplink direction in UP protocol layer.</t>
            <t>TSN Translator functionality to hold and forward user plane packets for
               de-jittering when 5G System is integrated as a bridge with the TSN
               network.</t>
          </list>
        </t>
      </section>
        
      <section anchor="traffic-detection" title="UP Traffic Detection">

        <t>
          The traffic detection is described in the section 5.8.2.4 of <xref
          target="TS.23.501-3GPP"/>. In 3GPP UP packet forwarding model, UPF
          detects UP traffic flow which belong to a N4 session configured by
          SMF. 
        </t>
        <t>
          The protocol of N4 interface, PFCP, brings a set of traffic
          detection information from SMF to UPF as Packet Detection
          Information (PDI) in a PDR to establish/modify the N4 PFCP session.
          It is defined in section 7.5.2.2 of <xref target="TS.29.244-3GPP"/>.
        </t>
        <t>
           Combination of the following information is used for the traffic detection:
        </t>
    
        <t>
          <list style="symbols">
            <t>For IPv4 or IPv6 PDU Session type
              <list style="symbols">
                <t>CN tunnel info (Tunnel ID and the endpoint IP address of 5G Core)</t>
                <t>Network instance</t>
                <t>QFI</t>
                <t>IP Packet Filter Set</t>
                <t>Application Identifier: 
                    The Application ID is an index to a set of application 
                    detection rules configured in UPF</t>
              </list>
            </t>

            <t>For Ethernet PDU Session type
              <list style="symbols">
                <t>CN tunnel info(Tunnel ID and the endpoint IP address of 5G Core)</t>
                <t>Network instance</t>
                <t>QFI</t>
                <t>Ethernet Packet Filter Set</t>
              </list>
            </t>
          </list>
        </t>

        <t>
          It is noted that Network Instance is encoded as Octet String in PFCP,
          and is NOT appeared in UP packet over the wire. It is expected like an
          attribute of the receiving IP interface of the UPF. It supports UPF to
          be able to connect to different IP domains of N3, N9 or N6, which run
          each independent policy in routing and addressing. The UPF detects
          traffic flow with Network Instance which the receiving interface
          attributed to. 
        </t>

        <t>The IP Packet Filter Set and Ethernet Packet Filter Set defined in
        clause 5.7.6 of 
           <xref target="TS.23.501-3GPP"/> are following:
          <list style="symbols">
            <t>IP Packet Filter Set:
              <list style="symbols">
                <t>Source/destination IP address or IPv6 prefix</t>
                <t>Source/destination port number</t>
                <t>Protocol ID of the protocol above IP/Next header type</t>
                <t>Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask.</t>
                <t>Flow Label (IPv6)</t>
                <t>Security parameter index</t>
                <t>Packet filter direction</t>
              </list>
            </t>

            <t>Ethernet Packet Filter Set:
              <list style="symbols">
                <t>Source/destination MAC address</t>
                <t>Ethertype as defined in IEEE 802.3</t>
                <t>Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG)
                VID fields as defined in IEEE 802.1Q</t>
                <t>Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG)
                PCP/DEI fields as defined in IEEE 802.1Q</t>
                <t>IP Packet Filter Set, in case Ethertype indicates
                IPv4/IPv6 payload</t>
                <t>Packet filter direction</t>
              </list>
            </t>
          </list>
        </t>

      </section>
      
      <section anchor="PFCP" title="User Plane Configuration">
      
        <t>
          User Plane configuration on a UPF is managed by an SMF through PFCP
          <xref target="TS.29.244-3GPP"/>. The SMF establishes PFCP sessions 
          on the UPF per PDU session basis. The UPF maintains each configured
          PFCP session states during the sessions exist.
        </t>
        
        <t>
          A PFCP session consists of the rules of packet detection,
          forwarding action, QoS enforcement, usage reporting and buffering
          action. <xref target="fig_PFCP_model"/> depicts overview of the
          PFCP session state structure.
        </t>
          
        <t>
          The listed information in <xref target="traffic-detection"/>
          indicates packet detection information of packet detection rule
          for that the rest of related rules within the PFCP session to be
          derived. All rules are per session unique and no rules are shared
          with other sessions.
        </t>
      
        <figure anchor="fig_PFCP_model" title="User Plane Configuration Model">
          <artwork align="center"><![CDATA[

PFCP-Session* [F-SEID]
  +- F-SEID(Full Qualified Session Endpoint ID)    uint64
  +- PDU-Session-Type               [IPv4|IPv6|IPv4v6|Ether|Unstrct]
  +- DNN(Data Network Name)
  +- PDR(Packet Detection Rule)* [PDR-ID]
  |  +- PDR-ID    uint16
  |  +- PDI (Packet Detection Information)
  |  |  +- Traffic-Endpoint-ID?   -> Traffic-Endpoint-ID reference
  |  |  +- ....
  |  +- FAR/URR/QER-ID            -> FAR/URR/QER-ID references
  +- FAR(Forwarding Action Rule)* [FAR-ID]
  |  +- FAR-ID                    uint32
  |  +- Forwarding-Parameters
  |  |  +- Network-Instance?        Octet String
  |  |  +- Outer-Header-Creation
  |  |  |  +- Outer-Hdr-Creation-Desc   [GTPoUDP/IPv4|IPv6, etc.,]
  |  |  |  +- TEID, outer IP-Address for N3/N9
  |  |  |  +- C/S-TAG, UDP Port-number for N6
  |  |  +- Forwarding-Policy-ID?    Octet String
  |  |  +- ....
  |  +- Duplicating-Parameters
  |  |  +- ....
  |  +- BAR-ID?                   -> BAR-ID reference
  +- QER(QoS Enforcement Rule)* [QER-ID]
  |  +- QER-ID                    uint32
  |  +- MBR(Maximum Bit Rate)
  |  |  +- UL/DL-MBR?   bitrate_in_kbps (0..10000000)
  |  +- GBR(Guaranteed Bit Rate)
  |  |  +- UL/DL-GBR?   bitrate_in_kbps (0..10000000)
  |  +- QoS-flow-identifier?       QFI value(6-bits)
  |  +- Reflective-QoS?            boolean
  |  +- Paging-Policy-Indicator?   PPI value(3-bits)
  |  +- ....
  +- URR(Usage Reporting Rule)* [URR-ID]
  |  +- URR-ID                    uint32
  |  +- Measurement-Method, Period, Reporting-Triggers?
  |  +- Volume/Event/Time Threshold, Quota?
  |  +- Quota-Holding-Time?
  |  +- FAR-ID for Quota action?        -> FAR-ID reference
  |  +- ....
  +- BAR(Buffering Action Rule)* [BAR-ID]
  |  +- BAR-ID                    uint8
  |  +- Suggested-Buffering-Packets-Count
  +- Traffic-Endpoint* [Traffic-Endpoint-ID]
     +- Traffic-Endpoint-ID                   uint8
     +- TEID, Tunnle IP Address, UE Address...?

         ]]></artwork>
        </figure>
      
      
      
      </section>
      
    </section>

    <section anchor="archi-req" title="Architectural Requirements for User Plane
    Protocols">
      <t>
        This section lists the requirements for the UP protocol on the 5G
        system. The requirements are picked up from <xref
        target="TS.23.501-3GPP"/>. In addition, some of service requirements
        described in <xref target="TS.22.261-3GPP"/> are referred to clarify the
        originations of architectural requirements.
      </t>
    
      <t>
        According to <xref target="TS.23.501-3GPP"/>, the specifications
        potentially have assumptions that the UP protocol is a tunnel
        representing a single TEID between a pair of UPFs and it is
        corresponding to a single PDU session. In short, the UP protocol is a
        tunnel and it is assumed to be managed under per PDU session handling.
        Also, it should be a stateful tunnel in the UPFs along with the PDU
        session.
      </t>
      
      <section title="Fundamental Functionalities">
      <t>
        The fundamental requirements for UP protocols are described below:
      </t>
        
      <t>
        <list style="format ARCH-Req-%d:" counter="arch-req">
          <t>
            Supporting IPv4, IPv6, Ethernet and Unstructured PDU
          </t>
        </list>
      </t>

      <t> 
        The 5G system defines four types of PDU session as IPv4, IPv6, Ethernet,
        and Unstructured. Therefore, UP protocol must support to convey all of
        these PDU session types.  This is described in <xref
        target="TS.23.501-3GPP"/>.
      </t>
      
      <t>
        Note: In TS 23.501 v15.2.0, IPv4v6 is added as a PDU session type.
      </t>     
      
      <t>
        <list style="format ARCH-Req-%d:" counter="arch-req">
          <t>
            Supporting IP connectivity for N3, N6, and N9 interfaces 
          </t>
        </list>
      </t>
      
      <t>
        The 5G system requires IP connectivity for N3, N6, and N9 interfaces. 
        The IP connectivity is assumed that it comprises of IP routing and L1/L2
        transport networks which are outside of 3GPP specifications.
      </t>
      
      <t>
        It is desirable that the IP connectivity built on IPv6 networks when it comes to address space 
        for end-to-end user plane coverage. But it is expected to take certain time.  During the IPv6 
        networks are not deployed for all the coverage, UP protocol should support RANs and DNs 
        running on IPv4 transport connect to UPF running on IPv6 transport.
      </t>

      <t>
         Furthermore, on N6 interface, point-to-point tunneling based on UDP/IPv6 may be used
         to deliver unstructured PDU type data. Then, the content information of
         the PDU may be mapped into UDP port number, and the UDP port numbers is
         pre-configured in the UPF and DN. This is described in the section 9.2
         of <xref target="TS.29.561-3GPP"/>.
      </t>
           
      <t>
        <list style="format ARCH-Req-%d:" counter="arch-req">
          <t>
             Supporting deployment of multiple UPFs as anchors for a single PDU
             session 
          </t>
        </list>
      </t>
      
      <t>
        The 5G system allows to deploy multiple UPFs as anchors for a single 
        PDU session, and supports multihoming of a single PDU session for 
        such anchor UPFs.
      </t>
      
      <t>
        Multihoming is provided with Branching Point (BP). BP provides
        forwarding of UL traffic towards the different PDU Session Anchors
        based on the source IPv6 prefixes and merge of DL traffic to the
        UE. IPv6 multihoming only means multiple source IPv6 prefixes are
        used for a PDU session. It is identical to one classified as
        scenario 1 in <xref target="RFC7157"/>.
      </t>
      
      <t>
        Up link classifier (UL CL) is to forward uplink packets to multiple
        anchor UPFs based on the destination IP of the T-PDU regardless of
        the source IP address. Noted that single source IP address/prefix
        PDU session is not defined as multihoming PDU session in 5GCS even
        though a PDU session has multiple anchor UPFs.
      </t>
   
      <t>
        On UL side, P2P tunnels are established per destination anchor UPFs
        basis from one UL CL UPF to the anchor UPFs for the PDU session.
      </t>
      
      <t>
        On DL side, one single multipoint-to-point (MP2P) tunnel exists from the
        source anchor UPFs to the destination BP UPF for the PDU session. 
        It means that the paths from the anchor UPFs are merged into just one 
        tunnel state at the destination BP UPF.
      </t>
        
      <t>
        Multiple P2P paths on DL could also be used for multihoming. However it
        should be the multiple PDU sessions multihoming case where the
        destination gNB or UPF needs to maintain multiple tunnel states under
        the one PDU session to one UP tunnel architectural principle. It causes increase of 
        load on tunnel states management in UPF due to increment of the anchor UPF
        for the PDU session.
      </t>

      <t>
        However, P2P tunneling could increase explosively the number of states
        in UPF as the anchor UPF/DN incremented to the PDU session. Thereby
        single PDU session multihoming with MP2P path should be a better option
        for multihoming in terms of reducing total number of tunnel states.
      </t>

      <t>
        SSC mode 3 for session continuity in hand-over case uses a single PDU
        multihoming with BP to make sure make-before-break. It is described in
        the section 5.6.4 and 5.6.9 of <xref target="TS.23.501-3GPP"/>. 
      </t>
      
      <t>
        Multihoming is also assumed to be used for edge computing scenario. Edge
        computing enables some services to be hosted close to the UE's access
        point of attachment, and achieves an efficient service delivery through
        the reduced end-to-end latency and load on the transport network. In
        edge computing, local user's traffic is routed or steered to application
        in the local DN by UPF. This refers the section 5.13 of <xref
        target="TS.23.501-3GPP"/>.
      </t>
      
      <t>
        <list style="format ARCH-Req-%d:" counter="arch-req">
          <t>
            Supporting flexible UPF selection for PDU
          </t>
        </list>
      </t>
      
      <t>
        The appropriate UPFs are selected for a PDU session based on parameters
        and information such as UPF's dynamic load or UE location information.
        Examples of parameters and information are described in the section
        6.3.3 of <xref target="TS.23.501-3GPP"/>.
      </t>
      
      <t>
        This means that it is possible to make routing on user plane more efficient in the 5GS. 
        For example, in case that UPFs are distributed geographically, decision 
        of the destination UPF based on locations of end hosts (e.g., UE or NF in DN) 
        enables to forward PDUs with a route connecting between UPFs nearby the hosts directly.  
        This would be useful UE-to-UE or UE-to-local_DN communication, and such usage is described 
        in the section 6.5 of <xref target="TS.22.261-3GPP"/>. 
      </t>

      <t>
        The 5GS allows operators to select parameters used for UPF selection. 
        (In other words, any specific schemes on UPF selection are not defined 
        in the current 3GPP documents.)
      </t>

      <t>
        <list style="format ARCH-Req-%d:" counter="arch-req">
          <t>
             No limitation for number of UPFs in a data path
          </t>
        </list>
      </t>
      
      <t>
        The number of UPF in the data path is not constrained by 3GPP
        specifications. This specification is described in the section 8.3.1 of
        <xref target="TS.23.501-3GPP"/>.
      </t>
        
      <t>
        Putting multiple UPFs, which provides specific function, in a data path
        enables flexible function deployment to make sure load distribution
        optimizations, etc.
      </t>
<!-->        
      <t>
        In addition, deployment of multiple UPFs as anchors closed to UEs' site
        and connecting them without extra anchor points enable to make data path
        more efficient.  This usage is described in the section 6.5 of <xref
        target="TS.22.261-3GPP"/>. 
      </t>
-->
      <t>
        Meanwhile, each UPF in a data path shall be controlled by an SMF via 
        N4 interface. Thus putting an excess of UPF for data paths might cause 
        increase of load of an SMF. Pragmatically, the number of UPF put in a 
        data path is one or two (e.g., for MEC or roaming cases), and, at most,
        it would be three (e.g., for case where UE moves during a session).
      </t>         
      
      <t>
        It is expected that multiple UPFs with per session tunnel handling for a
        PDU session becomes complicated task more and more for a SMF by
        increasing number of UPFs.
<!--
        , and UP protocol shall support to aggregate
        several PDU sessions into a tunnel or shall be a session-less tunnel.
-->
      </t>
      
      <t>
        <list style="format ARCH-Req-%d:" counter="arch-req">
          <t>
            Supporting aggregation of multiple QoS Flow indicated with
            QFI into a PDU Session
          </t>
        </list>
      </t>

      <t>
        Against to the previous generation, 5G enables UPF to multiplex QoS
        Flows, equivalent with IP-CAN bearers in  the previous generation, into
        one single PDU session. That means that a single tunnel includes
        multiple QFIs contrast to just one QoS Flow (a bearer) to one tunnel
        before 5G.
      </t>
      
      <t>
        In even the 5GS, each flow is forwarded based on the appropriate QoS rules. 
        QoS rules are configured by SMF as QoS profiles to UP components and these 
        components perform QoS controls to PDUs based on rules. In downlink, a UPF 
        pushes QFI into an extension header, and transmits the PDU to RAN or another 
        UPF. Then, such UPF may perform transport level QoS packet marking (e.g.,  
        DSCP marking in the outer header). In uplink, each UE obtains the QoS rule 
        from SMF, and transmit PDUs with QFI containing the QoS rules to the RAN. 
        The following RAN and UPFs perform enforcement of QoS control and charging 
        based on the QFI.
      </t>

      <t>
        This specification is described in 5.7.1 of <xref
        target="TS.23.501-3GPP"/>.
      </t>

      <t>
        <list style="format ARCH-Req-%d:" counter="arch-req">
          <t>
            Supporting network slicing
          </t>
        </list>
      </t>
      
      <t>
        The 5GS fundamentally supports network slicing for provision the
        appropriate end-to-end communication to various services. In the
        relevant documents (e.g., <xref target="TS.23.501-3GPP"/>, <xref
        target="TS.28.530-3GPP"/>), a network slice is defined as virtual
        network and it is structured with 5GS NF instances, such as SMF, UPF
        including IP transport connectivity between RANs and DNS. Each network
        slice is independent and its user plane (including network functions and
        links) should be noninteractive against the others.
      </t> 

      <t>
        The 5G architecture specification has been updated with that Network
        Instance is defined as the glue of network slice between 5G slice and
        corresponding IP transport slice in addition to the original role of
        separating IP domains, which is described in <xref
        target="traffic-detection"/>.
      </t>
      
      <t>
         It has been appeared from version 15.2.0 of <xref target="TS.23.501-3GPP"/> 
         in section 5.6.12.
      </t>
      
      <t>
        UP underlay transport networks and UPFs may be shared by 5G slices, as
        described in section 4 of <xref target="TS.28.530-3GPP"/>. The data
        model defined in <xref target="TS.29.510-3GPP"/> allows that a Network
        Instance, a UPF and its interfaces can belong to multiple slices as same
        as other type of NFs. UP endpoint IP prefix/address of an interface can
        also be shared with multiple interfaces on the UPF as the model doesn't
        make them slice unique.
      </t>
      
      <t>
        The slice lifecycle managements is described in the relevant documents:
        <xref target="TS.28.531-3GPP"/>, <xref target="TS.28.532-3GPP"/>, and
        <xref target="TS.28.533-3GPP"/>. 
      </t>

      <t>
        <list style="format ARCH-Req-%d:" counter="arch-req">
          <t>
            End Marker support
          </t>
        </list>
      </t>

      <t>
        The construction of End Marker packets specified in <xref
        target="TS.23.501-3GPP"/>  may either be done in the CP/UP functions for
        indicating the end of the payload stream on a given UP tunnel. PDU
        packets arrive after an End Marker message on the tunnel may be silently
        discarded. For example, End Maker is used for handover procedures, and
        it can prevent reordering of arriving packets due to switch of anchor
        UPFs.
      </t>
    </section>

    <section title="Supporting 5G Services">


      <t>
      In the release 16 <xref target="TS.23.501-3GPP"/>, some specifications have been added to 
      support 5G specific services and communications. This section describes overviews of the 
      specifications relevant to use plane functionalities.
      </t>
    
      <t>
        <list style="format ARCHI-Req-%d:" counter="arch-req">
          <t>
          URLLC Support
          </t>
        </list>
      </t> 
      
      <t>
      The 5GS supports Ultra-Reliable Low Latency Communication (URLLC) for mission critical applications. 
      The User Plane features are described below.
      </t>

      <t>
        <list style="symbols">
          <t>
          Redundant UP transmission for URLLC
          </t>
        </list>
      </t>

      <t>
        The 5G is expected to support services which are latency sensitive
        and require high reliability. Communication to realize such
        services is called Ultra-Reliable and Low-Latency Communication or
        URLLC. In URLLC, redundancy of QoS flows is required for providing
        highly reliable communication. For instance, a set of UP NFs (e.g.,
        UPF or gNB) and interfaces between UE and DN are redundant, and
        packets are replicated and forwarded via each route. UEs and DN
        support dual connectivity and drop duplicated received packets. The
        scheme of packet dropping at UE is out of responsibility of 3GPP.
        The overview is shown in <xref target="fig_redundant-UP-1"/>.
      </t> 

      <figure anchor="fig_redundant-UP-1" title="Redundant UP paths using dual connectivity">
        <artwork align="center"><![CDATA[
                 ---+-----------+----------+---
                Namf|       Nsmf|      Nsmf|
                 +--+--+     +--+--+    +--+--+
                 | AMF |     | SMF1|    | SMF3|
                 +-+---+     +--+--+    +-+---+
                  /            /         /
               N2/          N4/       N4/
                /            /         /
          +----++   N3   +--+---+     / N6     +----+
          |M-RAN+--------+ UPF1 +--------------+    |
          ++-+--+        +-+--+-+   /          |    |
          /  |             |  |    /           |    |
  +----+ /   |             +--+   /            |    |
  | UE +<    |Xn            N9   /             | DN |
  +----+ \   |                  /              |    |
          \  |                 /               |    |
          ++-+--+   N3   +----+-+       N6     |    |
          |S-RAN+--------+ UPF2 +--------------+    |
          +-----+        +-+--+-+              +----+
                           |  |
                           +--+
                            N9
    *Legends
     M-RAN: Master RAN
     S-RAN: Secondary RAN

      ]]></artwork>
      </figure>
      
      <t>
        Otherwise, in case that RAN nodes and UPFs have enough reliability
        and they are not redundant by dual devices, reliable connectivity
        of QoS flows is provided by dual N3 tunnels between RAN and UPFs.
        Such tunnels are treated as individual ones, but they have the same
        sequence number. UP NFs identifies the duplication of PDU packets
        based on sequence number content in the UP tunnel headers. For
        uplink packets, a RAN node replicates each packet from a UE. An
        anchor UPF receives the duplicated packets, and drops
        ones which reach later in each duplicated packet pare. On the other
        hand, for downlink packets, a UPF replicates packets received from
        DN, and a RAN node drops the duplicated packets as well. The
        overviews of the ways are shown in <xref
        target="fig_redundant-UP-2"/>.
      </t>

      <figure anchor="fig_redundant-UP-2" title="Redundant UP transmission with two N3 tunnels">
              <artwork align="center"><![CDATA[
                ----+-----------+-----------+---
                Namf|       Nsmf|       Npcf|
                 +--+--+     +--+--+     +--+--+
                 | AMF |     | SMF |     | PCF |
                 +-+---+     +--+--+     +-----+
                  /             |
               N2/            N4|
                /  N3 Tunnel1   |
  +----+    +--+--+__________+--+--+  N6 +----+
  | UE +----+ RAN |__________| UPF |-----+ DN |
  +----+    +-----+          +-----+     +----+ 
                   N3 Tunnel2
      ]]></artwork>
      </figure>

      <t>
        In addition, there is a case that two intermediate UPFs (I-UPFs)
        between anchor UPF and RAN are used to support the redundant
        transmission based on two N3 and N9 tunnels between single anchor UPF
        and RAN node. The RAN node and anchor UPF support the packet
        replication and dropping of duplicated packets as described above.
        As described above, anchor UPF and RAN node detect packet duplication
        with sequence number of UP tunnels, and thus I-UPFs would forward
        the packets with the same sequence number on N3 and N9 tunnels. 
        The overview is shown in <xref target="fig_redundant-UP-3"/>.
      </t>

      <figure anchor="fig_redundant-UP-3" title="Redundant UP transmission with two I-UPF and N3/N9 tunnels">
        <artwork align="center"><![CDATA[
                ----+-------------+--------------+---
                Namf|         Nsmf|          Npcf|
                 +--+--+      +---+---+       +--+--+
                 | AMF |      |  SMF  +       | PCF |
                 +--+--+      +-+-+-+-+       +-----+
                   /            | | |
               N2 /           N4| | +----------------+
                 /              | |                  |
                /  N3 Tunnel1 +-+-+---+  N9 Tunnel1  |
               /        +-----+I-UPF1 +----+         |
  +----+   +--+--+______|     +-------+    |______+--+--+ N6  +----+
  | UE +---+ RAN |______          |         ______| UPF +-----+ DN |
  +----+   +-----+  N3  |     +---+---+    |  N9  +-----+     +----+
                        +-----+I-UPF2 +----+
                   N3 Tunnel2 +-------+  N9 Tunnel2
      ]]></artwork>
      </figure>

      <t>
        <list style="symbols">
          <t>
          Supporting QoS Monitoring for URLLC
          </t>
        </list>
      </t>

      <t>
      QoS monitoring is also required for URLLC. It means that the user plane should be able to 
      measure packet delay between anchor UPF and UE. The measurement would be in various granularities, 
      in the basis of per QoS Flow per UE, or per UP path for example.
      </t>

      <t>
      To help the measurement at anchor UPF and RAN, UP protocol requires to have capability to convey 
      necessary information to do that; such as time information at sending or reception of a measurement packet. 
      That information should exist in per F-TEID and QFI basis which indicates QoS Flow of the packet.  
      UP protocol should also be able to indicate which packets include the corresponding information for 
      each measurement.
      </t>

      <t>
        The QoS monitoring requirement has been appeared in section 5.33.3 of <xref
        target="TS.23.501-3GPP"/> from Rel-16, version 16.2.0.
      </t>
    
      <t>
        <list style="format ARCHI-Req-%d:" counter="arch-req">
          <t>
          Time Sensitive Communication Support
          </t>
        </list>
      </t> 

      <t>
        The 5GS supports Time Sensitive Communications (TSC) for realtime applications, 
        and it can be integrated transparently as a bridge in an IEEE 802.1 TSN network. 
        For TSN time synchronization, the E2E 5GS can be considered as a "time-aware system 
        (ref <xref target="IEEE-Std-802.1AS"/>)". The TSN Translators (TTs) at the edges of the 5GS need to 
        support the <xref target="IEEE-Std-802.1AS"/> operations. For instance, UE, gNB, NW-TT 
        (Network-side TSN Translator) and DS-TTs (Device-side TSN Translators) are synchronized with the 
        Grandmaster (GM) located in the 5GS. In addition, the TTs fulfill some functions related to 
        <xref target="IEEE-Std-802.1AS"/> (e.g., gPTP support, timestamping, rateRatio, etc.). An overview 
        of the 5G and TSN GM clock distribution model via the 5GS is shown in <xref target="fig_5g-tsn"/>.
      </t>


<figure anchor="fig_5g-tsn" title="An overview of the 5G and TSN GM clock distribution model">
        <artwork align="center"><![CDATA[
<-TSN-D->    <----          5G Time Domain              ---->  <-TSN-D->

                           +-----+                              +------+
                           |5G GM|                              |TSN GM|
                           +-----+                              +------+
                              |M                                    |M
                              |                   +---+-----+       VS
 +----+                       VS    ,--------.    |   |NW-TT|    ,-----.
 |End |   +-----+  +--+  Uu +---+  / PTP      \   |   +-----+   / TSN   \
 |Sta.|<==|DS-TT|<-|UE|<----|gNB|--|Compatible|-->|UPF      |<==|Working|
 +----+S M+-----+  +--+S   M+---+M \ 5G TN    /  S+---------+S M\ Domain/
                                    `--------'                   `-----'



 Legend
  TSN-D   : Non-3GPP TSN Domain
  TN      : Transport Network
  End Sta.: End Station
  <--     : 5GS timing direction
  <==     : TSN timing direction
  M       : Master
  S       : Slave
]]></artwork>
</figure>

    <t>
     In this model, two independent synchronizations are processing, and gNB only needs to be 
     synchronized to the 5G GM clock. To enable TSN domain synchronization, the 5GS calculates 
     and adds the measured residence time between the DS-TT and NW-TT into the Correction Field (CF) 
     of the synchronization packet of the TSN working domain. The details are described in section 5.27 
     in <xref target="TS.23.501-3GPP"/>.
     </t>

      <t>
      From this feature, UP functions and protocol are needed to support TSN specified in 
      <xref target="IEEE-Std-802.1AS"/> .
      </t>


      <t>
        <list style="format ARCHI-Req-%d:" counter="arch-req">
          <t>
          Cellular IoT Support
          </t>
        </list>
      </t> 

      <t>
      For supporting Cellular IoT (CIoT) (ref. <xref target="TS.22.261-3GPP"/>), optimizations of functionalities 
      of the 5GS is needed. CIoT is in earlier 3GPP release also referred to as Machine Type Communication (MTC). 
      Some of CIoT functionalities relevant to user plane are described in this section. The details of CIoT support 
      is described in section 5.31 in <xref target="TS.23.501-3GPP"/>. 
      </t>

      <t>
        <list style="symbols">
        <t>Non-IP Data Delivery (NIDD)</t>
        </list>
      </t>

      <t>
      The 5GS may support Non-IP Data Delivery (NIDD) to handle Mobile Originated (MO) and Mobile 
      Terminated (MT) communication for unstructured data. Thus, User Plane Protocol should be conveyable 
      such unstructured data units.
      </t>

      <t>
        <list style="symbols">
        <t>Reliable Data Service (RDS)</t>
        </list>
      </t>

      <t>
      Reliable Data Service (RDS) may be used for a PDU session of unstructured type. The service provides 
      a mechanism for the NEF or UPF to determine if the data was successfully delivered to the UE and for 
      the UE to determine if the data was successfully delivered to the NEF or UPF. 
      </t>

      <t>
      When the service is enabled, a protocol that uses a packet header to identify the requested 
      acknowledgement from peered end-point may be used between end-points of the PDU session. 
      In addition, port numbers in the header are used to identify the applications on the originator and 
      receiver. The UE, NEF and the UPF may support reservation of the source and destination port 
      numbers for their use and subsequent release of the reserved port numbers.
      </t>

      <t>
      Therefore, UP protocol is required to have fields for containing information to determine 
      normality of unstructured PDU sessions and used applications.
      </t>

       <t>
        <list style="symbols">
        <t>High Latency Communication</t>
        </list>
      </t>
      
       <t>
       Functions for High Latency Communication may be used to handle mobile terminated (MT) 
       communication with UEs being unreachable while using power saving functions. "High latency" 
       refers to the initial response time before normal exchange of packets is established. High latency 
       communication is supported by extended buffering of downlink data in the UPF, SMF or NEF 
       when a UE is using power saving functions in CM-IDL state and the UE is not reachable.
       </t>

       <t>
         <list style="symbols">
         <t>Small Data Rate Control</t>
         </list>
       </t>

       <t>
       The SMF may apply Small Data Rate Control for PDU sessions based on, for example, operator policy, 
       DNN, S-NSSAI, RAT type etc. The rate control may indicate following parameters in each of uplink 
       and downlink.
       </t>

      <t>
      <list style="hanging">
          <t hangText="- an integer number of packets per time unit"/>
          <t hangText="- an integer number of additional allowed exception report packets per time unit once the rate control limit has been reached"/>
      </list>
      </t>

      <t>
      The UE shall comply with this uplink rate control instruction. If the UE exceeds the uplink number of 
      packet per time, the UE may still send uplink exception report if allowed and the number exception 
      reports per time unit has not been exceeded. 
      </t>

      <t>
      For the UPF and NEF,  Small Data Rate Control is based on a maximum allowed rate per direction. 
      The UPF or NEF may enforce the uplink rate by discarding or delaying packets that exceed the 
      maximum allowed rate. The UPF or NEF shall enforce the downlink rate by discarding or delaying 
      packets that exceed the downlink part of the maximum allowed rate. 
      </t>

        <t>
         <list style="symbols">
         <t>User Plane CIoT 5GS Optimisation</t>
         </list>
       </t>

       <t>
       User Plane CIoT 5GS Optimization enables transfer of user plane data from CM-IDLE without the need 
       for using the Service Request procedure by negotiation between UE and AMF in advance. In case that 
       there are many devices being CM-IDLE state for long time, it would be better that User Plane Protocol i
       s session less.
       </t>
    </section>
 


     
    




<!-- Any more requirements? -->
                                                                        
      </section>
    </section>

          
    <section anchor="eval_aspects" title="Evaluation Aspects">
      <t>
        This section provides UP protocol evaluation aspects that are mainly we
        derived from the architectural requirements described in <xref
        target="arch"/>. Those aspects are not prioritized by the order here.
        Expected deployment scenarios explain the evaluations purpose in the
        corresponding aspects. 
      </t>
      
      <t>
        As we were noticed that the gaps between GTP-U specifications and 5G
        architectural requirements through the analysis, those each gap are
        briefly described in the evaluation aspect associated to it.
      </t>
      
      <t>
         Since it is obvious that 5G system should be able to interwork with
         existing previous generation based systems, any aspects from coexisting
         and interworking point of view are not particularly articulated here.
         It may be described in a next version.
      </t>

         <section anchor="eval-pdu" title="Supporting PDU Session Type Variations">
          <t>
            Given that UP protocol is required to support all PDU session types:
            IPv4, IPv6, Ethernet, and Unstructured. However, it is expected that
            some deployment cases allow candidate protocol to adopt only one or
            few PDU session type(s) for simplicity of operations. As we can
            expect that IPv4 connectivity services will be available through
            IPv6-only PDU session that enabled by bunch of IPv6 transition
            solutions already available in the field.
          </t>
            
          <t>
            For this, the expected evaluation points from this aspect should be
            whether there is substitutional means to cover other PDU session
            types. And how much it makes simple the system than deploying
            original PDU session types.
          </t>
        </section>

        <section anchor="eval-nature" title="Nature of Data Path">
          <t>
            As it is described in <xref target="archi-req"/>, the single PDU
            session multi-homing case requires multipoint-to-point (MP2P) data
            path. It should be much scalable than multi-homing with multiple PDU
            sessions because number of required path states in the UPFs are
            reduced as closed to egress endpoint. Against that point-to-point
            (P2P) protocol requires same number of states in each UPF throughout
            the path, and it could increase explosively the load on management of 
            tunnel states. 
          </t>
                   
          <t>
            From this point of view, the expected evaluation points from this
            aspect is whether the nature of candidate UP protocols are to
            utilize MP2P data path. Supporting MP2P data path by GTP-U could be
            a gap since GTP-U is a point-to-point tunneling protocol as it is
            described in <xref target="gtp-u"/>. 
          </t>
          
          <t>
            Noted that 3GPP CT WG4 pointed out GTP-U was already required to allow 
            one single tunnel endpoint to receive packets from multiple source 
            endpoints (<xref target="C4-185491-3GPP"/>). It was an architectural requirement of
            3GPP system from a previous generation. It means that MP2P data path
            requirement for UP protocol has been existed before the 5G system.
          </t>
             
        </section>

        <section anchor="eval-transport" title="Supporting Transport Variations">
          <t>
            The 5G system will be expected that the new radio spectrums in high
            frequency bands require operators to deploy their base stations much
            dense for much wider areas compare to previous generation
            footprints. To make sure that density and coverage, all available
            types of transport in the field must be employed between RAN to UPF,
            or UPF to UPF.
          </t>
          
          <t>
            It is also expected that MTU size of each transport could be varied.
            Because one could be own fiber which the operator configure the MTU
            size as they like while others are third-party provided L2/L3 VPN
            lines which MTU size can't be controlled by the operators. 
          </t>
     
          <t>
            The MTU between RAN and UPF can be discovered by offline means and 
            the operator takes into account the MTU that is transferable on the 
            radio interface and based on this the operator configures the right 
            MTU to be used. That is then signaled to the UE either via PCO (for 
            IPv4 case) or the IPv6 RA message (for IPv6 case).
          </t>
     
          <t>
            In addition, for cases that third-parties provide VPN lines, it would 
            be recommended MTU size discovery for each data path and dynamic MTU
            size adjustment mechanisms, while GTP-U does not support those
            mechanisms.
          </t>
          
          <t>
            As the study item in 3GPP mentioned, IPv6 is preferable address
            family not only for UEs, but also for the UP transport, in terms of
            size of available address space to support dense and wide footprint
            of base stations. However it increases header size from 20bytes to
            40bytes compare to IPv4. It could be a problem if the MTU size is
            uncontrollable, or only limited MTU size available to carry
            committed PDU size on the user plane.
          </t>
          
          <t>
            The expected evaluation points from this aspect should be that the
            candidate protocols are able to dynamically adjust path MTU size
            with appropriate MTU size discovery mechanism. It also should be
            that how the candidate protocols leverage IPv6 to deal with header
            size increasing.
          </t>
        </section>

        <section anchor="eval-datapath" title="Data Path Management">
          <t>
            As <xref target="archi-req"/> described, the 5G systems allows user
            plane that flexible UPF selection, multiple anchor UPFs, and no
            limit on how many UPFs chained for the data path of the PDU session.
            UPF deployments in the field will thereby be distributed to be able
            to optimize the data path based on various logics and service
            scenarios.
          </t>
          
          <t>
            That powerful user plane capability could make data path management through 
            the control plane, or operation support systems (OSS) be complicated and difficult. Perhaps it could
            be the case where the UP protocol nature is P2P and it only supports
            per session base data path handling. Therefore it would be better that UP protocol could support to 
            aggregate several PDU sessions into a tunnel or shall be a session-less tunnel.
          </t>
          
          <t>
            Because it increases data path states by number of sessions, and
            number of endpoints of UPFs that makes data path handling much
            hectic and the control plane tend to be overloaded by not only usual
            attach/detach/hand-over operations, but also existing session
            manipulation triggered by UPF and transport nodes/paths restoration,
            etc.,
          </t>
          
          <t>
            The expected evaluation points from this aspect should be that how
            much the candidate protocols can reduce data path management loads
            both on the control plane NFs and UPFs compare to the per session
            based handling for P2P paths. It could possibly include N3 and N6 in
            addition to N9 while it supports flexible user plane data path
            optimizations for some example scenarios.
          </t>
        </section>
  
        <section anchor="eval-qos" title="QoS Control">
          <t>
            The QoS model is based on QoS flows to which QFI indicates in the 5G
            system that allows multiple QoS flows are aggregated into a single
            PDU session. So that it is given that the UP protocol should convey
            QFIs for a PDU session and the UPF needs to lookup them. It makes
            sure that reflects QoS policy in the 5G system to corresponding
            forwarding policy in the user plane IP transports.
          </t>
             
          <t>
            The expected evaluation points from this aspect should be whether
            the candidate protocols can provide stable ID space for QFI which
            shouldn't be a big deal since QFI just requires 6-bits space.
          </t>
             
          <t>
            As we pointed out in <xref target="gtp-u-header"/>, the lookup
            process could impact UPF performance if the QFI container position
            in the header is unpredictable. It could happen many times along the
            path because the each UPFs should do it again and again in case that
            various different QoS policies are deployed in the networks under
            the UP as we discussed in <xref target="eval-transport"/>.
          </t>
             
          <t>
            As <xref target="TS.29.281-3GPP"/> updated in version 15.3.0, it is 
            recommended that the first extension header is the PDU session container 
            in which QFI is present.
          </t>          

        </section>
        
        
        <section anchor="eval-flow" title="Traffic Detection and Flow Handling">
          <t>
            As described in <xref target="UPF-Func"/>, UPF need to detect
            traffic flow specified by SMF within a PDU session, and enforce some
            processes to the PDU based on the pre-configured policy rule.
          </t>
          
          <t>
            As similar with QoS flow lookup described in <xref
            target="eval-qos"/>, UPFs along the path are repeatedly detecting an
            specified traffic flow in inner PDU. It could increase redundant
            flow detection load on every UPFs that could be avoided if the
            upstream UPF put some identifier which abstracts the detected flow
            into the packets. It enables following UPFs just find the ID to
            detect the indicated flow from the packet.
          </t>
          
          <t>
            The expected evaluation points from this aspect should be whether
            the candidate protocols can provide means to reduce that redundant
            flow detection that could be enough bits space on stable ID space to
            put abstracted detected flow identifier.
          </t>
        </section>

        <section anchor="eval-slice" title="Supporting Network Slicing Diversity">

          <t>
            Network Instance has been defined as the glue of network slice
            between 5G and IP transport in addition to IP domain separation, as
            described in <xref target="traffic-detection"/>. It is expected that
            SMF is able to configure UPF to send UP packet to corresponding
            transport slice by indicating Network Instance in FAR so that UPF
            can determine outgoing interface for the UP packet.
          </t>
          
          <t>
            It is assumed that IP transport networks are Network Instance
            agnostic, i.e., transport slices are independently instantiated and
            not bound to specific IP address space in the 5GC, for preventing
            increase of  routing table size.
          </t>

          <t>
            As a transport slice may be shared with multiple IP domains, Network
            Instance could be instantiated for all combination of IP domains and
            transport slice. To indicate those combination in UP packet over the
            wire, the 5G architecture expects VPN solutions as described in
            section 5.6.12 of <xref target="TS.23.501-3GPP"/>.
          </t>
          
          <t>
            Binding Network Instance with corresponding VPN would be varied per
            VPN solutions and FAR is not able to do. Hence it is out of
            scope of 3GPP and it may be covered by IETF, or other SDOs.
          </t>
          
          <t>
            Apart from binding, if it is the case where MPLS based VPNs, such as
            <xref target="RFC4364"/> and <xref target="RFC4664"/> are expected
            as the existing VPN solution which bound to Network Instance, there
            are some avaiable deployment options, such as 1). PE router
            integrates UPF, 2). CE router integrates UPF, 3). UPF connects to
            the VPN behind the CE router.
          </t>
            
          <t>
            Option 1 could work since all legacy MPLS or Segment Routing
            <xref target="RFC8402"/> based solution are available for both VPN
            and transport slicing at the UPF integrated PE router. However it is
            hard to expect it in multi-vendor deployment case, where the PE
            routers providing vendor is different from the vendor who provides
            UPFs, for example.
          </t>
          
          <t>
            Option 2 and 3 are expected as IP domain separation, but it
            is hard to see that it is able to indicate transport slice in
            addition to the IP domain. Other L2 and tunneling solutions should
            be same with those options.
          </t>

          <t>
            The expected evaluation points from this aspect should be whether
            the candidate protocols can contain forwarding information
            associated to the assigned IP domain and transport slice for all
            possible deployment cases.
          </t>

        </section>

        <section anchor="eval-urllc" title="Reliable Communication support">
        <t>
          As <xref target="archi-req"/> described, more than two UP
          paths are required for a QoS flow of a PDU session between the
          anchor UPF and gNB. Those UP paths are to convey redundant
          duplicated packets.
        </t>

        <t>
          To support reliable communication with above requirements, UPF
          and gNB must replicate the sending UP packets and eliminate
          the received duplicated UP packets. Not to mention that UP protocol
          should be able to make sure that the paths are not in fate
          sharing, the UP packet must have sequence number to indicate
          duplicate packets per QoS flow basis.
        </t>
        
        <t>
          The expected evaluation points from this aspect should be whether
          the candidate protocols can indicate packet sequence and diversed
          paths in the context of QoS flow, not in UP tunnel context. The
          packet sequence information should be transparent through
          I-UPF(s) exist in the middle of the path even in case that the UP
          tunnels are terminated at the I-UPF(s).
        </t>

      </section>


    </section>


    <section anchor="conclusion" title="Conclusion">
      <t>
        We analyzed the 3GPP specifications of the 5G architecture in terms of user
        plane and the current protocol adopted to the user plane. After the
        analysis work, we believe that the results described in this document
        shows that we reach at certain level of understanding on the 5G systems and
        ready to provide our inputs to 3GPP.
      </t>
      
      <t>
        We clarified GTP-U through the analysis and listed observed
        characteristics in <xref target="gtp-u-summary"/>. We also clarified the
        architectural requirements for UP protocol described in <xref
        target="archi-req"/>.
      </t>
        
      <t>
        Our conclusion here is that it is hopefull if the evaluation aspects 
        described in <xref target="eval_aspects"/> help for the study progress.
        It is worth to study possible candidate UP protocols for the 5G system 
        including current one based from the aspects.
      </t>
    </section>

    <section title="Security Consideration">
    <t>TBD</t>
    </section>
    
    
    <section title="Acknowledgement">
    <t>
      The authors would like to thank Tom Herbert, Takashi Ito, John Leddy,
      Pablo Camarillo, Daisuke Yokota, Satoshi Watanabe, Koji Tsubouchi and
      Miya Kohno for their detailed reviews, comments, and contributions.
    </t>
    
    <t>
      A special thank you goes to Arashmid Akhavain for his technical review and feedback.
    </t>
    
    <t>
      Lastly, the authors would like to thank 3GPP CT WG4 folks for their review and feedback.
    </t>

    </section>

  </middle>

  <!-- ***** BACK MATTER ***** -->

  <back>

<!--
    <references title="Normative References">

    &RFC2119;

    </references>
-->    
    <references title="Informative References">

    &RFC2460;
    &RFC4364;
    &RFC4664;
    &RFC4861;
    &RFC6437;
    &RFC6438;
    &RFC6935;
    &RFC7157;
    &RFC8200;
    &RFC8402;
<!--    &I-D.bogineni-dmm-optimized-mobile-user-plane;
-->
         
      <reference anchor='TR.29.891-3GPP' target="http://www.3gpp.org/FTP/Specs/2017-12/Rel-15/29_series/29891-f00.zip">
        <front>
        <title>3GPP TR 29.891 (V15.0.0): 5G System Phase 1, CT WG4 Aspects</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2017"/>
        </front>
      </reference>

      <reference anchor='TS.29.244-3GPP' target="http://www.3gpp.org/FTP/Specs/2018-03/Rel-15/29_series/29244-f40.zip">
        <front>
        <title>3GPP TS 29.244 (V15.1.0): Interface between the Control Plane and the User Plane Nodes; Stage 3</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2018"/>
        </front>
      </reference>

      <reference anchor='TS.29.281-3GPP' target="https://www.3gpp.org/ftp//Specs/archive/29_series/29.281/29281-g10.zip">
        <front>
        <title>3GPP TS 29.281 (V16.1.0): GPRS Tunneling Protocol User Plane (GTPv1-U)</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="September" year="2020"/>
        </front>
      </reference>

<!--
      <reference anchor='TS.23.203-3GPP'>
        <front>
        <title>Policy and Charging Control Architecture, 3GPP TS 23.203 v2.0.1</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2017"/>
        </front>
      </reference>

      <reference anchor='TS.23.401-3GPP' target="http://www.3gpp.org/ftp//Specs/archive/23_series/23.401/23401-e80.zip">
        <front>
        <title>3GPP TS 23.401 (V14.8.0): General Packet Radio Service (GPRS) enhancement for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 14</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="March" year="2018"/>
        </front>
      </reference>
-->
         
      <reference anchor='TS.23.501-3GPP' target="http://www.3gpp.org/ftp//Specs/archive/23_series/23.501/23501-g20.zip">
        <front>
        <title>3GPP TS 23.501 (V16.2.0): System Architecture for 5G System; Stage 2</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="September" year="2019"/>
        </front>
      </reference>

      <reference anchor='TS.23.502-3GPP' target="http://www.3gpp.org/FTP/Specs/2018-03/Rel-15/23_series/23502-f40.zip">
        <front>
        <title>3GPP TS 23.502 (V15.4.0): Procedures for 5G System; Stage 2</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2018"/>
        </front>
      </reference>

      <reference anchor='TS.23.503-3GPP'  target="http://www.3gpp.org/FTP/Specs/2018-03/Rel-15/23_series/23503-f40.zip">
        <front>
        <title>3GPP TS 23.503 (V15.4.0): Policy and Charging Control System for 5G Framework; Stage 2</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2018"/>
        </front>
      </reference>

      <reference anchor='TS.38.300-3GPP'  target="http://www.3gpp.org/FTP/Specs/2018-03/Rel-15/38_series/38300-f40.zip">
        <front>
        <title>3GPP TS 38.300 (v15.4.0): NR and NG-RAN Overall Description; Stage 2</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2018"/>
        </front>
      </reference>

      <reference anchor='TS.38.401-3GPP'  target="http://www.3gpp.org/FTP/Specs/2018-03/Rel-15/38_series/38401-f40.zip">
        <front>
        <title>3GPP TS 38.401 (v15.4.0): NG-RAN; Architecture Description</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2018"/>
        </front>
      </reference>

      <reference anchor='TS.38.415-3GPP'  target="https://www.3gpp.org/ftp//Specs/archive/38_series/38.415/38415-g20.zip">
        <front>
        <title>3GPP TS 38.415 (v16.2.0): NG-RAN; PDU Session User Plane protocol</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="October" year="2020"/>
        </front>
      </reference>

      <reference anchor='TS.22.261-3GPP'  target="http://www.3gpp.org/FTP/Specs/2018-03/Rel-15/22_series/22261-f70.zip">
        <front>
        <title>3GPP TS 22.261 (V15.7.0): Service requirements for 5G system stage 1</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2018"/>
        </front>
      </reference>

       <reference anchor='TS.29.561-3GPP'  target="http://www.3gpp.org/FTP/Specs/2018-06/Rel-15/29_series/29561-f10.zip">
        <front>
        <title>3GPP TS 29.561 (V15.1.0): 5G System; Interworking between 5G Network and external Data Networks; Stage 3</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="September" year="2018"/>
        </front>
      </reference>
         
       <reference anchor='TS.28.530-3GPP'  target="http://ftp.3gpp.org//Specs/archive/28_series/28.530/28530-f10.zip">
        <front>
        <title>3GPP TS 28.530 (V15.1.0): Management and orchestration of networks and network slicing; Concepts,
               use cases and requirements (work in progress)</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2018"/>
        </front>
      </reference>
         
      <reference anchor='TS.28.531-3GPP' target="http://ftp.3gpp.org//Specs/archive/28_series/28.531/28531-f10.zip">
        <front>
        <title>3GPP TS 28.531 (V15.1.0): Management and orchestration of networks and network slicing; Provisioning; Stage 1 (Release 15)</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2018"/>
        </front>
      </reference>

      <reference anchor='TS.28.532-3GPP' target="http://www.3gpp.org/ftp//Specs/archive/28_series/28.532/28532-f10.zip">
        <front>
        <title>3GPP TS 28.532 (V15.1.0): Management and orchestration of networks and network slicing; Provisioning; Stage 2 and stage 3 (Release 15)</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="Decempber" year="2018"/>
        </front>
      </reference>

      <reference anchor='TS.28.533-3GPP' target="http://www.3gpp.org/ftp//Specs/archive/28_series/28.533/28533-f10.zip">
        <front>
        <title>3GPP TS 28.533 (V15.1.0): Management and orchestration of networks and network slicing; Management and orchestration architecture (Release 15)</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2018"/>
        </front>
      </reference>
         
       <reference anchor='TS.29.510-3GPP'  target="http://www.3gpp.org/FTP/Specs/2018-06/Rel-15/29_series/29510-f20.zip">
        <front>
        <title>3GPP TS 29.510 (V15.2.0): 5G System; Network Function Repository Services; Stage 3</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2018"/>
        </front>
      </reference>

       <reference anchor='TS.29.274-3GPP'  target="http://www.3gpp.org/ftp//Specs/archive/29_series/29.274/29274-f40.zip">
        <front>
        <title>3GPP TS 29.274 (V15.4.0): 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunneling Protocol for Control plane (GTPv2-C); Stage 3</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="June" year="2018"/>
        </front>
      </reference>

      <reference anchor='TS.23.060-3GPP' target="http://www.3gpp.org/ftp//Specs/archive/23_series/23.060/23060-f30.zip">
        <front>
        <title>3GPP TS 23.060 (V15.3.0): General Packet Radio Service (GPRS); Service description; Stage 2</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="June" year="2018"/>
        </front>
      </reference>

      <reference anchor='CP-180116-3GPP'  target="http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_79_Chennai/Docs/CP-180116.zip">
        <front>
        <title>LS on user plane protocol study</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="March" year="2018"/>
        </front>
      </reference>

      <reference anchor='CP-173160-3GPP'  target="http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_78_Lisbon/Docs/CP-173160.zip">
        <front>
        <title>New Study Item on User Plane Protocol in 5GC</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="December" year="2017"/>
        </front>
      </reference>

      <reference anchor='C4-185491-3GPP'  target="http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_85bis_Sophia_Antipolis/Docs/C4-185491.zip">
        <front>
        <title>LS OUT on User Plane Analysis</title>
        <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
        </author>
        <date month="July" year="2018"/>
        </front>
      </reference>

      <reference anchor='IAB-Statement'  target="https://www.iab.org/2016/11/07/iab-statement-on-ipv6/">
        <front>
        <title>IAB Statement on IPv6</title>
        <author>
        <organization>
        Internet Architecture Board (IAB)
        </organization>
        </author>
        <date month="November" year="2016"/>
        </front>
      </reference>

      <reference anchor='IEEE-Std-802.1AS' target="https://www.ieee802.org/1/pages/802.1as.html">
        <front>
        <title>Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks</title>
        <author>
        <organization>
        Institute of Electrical and Electronics Engineers (IEEE)
        </organization>
        </author>
        <date month="March" year="2011"/>
        </front>
      </reference>


    </references>



  </back>

</rfc>
