5G/NR

 

 

 

5G LAN - 5G VN Group Communication

 

A normal PDU session connects a UE to a data network, and nothing else. Two UEs that want to talk to each other send their traffic out of the 5G core to the internet or to an enterprise network, and back in again. For a factory, a campus or a group of machines, that is the wrong shape. They want a private LAN, where devices see each other directly, with their own addresses, broadcast and multicast, as if they were on one Ethernet switch.

Release 16 added this as the 5G LAN-type service. The UEs that share such a private network form a 5G VN (Virtual Network) group. The 5G core then forwards traffic between the members inside the user plane, without a detour through an external network. The specification is TS 23.501 clause 5.29, with the user plane details in clause 5.8.2.13. This page goes through how a group is defined, how its PDU sessions are set up, and how the UPFs forward traffic between members.

Why does 5G need a LAN service ?

Why not just route the traffic through an external router ? Technically it works. Each UE has a PDU session, the traffic leaves the PSA UPF over N6, a router in the data network sends it back, and it enters the destination UE's session. But the path is longer than it needs to be, it depends on equipment outside 3GPP, and it handles only what that router handles. Industrial and enterprise users often need Ethernet frames, not just IP, and they rely on broadcast and multicast for discovery and control.

5G LAN-type service moves the switching into the 5G core. The UPF that anchors the sessions can forward a packet from one member directly to another member. If the members are anchored at different UPFs, the UPFs forward between themselves over N19, a UPF to UPF tunnel. And if a member device sits in the data network, N6 is still available. So a 5G VN group behaves like a private LAN or VPN, but the 5G system provides it.

  • 5G VN group: a set of UEs using private communication for 5G LAN-type services (23.501 clause 5.29.1).
  • IP or Ethernet: a member UE reaches the group through a PDU session of IP type or Ethernet type.
  • Unicast, broadcast, multicast: one PDU session carries all three for the group, and the PSA UPF decides which one from the destination address.
  • Typical users: industrial IoT, enterprise and campus networks, and private groups of devices. The service requirements are in TS 22.261.

5G VN group management

Who decides which UEs belong to a group, and what the group looks like ? 23.501 allows two ways. An operator can configure the group by OAM, or an AF can create and change it dynamically through the NEF. The NEF exposes services to add, delete and modify 5G VN groups, their members and their group data. In both cases the result is stored in the UDR, behind the UDM.

 

Part

Content

Group identity

External Group ID, used by the AF, and Internal Group ID, used inside the 5GC. The UDM maps one to the other and chooses the Internal Group ID for a new group

Membership

The members, each identified by GPSI. The AF can update the member list at any time

Group data

PDU session type, DNN, S-NSSAI, application descriptor, an indication that the group uses 5G VN group communication, information for secondary authentication, Maximum Group Data Rate, user plane security policy

 

The DNN and S-NSSAI are the most important items, because they are what ties a PDU session to the group. In this release only a 1:1 mapping between a (DNN, S-NSSAI) combination and a 5G VN group is supported. The DNN, S-NSSAI and user plane security policy cannot be changed after the group is first provisioned. An AF that wants different values creates a new group.

How does the UE learn the group's DNN and S-NSSAI ? Through URSP. The PCF reads the 5G VN group data from the UDR and learns the UE's Internal Group IDs from the AMF. It then builds URSP rules with the group configuration: DNN, S-NSSAI and PDU session type. It delivers them with the UE Configuration Update procedure. If the group data or the membership changes, the UDR notifies the PCF, and the PCF can update the URSP of the affected members. URSP is described in the Manage UE Policy page.

  • Two identities: the AF sees External Group IDs and GPSIs, and the 5GC uses Internal Group IDs. The UDM translates between them.
  • One home network: in this release, all members of a group have the same home network.
  • Same UDM group: all members are assumed to belong to the same UDM Group ID, so the NEF can pick one UDM instance for the whole group.
  • Subscription: the UDM gives the AMF and SMF the member's subscription with the 5G VN group data included. The UDM itself is described in the UDM page.

PDU sessions for a 5G VN group

Once a UE knows the group's DNN and S-NSSAI, it simply establishes a PDU session for them. There is no new session type and no special NAS message. Normal 5GS session management applies, with a few rules that make sure the group's sessions can be connected to each other in the user plane. The general procedure is described in the PDU Session Establishment page.

  • One group per session: a PDU session provides access to one and only one 5G VN group.
  • Same anchor network: all sessions of a group should anchor in the same network, the common home network of the members.
  • Dedicated SMF: one SMF, one SMF set or several SMF sets can be responsible for all PDU sessions of a group. With a single SMF or SMF set, the network is configured so that the same one is always selected. One way is to register the group's DNN and S-NSSAI in the NRF only for that SMF set.
  • Authentication: secondary authentication for the DNN and S-NSSAI can be used. Authorization for the DNN and S-NSSAI means authorization for the group, and there is no separate group authentication. See the PDU Session Authentication page.
  • Session continuity: SSC modes 1, 2 and 3 apply to N6-based forwarding within the group.

The reason for a dedicated SMF is the user plane. The SMF has to correlate all PDU sessions of the group, to know which UE is anchored at which UPF, and to configure the forwarding rules between them. 23.501 says it directly: to realise N19 forwarding with a single SMF or SMF set, the SMF correlates the sessions of the same group and configures each UPF with a group-level N4 session. A group-level N4 session belongs to the group, not to any single UE. It holds the rules for traffic to and from N19 and N6.

User plane - local switch, N19 and N6

Where does a packet from one member to another actually turn around ? 23.501 clause 5.29.4 defines three forwarding methods. The SMF can use all three for the same group at once, choosing per packet flow by the destination address. Figure 1 shows them together.

SMF : group-level N4 sessions PSA UPF 1 local switch PSA UPF 2 local switch N19 shared tunnel of the group UE A UE B UE C A to B DN device, router N6 A to B : local switch in UPF 1. A to C : UPF 1 to UPF 2 over N19. A to a DN device : N6.

Figure 1. The three forwarding methods of a 5G VN group. The SMF chooses among them by destination, and it prefers to anchor as many members as possible at one UPF, so that local switching is enough.

 

Method

When it applies

What the SMF configures

Local switch

Both members are anchored at the same PSA UPF

Rules in each member's own N4 session

N19-based

Members are anchored at different PSA UPFs of the same SMF or SMF set

A group-level N4 session in each involved UPF, with the N19 tunnels of the group

N6-based

The destination is in the data network, or the UPFs are connected only through the DN

Rules towards and from N6, optionally with an L2TP tunnel over N6

 

  • Prefer one UPF: the SMF may select a single PSA UPF for as many sessions of the group as possible, so that local switching handles the traffic. Before adding a new UPF, it can check whether a UPF already used by the group can serve the new session.
  • N19 on demand: N19 tunnels are set up when a new UPF joins the group, and released when a UPF has no more sessions of the group. Both happen within the group-level N4 session.
  • Mobility: when a member's PSA UPF changes and its address stays, the SMF moves the N19 rules for that member from the old UPF to the new one in all involved UPFs.
  • Unknown destination: the group-level N4 session can carry a lowest-precedence match-all rule that sends unknown destinations to N6, or drops them if N6 forwarding is not used.

The UPF role in general is described in the UPF page, and N6 in the N6 page.

How the UPF forwards - the 5G VN internal interface

A UPF normally has rules per PDU session: what comes in on a tunnel goes out on N6, and the reverse. How can such a rule send a packet into another UE's session ? 3GPP solved it with a virtual interface inside the UPF, called "5G VN internal", and a two-step lookup. The idea is close to a router that loops a packet back to its own forwarding table.

In the first step, a packet arrives from a member on its PDU session tunnel, on N19 or on N6. It matches a PDR whose FAR sends it to the 5G VN internal interface. In the second step, the packet is classified again, now with Source Interface set to 5G VN internal. This time it matches a PDR by its destination address. That PDR belongs either to the destination member's N4 session, for local switching, or to the group-level N4 session, for N19 or N6. Figure 2 shows the two steps.

PSA UPF Step 1 : N4 session of UE A PDR : access side, N3 TEID FAR : to 5G VN internal Step 2 : match on Source Interface = 5G VN internal UE B address : B's session UE C address : group N19 DN device : group N6 unknown : N6 or drop Network Instance = this 5G VN group from UE A, N3 to UE B, N3 to UPF 2, N19

Figure 2. Two-step forwarding in the UPF. Every packet of the group passes through the 5G VN internal interface once, and the second lookup decides whether it goes to a local member, to N19 or to N6.

  • Isolation between groups: when a PLMN has more than one 5G VN group, the PDRs and FARs on the 5G VN internal interface also carry a Network Instance that represents the group. A packet can therefore only be matched against rules of its own group.
  • Group-level N4 session: needed only when N19 forwarding is used. Without N19, the per-session rules and N6 are enough.
  • N4 based: all of this is ordinary PFCP rules (PDR, FAR) with new interface values, so the UPF needs no separate switching protocol.

Broadcast, multicast and Ethernet

A LAN is not only unicast. Devices use broadcast to find each other and multicast to send the same data to several receivers. How does a UPF copy one packet to many members across local switching, N19 and N6 ? 23.501 clause 5.8.2.13.3 gives two ways, and the SMF chooses which to use.

The first way uses UPF internal functionality. For Ethernet sessions, the UPF replicates frames as it does for Ethernet PDU sessions in general. For IP sessions, the UPF handles IP multicast with IGMP and MLD, reusing the mechanism TS 23.316 defined for wireline access. The second way uses explicit N4 rules. The SMF installs PDRs that match the broadcast or multicast address on the 5G VN internal interface, with an instruction to continue matching and to duplicate the packet. Each member's N4 session then gets a copy, and the group-level session sends copies to each N19 peer and to N6.

  • No echo to the sender: the per-member PDR carries packet replication skip information with the member's own address, so the source UE does not receive its own broadcast. The same skip logic stops a packet that came from N19 or N6 from going back the same way.
  • Conditions for the PDR method: N19 tunnels must form a full mesh between the UPFs of each SMF set, and each UPF has one N6 instance or none. Broadcast or multicast from a source address unknown to the SMF and UPF is not forwarded.
  • Multicast membership: for multicast, the SMF also installs PDRs that detect IGMP or MLD messages and asks the UPF to report joins and leaves. It then adds or removes the multicast PDRs for that member.
  • Ethernet unicast: the SMF can configure downlink PDRs with MAC addresses that the UPF detects and reports, acting as a central controller that avoids loops. Alternatively it can let the UPF learn MAC addresses itself, where the group's sessions are not interconnected by N19. 23.501 warns that explicit MAC configuration can cause N4 signalling scalability issues for large groups.
  • VLAN: for Ethernet sessions, the SMF can tell the UPF to classify frames by VLAN tag, and to add or remove VLAN tags, on N6, N19 or the 5G VN internal interface.

Limits and later extensions

Release 16 created the service, and later releases extended it. The version of 23.501 used for this page is v20.3.0, so it contains all those additions, and the clauses do not mark which release each sentence comes from. The list below separates the stated limits, which 23.501 still marks with "in this Release", from features that are present in the current text. For the second group, my understanding is that most of them came after Release 16, but this page does not verify each one against the Release 16 version of 23.501.

  • Same home network: all members of a group have the same home network.
  • One group per DNN and S-NSSAI: only a 1:1 mapping between a (DNN, S-NSSAI) combination and a 5G VN group.
  • Fixed DNN, S-NSSAI and security policy: these cannot be modified after the group is first provisioned.
  • Multiple SMF sets: for a group spread over an area larger than any SMF set serves, several SMF sets can control the sessions. Forwarding between UPFs of different SMF sets then uses OAM-configured tunnels on N6 or N19, which can be GTP-U or an IETF VPN, and the details are left to implementation.
  • Group QoS and service area: an AF can configure QoS, a service area and traffic characteristics for a group. The group data can also carry a Maximum Group Data Rate, which the PCF enforces across the group.
  • Group-wide traffic routing: with N6 forwarding, an AF can steer the traffic of all members to suitable DNAIs, and with a traffic correlation indication ask for one common DNAI for the whole group.

The release overview is in the Release 16 page, and the session anchor and SMF roles in the SMF page.

Reference