Fixed Wireless Access sessions

FWA sessions obtain network connectivity through a mobile RAN such as (e-)UTRAN (4G) or NR (5G). FWA sessions use the same BNG-UP, charging, authentication, and address management methods (including ODSA) as fixed BNG sessions.

Introduction to FWA sessions and terminology

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.

Residential Gateway models

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.
Note: The separation is logical and not mapped to on-premises hardware components.
  • An integrated RG and UE can have a separate outdoor unit for radio signaling and therefore, can consist of two hardware components.
  • A separate model can be a single hardware device that implements the RG and UE function separately with an internal link.

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

Figure 1. A separate model with PPP connectivity


Selected and real APN

When a session is initially set up, only one APN is available, as signaled during session management (for example, in the GTP Create Session Request message). This APN is known as the real APN. It is used to pick up a BNG authentication flow that is configured using the authentication-flow command in the following context.
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.

The APN name can be used in one of the following formats for both authentication and accounting purposes.
  • real

    The real, unmodified APN is used as is, including the OI if it was signaled. For example, the received APN equals internet.mnc001.mcc001.gprs and is used as is.

  • real-ni-only

    The real APN is used, but without the OI part if it was signaled. For example, the received APN equals internet.mnc001.mcc001.gprs and is used as internet.

  • selected

    This is the default option. The selected APN is used as is. If no selected APN is available, the system falls back to the real-ni-only option.

To configure the format, use the apn-format command. The context of the command depends on the use case. The following table shows the different use cases and the related context for the apn-format command.
Table 1. Use cases and context for the apn-format command
Use case Context

Use the APN as a match criterion in the ADB.

The APN format only applies if the attribute parameter in the match command equals apn.

configure mobile-gateway profile authentication-database match

Reflect the APN in the Called-Station-Id attribute for RADIUS authentication.

The APN format also applies to the username, if the user-name-format fixed-wireless-access format command in the same context is configured to include the APN.

Note: If the mobile UE sends a PPP username as a PCO during session setup signaling, the username is reflected as is. The apn-format command in this context does not modify the username even if it contains an APN.
configure mobile-gateway profile bng radius-authentication-profile

Reflect the APN in the Called-Station-Id attribute for RADIUS accounting.

Note: The user-name attribute from the authentication is reflected as is in RADIUS accounting. The apn-format command in this context does not modify the username in accounting even if it contains an APN.
configure mobile-gateway profile charging bng-charging radius session

Session identification, subscriber identification, and multi-APN support

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.

FWA-UP selection

Because FWA session setup messages are sent out-of-band, an FWA session is not tied to a FWA-UP as is the case with fixed BNG access. To select a FWA-UP, the following configuration is needed.
  • Define a UP peer list using the up-peer-list command in the following context.
    configure mobile-gateway profile pfcp
  • Configure all FWA-UPs as peer in the UP peer list using the peer command in the following context.
    configure mobile-gateway profile pfcp up-peer-list
    The IP address to use as parameter in the peer command is the source IP address of the PFCP association of the FWA-UP.
  • Set the FWA-UP selection to true for each peer using the upf-selection command in the following context.
    configure mobile-gateway profile pfcp up-peer-list peer
  • Configure the APNs that are supported on the peer using the apn command in the following context.
    configure mobile-gateway profile pfcp up-peer-list peer
  • Make a reference to the configured UP peer list using the up-peer-list command in the configure mobile-gateway pdn context.

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.

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.

Address signaling methods and deferred allocation

The 3GPP specifications define two 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.

  • via DHCP

    The IPv4 address is signaled after the session setup completes.

Which method is used depends on the following parameters, in order of precedence. Each parameter can be absent, or can have the value NAS or DHCP:

  • the RADIUS Alc-FWA-IPv4-Signaling-Method VSA
  • the configuration of the ipv4-signaling-method command in the following context
    configure mobile-gateway profile authentication-database entry fixed-wireless-access
  • 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.
  • 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
  • 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.

Note: Any allocated SLAAC prefix is sent in a GTP Create Session Response message for the MME/HSS. It is not further propagated to the UE/RG via NAS signaling. If no SLAAC prefix is allocated but another IPv6 stack is allocated, the prefix signaled in GTP is set to 0:0:0:0.

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.

QoS

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).

Note: In case there is only a default bearer or QoS flow, a PCC rule classifier can be absent.
Figure 2. Example of a bearer or QoS flow rate enforcement


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.

4G QoS attributes

The concept of a bearer defines the 4G FWA QoS functionality in mobile networks. Sessions support default bearers of the non-GBR type, as determined by specific parameters, and only APN-AMBR is supported for mobile rate-limiting.

4G FWA sessions only support default bearers and these default bearers must be of the non-GBR type. This means that only an APN-AMBR is supported for mobile-specific rate-limiting.

ARP, QCI, and APN-AMBR for the default bearer are determined using the following parameters, in order of precedence:

  • from RADIUS, the 3GPP-GPRS-Negotiated-QoS-Profile attribute
  • from the ADB, the QoS profile configured using the qos-profile command in the following context
    configure mobile-gateway profile authentication-database entry fixed-wireless-access
    Note: The QoS profile must reference a profile configured in the following context.
    configure mobile-gateway profile qos-profile
  • from the MME/HSS, the parameters in the GTP Create Session Request message
The values signaled in the GTP Create Session Request message can optionally be sent to a RADIUS authentication server using the 3GPP-GPRS-Negotiated-QoS-Profile attribute. To enable this, use the gprs-negotiated-qos-profile command in the following context.
configure mobile-gateway profile bng radius-authentication-profile include-attribute

The final QoS parameters are used for the generic mobile QoS functionality. They are included in the GTP Create Session Response message so the MME can signal their values to the eNodeB and the UE.

The APN-AMBR can be dynamically changed during the session lifetime using the following procedures:

  • a CoA including the 3GPP-GPRS-Negotiated-QoS-Profile attribute
  • an HSS-initiated QoS procedure, where the new APN-AMBR is sent using a GTP Modify Bearer Command message

Both procedures trigger a forced change of the APN-AMBR on the FWA-UP using a PFCP Session Modification Request that updates the applicable QER IE. When successful, the MAG-c initiates the PGW-initiated QoS update procedure to signal the new APN-AMBR to the MME/HSS using a GTP Update Bearer Request message.

5G QoS attributes

In 5G mobile networks, the QoS flow is a key concept. The MAG-c interacts with the PCF to create and then signal QoS flows, along with corresponding default-bearer information, to the RAN (gNodeB), UPF, and the UE.

The following parameters in order of precedence determine the default ARP, 5QI, and session-AMBR for the default bearer:

  1. from the PCF, the authSessAmbr and authDefQos information elements
  2. from RADIUS, the 3GPP-GPRS-Negotiated-QoS-Profile attribute
  3. from the ADB, the QoS profile configured using the following command:
    configure mobile-gateway profile adb entry fixed-wireless-access qos-5g-profile
    Note: The QoS profile must reference a profile configured in the following context.
    configure mobile-gateway profile qos-5g-profile
  4. from the UDM, the 5G QoS profile and sessionAmbr information elements
After interaction with the PCF, the MAG-c creates QoS flows for each 5QI associated with the session. The QoS flow is identified by a QoS Flow Identifier (QFI), which is also downloaded to the UPF and sent on the wire as an extension header to GTP-U. By default, the MAG-c allocates a dynamic QFI for each QoS flow, but it can also use the 5QI itself as a QFI. The latter can be achieved by enabling the following command.
configure mobile-gateway profile qfi-mapping-profile 5qi-as-qfi 
Use the following commands to apply a QFI mapping profile per PDN or per APN.
configure mobile-gateway pdn qfi-mapping-profile
configure mobile-gateway pdn apn qfi-mapping-profile
Note: The advantage of using 5QI as a QFI is you can map the dataplane traffic directly to a specific 5QI. However, the following limitations apply and for these reasons Nokia does not recommend using 5QI as QFI in a production network:
  • It is not allowed to modify the 5QI for a QoS flow mid-session. This includes the default 5QI for the default QoS flow.
  • It is not possible to use standard or vendor-specific 5QI values above 64.

When QoS flows are created, the MAG-c acting as the SMF signals the QoS flows and the corresponding parameters to the RAN (gNodeB), UPF, and the UE. Toward the RAN and UE this includes parameters that are typically not applicable to SMF or UPF and are passed through as they are; for example, averaging window.

Dynamic QoS based on PCC rules

When a session is provisioned with policy and charging control (PCC) rules, the MAG-c enforces QoS as specified in 3GPP TS 23.501 and TS 23.503. The MAG-c supports the following PCC rule parameters for QoS enforcement:

  • precedence versus other PCC rules in case of overlapping packet classifiers
  • list of service data flows (SDFs) that act as classifiers to associate packets with PCC rules. SDFs can contain the 5-tuple or the type of service (TOS) field classification, and can be bidirectional or unidirectional.
  • 5G quality of service identifier (5QI) and allocation and retention priority (ARP) to determine the end-to-end 5G QoS characteristics
  • indicator to bind the PCC rule to the default QoS flow, which is created based on the session level 5QI and ARP values. The 5QI and ARP values are ignored for the QoS flow binding.
  • indicator to enable reflective QoS
  • gate status to allow or disallow the PCC rule to forward traffic
  • maximum bit rate (MBR) and guaranteed bit rate (GBR) values
  • QoS characteristics specific to a radio access network (RAN) such as priority level, averaging window, maximum data burst volume, and maximum packet loss rate. These are passed as is to the RAN and act as overrides for the QoS characteristics associated with the 5QI.
    Note: QoS characteristics for a standard 5QI are defined in 3GPP TS 23.503 table 5.7.4-1.

Based on the provided 5QI and ARP values and the default QoS flow binding, the MAG-c generates QoS flows as specified in 5G QoS attributes. For any GBR QoS flows, it sets the guaranteed flow bit rate (GFBR) and the maximum flow bit rate (MFBR) value to the sum of the GBR and MBR values of all PCC rules tied to that QoS flow.

On top of the QoS flow rates, the MAG-c instructs the FWA-UP to enforce any MBR rate on a per PCC-rule level. This MBR is known as the SDF MBR. The FWA-UP combines the rate enforcements as follows:
  • Downlink packets tied to a GBR flow are first subjected to the SDF MBR, and subsequently to the GFBR and MFBR.
  • Downlink packets tied to a non-GBR flow are first subjected to the SDF MBR, and subsequently to the session aggregate maximum bit rate (AMBR).
  • Uplink packets tied to a GBR flow are only subjected to the SDF MBR because the RAN enforces the GFBR and MFBR.
  • Uplink packets tied to a non-GBR flow are first subjected to the SDF MBR, and subsequently to the session AMBR.
Note: The Nokia FWA-UP by default uses policing to enforce all UL rates and the DL PCC rule MBR, and shaping to enforce the DL QoS flow rates (GFBR, MFBR and session AMBR).

The following figures show the rate enforcements.

Figure 3. Downlink QoS enforcement on a FWA-UP
Figure 4. Uplink QoS enforcement on a FWA-UP
The FWA-UP also performs the following based on the PCC rule classifier:
  • QoS flow identifier (QFI) marking
  • reflective QoS identifier (RQI) marking
  • differentiated services code point (DSCP) marking, if configured on the MAG-c

The MAG-c automatically generates a default any-to-any PCC rule that uses the session level 5QI and ARP in addition to any explicit per-session PCC rules. When the creation of the any-to-any rule is disabled, the MAG-c does not automatically install a default rule and drops any traffic that does not match a specific PCC rule.

Perform the following steps to disable the creation of the any-to-any PCC rule:

  1. Use the following command to enable 5QI to be used as the QFI value.
    configure mobile-gateway profile qfi-mapping-profile 5qi-as-qfi
  2. Provision a PCC rule with the same 5QI and ARP as the session 5QI and ARP.

DSCP marking

In addition to applying base 4G and 5G QoS, Nokia’s FWA solution can also apply DSCP marking based on QCI/5QI and ARP values. The FWA-UP remarks the DSCP values as follows:

  • In the uplink direction, the FWA-UP marks the DSCP value of the forwarded IPv4 and IPv6 PDU packets. This is useful for QoS treatment based on QCI/5QI in the data network beyond the FWA-UP.
  • In the downlink direction, the FWA-UP marks the DSCP value of both the forwarded IPv4 and IPv6 PDU packets and marks the DSCP value of the outer GTP-u header. This is useful to honor 4G/5G QoS properties in the aggregation network between UP and RAN.
Note: If marking is not applied, the outer GTP-u header DSCP uses the DSCP value of the inner PDU packet by default.

As shown in the following figure, in both directions statically preprovisioned QoS treatment is applied based on QCI/5QI and ARP via the DSCP values in Network Elements (NEs) that are typically not 4G or 5G QoS aware.

Figure 5. 4G/5G QoS aware versus non-QoS aware NEs

Do the following to apply DSCP marking on the UP:

  1. Use the following command to configure a QCI policy.
    configure mobile-gateway profile policy-options qci-policy
  2. Use the following commands to configure per QCI and ARP combination, the DSCP value in the uplink (in) and downlink (out) directions and to disable DSCP preserve.
    Note: The no dscp-preserve command specifies that the MAG-c signals the configured DSCP values to the FWA-UP in PFCP messages. See the MAG-c CLI Reference Guide for more information about this command.
    configure mobile-gateway profile policy-options qci-policy qci 
    configure mobile-gateway profile policy-options qci-policy qci dscp
    configure mobile-gateway profile policy-options qci-policy qci no dscp-preserve
  3. Apply the QCI policy in the following context.
    configure mobile-gateway pdn apn qci-policy

PAP/CHAP authentication

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.

Session lifetime and held addresses

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.

To solve this, FWA sessions support holding addresses when a session gets deleted. To configure this, use the address-hold-time command in the following context.
configure mobile-gateway profile authentication-database entry fixed-wireless-access
context. The hold time can be set to a fixed amount of minutes or be based on the longest remaining address lifetime. In both cases, the hold time value is limited to a maximum of 10 days.

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.

Note: When a session setup fails, the held addresses are permanently removed to avoid infinite retries.

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.

PDN type selection

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.

Mobility and idling

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).
Note: Variants of 4G procedures with an SGW change are not supported.

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.

Location tracking

The MAG-c tracks and learns the location of an FWA session using procedures such as X2/Xn-based handover, UE-triggered service request, location reporting, and tracking area update. For 4G, the MAG-c requests the MME to report location if the MME signals the "Change Reporting Support Indication" flag and if the BNG charging profile is enabled to track the location. For 5G the MAG-c does not subscribe to specific location updates and only learns location changes as part of other procedures.

When RADIUS location tracking is enabled, an Interim Update message is triggered whenever the user location changes. The user location is sent in the 3GPP-User-Location-Info attribute.

Use the following commands to configure location tracking for RADIUS:

  • Use the following command to enable location tracking.
    configure mobile-gateway profile charging bng-charging radius session update-triggers user-location-change
  • Use the following command to send the user location in the 3GPP-User-Location-Info attribute.
    configure mobile-gateway profile charging bng-charging radius session include-attribute user-location-info

Headless mode for FWA

Headless mode as described in section 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 section 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. Use the following command to set the path restoration time.
configure mobile-gateway profile pfcp pfcp-profile path-restoration-time

4G and 5G NSA option 3 sessions

Basic FWA network shows the elements involved in a simple FWA network with a MAG-c operating as a combined PGW-C and SGW-C, and a FWA-UP operating as a combined PGW-U and SGW-U. The following figure shows the communication between the elements with the interface name if applicable and for the BNG relevant interfaces, the protocol being used. The high-level role of the MME, SGW, and PGW elements is as follows:

  • MME

    The MME orchestrates the basic connectivity of the UE and how this connectivity evolves during the lifetime of a session (for example, mobility, idling, paging).

  • SGW

    The SGW provides advanced data forwarding functionality such as buffering packets for idling UEs or providing a mobility anchor for inter-eNodeB mobility. Often this functionality is combined with a PGW in a single network element. In a CUPS environment the SGW is split in an SGW-C and an SGW-U element.

  • PGW

    The PGW provides PDN connectivity to an IP network. It can perform additional authorization to PDN-specific AAA servers; for example, authorization using the RADIUS protocol. It enforces charging functionality. In a CUPS environment the PGW is split in a PGW-C and a PGW-U element.

Figure 6. Basic FWA network


To enable 4G FWA sessions for a combined gateway, the GTP-C S11 and S5 interfaces need to be enabled on the MAG-c. The S5 interface is between the SGW and PGW and is internal for a combined gateway.

  • To enable the S5 interface, use the gtp-c command in the following context.
    configure mobile-gateway pdn s5 interface
    This interface is not necessarily used to terminate packets, but its IP must match the “PGW S5/S8 Address for Control Plane or PMIP” address that is signaled in the GTP Create Session Request.
  • To enable the S11 interface, use the gtp-c command in the following context.
    configure mobile-gateway pdn s11 interface
    This interface transfers the GTP-C packets.
  • To identify the L3 service on the FWA-UP where the GTP-U packets are received, configure the interface-realm parameter of the gtp-c command in the following contexts.
    configure mobile-gateway pdn s11 interface
    configure mobile-gateway pdn s5 interface
    Both realms must be configured the same.
  • Configure the EPC node name using the epc-node command in the configure mobile-gateway pdn context. The MCC and MNC value under this node must match the MCC and MNC of the IMSI for new FWA sessions. Otherwise, the session is seen as roaming, which is not supported for FWA.

The following figure shows an example of a 4G FWA session setup.

Figure 7. 4G FWA session setup


The following describes the message flow and actions to set up a 4G FWA session.
  1. An initial attach sequence is initiated between the UE and the MME, which leads to a GTP Create Session Request message toward the MAG-c. This message contains three sets of parameters:
    • protocol-specific data to initiate the stateful control session between the MME and the MAG-c
    • the required identification and subscription parameters to initiate session management for the PDN session
      Note: These parameters always include IMSI, IMEI, APN, PDN type, and can be extended with additional values such as MSISDN, static IP addresses, and APN-AMBR.
    • PCOs sent from the client; for example, a request for DNS servers, a request for deferred allocation, or PDN-specific authorization using encapsulated PAP/CHAP messages
  2. Based on the signaled APN, the MAG-c looks up the APN under the following context.
    configure mobile-gateway pdn apn
    To enable FWA functionality, the APN must be configured with an FWA node in the no shutdown state using the fixed-wireless-access command in the following context.
    configure mobile-gateway pdn apn
    The authentication flow of the FWA node configured using the authentication-flow command in the following context is used to authenticate the session.
    configure mobile-gateway pdn apn fixed-wireless-access
    FWA-specific ADB match criteria or RADIUS include attributes can be used.
  3. The MAG-c selects a FWA-UP and sets up a PFCP session. The PFCP session carries the full session data, including all BNG-specific parameters. At this point, the RAN has not yet allocated a downlink GTP-U F-TEID, so the downlink data packet is buffered. For uplink traffic, the FWA-UP allocates an F-TEID and sends it to the MAG-c.
  4. The MAG-c sends a GTP Create Session Response message to the MME. This message includes the uplink GTP-U F-TEID as allocated by the FWA-UP. It includes the IPv4 address if one was allocated and signaled via NAS. The MME completes the attach toward the UE and sets up the radio bearers toward the RAN. At this point, uplink data traffic can be sent.
  5. As part of the radio bearer setup, the RAN allocates a downlink GTP-U F-TEID. The MME signals the downlink to the MAG-c using a GTP Modify Bearer Request Message. The MAG-c forwards it to the FWA-UP using a PFCP Session Modification Request message which changes the downlink rules from buffering to forwarding with the provisioned F-TEID. The FWA-UP acknowledges the PFCP message to the MAG-c. The MAG-c acknowledges the GTP message to the MME. At this point, downlink traffic is possible.
  6. The data layer connectivity is ready, but it is possible that not all IP addresses allocated to the RG are signaled to the UE. The addresses are signaled over the data connection using the DHCP, ICMPv6, and DHCPv6 protocols.

5G standalone sessions

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.

Figure 8. Basic 5G FWA network

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

SMF PDUSession service server configuration

To enable 5G FWA sessions, do the following:

  1. Use the following command to configure an SMF PDUSession service server instance on the MAG-c, to handle service calls from the AMF to the SMF.
    configure mobile-gateway pdn sba-server-services nsmf-pdusession
  2. Configure the service instance with the following required elements:
    • an interface on which the MAG-c listens for incoming connections from the AMF
    • the N3 interface realm that is sent to the FWA UP as the realm (service) where N3 GTP-u tunnels are terminated
    Note: When 4G and 5G interworking is required, configure the interface-realm option for the S11 interface using the following command.
    configure mobile-gateway pdn s11 interface gtp-c

    See 4G and 5G NSA option 3 sessions for more information about configuring the S11 interface.

  3. Optionally provision the following for the server instance:

    • An HTTP2 profile to influence generic HTTP/2 and SBi parameters; see HTTP/2, OpenAPI, and Python for more details.
    • An API prefix to be part of the service URI; see URI construction for more information about how URIs are constructed.
    • An FQDN to identify the service by other NF peers. For example, the AMF can use this when constructing URIs or when discovering the SMF using DNS.
    • Multiple attributes to send to the NRF when registering the service:
      • NF domains lists using the following command.
        configure mobile-gateway pdn sba-server-services nsmf-pdusession allowed-nf-domains-list
      • PLMNS using the following command.
        configure mobile-gateway pdn sba-server-services nsmf-pdusession allowed-plmns
      • slices using the following command.
        configure mobile-gateway pdn sba-server-services nsmf-pdusession allowed-slices

        See NF registration for more information about how services and related attributes register with the NRF.

  4. Use the following command option to enable the service instance.
    configure mobile-gateway pdn sba-service-realm server-service service-instance

AMF client communication service configuration

In addition to the SMF server instance, you must configure the AMF communication client service. This service generates service calls from the SMF to the AMF, to forward N1 or N2 messages to the UE or RAN.

To configure the AMF client service, do the following:

  1. Use the following command to configure the AMF service.
    configure mobile-gateway pdn sba-client-services amf-client namf-comm
  2. Use the following command to configure an interface for the service instance that the MAG-c uses to communicate with the AMF.

    configure mobile-gateway pdn sba-client-services amf-client namf-comm interface
  3. Optionally configure the following for the client service instance:
    • An FQDN to identify the service by other NF peers. For example, when generating callback functions the SMF can use the FQDN in the URI, rather than the IP address; see URI construction for more information about how URIs are constructed.
    • An NF ID list to specify which NF instances can be used for the AMF service; see Local NF ID list-based discovery for more information. This command is required if the AMF is not dynamically discovered using NRF.
    • An HTTP2 profile to influence generic HTTP/2 and SBi parameters; see HTTP/2, OpenAPI, and Python for more information.
    • An AMF profile to handle AMF failure handling; see section Failure handling for more information.
    • An N1 profile configured using the following command.
      configure mobile-gateway profile n1-profile

      Use the following commands to configure the N1 profile to influence N1 signaling:

      • The N1 profile timer governs retransmit behavior for an N1 PDU SESSION MODIFICATION COMMAND message.
        configure mobile-gateway profile n1-profile n1-t3591
      • The N2 profile timer specifies retransmit behavior for an N1 PDU SESSION RELEASE COMMAND message.
        configure mobile-gateway profile n1-profile n1-t3592
      • The cause-code commands in the following context specify which error codes are signaled to the UE and AMF for several session removal and rejection cases.
        configure mobile-gateway profile n1-profile
  4. This service generates service calls from SMF to AMF, to forward N1 or N2 messages to the UE or RAN. Use the following command option to subsequently enable this service instance.
    configure mobile-gateway pdn sba-service-realm client-service service-instance

UDM function configuration

In 5G, the MAG-c acting as the SMF directly communicates with the UDM function to retrieve session subscription data, such as subscribed default QoS. The MAG-c subscribes to any subscription data changes to apply these changes.

This differs from 4G where a similar function is provided by the HSS, but the PGW does not retrieve this context directly. In 4G, the MME retrieves the subscription data from HSS and signals this via GTP messages to the PGW.

UDM SDM client service

To enable UDM-based subscription retrieval, do the following:

  1. Use the following command to configure a UDM SDM client service.
    configure mobile-gateway pdn sba-client-services udm-client nudm-sdm
  2. Use the following command to configure an interface for the service instance over which the MAG-c communicates with the UDM.
    configure mobile-gateway pdn sba-client-services udm-client nudm-sdm interface
  3. Configure the following optional parameters:
    • An FQDN to identify the service by other NF peers. For example, when generating callback functions, the MAG-c can use the FQDN in the URI, instead of the IP address. See URI construction for more information about how URIs are constructed.
    • An NF ID list to specify NF instances that can be used for the UDM function. See Local NF ID list-based discovery for more information. This configuration is required if the UDM is not dynamically discovered using NRF.
    • An HTTP2 profile to influence generic HTTP/2 and SBI parameters. See HTTP/2, OpenAPI, and Python for more information.
    • A UDM SDM profile that contains parameters on how to handle UDM failure handling. See Failure handling for more information.
  4. Use the following command to enable this service instance.
    configure mobile-gateway pdn sba-service-realm client-service

UDM UECM client service

The UDM UECM (UE Context Management) service is also used to register the MAG-c as an SMF providing service for the UE. To enable this service:

  1. Use the following command to configure a UDM UECM client service.
    configure mobile-gateway pdn sba-client-services udm-client nudm-uecm 
  2. Use the following command to configure an interface for the service instance over which the MAG-c communicates with the UDM.
    configure mobile-gateway pdn sba-client-services udm-client nudm-sdm interface
  3. Configure the optional parameters as described for the UDM client service. See UDM SDM client service.
  4. Use the following command to enable this service instance.
    configure mobile-gateway pdn sba-service-realm client-service

UDM Failure Handling

UDM communication supports generic SBi failure handling as specified in Failure handling. When the ap-continue action is used, session setup continues without SDM data, an SDM subscription, or a UECM registration. However, a locally configured 5G QoS profile must be present to provide fallback default QoS values. If this profile is not present, session setup fails anyway. Use the following steps to configure a fallback 5G QoS profile:
  1. Use the following command to configure a new 5G QoS profile.
    configure mobile-gateway profile qos-5g-profile
  2. In the 5G QoS profile, configure the 5qi, arp, dl-ambr, and ul-ambr parameters as needed.
  3. Use the following command to apply the profile in an ADB entry that is used for the 5G FWA sessions. For more information about matching sessions to ADB entries, see BNG EP and ADB lookup.
    configure mobile-gateway profile authentication-database entry fixed-wireless-access qos-5g-profile

FWA session setup for 5G

Typically a UDM (see UDM function configuration) and PCF (see PCF-based policy management) are configured for a 5G session, in addition to the SMF PDUSession service and the AMF client communication service. The following figure shows the basic 5G FWA session setup when all these components are configured.

Figure 9. 5G FWA session setup

The following describes the message flow and actions to set up a 5G FWA session.

  1. An initial registration sequence is initiated between the UE and the AMF. This procedure is orthogonal to the SMF because it does not involve any session-management functionality. Upon completion of the registration, an FWA UE requests creation of a PDU session to forward traffic. To do this, it generates a PDU Session Establishment Request NAS message and signals this to the AMF. Upon receipt of this message, the AMF may obtain additional subscription parameters from the UDM and determines which SMF should handle the session based on local configuration. For example, a specific FWA slice (S-NSSAI) could be used, with which the SMF registers (see NF registration) and the AMF discovers this SMF by calling the Nnrf_Discovery service that has the S-NSSAI configured in the query parameters. Upon discovering the SMF, the AMF creates a session management resource on the SMF by calling the Nsmf_PDUSession_CreateSMContextRequest service operation. In this it includes the PDU Session Establishment Request NAS message as it is, and any additional metadata it can provide, for example the DNN.
  2. Upon receiving the Nsmf_PDUSession_CreateSMContextRequest the MAG-c uses the signaled DNN to look up the configured APN/DNN in the following context.

    configure mobile-gateway pdn apn
    Note: To enable 5G FWA functionality, the APN must be in the enabled state and configured with an FWA node using the following command.
    configure mobile-gateway pdn apn fixed-wireless-access

    If a UDM client service is configured (see UDM function configuration ), a Nudm_SDM_Get Request service call is executed to obtain subscription parameters such as session AMBR, default 5QI, default S-NSSAI, and so on.

    If the UDM is not configured, these parameters must either be provided by the PDU Session Create message, or locally configured on the MAG-c. Subsequently, the authentication flow of the FWA node (configured using the following command) is used to authenticate the session.

    configure mobile-gateway pdn apn authentication-flow

    FWA-specific ADB match criteria or RADIUS include attributes can be used. Match criteria use data from the PDU Session create call and the UDM. For example, if an S-NSSAI is not provided in the create call, but a default S-NSSAI is provided in UDM subscription data, this is matched.

  3. After the UDM and authentication flow is completed, the MAG-c answers the call from the AMF Nsmf_PDUSession_CreateSMContext. This creates the session context in the AMF only; it does not yet include an answer to the UE-originated PDU Session Establishment Request message.
  4. Optionally, after the UDM and authentication flow completes, the MAG-c can obtain policy data from a PCF. See PCF-based policy management for more information about policy management and the PCF service.
  5. When all authentication and policy management is completed, the MAG-c selects an FWA-UP and sets up the corresponding PFCP session that carries the full session data, including all BNG-specific parameters. The RAN (gNodeB) has not yet allocated a downlink GTP-U F-TEID, so the downlink data packet is buffered. For uplink traffic, the FWA-UP allocates an F-TEID and sends it back to the MAG-c. See the 7750 SR and VSR BNG CUPS User Plane Function Guide for information about the BNG CUPS UPF.
  6. The MAG-c acknowledges the UE-originated PDU Session Establishment Request message by generating an N1 PDU Session Establishment Accept message. It also generates an N2 SM Information message which is sent to the RAN (gNodeB), including the F-TEID it received from the FWA-UP. Both messages also include any policy QoS rules applicable to either the UE or RAN. It includes these messages in a Namf_Communication MessageTransfer service call toward the AMF. The AMF in turn creates an N2 PDU Session Request call to the RAN to create context on the RAN, including the N2 SM Information and N1 PDU Session Establishment Accept message generated by the SMF. The RAN and UE finalize the radio resources setup. The uplink data can now flow.
  7. The RAN acknowledges the session context creation using an N2 PDU Session Response message to the AMF. In this message it also includes an N2 SM Information message with its F-TEID for downlink data, which the AMF forwards to the MAG-c using the smf_PDU_Session_UpdateSMContext service. The MAG-c forwards the F-TEID to the FWA-UP using a PFCP Session Modification Request message. This changes the downlink rules from buffering to forwarding with the provisioned F-TEID. The FWA-UP acknowledges the PFCP message to the MAG-c, which in turn acknowledges the smf_PDU_Session_UpdateSMContext call. Downlink traffic is now possible.
  8. If the UDM is enabled, the MAG-c registers itself for subscription updates for this session context using the Nudm_SDM_Subscription service call. Additionally, it also registers itself as the active SMF for this UE session using the Nudm_UECM_Registration service call.
  9. The data layer connectivity is now fully ready, although it is possible that not all IP addresses allocated to the RG are signaled to the UE. The addresses are signaled over the data connection using the DHCP, ICMPv6, and DHCPv6 protocols as needed. See Address signaling methods and deferred allocation for more information.

5G slicing

In 5G networks, a slice identifies an end-to-end logical network, from the UE to the network, on top of the shared physical infrastructure. The user can pick the physical or virtual components on a per-slice basis. This is a very flexible and powerful concept that can be used for many purposes. For example, FWA can be expressed as a single slice with dedicated FWA SMF and FWA UPF components.

MAG-c acting as the SMF is not involved in the slice-selection function itself. However, when selecting a peering NF instance via NRF, the MAG-c can use S-NSSAI as a query parameter to discover only peers associated with the selected slice. The MAG-c also passes the S-NSSAI to any peers, such as the UDM, PCF, or CHF, which require the MAG-c S-NSSAI to identify the services to offer. Finally, the SST and SD part of the S-NSSAI can be used as a match parameter in the authentication database, which allows the S-NSSAI to influence a wide set of parameters on itself.