Probably the quirkiest architecture specified for EPC was the support for the untrusted non-3GPP access network. The most sought-after use-case for this architecture was the VoWiFi. But, VoWiFi never gained notable traction due to two major flaws in the EPC architecture.
Firstly, in EPC, a mobile device doesn’t have session continuity when moving between 3GPP and non-3GPP access networks; neither UE controlled (idle-mode) nor network controlled (connected-mode) is supported. It is because the ePDG has no reference-point with MME. Secondly, the SWn interface between the ePDG and non-3GPP access is an IPSEC ESP tunnel; therefore, DiffServ (DSCP) value in the IP header needs to carry the QoS parameter. In many cases, the non-3GPP access provider may not honor an external DSCP value and reset to default -BE (best effort).
Luckily, 3GPP addressed these issues considerably in 5G, resulting in completely overhauled architecture for interworking with untrusted non-3GPP access.
Like many functions in 5GC replacing nodes in EPC, the N3IWF supplanted the ePDG and surprisingly there are more differences than the similarities among them.
An N3IWF has both N2 and N3 with AMF and UPF respectively, which is the same as a 5GNR -a gNB. So, N3IWF is more like a gNB than an ePDG. Implementation of both N2 is identical, each using SCTP as a transport protocol; though in specification NGAP is associated with gNB while N3GPP for N3IWF. Due to this striking similarity, network-controlled mobility is possible in 5GC. Since there is no reference-point defined between 3GPP and non-3GPP access, UE controlled or RAN controlled (Xn Handover) mobility is not possible.
The reference-point Y2 is similar to SWn in EPC, but with another remarkable difference. The Y2 uses IPSEC over GRE. So like GTP, the GRE header can carry QoS value in one of the “Key” fields. As a result, user-plane traffic (Y1, sent over Y2) is not subject to the access provider’s QoS enforcement policy.
It is hard to predict whether the enhancement mentioned so far will bring back VoWiFi into the spotlight. But, It certainly posed an incredible opportunity for the grand unification of fixed triple-play and mobile services — few other 5G features (not related to non-3GPP access) contributing to this possibility worth mention here.
The 5G supports the “Ethernet” type PDU session. A DNN (aka APN) in 5GC with PDU type Ethernet is a virtual Bridge Domain (aka VLAN). An Ethernet DNN can transparently transport multicast traffic. Such DNN is suitable for IPTV service; the IGMP-Join messages will be forward over N6 to upstream IP/MPLS router running PIM.
Though SMF and UPF in 5GC evolved from EPC nodes -S/PGW-C and S/PGW-U respectively, an S/PGW-C cannot forward a single EPS-bearer onto to S/PGW-U. In 5GC, a true service-chaining is possible. An SMF can daisy-chain a single PDU session through multiple UPFs using N9. However, it is not possible to route different traffic-flows belongs to a single PDU session through different UPFs. As a result, fixed IMS LBO (local breakout) for voice service requires IP/MPLS reachability to P-CSCF located at core DNN.
GNOP, specially NG-PON2, is of particular interest in the diagram shown here. As a passive media, it’s analogous to 3GPP AS (access stratum). Both use electromagnetic waves. In 5G, the carrier with the smallest wavelength is the mmWave supporting Dynamic-TDD, whereas in GPON it’s nanometer Wave support T-WDM. A 5G ONT needs a software upgrade to incorporate IP/IKEv2/EAP-5G/NAS protocol-stack on top of the optical layer.
Now the question may arise -whether a traditional BNG, aka distributed-BNG, can be an MEC use-case. Implementation of CUPS is mandatory for MEC, but not for BNG. This requirement may prohibit many operators who don’t have CUPS BNG, this is because deploying non-CUPS BNG at the network edge will create exorbitant control-plane integrations which will be extremely difficult to scale and manage. Moreover, BNG (both CUPS or non-CUPS) doesn’t support service-chaining; as a result, forceful LBO required for all services.