General session functionality

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

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

Components for PFCP provisioning

To enable the PFCP protocol, provision and reference the following components in the PDN configuration:

IP interface
Before provisioning the PFCP protocol, an IP interface is required on both the MAG-c and the BNG-UPs. The PFCP protocol and PFCP association reference the IP interface endpoint. This means that the IP endpoints use full IP connectivity, which may require a routing protocol.
Note: You can use a direct interface, loopback interface, or system interface as an IP interface endpoint.
Node ID
The MAG-c requires a Node ID for the PFCP association. This can either be an IP address or an FQDN (default). Use the following command to configure the ip or fqdn option for the PFCP node ID.
```
configure mobile-gateway pdn pfcp-node-id-type
```
To use an FQDN, use the following command to also configure an FQDN.
```
configure mobile-gateway pdn epc-node
```
PFCP association peer list
Use the following command to configure the list of peer BNG-UP devices.
```
configure mobile-gateway profile pfcp pfcp-association-peer-list
```
The list can be 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 PFCP peer association list is enforced using the following command, all BNG-UP devices must already be provisioned in the PFCP peer association list.
```
configure mobile-gateway pdn sx-n4 enforced-pfcp-association-list
```
If enforcement is enabled, PFCP association requests coming from a peer that is not configured in the PFCP peer association list are not accepted and the requesting peer is not dynamically added to the list.
UP peer list
Use the following command to configure a list of UPs with the supported APNs and the UE IP address pools.
```
configure mobile-gateway profile pfcp up-peer-list
```
This context creates a list of peer FWA-UP or BNG-UP devices 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
Use the commands in the following context to configure PFCP profile options.
```
configure mobile-gateway profile pfcp pfcp-profile
```
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. See the 7750 SR and VSR BNG CUPS User Plane Function Guide for more information about BNG-UP configuration.

PFCP provisioning in PFCP profile and PDN contexts

Note: In this example the system interface is referenced. However, other interface types (for example, direct and loopbacks) are also allowed.

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 ipoe-data 
                        exit 
                    exit 
                exit
                up-peer-list "ups" 
----------------------------------------------

Verifying PFCP association setup

Use the following command to view the PFCP association establishment for the MAG-c.

show mobile-gateway pdn ref-point-peers sx-n4

PFCP association reference point peers

A:MAG-c>show mobile-gateway pdn ref-point-peers sx-n4
===============================================================================
PFCP reference point peers
===============================================================================
Peer address : 192.168.50.84
Node Id : 192.168.50.84
Router : Base
Path Mgmt State : up
Create Time : 06/21/2023 13:53:16 Gateway Id : 1
UP Features : FTUP TREU EMPU PDIU FRRT ADPDP MNOP IP6PL
UP BBF Features : PPPOE IPOE LCPKO
UP Nokia Features: BULK-AUDIT LAC SSSG FSG
UP Association : up Last Change Time : 06/21/2023 13:53:16
UP Selection : False
Enforced PFCP association list : No
-------------------------------------------------------------------------------
Number of peers : 1
===============================================================================

Dynamic overload reduction

To handle overload scenarios, the MAG-c limits the in-flight PFCP session messages that are sent toward each BNG-UP. This automatically limits the rate with which messages are sent to the BNG-UP. When this message limit is reached, a new PFCP transaction automatically fails. The MAG-c handles failed PFCP transactions for the most part as follows:

When the failure is triggered by an external message (for example, a DHCP Discover, GTP Create Session Request, or RADIUS CoA), the external message is discarded. A retry of the external message restarts the procedure and the PFCP signaling.
When the failure is triggered by an internal event (for example during a UP resiliency FSG switchover), the MAG-c automatically retries the PFCP transaction itself.

The MAG-c starts with an initial in-flight limit value (not configurable) and dynamically increases or decreases the limit to address the following cases:

The processing time on the BNG-UP differs per PFCP procedure. The MAG-c can send messages with a high rate for some PFCP procedures, but needs to lower the rate for other PFCP procedures.
The processing time differs per BNG-UP because of the difference in hardware and software.

Depending on the overload conditions, the MAG-c dynamically updates the in-flight limit as follows:

decreases the in-flight limit when overload conditions are detected
increases the in-flight limit when the overload conditions have subsided for a period of time

The MAG-c monitors the following overload conditions:

PFCP messages that have timed out
PFCP messages that are explicitly rejected with a PFCP congestion cause (code 74)

PFCP connectivity failure

To protect against temporary PFCP connectivity failures, MAG-c supports a headless mode. Following the rules for configuring sessions timers ensures 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.

Use the commands in the following context to configure message retransmit options.

configure mobile-gateway profile pfcp pfcp-profile heart-beat

Note: When using headless mode, Nokia recommends configuring the total message retransmit timeout for all other messages to be longer than the time to detect headless mode.

When BFD is enabled, configure the message retransmit to be higher than the interval times the multiplier. It is important to use the operational, negotiated values and not the configured values because these could differ.
When BFD is not enabled, configure the message retransmit to be higher than the value of the interval command plus the retry-count command times the timeout command, as configured in the heart-beat context.

When headless mode is enabled, the sessions are not removed when there is a heartbeat failure. Instead, the configured timer starts 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 following context.
```
configure mobile-gateway profile pfcp pfcp-profile
```
DHCP lease time: option with option-number 51 in the following context.
```
configure mobile-gateway profile bng dhcp-profile options
```
Renew time: option with option-number 58 in the following context.
```
configure mobile-gateway profile bng dhcp-profile options
```
Router lifetime in RA messages: options router-lifetime in the following context.
```
configure mobile-gateway profile bng ra-profile
```
Maximum advertisement interval: advertisement-interval max in the following context.
```
configure mobile-gateway profile bng ra-profile
```

IPv6 preferred lifetime: preferred in the following context.

configure mobile-gateway profile authentication-database entry address-assignment lifetimes

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.

The following figure shows an example of a HQoS model.

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 MAG-c model is based on 3GPP, which means that 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
----------------------------------------------

Operational commands and debugging

Use the commands in the show, clear, and tools contexts to display MAG-c sessions and subscribers, remove a session, and debug a failing session setup. Use the call trace feature for advanced debugging.

Removing, debugging, and displaying session information

Use the following command to display information about MAG-c sessions and subscribers.

show mobile-gateway bng session

The session command displays basic data related to a session.
The supported filter options for the session command display the data for specific sets of sessions.
The count keyword displays only the number of matching sessions.
Use other commands in the session context to display specific details for the session (for example, the charging command displays session charging data).

Use the following command to display an overview of the operational data related to a subscriber. The command has similar options as the session command.

show mobile-gateway bng subscriber

Use the ibcp keyword in the following context to display IBCP statistics for fixed-access sessions.

show mobile-gateway pdn ref-point-stats

Use the following command to remove a session from the MAG-c. When you issue this command, the MAG-c sends a PFCP Session Deletion Request to the BNG-UP.

 clear mobile-gateway bng session

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

Tip: Always add filters to the session command in the clear mobile-gateway bng context to avoid accidentally clearing all sessions.

Use the following command to display a basic error log to debug a failing setup session.

tools dump mobile-gateway bng error-history

Call trace

For advanced debugging, the MAG-c supports the call trace feature, which allows tracing of control-plane packets or events during the lifetime of a session.

Call trace allows correlation of multiple signaling interfaces and detection of 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.

Use the following command to enable call trace debugging of fixed access sessions.

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.

Use the following command to enable call trace debugging of FWA sessions.

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. These 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 system call-insight location
```
The default for the location is CF1. The MAG-c stores the files in the following locations:
- ongoing traces in the calltrace/running/ folder
- 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 system performance. Therefore, Nokia recommends not to send call trace output to the debug logging system when a large number of messages are 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:

Use the following command to create a profile.
```
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.

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 limit 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 specify conditions to automatically finish the tracing. By default, these limits are set to 10 MB and 1 day.

Use the following commands to display the details for an ongoing call trace capture.

show mobile-gateway call-insight ue
show mobile-gateway call-insight bng

Call trace detail for a MAC address

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

Simulating data triggers for IPoE sessions

The MAG-c supports configuration of data-trigger simulation options for IPoE sessions.

Use the following command to configure data-triggers for IPoE sessions. You can use the command options to define the details of the data-trigger packet.

tools perform mobile-gateway pdn bng data-triggered-host

The following message confirms if the data-trigger generation is successful.

INFO: CLI Data-trigger-host setup request successful,please monitor and validate further session establishment.

CP session state and VM resilience

For scalability, the Nokia MAG-c distributes the session state functionality over multiple 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. 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. The SM-VMs must be configured in 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 SM-VM or an OAM-VM based on load-balancing decisions. The LB-VM directly forwards session management messages to the correct SM-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 SM-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 failed SM-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 following context to true.

configure mobile-gateway profile authentication-database entry address-assignment

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 following context is set to false.

configure mobile-gateway profile authentication-database entry

Lawful intercept

Configure Lawful Intercept (LI) on MAG-c and learn about the content of the LI notifications.

Description of LI

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

MAG-c LI solution overview

Understand how the MAG-c LI solution is implemented on the MAG-c and on the User Plane (UP), which share a private key to allow decryption of LI PFCP IEs.

LI typically consists of the following interfaces, irrespective of the access technology:

administrative interface – supports LI target provisioning
information related interface – provides event information related to subscribers
contents-of-communications interface – sends mirrored packets to the LI gateway (LIG)

The MAG-c architecture supports the administrative and information interfaces on the MAG-c and the contents-of-communication interface on each User Plane (UP).

The MAG-c provides a centralized location to provision all LI targets. The MAG-c instructs the UP to perform LI for specific target subscribers by sending encrypted LI PFCP IEs through the Sx interface. The MAG-c and the UP share a private key to allow decryption of LI PFCP IEs.

To allow the LI target to remain anonymous, every subscriber PFCP session includes encrypted LI PFCP IEs.

The UP requires a minimal set of LI configurations to support MAG-c LI. The mirror destination ID is a key parameter that the MAG-c sends to the UP. You must configure matching mirror destination IDs on the UP and the MAG-c. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR OAM and Diagnostics Guide for more information.

MAG-c LI for wireline application

Understand the tools to use and guidelines to follow when configuring MAG-c LI for wireline applications.

For wireline (BNG) application, the following criteria apply for the MAG-c LI:

Perform all target provisioning for LI on the MAG-c through SSH CLI.
The MAG-c sends log events related to LI targets via the SNMPv3 interface.
Each BNG-UP can be configured to send mirrored traffic according to the mirror destination type: SAP, SDP, or IP-UDP SHIM.

Use the following command on the MAG-c to activate an LI target.

configure li target

For wireline subscribers, use the following command with the subscriber keyword. The name (ID) must match the subscriber ID returned from RADIUS, which is VSA Alc-Subsc-ID-Str [11].

configure li target source id subscriber name

Note: If you use the subscriber keyword, the MAG-c does not allow the input of the Intercept Related Information (IRI) peer because IRI is only used for wireless subscribers.

You can combine this command with other settings, including the ingress, egress, intercept ID, and session ID configurations.

MAG-c LI for wireless applications

Understand the tools to use and guidelines to follow when configuring MAG-c LI for wireless applications.

For fixed wireless application (FWA), the following criteria apply to the MAG-c LI:

Perform all target provisioning for LI on the MAG-c through SSH CLI. Use the IMSI number for the target source ID for both 4G and 5G subscribers.
The IRI/X2/DF peer (configure li target source iri-peer) is not currently supported on the MAG-c, although it is possible to configure it. For FWA, only mirroring of the UE traffic is supported.
Each UP sends mirrored traffic according to the mirror destination type: SAP, SDP, or IP-UDP SHIM.

Use the following command on the MAG-c to activate an LI target.

configure li target

For wireless subscribers, use the following command with the imsi keyword for both IMSI and SUPI.

configure li target source id imsi id

If you use the imsi keyword, the MAG-c allows the input of an iri-peer option. However, this is not currently supported for wireless subscribers. For wireless subscribers, only configure the LI target using the mirror-dest option.

You can combine this command with other settings, including the ingress, egress, intercept ID, and session ID configurations.

MAG-c LI through the UP

It is possible to provision LI targets on the UP, although it is not recommended for a number of reasons. It is helpful to users to understand the risks and requirements before considering this option.

Although Nokia does not recommend it, you can provision the LI target directly on the UP, by using the subscriber ID on the UP. However, each time a subscriber logs on to the MAG-c, the UP assigns the subscriber a different subscriber ID. The following methods help the LIG identify the UP where the subscriber is located and the new subscriber ID on the UP.

Using RADIUS accounting messages is one method to help to locate the subscriber and subscriber ID on the UP. Use the up-info, up-subscriber-id, and subscriber-id commands in the following context to configure the MAG-c to include RADIUS attributes in the accounting messages.

configure mobile-gateway profile charging bng-charging radius session include-attribute

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.

In addition to using RADIUS, the MAG-c also reports the subscriber and LI events through SNMPv3 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

Review the guidelines and options for enabling MAG-c notifications to the LI mediation gateway, about the LI and subscriber events.

The MAG-c notifies the LI mediation gateway about the LI and subscriber events. Some key parameters in the notifications include the BNG-UP subscriber ID and the BNG-UP IP address. The LI mediation gateway uses the key parameters 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 example displays a MAG-c log.

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 example shows VSAs in a MAG-c RADIUS accounting message.

VSAs in a MAG-c RADIUS accounting message

Alc-Subsc-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 prepends _cups_ to the auto-generated subscriber ID; for example, _cups_549.

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

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