Fixed Wireless Access sessions

FWA sessions obtain network connectivity through a mobile RAN, for example 4G (e-)UTRAN or 5G NR, and therefore they have the following important differences from fixed access sessions.

1. FWA sessions perform the initial setup out-of-band and signal directly to the MAG-c, which acts as a PGW-C, SGW-C + PGW-C, or a session management function (SMF), whichever is applicable.
2. FWA sessions have tunneled IP connectivity from the client device to the FWA-UP, which acts as a 4G PGW-U, 4G SGW-U + PGW-U, or 5G UPF, whichever is applicable.

FWA sessions are BNG subscriptions, which means they have the same service requirements as fixed sessions. QoS, service selection, pool management, and charging are all applicable to FWA sessions.

FWA sessions often use mobile-specific terminology. The following lists the most common terms and how they map to an FWA deployment.

APN

An Access Point Name (APN) identifies a specific PDN but can also be used to identify a specific gateway within a PDN, or even a specific service type within a PDN. A single UE can be connected to multiple APNs. Each such session is called a PDN session. This model maps directly to FWA and is also common with fixed BNG sessions. An APN consists of the following two sub-fields.

• Network Identifier (NI): defines the network (PDN).
• Operator Identifier (OI): defines the operator’s mobile network in which the PDN gateway resides. This consists of the operator’s MNC and MCC. This field is optional.

DNN

A Data Network Name (DNN) is the 5G equivalent to an APN.

GPSI

Similar to SUPI, the Generic Public Subscription Identifier (GPSI) is introduced in 5G to contain public identifiers such as MSISDN and is also ready to support other type of identifiers. For FWA, the GPSI always contains an MSISDN.

IMEI

An International Mobile Equipment Identity (IMEI) is a unique identifier for the hardware device used for the connection. Part of the IMEI is the Type Allocation Code (TAC) which is allocated to a specific device model.

IMSI

An International Mobile Subscriber Identity (IMSI) is a globally unique number identifying the subscriber. For FWA, the IMSI is mapped to a subscriber ID. Its value consists of the following three sub-fields.

• Mobile Country Code (MCC): uniquely identifies a country
• Mobile Network Code (MNC): uniquely identifies a mobile network within the country
• Mobile Subscriber Identification Number (MSIN): a second globally unique number identifying the subscriber

MSISDN

For mobile subscriptions, the Mobile Station International Subscriber Directory Number (MSISDN) is the public and well-known phone number. For FWA sessions, it can be used as an identifier for compatibility with AAA systems that are mostly MSISDN based.

NSSAI

Network Slice Selection Assistance Information (NSSAI) is a set of S-NSSAIs that is applicable to a UE. A UE can connect to a single S-NSSAI or to multiple S-NSSAIs.

PDN

A Packet Data Network (PDN) is a network the subscriber connects to; for example, the public Internet.

PEI

A Permanent Equipment Identifier (PEI) is introduced in 5G that can contain an IMEI and is also ready to support other type of identifiers. For FWA, the PEI always contains an IMEI.

RAB

A Radio Access Bearer (RAB) is a radio channel between a UE and the RAN. Multiple RABs per PDN session can exist.

RAN

The Radio Access Network (RAN) is antennas providing wireless connectivity.

S-NSSAI

Single Network Slice Selection Assistance Information (S-NSSAI) identifies a single network slice, which is a group of mobile functions such as SMF, UPF, and PCF that together provide specific capabilities and characteristics. For example, an FWA slice may contain all FWA UPFs and SMFs, as well as the necessary supporting functions such as CHF or PCF.

SUPI

A global unique Subscription Permanent Identifier (SUPI) is introduced in 5G that can contain an IMSI and is also ready to support other type of identifiers. For FWA the SUPI always contains an IMSI.

UE

The User Equipment (UE) is an end device used by the subscriber. The UE and RG can be integrated in one device or can be two separate devices.

For FWA, there are two common models for a RG.

• An integrated model where the RG provides classic BNG RG functions and acts as a mobile UE. A single IP address can be used to manage this entity. The RG or UE authentication is based on mobile SIM authentication.
• A separate model where there is a logical RG function and a logical UE function. The MAG-c abstracts from how these functions are connected. Often both functions require their own address for management purposes. It is possible to do additional RG device authentication based on PAP/CHAP.

The following figure shows a model using a PPP link between the RG and the UE.

configure mobile-gateway pdn apn fixed-wireless-access

After initial authentication, a new APN can be returned. This APN is known as the selected APN or the virtual APN. It determines the service selection for the FWA session. If no new APN is returned, the selected service is based on the real APN.

configure mobile-gateway profile authentication-database match

configure mobile-gateway profile bng radius-authentication-profile

configure mobile-gateway profile charging bng-charging radius session

For FWA sessions, the MAG-c subscriber key is the IMSI and the FWA session key is the pair (IMSI, APN). So multiple FWA sessions can be set up for the same UE/RG if those sessions use a different APN. This is called multi-APN support. The following lists some use cases of how multi-APN can be used.

• Have a different APN for Internet, video, and voice services.
• Have a different APN for public Internet and private work-from-home VPN connections.
• Have a different APN for a UE management IP address in case of the separated UE/RG model.

Each session can be mapped to a different L3 service and a different FWA-UP. For example, to optimize the BNG-UP resource usage, a low-throughput management-only session can be installed on a different FWA-UP than a high-throughput Internet session.

During setup, the FWA session automatically selects a peer from the UP peer list that is enabled for that APN. Load balancing over the FWA-UPs is done in a round-robin fashion.

Additionally, the MAG-c supports a generic policy-based UPF selection. This can include different selection criteria such as APN and location, where the location can be specified as a list of TAIs. See Configuring policy-based UPF selection with TAI list as selection criterion.

For FWA-UP selection, the MAG-c does not consider a UP for which the PFCP association or path fails, including a headless state, even if the UP is configured under the UP peer list. The MAG-c terminates FWA-UP sessions for which the association or path is down, not including a headless state, and sets a reactivation cause. The affected FWA RGs are expected to reconnect using a new session establishment procedure and chose a new non-failed UP, thereby providing a basic UP resiliency mechanism.

The 3GPP specifications define the following methods to signal an allocated IPv4 address:

• directly in NAS messaging during session setup

  From MAG-c point of view, the address is included in the session setup messages; for example, in the GTP Create Session Response message for 4G, or the N1 PDU Session Establishment Accept message for 5G.

• via DHCP

  The IPv4 address is signaled after the GTP or PDU session setup completes.

The method used depends on the following parameters and configuration, listed in order of precedence (item 1 being highest priority). Each parameter or configuration can be absent, or can have the value NAS or DHCP:

1. the RADIUS Alc-FWA-IPv4-Signaling-Method VSA
2. the configuration of the ipv4-signaling-method command in the following context

   configure mobile-gateway profile authentication-database entry fixed-wireless-access

3. the 00AH (IP address allocation via NAS signaling) and the 000BH (IPv4 address allocation via DHCPv4) PCOs as signaled by the UE. If only one is present, that method is used.
4. the configuration of the default-ipv4-signaling-method command in the following context of the selected APN where the session is created

   configure mobile-gateway pdn apn fixed-wireless-access

5. NAS, by default

If IPv6 is enabled, a UE/RG interface-identifier is derived from the link-local address of the MAG-c. This interface-identifier is signaled via NAS to the UE/RG, which derives a link-local address from it when needed; for example, to send ICMPv6 RS messages.

IPv6 global addresses always use deferred allocation and are signaled in-band after session setup completion. In case of SLAAC, the UE/RG can optionally use the signaled interface-identifier to construct a global address.

For FWA, deferred allocation can be used to assign an address to an RG function in the separated UE/RG model. In this case, the UE can forward the relevant DHCP, DHCPv6, or ICMPv6 messages to the RG without maintaining the stack itself.

FWA sessions generally support the generic BNG QoS functionality and are additionally subject to specific mobile QoS constructs. In mobile networks, the concept of a bearer defines 4G QoS functionality and a QoS flow defines the 5G QoS.

This topic gives a high-level overview of how mobile QoS works. For information about the specific subset that is supported for FWA, see 4G QoS attributes and 5G QoS attributes.

In mobile networks, the concept of a bearer (4G), or a QoS flow (5G), defines the QoS. At least one default bearer or QoS flow exists to which all traffic is mapped by default. More dedicated bearers and QoS flows can be created to which specific traffic is mapped using PCC rules.

Each bearer or QoS flow is classified as either GBR or non-GBR, and QoS treatment on the BNG-UP is applied accordingly. The specified rate values are sent to the BNG-UP using PFCP QER IEs.

• GBR bearer or QoS flow: a GBR and an MBR value are applied.
• Non-GBR bearer or QoS flow: a common MBR is applied to all bearers or QoS flows of this session. For 4G, this value is known as the APN-AMBR, for 5G this value is known as the session AMBR.

The following figure shows a high-level example of QoS handling. It shows a setup with four bearers or QoS flows, of which two are GBR and two are non-GBR (including the default).

Each bearer or QoS flow has QCI (4G), 5QI (5G), and ARP (4G/5G) values. The RAN uses these values, which are transparent to the MAG-c and the FWA-UP, with the exception of the GBR or non-GBR determination of the bearer or QoS flow.

• For 4G, standardized QCI values and the corresponding GBR or non-GBR classification are specified in 3GPP TS 23.203 section 6.1.7.2.
• For 5G, standardized 5QI values and the corresponding GBR or non-GBR classification are specified in 3GPP TS 23.501 section 5.7.4.
• Both QCI and 5QI can be operator-specific, and in this case GBR or non-GBR classification is provisioned together with the QCI or 5QI provisioning. The operator-specific range is from 128 to 254 as defined in 3GGP TS 24.301 section 9.9.4.3 (4G) and 3GPP TS 24.501 section 9.11.4.12 (5G).

The access technology defines how the system learns the different values.

A mobile UE can send PAP/CHAP authentication credentials as a PCO option during the session setup signaling. When such a PCO option is received, the MAG-c uses these credentials in the authentication instead of the locally configured credentials.

• The PAP/CHAP username can be used for the relevant ADB match criteria. For RADIUS authentication, the username has precedence over the configuration of the user-name-format fixed-wireless-access format command in the following context.

  configure mobile-gateway profile bng radius-authentication-profile

• The PAP/CHAP credentials are reflected in RADIUS instead of the password configured in the following context.

  configure mobile-gateway profile bng radius-authentication-profile

PAP/CHAP authentication is typically used for separate RG/UE models, where a PPP link is present between the RG and UE. PAP/CHAP authentication is performed over the link. The UE pretends successful authentication of PAP/CHAP and moves the session to the NCP state. The MAG-c gets a CHAP challenge and a CHAP response in PCOs. In cases where the PAP/CHAP based authentication on the MAG-c fails, the UE tears down the PPP session using the LCP terminate messages.

The session management procedures define the lifetime of an FWA session; for example, a GTP Delete Session Request message. An FWA session can exist without any stack being signaled to the client if deferred allocation is used. Stack timeouts do not drive session deletion. If a session management procedure deletes a session with active IP stacks, those stacks are by default released.

For an integrated RG/UE, this is not a problem because the RG/UE knows of the session failure and knows that IP stacks are lost.

For a separated RG/UE model, the UE can have forwarded those stacks to a RG. Depending on the RG/UE connection model, it is possible that the RG is not aware of the failure and keeps using assigned addresses until their signaled lifetimes expire.

configure mobile-gateway profile authentication-database entry fixed-wireless-access

When the hold time is configured, the MAG-c keeps a state for these addresses for the specified hold time. If the ODSA local address assignment allocated the addresses, the ODSA address hold time is automatically increased to the configured hold time. Other than that, there is no link between held addresses and the original allocation source of the addresses (for example, ODSA or AAA). For example, if a held address allocated by ODSA is removed, it is not explicitly released for ODSA. It needs to time out independently.

Held addresses are linked to the FWA session key pair (IMSI, APN). If a new session for the key of a held address is created, the held address is picked up and re-used. The interaction with specific address assignment methods is as follows:

• local address assignment (ODSA)

  The new session requests the held address from ODSA. The request cancels any running ODSA hold time and ODSA links the address to the new session. In case ODSA cannot assign the address, the session setup fails; for example, ODSA was not the original allocation source of the held address.

• AAA

  The held addresses are ignored and removed in favor of the AAA-signaled address.

Because held addresses do not interact with the original allocation method, Nokia recommends to only enable holding addresses when the address assignment source of a particular session is stable over session creation and deletion. If the address assignment source is not stable, session setups can fail or addresses can be hold for a long time. For example, consider a locally assigned ODSA address being put in the hold state for ten days. If the session is re-established but indicates an AAA address, the held address is not used and not released toward ODSA. The ODSA address keeps its ten day hold time and is not usable during that period.

FWA sessions need an assigned PDN type, which can be ipv4, ipv6, or ipv4v6. During setup, an initial wanted PDN type is signaled as follows:

• GTP for 4G
• N1 NAS/UDM SDM for 5G

The PDN type is checked against the local configuration that is done with the following command.

configure mobile-gateway pdn apn pdn-type

The PDN type acts as an allow-list. If the signaled PDN type does not match the configured PDN type, but the PDN types are compatible (for example, IPv4 is configured but IPv4v6 is signaled), MAG-c allows the FWA session and performs a downgrade to a compatible PDN type (for example, IPv4). If a downgrade is possible to both IPv4 and IPv6 (for example, both IPv4 and IPv6 are configured and IPv4v6 is signaled), by default MAG-c chooses IPv4, unless the pdn-type-preferred-IPv6 command is enabled.

To optimize IP address usage, only ODSA addresses that are applicable for the selected PDN type are allocated. For example, if a local IPv4 pool and a local IPv6 PD pool are provisioned, and the PDN type is IPv6, no IPv4 address is allocated.

Similarly, if local or AAA based address assignment allocates addresses for only one stack, the PDN type is downgraded to the type matching that stack if applicable.

FWA supports mobility and idling procedures, and tracks location.

FWA supports the following mobility and idling procedures:

• mobility procedures — X2-based handover (4G) and Xn-based handover (5G)
• idling procedures — S1 release (4G) and AN release (5G)
• reactivation and paging procedures — UE triggered service request (4G+5G) and network triggered service request (4G+5G).

Most of these procedures require interoperability with standard RAN deployments, which assumes these procedures are available by default. Handover procedures provide RAN resiliency when a UE or RG uses them to switch to a new antenna if its current antenna fails.

Most of these procedures require updating the FWA-UP to handle the new traffic rules. This update is done using the following PFCP Session Modification Request messages.

• For mobility procedures, the F-TEID field in the Forwarding Parameter IE is updated.
• For idling procedures, the forwarding rule is removed and replaced by a buffering rule that instructs the FWA-UP to buffer packets. The FWA-UP is also instructed to notify the MAG-c when buffering a packet such that the MAG-c can start paging procedures.
• When completing reactivation procedures, the buffering rule is removed and replaced by a forwarding rule with an F-TEID. Buffered packets are sent to the new F-TEID by the FWA-UP.

Headless mode as described in Headless mode is partially supported for FWA sessions. When the connection between the FWA-UP and the MAG-c fails, the currently installed sessions on the FWA-UP remain unaffected and continue forwarding data.

However, when new FWA procedures are initiated, such as a mobility, idling, or reactivation, the headless mode procedure fails and immediately terminates the session on the MAG-c. Terminated FWA sessions do not wait for the FWA-UP confirmation as described in Headless mode, but release the addresses back to the ODSA while in headless mode. To prevent a FWA-UP from announcing these released addresses, Nokia recommends setting the path restoration time lower than the hold time configured for any ODSA pools used by FWA sessions.

configure mobile-gateway profile pfcp pfcp-profile path-restoration-time

Basic 5G FWA network shows the elements involved in a basic 5G FWA network with a MAG-c operating as an SMF and an FWA-UP operating as a UPF. The figure highlights the direct communication between the interface elements and the protocols used, if applicable. The figure does not include the N1 (NAS signaling from and to the UE) and N2 (RAN control plane) interfaces because these interfaces may terminate on both AMF and SMF depending on the type of control plane signaling.

The following are high-level descriptions of the role of each function:

• AMF

  The Access and Mobility Function (AMF) orchestrates the basic connectivity of the UE and how this connectivity evolves during the lifetime of a UE (for example, mobility, idling, and paging).

• SMF

  The Session Management Function (SMF) maintains 5G sessions. It connects to other functions such as AAA, UDM, PCF, and CHF to retrieve and manage subscription, policy (including QoS), and charging data for an active session. The SMF provides a similar function to a combined SGW-C and PGW-C in 4G, however, in contrast to 4G it performs all the signaling for session management directly. For example, the SMF constructs all N1 (NAS) session-management messages for the UE directly, as compared to 4G, which uses the MME to proxy relevant data over GTP to the UE.

• UDM

  The Unified Data Management (UDM) provides subscription data for a user. This subscription data is queried by multiple functions, for example, the AMF retrieves access and mobility subscription data and the SMF retrieves session management subscription data. Additionally, functions such as the SMF register themselves with the UDM to indicate they are an active function for a specific UE or session.

• NRF

  The Network Repository Function (NRF) keeps a repository of all 5G functions. When a function becomes available, for example the SMF, it registers itself with the NRF. Subsequently, other functions such as the AMF can query the NRF to discover the functions with which they need to communicate.

• PCF

  The SMF queries the Policy Control Function (PCF) at setup to retrieve policy information applicable to a session. This policy information can be QoS, ACL, or charging related. Some policy information is directly applied by the SMF, but most is passed to other functions to enforce, such as the UPF, gNodeB, UE, or CHF. The PCF can also request updated policies on some triggers, such as location changes or revalidation timeouts and make direct requests for a policy update without requiring a trigger.

• CHF

  The Charging Function (CHF) is used for both online and offline charging. In both cases CHF manages charging based on Rating Groups (RGs), which can either represent an entire session or a subset of traffic. For offline charging, the CHF requests to signal statistics upon reaching a specific time or volume threshold; however, it does not enforce any limits. For online charging, the CHF additionally enforces quota limits that trigger the SMF and UPF to take immediate action without communicating to the CHF; for example, to stop forwarding for the RG.

• UPF

  The User Plane Function (UPF) provides connectivity to an IP network, enforcing dataplane policies such as QoS and ACLs, reporting statistics, and quotas.

Enabling 5G FWA sessions requires configuration of the following:

• SMF PDUSession services
• AMF client communication services
• 5G UDM function
• FWA sessions