Internet DRAFT - draft-tjiang-dmm-5g-dupf-5mbs

draft-tjiang-dmm-5g-dupf-5mbs







dmm                                                             T. Jiang
Internet-Draft                                              China Mobile
Intended status: Informational                                    L. Han
Expires: 10 September 2023                   Futurewei Technologies, Inc
                                                            9 March 2023


   5G Distributed UPFs for 5G Multicast and Broadcast Services (5MBS)
                    draft-tjiang-dmm-5g-dupf-5mbs-01

Abstract

   The drafts [I-D.zzhang-dmm-5g-distributed-upf] and
   [I-D.zzhang-dmm-mup-evolution] have described the 5G mobile user
   plane (MUP) via the refinement of distributed UPFs and a more radical
   proposal by integrating gNB & UPF as a single network function (NF).
   Some user plane implementation requirements that vendors and
   operators are exploring are not introducing changes to 3GPP
   architecture & signaling, if possible.  The document 3GPP TS 23.247
   [_3GPP-23.247] for 5G multicast and broadcast services, or 5MBS,
   specifies the 5GS architecture to support MBS communication.  Thanks
   to the addition of new 5GS network functions (NFs) and MB-interfaces
   on 5G CP & UP, specifically if coupled with the increasingly popular
   satellite-related requirements, these would certainly post additional
   provisioning & implementation challenges to the underlay transport
   infrastructure.

   This document is not an attempt to do 3GPP SDO work in IETF.
   Instead, it discusses how to potentially integrate distributed UPFs
   with the delivery of 5MBS communication, as well as the benefits of
   using distributed UPFs to handle 5MBS traffic delivery.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 10 September 2023.



Jiang & Han             Expires 10 September 2023               [Page 1]

Internet-Draft              5G dUPFs and 5MBS                 March 2023


Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Distributed UPFs in 5G User Plane . . . . . . . . . . . . . .   2
   2.  5G Multicast and Broadcast Services (5MBS)  . . . . . . . . .   4
   3.  Challenges in 5G MBS Communication  . . . . . . . . . . . . .   5
     3.1.  5MBS Transport Challenges . . . . . . . . . . . . . . . .   5
     3.2.  5MBS UP Signaling Challenges  . . . . . . . . . . . . . .   5
     3.3.  5MBS Challenges in Satellite Communication  . . . . . . .   6
   4.  5G Distributed UPF for 5G MBS Implementation  . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Distributed UPFs in 5G User Plane

   Mobile User Plane (MUP) in 5G has two distinct parts: the Access
   Network part between UE and gNB, and the Core Network part between
   gNB and UPF.  UPFs are traditionally deployed at central locations,
   with UEs' PDU sessions encapsulated and extended thru GTP-U tunnels
   via the N3 (and potentially N9) interfaces in 5GS.  The interface N6
   supports fundamentally a direct IP or Ethernet connection to the data
   network or DNN.

   Actually, UPFs could be distributed & deployed closer to gNBs.
   The draft [I-D.zzhang-dmm-5g-distributed-upf] has described the 5G
   mobile user plane (MUP) via the refinement of distributed UPFs or
   dUPFs.  The following picture shows the dUPF architecture:







Jiang & Han             Expires 10 September 2023               [Page 2]

Internet-Draft              5G dUPFs and 5MBS                 March 2023


                             N3             N6
       UE1          gNB1      |     dUPF1    |
   +---------+                |+------+-----+|
   |   PDU   |                || PDU  |     ||      PE1
   +---------+ +------+------+|+------+ IP/ ||    +-----+--+
   |         | |      |GTP-U |||GTP-U |     ||----+ IP/ |  |
   | 5G-AN   | |5G-AN +------+|+------+Ether||    |Ether|  |
   | xHaul   | |xHaul |L3/2/1|||L3/2/1|     ||    +-----+--+
   +---------+ +------|------+|+------------+|   (          )
                              |              |  ( Transport  )  PE3
                              |              |  (  Network   +--+-----+
       UE2          gNB2      |     dUPF2    |  (            |  | IP/ |
   +---------+                |+------+-----+|  (   (DN)     |  |Ether|
   |   PDU   |                || PDU  |     ||   (           +--+-----+
   +---------+ +------+------+|+------+ IP/ ||    +-----+--+
   |         | |      |GTP-U |||GTP-U |     ||    | IP/ |  |
   | 5G-AN   | |5G-AN +------+|+------+Ether||    |Ether|  |
   | xHaul   | |xHaul |L3/2/1|||L3/2/1|     ||    +-----+--+
   +---------+ +-------------+|+------------+|      PE2

   In distributed UPF architecture, the central (PSA) UPF is no longer
   needed. dUPF1 and UPF2 connect via PE1 and PE2, respectively, to the
   DN VPN (or network instance/NI) that UE1 and UE2 intend to access.
   There could exist other PEs, like PE3 in the picture, for other sites
   of the same network domain(VPN or NI) or for global Internet access.

   There are some benefits of distributed UPFs:

   *  The N3 interface becomes very simple - over a direct or short
      transport connection between gNB and dUPF.

   *  The transport infrastructure off N3/N9 and N6 are straightforward,
      most likely over the same underlay VPN (MPLS, SR-MPLS or SRv6)
      supporting the traditional N3/N9 tunneling as in centralized PSA
      UPF case.

   *  MEC becomes much simpler since no need to deploy centralized PSA
      UPF plus ULCL UPFs; UE-UE traffic can be optimized for LAN-type
      services (via host-route).

   In short, the distributed UPFs model achieves "N3/N9/N6 shortcut and
   central UPF bypass", which is desired by many operators.









Jiang & Han             Expires 10 September 2023               [Page 3]

Internet-Draft              5G dUPFs and 5MBS                 March 2023


2.  5G Multicast and Broadcast Services (5MBS)

   The 3GPP document TS 23.247 [_3GPP-23.247] for 5G multicast and
   broadcast services, or 5MBS, specifies the 5GS architecture to
   support MBS communication.  The following picture shows the brief
   system architecture of 5MBS:

                ----+----------(SBA for 5GC) ---------+-----
                    |          |                      |
                 +--+--+   +---+---+              +---+----+
                 | AMF |   |  SMF  |              | MB-SMF |
                 +--+--+   +-+-+-+-+              +---+----+
                   /           |                      |
               N2 /         N4 |                  N4mb|
                 /             |                      |
                /    N3    +-+-+---+     N19mb    +---+----+ N6mb +----+
           +-----+---------+  UPF  +--------------| MB-UPF |------| DN |
  +----+   |     |         +-------+ (Individual) +---+----+      +----+
  | UE +---+ gNB |                                    |
  +----+   +-----+                                    |
                 |_________N3mb (shared delivery)_____|

   TS 23.247 [_3GPP-23.247] adds new 5GS network functions (NFs) on both
   5G control-plane (CP) and user-plane (UP).  For example, the CP NF
   MB-SMF is, in collaboration with the regular SMF, to provision and
   signal to the UP NF MB-UPF (via the interface N4mb) for setting up
   MBS delivery path.

   5MBS has specified two data delivery modes, individual delivery vs.
   shared delivery:

   *  Individual delivery: When the (downlink or DL) MBS packets are
      received by the MB-UPF from the interface N6mb, MB-UPF replicates
      & forwards those packets towards (multiple) UPFs, via the
      interface N19mb, through either unicast (requiring multiple GTP
      tunnels if unicast underlay transport is applied) or multicast (if
      multicast underlay transport over N19mb is applied) transmission.

   *  Shared delivery: When the (DL) MBS packets are received by the MB-
      UPF from N6mb, MB-UPF replicates & forwards those packets towards
      (multiple) gNBs, via the interface N3mb (the lower-path in the
      picture), through either (multiple) separate GTP tunnels if
      unicast underlay transport over N3mb is applied, or a single GTP
      tunnel if multicast underlay over N3mb is supported.







Jiang & Han             Expires 10 September 2023               [Page 4]

Internet-Draft              5G dUPFs and 5MBS                 March 2023


3.  Challenges in 5G MBS Communication

3.1.  5MBS Transport Challenges

   The 5MBS architecture in TS 23.247 [_3GPP-23.247] introduces some
   network challenges:

   *  Because of the addition of new CP and UP NFs, this will post
      additional provisioning & implementation challenges to the
      underlay transport infrastructure.  For example, in the individual
      delivery mode, both SMF and MB-SMF have to synchronize with each
      other to help set up the relay/stitching path between UPF, MB-UPF
      and DN.

   *  The picture in previous section shows three new interface types
      corresponding to three different segments: N3mb, N6mb and N19mb.
      Based on the traffic delivery mode, once MB-UPF receives DL
      traffic from N6mb, it will have to do either individual or shared
      delivery.

   *  In accordance with TS 23.247 [_3GPP-23.247], the underlay
      transport infrastructure of all three segments can use either
      unicast or multicast transmission, based on the capabilities of
      underlay networks.  For example, for the DL _shared_ delivery from
      MB-UPF to gNB via the interface N3mb, 5G MBS packets can be
      transmitted to multiple gNBs via multicast transmission if the
      underlay network supports.  Otherwise, MB-UPF will have to use
      unicast to transmit separately to (multiple) gNBs.  Considering
      that this unicast/multicast flexibility is applicable to all the
      three above-mentioned segments, the implementation will have to
      face more challenges.

3.2.  5MBS UP Signaling Challenges

   The user plane from the MB-UPF to gNB directly (i.e., the lower-path
   in the above figure for the shared delivery) and the user plane from
   the MB-UPF to UPFs then to gNB (i.e., the upper path in the figure
   for individual delivery) may use IP multicast transport via a common
   GTP-U tunnel per MBS session, or use unicast transport via separate
   GTP-U tunnels at gNB or at UPF per MBS session.  When using the IP
   multicast transport, GTP-U Multicast Tunnels shall be used for
   unidirectional transfer of the encapsulated T-PDUs from one GTP-U
   Tunnel Endpoint (i.e., acting as the sender) to multiple GTP-U Tunnel
   Endpoints (i.e., acting as receivers).  The Common Tunnel Endpoint ID
   (C-TEID) which is present in the GTP header shall indicate which
   tunnel a particular T-PDU belongs to.  The C-TEID value to be used in
   the TEID field shall be allocated at the source Tunnel Endpoint
   (e.g., the sender) and signaled to the destination Tunnel Endpoints



Jiang & Han             Expires 10 September 2023               [Page 5]

Internet-Draft              5G dUPFs and 5MBS                 March 2023


   (e.g., receivers) using a control plane protocol, e.g., GTPv1-C &
   GTPv2-C.  One C-TEID shall be allocated per MBMS bearer service or
   per MBS session [_3GPP-23.247][_3GPP-29.281].  As we have explained
   in the draft [I-D.zzhang-dmm-mup-evolution], the signaling overhead
   to establish a N3 GTP unicast tunnel has reached seven steps, let
   alone the case of the more complicated MBS tunnel creation.

3.3.  5MBS Challenges in Satellite Communication

   The 5G service via the satellite constellation has become a popular
   topic in 3GPP.  There are currently three major satellite-related
   projects in SA workgroups, i.e., the satellite access (SAT_Ph2)
   [_3GPP-23.700-28] and the satellite backhaul (SATB) [_3GPP-23.700-27]
   in SA2 as well as the Phase-3 enhancement via the satellite-based
   store-and-forward technology (SAT_Ph3) in SA1 WG [_3GPP-22.865].
   These projects study various 5GS requirements when either a gNB or a
   UPF or both are on-board satellites.  Evidently, the continuously-
   moving satellite constellations introduce another dimension of
   challenges to UE registration, session management and traffic
   routing.  The GTP-U tunnel end points have to be changed frequently
   when the satellite providing the on-board service for a UPF rotates
   away from the corresponding gNB of the same GTP-U tunnel.  For the
   SAT_access case, the ground station (GS) has to find a new gNB on-
   board another satellite every couple of minutes (e.g., being around
   7-8 minutes for the LEO category) to hand over UEs.  There are
   significantly large amount of singalling messages involved even for
   unicast case via satellite constellation, let alone if we extend the
   similar scenarios to 5G MBS communication.

4.  5G Distributed UPF for 5G MBS Implementation

   The REQ8 of [RFC7333] talks about the multicast efficiency between
   non-optimal and optimal routes, where it states that, in term of
   multicast considerations, DMM SHOULD enable multicast solutions to be
   developed to avoid network inefficiency in multicast traffic
   delivery.

   The current 5MBS architecture requires all DL multicast traffic go
   through the (centralized) MB-UPF, regardless of using the individual
   or shared delivery.  In many operators' networks, 5GS might be
   deployed in a location that is distant from customer sites.  If the
   deployed site happens to be on-board satellites, the additional
   complexities and moving dynamics will certainly worsen the
   operations.  In these scenarios, the efficiency of multicast
   transmission will be compromised.  On the other aspect, a 5G dUPF
   deployed closer to gNB, or even more radically applying 'ANUP' via
   the possible integration of gNB & UPF [I-D.zzhang-dmm-mup-evolution],
   might lead to more efficient implementation:



Jiang & Han             Expires 10 September 2023               [Page 6]

Internet-Draft              5G dUPFs and 5MBS                 March 2023


   *  For shared delivery, the MB-UPF can be distributed closer to or
      integrated with gNB, i.e., either dUPF or ANUP-like.  The N6mb is
      a normal IP interface which is connected to DN over underlay
      network.  This transport connection will most likely use the VPN
      infrastructure that has been provisioned by operators for 5GS.  As
      a dUPF or ANUP, the N3mb tunnel off MB-UPF could be made much
      simpler.  In some field edge sites, a dUPF could co-locate on-prem
      with gNB, which can even remove the usage of complex (inter-site)
      VPN to favor native IP transport.

   *  For individual delivery, it involves two UPFs, one regular UPF and
      one MB-UPF.  To follow the current 3GPP specification, we can
      distribute and deploy both UPFs closer to gNB.  While the DL
      traffic off the N6mb interface may achieve the same gain as in the
      shared-delivery mode, the transport for the N19mb tunnel and the
      (regular) N3 tunnel can be significantly simplified.  Remember we
      have mentioned previously that either unicast or multicast
      (underlay) transmission can be used for N19mb (and actually also
      for N6mb and N3mb).  Therefore, applying dUPF or, possibly ANUP in
      future, will help simplify the N19mb VPN transmission.

   *  For individual delivery, if we expand the scope beyond the current
      3GPP spec., e.g., looking beyond the 5G or even 6G roadmap that
      are already on the horizon of the 3GPP planning, we could
      integrate the regular UPF and MB-UPF together as a distributed
      UPF, and then deploy the dUPF closer to gNB.  Of course, we might
      even take one step further by integrating both UPFs (UPF and MB-
      UPF) and gNB as a single 'logical' node, i.e., ANUP
      [I-D.zzhang-dmm-mup-evolution].  Regardless, in either scenario,
      both the N19mb and N3 tunnels can be simplified, or even
      consolidated, significantly, TS 23.247 [_3GPP-23.247] specifies
      the behaviors of MB-UPF, as a standalone NF.  Indeed, all the
      features and behaviors that would be implemented by a MB-UPF can
      be collaboratively integrated into a regular UPF.  This type of
      'merging' should lead to more network efficiency and better
      multicast traffic forwarding, conforming to the [RFC7333] REQ8.

   When we take into consideration the above plausible arguments and
   accordingly apply them to different 3GPP satellite-related projects,
   e.g., SATB (backhaul), SAT_Ph2 & SAT_Ph3 (access), we can certainly
   draw the conclusion that the extra burden of signalling messages, the
   complexity of control plane as well as the excessive encapsulations
   of user plane, as introduced by 5MBS, can be relieved dramatically.

   Both drafts [I-D.zzhang-dmm-5g-distributed-upf]
   [I-D.zzhang-dmm-mup-evolution] discussed and compared briefly
   different tunneling mechanisms to implement the 3GPP GTP-U UP, i.e.,
   SRv6, MPLS as the underlay, or in [I-D.mhkk-dmm-srv6mup-architecture]



Jiang & Han             Expires 10 September 2023               [Page 7]

Internet-Draft              5G dUPFs and 5MBS                 March 2023


   specifying a new SRv6 based MUP architecture to replace the GTP-U.
   While these proposals may experience different issues upon 5MBS
   transport implementation, the application of distributed or
   'integrated' UPF might make it more feasible.

5.  Security Considerations

   TBD.

6.  IANA Considerations

   This document requests no IANA actions.

7.  References

7.1.  Normative References

   [RFC7333]  Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
              Korhonen, "Requirements for Distributed Mobility
              Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
              <https://www.rfc-editor.org/info/rfc7333>.

7.2.  Informative References

   [I-D.mhkk-dmm-srv6mup-architecture]
              Matsushima, S., Horiba, K., Khan, A., Kawakami, Y.,
              Murakami, T., Patel, K., Kohno, M., Kamata, T., Camarillo,
              P., Horn, J., Voyer, D., Zadok, S., Meilik, I., Agrawal,
              A., and K. Perumal, "Segment Routing IPv6 Mobile User
              Plane Architecture for Distributed Mobility Management",
              Work in Progress, Internet-Draft, draft-mhkk-dmm-srv6mup-
              architecture-04, 24 October 2022,
              <https://datatracker.ietf.org/doc/html/draft-mhkk-dmm-
              srv6mup-architecture-04>.

   [I-D.zzhang-dmm-5g-distributed-upf]
              Zhang, Z. J., Patel, K., Jiang, T., and L. M. Contreras,
              "5G Distributed UPFs", Work in Progress, Internet-Draft,
              draft-zzhang-dmm-5g-distributed-upf-01, 11 July 2022,
              <https://datatracker.ietf.org/doc/html/draft-zzhang-dmm-
              5g-distributed-upf-01>.










Jiang & Han             Expires 10 September 2023               [Page 8]

Internet-Draft              5G dUPFs and 5MBS                 March 2023


   [I-D.zzhang-dmm-mup-evolution]
              Zhang, Z. J., Patel, K., Contreras, L. M., Islam, K.,
              Mutikainen, J., Jiang, T., Jalil, L., and O. P. Sejati,
              "Mobile User Plane Evolution", Work in Progress, Internet-
              Draft, draft-zzhang-dmm-mup-evolution-03, 4 February 2023,
              <https://datatracker.ietf.org/doc/html/draft-zzhang-dmm-
              mup-evolution-03>.

   [_3GPP-22.865]
              "Study on satellite access - Phase 3; Rel-19; V0.3.0",
              February 2023.

   [_3GPP-23.247]
              "Architectural enhancements for 5G multicast-broadcast
              services; V18.0.0", December 2022.

   [_3GPP-23.700-27]
              "Study on 5G System with Satellite Backhaul; V18.0.0",
              December 2022.

   [_3GPP-23.700-28]
              "Study on Integration of satellite components in the 5G
              architecture; Phase 2; V18.0.0", December 2022.

   [_3GPP-29.281]
              "General Packet Radio System (GPRS) Tunnelling Protocol
              User Plane (GTPv1-U); V17.4.0", September 2022.

Authors' Addresses

   Tianji Jiang
   China Mobile
   Email: tianjijiang@chinamobile.com


   Lin Han
   Futurewei Technologies, Inc
   Email: lhan@futurewei.com













Jiang & Han             Expires 10 September 2023               [Page 9]