ANUP Implementation in 5G with BGP Signaling

Introduction The Access Node User Plane (ANUP) Network Function in 6G as proposed in integrates co-located Access Node and UPF function into a single NF, so that signaling can significantly simplified and data plane significantly optimized because no N3 tunneling is needed anymore. The signaling simplification is only expected in 6G. In 5G, the data plane optimization can still be realized with integrated AN and UPF function even though separate N2 and N4 signaling are still used. The ANUP can run N2 to AMF and N4 to SMF simultaneously, and the correlation of N2 and N4 signaling allows the ANUP to install UL/DL forwarding state w/o GTP tunneling: UL traffic is directed into to the routing instance for the DN after Access Network encapsulation header (e.g. radio protocol headers) is removed, as if the GTP-U header was removed on a traditional UPF. For DL traffic in the routing instance for the DN, a route lookup produces Access Network encapsulation information (e.g. radio protocol headers) for a PDU session, as if the traffic just arrived via GTP-U and the TEID was used to produce the same information. While the above work with separate N2/N4 signaling on the same ANUP, it does require the SMF to interfaces with many ANUPs - a changed deployment model. An alternative is to use the MUP Gateway architecture described in , in which the SMF only interfaces a few apparent central UPFs, though a "central UPF" is actually a collection of a MUP controller and a set of distributed MUP GWs and MUP PEs.

ANUP with MUP Controller and BGP Signaling In this model, the ANUP is the integration of an Access Node (e.g., gNB) and a MUP GW. GTP/N3 tunneling is no longer needed - DL traffic in the routing instance for the DN routes directly to radio protocol encapsulation for the session, and UL traffic is directed to the VRF for the DN after the radio protocol encapsulation is removed.

With Route Lookup in the DN Routing Instance For UL traffic, the <UPF address, TEID> tuple received in N2 signaling for a PDU session is matched against a Session Transformed Route Type 2 (ST2) route to determine the routing instance for the PDU session's DN, and UL traffic is then directed to the routing instance for further route lookup. For DL traffic, the <AN address, TEID> tuple sent in N2 signaling for the PDU session is matched against a Session Transformed Route Type 1 (ST1) route to install a UE prefix route in the routing instance with the forwarding nexthop being radio protocol encapsulation for the PDU session.

Avoiding DL Route Lookup With the MUP GW architecture, DL traffic arriving on a MUP GW may be with an SRv6 destination address with the End.GTP4/6.E behavior. The MUP GW would construct a GTP-U header accordingly and send encapsulated traffic to the AN. With an ANUP integrating a MUP GW and AN, there is no need for GTP-U - the SRv6 end point behavior would be a new one that directly maps the decapsulated traffic to the radio protocol encapsulation information for the PDU session identified by the TEID in the SRv6 address. Notice that the TEID is allocated by the ANUP and sent in the N2 signaling (and then signaled back via ST1 route). In case of MPLS, the DL traffic starts with a GTP-U header (after the MPLS label stack). The TEID in the header, like in the SRv6 case, identifies the PDU session so the packet can be forwarded directly w/o inner header lookup or GTP-U encapsulation. This is as if the GTP-U tunnel was replaced with an SRv6/MPLS tunnel. Note this can happen with or without a routing instance for the DN.

Avoiding UL Route Lookup Similarly, UL route lookup may also be skipped. For a PDU session, the <UPF address, TEID> tuple received in the N2 signaling is matched against an ST2 route, which carries information for the DN. If there is no local routing instance for the DN, a Direct Segment Discovery route from a remote MUP PE is matched and PDU session traffic is forwarded to that remote MUP PE according to the Direct Segment Discovery route.

Security Considerations There are no additional security implications compared to the MUP architecture in and .

Acknowledgements The authors thank Arda Akman and Constantine Polychronopoulos for their review/comments/suggestions to make this document and solution more complete.