General session functionality

Get a high level overview of the PFCP protocol and general session related functionality including grouping sessions for a subscriber, QoS, service selection, session state, and lawful intercept.

PFCP protocol

Get a high level overview of the core protocol of session management.

The core of session management is the PFCP protocol as defined in 3GPP TS 29.244, with BNG-specific extensions defined in BBF TR-459.

PFCP association and path

The PFCP association and path define the connectivity between the MAG-c and BNG-UP.

To send a session to a BNG-UP, a PFCP association needs to be established. While establishing this association, the BNG-UP and the MAG-c exchange capabilities, functional features, and parameters; for example, a BNG-UP sends functional features such as PPPoE support, IPoE support, and LCP Keep-alive Offload support. Capability exchange can influence the IE applicability in PFCP session messages.

  • PFCP association

    A PFCP association must be set up before sessions can be established between the BNG-UP and the MAG-c. Only one association per MAG-c and BNG-UP pair is allowed. The identifiers of the association are the MAG-c and the BNG-UP node IDs, which can be IP addresses or domain names. Provisioning commands specific to PFCP associations allow to enable the PFCP protocol.

  • PFPC path

    Multiple paths are possible per PFCP association. The identifier of a PFCP path is the pair of IP addresses used to communicate between the MAG-c and the BNG-UP. Paths are not negotiated but are learned while using PFCP signaling. Each IP address is called a PFCP entity. Each pair of MAG-c and BNG-UP IP addresses is called a PFCP path.

Note:

  • The Nokia MAG-c uses only one IP address per association, although in general a MAG-c or BNG-UP (also called a PFCP node) could use multiple IP addresses for communication within the same PFCP association. Because the Nokia MAG-c and BNG-UP use only one PFCP path per association, the terms path and association are often used interchangeably.

  • Both the MAG-c and BNG-UP verify that all known paths are alive using PFCP heartbeat messages. The heartbeat parameters are configured in the context of the PFCP profile. When a path fails, all related sessions are removed.

BNG-UP selection

The MAG-c selects a BNG-UP for each session depending on the session type.

The BNG-UP selection varies from very static (for example, because of hard wiring) to very dynamic (for example, for FWA).

See In-band control plane and BNG-UP selection for more information about the selection process for fixed access session.

See FWA-UP selection for more information about the selection process for FWA sessions.

PFCP session state

PFCP sessions require the creation of a forwarding state on the BNG-UP device. Session operations allow to manage the forwarding state on the BNG-UP.

The forwarding state includes rules (for example, encapsulation and decapsulation), information about routing context forwarding, QoS rules, and requested statistics collection.

The PFCP session establishment procedure creates the initial forwarding state. The path used for the PFCP session establishment procedure is tied to the session.

The following operations are supported for an established session:

  • PFCP session modification

    The MAG-c modifies the state or performs a state query (for example, to fetch statistics).

  • PFCP session deletion

    The MAG-c removes all state information.

  • PFCP session report

    The BNG-UP sends information unsolicited (for example, to report statistics or a connectivity failure).

In stable conditions, the BNG-UP only modifies or deletes the state if instructed by the MAG-c. If the BNG-UP detects failure, for example, a link failure, it does not delete the state but sends a report and keeps the local state. The BNG-UP deletes the state only when the MAG-c sends a Delete Request.

PFCP provisioning components

The PFCP protocol uses components that must be provisioned using the CLI.

To enable the PFCP protocol, the following components must be provisioned and referred to in the PDN configuration:
  • pfcp-association-peer-list

    The pfcp-association-peer-list command in the config>mobile>profile>pfcp context provisions the list of peer BNG-UP devices. It can be left empty if the BNG-UP initiates the PFCP association. By default, PFCP association requests coming from a peer that is not configured in the PFCP association list are accepted and the requesting (BNG-UP) peers are added dynamically to the PFCP association list for the MAG-c.

    Note:

    If the peer association list is enforced with the enforced-pfcp-association-list command in the config>mobile>pdn>sx-n4 context, all BNG-UP devices must already be provisioned in the PFCP peer association list. If enforcement is enabled, PFCP association requests coming from a peer that is not configured in the PFCP association list are not accepted and the requesting peer is not dynamically added to the list.

  • up-peer-list

    The up-peer-list command in the config>mobile>profile>pfcp context creates a list of UPs with the supported APNs and the UE IP address pools. In a MAG-c deployment, it must be configured for FWA sessions. It can be empty for the other types of session.

  • pfcp-profile

    The pfcp-profile command in the config>mobile>profile>pfcp context creates a PFCP profile in which the PFCP parameters can be configured.

    Note:

    The heartbeat and the retransmit options must be configured with the same values in both the BNG-UP and MAG-c, to prevent the BNG-UP and MAG-c from going out of sync if a link failure occurs.

The following example shows the provisioning in the config>mobile>profile>pfcp context and the config>mobile>pdn context.

A:MAG-c>config>mobile>profile>pfcp# info  
---------------------------------------------- 
                pfcp-association-peer-list "peers" 
                exit 
                up-peer-list "ups" 
                exit 
---------------------------------------------- 
A:MAG-c>config>mobile>pdn# info  
---------------------------------------------- 
                instance-type control 
                sx-n4 "default"
                    pfcp-association-list "peers" 
                    interface 
                        pfcp "system" 
                        ibcp "system" 
                    exit 
                    signaling 
                        pfcp  
                            profile "default" 
                        exit 
                        ibcp  
                            bng-entry-point "start" 
                            triggers pppoe-discover ipoe-dhcp ipoe-dhcpv6 ipoe-router-solicit 
                        exit 
                    exit 
                exit
            up-peer-list "ups" 
----------------------------------------------

PFCP connectivity failure

To protect against temporary PFCP connectivity failures, MAG-c supports a headless mode. Following the rules for the configuration of the sessions timers makes sure that the headless mode works as expected.

Headless mode

To prevent the removal of sessions with a temporary heartbeat failure, MAG-c supports a short-lived headless mode to restore connectivity.

PFCP heartbeat messages check the connectivity of a PFCP path. When the heartbeat procedure fails, all state information for the corresponding path is removed and all sessions using that path are terminated. The association remains in place.

Use the following command to configure the heartbeat parameters:
configure mobile-gateway profile pfcp pfcp-profile heart-beat
To protect against temporary failures, the MAG-c and BNG-UP support a headless mode. Use the following command to enable the headless mode:
configure mobile-gateway profile pfcp pfcp-profile path-restoration-time

To enable BFD, use the optional bfd-enable keyword in the preceding command.

When BFD is enabled, the system starts a BFD session for each known PFCP path on the BNG-UP. If a BFD failure is detected, the system immediately brings down the associated path. BFD does not affect the path recovery detection, which requires the configuration of PFCP heartbeats.

When headless mode is enabled, the sessions are not removed when there is a heartbeat failure. Instead, the configured timer is started and heartbeats continue to be sent. Subsequently, one of the following events occurs:

  • The timer expires and all sessions are removed. The association remains in place.

  • The path is restored (a successful heartbeat is completed) but a BNG-UP restart is detected and all sessions are removed.

  • The path is restored (a successful heartbeat is completed), the sessions are kept, and a PFCP audit procedure is started to ensure that the BNG-UP and MAG-c states are synchronized.

Note:
  • To prevent the MAG-c or BNG-UP from deleting all sessions while the other node keeps all the sessions, Nokia recommends that the path restoration time is at least twice as large as the sum of the heart-beat interval plus the total heartbeat timeout (total heartbeat timeout = heart-beat retry-count N1 × heart-beat timeout T1). This ensures that the MAG-c and BNG-UP nodes each run an audit or delete all the sessions in their respective nodes.
  • All parameter configurations must be identical between the MAG-c and BNG-UP.

To avoid hanging resources on a BNG-UP, the MAG-c only removes a session after it receives confirmation that the BNG-UP has removed the session. The MAG-c may receive confirmation in the following messages:

  • PFCP Session Deletion Response message (most common case)
  • PFCP message including a Cause IE that indicates an error (the BNG-UP lost the session)
  • an indication that the BNG-UP restarted and lost all its sessions; for example, a new PFCP Association Setup Request
To remove a session manually, use the force keyword with the following command: 
clear mobile-gateway bng session
This removes operational BNG (non-FWA) sessions on the MAG-c without synchronization with any external server or the client.

Session timer alignment

Nokia recommends aligning the session timers (signaled to the BNG RG) with the path restoration time. If the session timers are not aligned with the path restoration time, a session may time out autonomously before the headless mode could restore the path.

The following configurations for the session timers guarantee that the headless mode kicks in as expected.

  • For DHCP, the DHCP lease time must at least equal the renew time plus the path restoration time. In the default case, where the renew time is half of the lease time, the lease time must be at least twice the path restoration time.
  • For all IPv6 enabled sessions, the router lifetime included in RA messages must be at least equal to the maximum advertisement interval plus the path restoration time. In the default case, where the router lifetime is three times the maximum advertisement interval, the maximum advertisement interval must be equal to at least twice the path restoration time.
  • For SLAAC, the IPv6 preferred lifetime must be at least equal to the maximum router advertisement interval plus the path restoration time.
  • For DHCPv6, the IPv6 preferred lifetime must be at least equal to the renew timer (T1 timer) plus the path restoration time. In the default case, where the renew timer is half of the preferred lifetime, the preferred lifetime must be equal to at least twice the path restoration time.

The parameters can be locally configured or received from an external AAA server.

To configure or get info about the following locally configured parameters, use the indicated CLI commands:

  • path restoration time: path-restoration-time in the config>mobile>profile>pfcp>pfcp-profile context
  • DHCP lease time: option with option-number 51 in the config>mobile>profile>bng>dhcp-profile>options context
  • Renew time: option with option-number 58 in the config>mobile>profile>bng>dhcp-profile>options context
  • Router lifetime in RA messages: options router-lifetime in the config>mobile>profile>bng>ra-profile context
  • Maximum advertisement interval: advertisement-interval max in the config>mobile>profile>bng>ra-profile context
  • IPv6 preferred lifetime: preferred in the config>mobile>profile>adb>entry>address-assignment>lifetimes context

Subscribers

The MAG-c supports bundling a group of sessions for a single subscriber.

Grouping of sessions is useful in cases where a subscription consists of multiple directly connected devices. For example, a subscription may consist of a routed residential gateway for Internet access, VoIP phones, and set-top boxes. The residential gateway bridges traffic for voice and video services to the VoIP phones and to the set-top boxes. The MAG-c automatically creates a subscriber based on keys it derives from the session types, and allocates an auto-generated subscriber ID to the sessions.

See Subscriber identification for fixed access sessions and Session identification, subscriber identification, and multi-APN support for FWA sessions for more information about how the subscriber ID is generated.

A subscriber ID alias can be provided via AAA interfaces, but this alias cannot change the scope of a subscriber. For example, if the key of a subscriber contains a Layer 2 circuit (l2-circuit), the AAA subscriber ID alias cannot group two sessions with two different l2-circuit values.

QoS

The MAG-c enables the appropriate HQoS configuration by sending subscriber profiles and SLA profiles to the BNG-UP.

A BNG connection uses HQoS structures, in which there are multiple levels of rate limiting and scheduling. For example, one structure has an aggregate rate per MSAN, a second structure has an aggregate rate per subscriber level, and a third structure has an aggregate rate per session.

Figure 1. HQoS example
HQoS example

HQoS models can be complex and very hardware specific, the MAG-c signals the BNG-UP profiles to enable the appropriate HQoS configuration. The Nokia MAG-c signals a subscriber profile and an SLA profile in the Activate Predefined Rules IE of the PFCP message. The profiles are provisioned during authentication.

The subscriber profile should be kept consistent for all sessions of a subscriber, but the MAG-c does not enforce consistency. Short-lived inconsistencies are allowed while changing a subscriber profile; for example, when sending a CoA message to all sessions of the subscribers. However, long-lived inconsistencies may lead to unexpected behavior, including reverting to an old subscriber profile.

Service selection

The service selection requires an APN with a provisioned network realm.

Because the MAG-c model is based on 3GPP, the service selection relies on APNs. An APN must be provided during the session authentication to avoid session setup failure.

To map the APN to a specific routing service on the BNG-UP, a network realm must be provisioned in the APN context. This realm is sent over the PFCP interface and maps to a Layer 3 service on the BNG-UP. APNs using different pools can map to the same realm.

The following example shows an APN configuration.

A:MAG_C>config>mobile>pdn>apn# info 
----------------------------------------------
                network-realm "hsi"
                no shutdown
----------------------------------------------
Note:

Most of the APN configurations do not apply to a MAG-c.

Operational commands and debugging

Commands in the show, clear, and tools context allow to display MAG-c sessions and subscribers, to remove a session, and to debug a failing session setup. The call trace feature can be used for advanced debugging.

To display the MAG-c sessions and subscribers, use the following commands in the show context:

  • Use the session command in the show>mobile>bng context to display an overview of all basic data related to a session.
    • Add filters supported for the session command to display the data of specific sets of sessions.
    • Add the count keyword to display only the number of matching sessions.
    • Use sub-commands to get details on a specific aspect of the session (for example, charging).
  • Use the subscriber command in the show>mobile>bng context to display an overview of the operational data related to a subscriber. The command has similar options as the session command.
  • Use the ibcp keyword with the ref-point-stats command in the show>mobile>pdn context to display IBCP statistics for fixed access sessions.

To remove a session from the MAG-c, use the session command in the clear>mobile>bng context. When you issue this command, the MAG-c sends a PFCP Session Deletion Request to the BNG-UP.

To delete an operational BNG (non-FWA) session on the MAG-c without synchronization with any external server or the client session, use the force keyword with the session command. This bypasses the headless mode mechanism.

Tip: Always add filters to the session command in the clear>mobile>bng context to avoid accidental clearing of all sessions.

To debug a failing setup session, use the error-history command in the tools>dump>mobile>bng context to display a basic error log.

Call trace

For more advanced debugging, the MAG-c supports the call trace feature which allows to trace control plane packets or events during the lifetime of a session. Such a trace allows to correlate multiple signaling interfaces and detect issues in a session setup flow. Call trace supports the most frequently used BNG and FWA protocols such as GTP, SBi, DHCP, DHCPv6, RADIUS, and Diameter. Important non-protocol related events are also logged, such as ADB lookups or running a Python script.

To enable call trace debugging of fixed access sessions, use the following command: 
debug mobile-gateway call-insight bng

The parameters of the command, including MAC address, layer 2 access ID, layer 2 circuit ID, and remote ID, define the sessions to trace.

To enable call trace debugging of FWA sessions, use the following command: 
debug mobile-gateway call-insight ue

The parameters of the command, including IMSI, MSISDN, and IMEI, define the sessions to trace.

Call trace supports the following output options to make traces available for further inspection. The options are mutually exclusive:

  • as a PCAP file on local MAG-c storage
    The MAG-c creates the PCAP files automatically on local CF storage. Use the following command to configure the CF storage location:
    configure mobile-gateway call-insight location
    The default for the location is CF1. The MAG-c stores the files in the following locations:
    • for ongoing traces in the calltrace/running/ folder
    • for completed traces in the calltrace/finished/ folder
    The PCAP files can be downloaded from the system for further offline inspection. Use the following command to list all PCAP files currently on the system:
    show mobile-gateway call-insight files
  • streaming to an external service

    The external service can monitor the packets directly; for example, using the Wireshark packet inspection tool.

  • in the MAG-c debug logging system

    The MAG-c parses and displays packets in a user-friendly format in the system debug logs. The messages are available in the log file and can be viewed on the router depending on the log file configuration. Viewing messages on the router simplifies troubleshooting by eliminating the need to extract PCAP files from the router to view the messages.

    Caution: The parsing and formatting of packets uses a lot of processing time and may affect the performance of the system. Therefore, Nokia recommends not to send call trace output to the debug logging system when a large number of messages is expected.

For both the PCAP file and streaming output options, the MAG-c can add metadata to the traced packet. This metadata includes information such as the associated IMSI, MAC address, reference point, or UE ID. Nokia makes a plugin available for the Wireshark application to decode and display that metadata. By default, call trace uses the local PCAP output option. To change this and other advanced options:

  • Create a profile using the following command:
    configure mobile-gateway profile call-insight ue
  • Apply the configured profile to a specific call trace session using the profile option of the debug commands mentioned above.

The following advanced configuration options are available:

  • The debug-output command enables the debug logging output option.
  • The live-output command enables the streaming output option.
  • The ref-point and sba-service commands allow limiting the call trace to only specific reference points or SBA services. The MAG-c enables by default all reference points and SBA services.
  • The events command allows tracing internal MAG-c events that are not directly related to an on-the-wire protocol message. Examples include ADB lookups or running a Python script.
  • The size-limit and time-limit commands allow to specify conditions to automatically finish the tracing. By default these limits are set to 10 MB and 1 day.
To show the details for an ongoing call trace capture, use the following commands:
show mobile-gateway call-insight ue
show mobile-gateway call-insight bng
For example:
A:MAG-c>config# /show mobile-gateway call-insight bng mac-address 00:00:00:00:01:01 detail

===============================================================================
Call-insight BNG detail
===============================================================================
MAC address          : 00:00:00:00:01:01           Status        : running
Circuit Id           : --                          Profile       : default
Remote Id            : --                          Capture format: simulated-p*
UP Node Id           : --                          Time limit    : 86400s
L2 Access Id         : --                          Data limit    : 10MB
L2 Circuit           : --                          Session limit : --
Nr. of captured msgs : 125
|--control-plane msgs: 125
|--user-plane msgs   : 0
|--events            : 0
Size of captured msgs: 22244B
Started              : JAN 11 2023, 14:18:03 UTC
Ref-points           : dhcp,dns,ga,gn,gp,gx,gxc,pi,radius,rf,ro,s1,s11,s12,s2a
                       ,s2b,s4,s5,s6b,s8,sd,swm,swu,swu-cleartext,sww,sta,sx-
                       n4
SBA-services         : all
User-traffic         : none
Events               : none
Mask-name            : N/A
Live output          : N/A
Output file base     : bng_000000000101_230111_1418
-------------------------------------------------------------------------------
Number of call-insight debug jobs: 1
Nr. of dropped user-plane packets: 0
-------------------------------------------------------------------------------
Note:Reference points field above is applicable only to control-plane messages.
===============================================================================

CP session state and VM resilience

For scalability, the Nokia MAG-c distributes the session state functionality over multiple CMG virtual machines. This section provides a high-level overview of the MAG-c virtual machines.

The following types of virtual machines are used in a MAG-c to handle session state:

  • OAM-VM

    The OAM-VM handles all centralized functionality, such as IP address allocation and session ID assignments, and is the management interface for the configuration (CLI, SNMP, and so on). It creates the sessions, allocates basic resources such as session ID, and distributes the sessions over the SM-VMs. It balances the load of the sessions over the SM-VMs. To provide redundancy, two OAM-VMs should be deployed on different host systems.

  • SM-VM
    The SM-VM is also known as the CP-VM, or the MSCP. The SM-VM handles the session management after session creation. -VMs must be configured using N:K redundancy using the DB-VM for resilience. The MAG-c does not support 1:1 SM-VM redundancy. The following example shows the configuration of the resource pool.
    *A:G-c>config>mobile>system# info  
---------------------------------------------- 
           resource-pool 1 redundancy many-to-many gateway 1
                card 3
                card 4
                card 5
                card 6
            exit
            group 1 resource-pool 1
                no shutdown
            exit
            group 2 resource-pool 1
                no shutdown
            exit
            group 3 resource-pool 1
                no shutdown
            exit 
----------------------------------------------

  • LB-VM

    The LB-VM forwards packets to a SMVM or an OAM-VM based on load-balancing decisions. The LB-VM directly forwards session management messages to the correct -VM. To provide redundancy, two LB-VMs should be deployed on different host systems.

  • DB-VM
    The DB-VM stores SM-VM session states. In the case of a SM-VM failure, a redundant SM-VM recovers the state from the database to take over. An active redundant DB-VM is not required. Whenever a restart of a DB-VM is detected, all -VMs repopulate the database. Therefore, it is sufficient that a VM orchestrator spawns a new DB-VM upon failure. For redundancy reasons, the DB-VM should not be deployed on the same host as any SM-VM. If DB-VM and SM-VM are on the same host and the system fails, the sessions on the M-VM are irretrievably lost. The following example shows the configuration of database connectivity.
    A:MAG-c>config>mobile>pdn>cdbx# info 
---------------------------------------------- 
                cloud-db-profile db 
                interface "toDB" router "Base" 
---------------------------------------------- 
A:MAG-c>config>mobile>profile# info 
---------------------------------------------- 
            cloud-db "db" 
                no description 
                server 203.0.113.5 port 5678 
                    no shutdown 
                exit 
            exit  
----------------------------------------------

Prefix delegation as a framed route

When configured properly, the MAG-c can signal a PD prefix as a framed route to the BNG-UP.

When a PD prefix is allocated to a session, the MAG-c can be configured to signal the PD prefix as a framed route instead of as an explicit session address to the BNG-UP. When the PD prefix is signaled as a framed route, the BNG-UP cannot identify that the signaled prefix originated from a DHCPv6 PD lease, and treats it as any other IPv6 framed route.

To have the PD prefix signaled as a framed route, set the pd-as-framed-route command in the config>mobile>profile>adb>entry>address-assignment context to true.

To optimize host resource consumption on a Nokia BNG-UP, the framed route is signaled with a :: next-hop address. As with regular framed routes, it is a requirement that the ip-anti-spoof command in the config>mobile>profile>adb>entry context is set to false.

Lawful intercept

Configure LI on BNG CUPS and learn about the content of the LI notifications.

Description of LI

Lawful intercept is a legally sanctioned official access to private communications. To provide intercepted private communications to law enforcement officials, a service provider or network operator collects communication of a private subscriber or organization using an LI security process.

Subscriber events on the MAG-c

To perform LI on BNG CUPS, you need to configure both the MAG-c and the BNG-UP. To configure that the MAG-c includes RADIUS attributes in the accounting messages, use the up-info, up-subscriber-id, and subscriber-id commands in the config>mobile>profile>charging>bng>radius>session>include-attribute context.

The MAG-c and the BNG-UP have the following responsibilities for the LI functionality.

  • When configured to perform LI, the MAG-c reports the subscriber and LI events.
  • The BNG-UP provisions LI targets and supports mirroring of LI packets.

The MAG-c reports the subscriber and LI events through SNMPv3 and RADIUS to the LI mediation gateway. The LI mediation gateway uses the reported subscriber ID to enable LI on the BNG-UP.

The BNG-UP creates a new subscriber ID every time the subscriber logs on. For more information about LI on the BNG-UP, see 7750 SR and VSR BNG CUPS User Plane Function Guide.

Subscriber ID and IP address notifications for LI meditation devices

The MAG-c notifies the LI meditation gateway about the LI and subscriber events. The key parameter in the notifications includes the BNG-UP subscriber ID and the BNG-UP IP address. The LI mediation gateway uses the key parameter to provision the LI targets (using the subscriber ID) directly on the BNG-UP (using the IP address).

The MAG-c writes the following information in logs and includes it in RADIUS accounting messages:

  • real subscriber name; for example, John Smith
  • auto-generated BNG-UP subscriber ID; for example, 549
  • BNG-UP IP address; for example, 3.3.3.3
The following is an example of a MAG-c log.
767 2020/08/07 13:24:41.990 UTC WARNING: MOBILE_CUPS_BNG #2003 Base CUPS-BNG
           
"CUPS BNG new subscriber created: Sub-Id '549', externally assigned alias (if any)
'John Smith', UP IP 3.3.3.3"
The following is an example of the VSAs in a MAG-c RADIUS accounting message.
Alc-sub-Id-str = John Smith
Alc-UP-Ip-Address = 3.3.3.3
Alc-UP-Subscriber-Id = 549

The LI mediation gateway uses the information in the log and in the accounting message to detect possible LI targets. If the information points to an LI target, the LI mediation gateway sends an SNMPv3 command to the IP address of the BNG-UP to set up an LI target on the subscriber ID on the BNG-UP.

Note: The BNG-UP automatically adds _cups_ to the auto-generated subscriber ID; for example, _cups_549.

For further information about the BNG-UP LI target provisioning and LI packet mirroring, see 7750 SR and VSR BNG CUPS User Plane Function Guide.

For further information about LI access through SNMPv3, see 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.