WO2019011794A1 - Offline charging continuity in next generation networks - Google Patents

Abstract

Systems, methods, and software providing a charging solution for service continuity. In one embodiment, a Session Management Function (SMF) of a next generation network allocates a first User Plane Function (UPF) element as an anchor point of a first Packet Data Unit (PDU) session for a service accessed by User Equipment (UE). The SMF reports charging information for the first PDU session to a charging system. The SMF allocates a second UPF element as an anchor point for a second PDU session for the service in response to a trigger condition. When the anchor point is relocated in this manner for a service, the SMF reports charging information for the second PDU session and the charging information for the first PDU session to the charging system.

Description

OFFLINE CHARGING CONTINUITY IN NEXT GENERATION NETWORKS

Related Applications

This non-provisional patent application claims priority to U.S. Provisional Patent Application No. 61/531,447 filed on July 12, 2017, which is incorporated by reference as if fully provided herein.

Technical Field

This disclosure is related to the field of communication systems and, in particular, to charging in networks.

Background

Next generation networks (e.g., 5^th Generation or 5G) will need to support demands from a variety of users, machines, industries, organizations, etc. Thus, next generation networks will have to support a variety of requirements for latency, throughput, capacity, and availability. As many end user devices (e.g., User Equipment (UE)) of next generation networks will be mobile, continuity for services and/or sessions will be a focus of network operators. Continuity is part of mobility management, where the access network serving a UE may change, but the change in access does not result in interruption of a service/session. Although general descriptions may exist for continuity in next generation networks, further solutions are desired for network operators to successfully implement next generation networks.

Summary

Embodiments described herein provide a charging solution in next generation networks to support service continuity. A UE may be mobile while receiving a service from a data network. A Session Management Function (SMF) of a next generation network is tasked with allocating a User Plane Function (UPF) as the anchor point to the data network for a Packet Data Unit (PDU) session established for the service, and to report charging information for the PDU session to a charging system. As the UE moves, the SMF may determine that the UE has moved out of a service area of the present UPF, and into a service area of a new UPF. Thus, the SMF provides service continuity by allocating the new UPF as the new anchor point to the data network for a new PDU session established for the service, while providing an uninterrupted user experience of the service. The SMF reports charging information for the new PDU session to the charging system. The SMF is enhanced in these embodiments to report charging information for the present PDU session, and report charging information for one or more previous PDU sessions for the service. For instance, the SMF may report a UPF identifier, a network address for the UE, a charging identifier, or other information specific to a previous PDU session for the service. The reference point between the SMF and the charging system may also be enhanced to enable the SMF to report this information to the charging system.

Because the SMF reports charging information for a present PDU session and one or more previous PDU sessions, the charging system is able to insert the charging information into Charging Data Records (CDRs). This is advantageous as downstream elements are able to more easily collate or otherwise assemble the CDRs for the service based on the charging information described above so that proper tariffs are applied for the service.

One embodiment comprises an SMF element implemented in a control plane of a next generation network. The SMF element includes a service continuity manager configured to allocate a first UPF element as an anchor point of a first PDU session for a service accessed by a UE. The SMF element also includes a Charging Trigger Function (CTF) implemented in a processor that is configured to collect charging information for the first PDU session, and to report the charging information for the first PDU session to a charging system. The service continuity manager is configured to allocate a second UPF element as an anchor point for a second PDU session for the service in response to a trigger condition (i.e., triggers relocation to a different UPF element). The CTF is configured to collect charging information for the second PDU session, and to report the charging information for the second PDU session and the charging information for the first PDU session to the charging system.

In another embodiment, in reporting the charging information for the first PDU session, the CTF is configured to format a first charging request in response to a chargeable event during the first PDU session, and to transmit the first charging request to the charging system. The CTF is configured to format the first charging request to include the charging information for the first PDU session. In reporting the charging information for the second PDU session, the CTF is configured to format a second charging request in response to a chargeable event during the second PDU session, and to transmit the second charging request to the charging system. The CTF is configured to format the second charging request to include the charging information for the second PDU session and to also include the charging information for the first PDU session.

In another embodiment, the charging information for the first PDU session includes a UPF identifier for the first UPF element, a first charging identifier for the first PDU session, and a first Internet-Protocol (IP) address assigned to the UE for the first PDU session. The charging information for the second PDU session includes a UPF identifier for the second UPF element, a second charging identifier for the second PDU session, and a second IP address assigned to the UE for the second PDU session.

In another embodiment, the CTF is configured to report the charging information for the second PDU session in a Diameter charging request. Attribute Value Pairs (A VPs) are defined in the Diameter charging request for charging information pertaining to the second PDU session and the first PDU session.

In another embodiment, a first one of the AVPs is defined to identify the UPF identifier for the first UPF element that was the anchor point for the first PDU session. A second one of the AVPs is defined to identify the first charging identifier for the first PDU session. A third one of the AVPs is defined to identify the IP address assigned to the UE for the first PDU session. A fourth one of the AVPs is defined to identify a start time of the first PDU session. A fifth one of the AVPs is defined to identify a duration that the first PDU session.

In another embodiment, the SMF element further comprises a first interface component configured to directly communicate with the charging system, and a second interface component configured to directly communicate with the first UPF element and the second UPF element.

In another embodiment, the CTF is configured to cache the charging information for the first PDU session after the first PDU session is released.

Another embodiment comprises a method in an SMF element. The method comprises allocating a first UPF element as an anchor point of a first PDU session for a service accessed by a UE, collecting charging information for the first PDU session, and reporting the charging information for the first PDU session to a charging system. The method further comprises allocating a second UPF element as an anchor point for a second PDU session for the service in response to a trigger condition, collecting charging information for the second PDU session, and reporting the charging information for the second PDU session and the charging information for the first PDU session to the charging system.

Another embodiment comprises an SMF element of a next generation network. The SMF element includes a means for allocating a first UPF element as an anchor point of a first PDU session for a service accessed by a UE, and a means for collecting charging information for the first PDU session, and reporting the charging information for the first PDU session to a charging system. The SMF element further includes a means for allocating a second UPF element as an anchor point for a second PDU session for the service in response to a trigger condition, and a means for collecting charging information for the second PDU session, and reporting the charging information for the second PDU session and the charging information for the first PDU session to the charging system.

Another embodiment comprises an apparatus comprising at least one processor, and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform functions of a Session Management Function (SMF) element implemented in a control plane of a next generation network. The functions include allocating a first UPF element as an anchor point of a first PDU session for a service accessed by a UE, collecting charging information for the first PDU session, and reporting the charging information for the first PDU session to a charging system. The functions further include allocating a second UPF element as an anchor point for a second PDU session for the service in response to a trigger condition, collecting charging information for the second PDU session, and reporting the charging information for the second PDU session and the charging information for the first PDU session to the charging system.

The above summary provides a basic understanding of some aspects of the specification. This summary is not an extensive overview of the specification. It is intended to neither identify key or critical elements of the specification nor delineate any scope of the particular embodiments of the specification, or any scope of the claims. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that is presented later. Description of the Drawings

Some embodiments of the invention are now described, by way of example only, and with reference to the accompanying drawings. The same reference number represents the same element or the same type of element on all drawings.

FIG. 1 illustrates a non-roaming architecture of a next generation network in an illustrative embodiment.

FIG. 2 is a block diagram of an SMF element in an illustrative embodiment.

FIG. 3 is a block diagram of a charging system in an illustrative embodiment.

FIG. 4 illustrates movement of a UE in an illustrative embodiment.

FIG. 5 is a flow chart illustrating a method of reporting charging information in an illustrative embodiment.

FIG. 6 is a signal diagram indicating service continuity in an illustrative

embodiment.

Description of Embodiments

The figures and the following description illustrate specific exemplary

embodiments. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the embodiments and are included within the scope of the embodiments. Furthermore, any examples described herein are intended to aid in understanding the principles of the embodiments, and are to be construed as being without limitation to such specifically recited examples and conditions. As a result, the inventive concept(s) is not limited to the specific embodiments or examples described below, but by the claims and their equivalents.

FIG. 1 illustrates a non-roaming architecture 100 of a next generation network in an illustrative embodiment. The architecture in FIG. 1 is a reference point representation, as is further described in 3GPP TS 23.501 (v 1.0.0), which is incorporated by reference as if fully included herein. The control plane of architecture 100 includes Authentication Server Function (AUSF) 1 10, a Unified Data Management (UDM) 1 12, a Network Slice Selection Function (NSSF) 113, an Access and Mobility Management Function (AMF) 114, a Session Management Function (SMF) 1 16, a Policy Control Function (PCF) 118, and an

Application Function (AF) 120. The user plane of architecture 100 includes one or more User Plane Functions (UPF) 124 that communicate with a Data Network (DN) 126. A (Radio) Access Network ((R)AN) 130 and User Equipment (UE) 132 are able to access the control plane and the user plane of the core network. (R)AN 130 is a type of

communication network where the last link to end user devices (e.g., UE) is wireless.

AUSF 1 10 is configured to support authentication of UE 132. UDM 112 is configured to store subscription data/information for UE 132. UDM 112 may store three types of user data: subscription, policy, and session-related context (e.g., UE location). AMF 114 is configured to provide UE-based authentication, authorization, mobility management, etc. SMF 116 is configured to provide the following functionality: session management (SM), UE Internet Protocol (IP) address allocation and management, selection and control of UPF 124, termination of interfaces towards PCF 1 18, control part of policy enforcement and Quality of Service (QoS), lawful intercept, termination of SM parts of NAS messages, Downlink Data Notification (DNN), roaming functionality (including charging interface), handle local enforcement to apply QoS for Service Level Agreements (SLAs), charging data collection and charging interface, etc. If UE 132 has multiple sessions, different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session. PCF 118 is configured to support a unified policy framework to govern network behavior, and to provide policy rules to control plane functions for QoS enforcement, charging, access control, traffic routing, etc. AF 120 provides information on a packet flow to PCF 1 18. Based on the information, PCF 1 18 is configured to determine policy rules about mobility and session management to make AMF 114 and SMF 1 16 operate properly.

UPF 124 supports various user plane operations and functionalities as part of a service, such as packet routing and forwarding, traffic handling (e.g., QoS enforcement), an anchor point for Intra-RAT/Inter-RAT mobility (when applicable), packet inspection and policy rule enforcement, lawful intercept (UP collection), traffic accounting and reporting, etc. DN 126 is not part of the core network, and provides Internet access, operator services, 3rd party services, etc.

Architecture 100 includes the following reference points. The Nl reference point is implemented between UE 132 and AMF 114. The N2 reference point is implemented between (R)AN 130 and AMF 114. The N3 reference point is implemented between (R)AN 130 and UPF 124. The N4 reference point is implemented between the SMF 1 16 and UPF 124. The N5 reference point is implemented between PCF 118 and AF 120. The N6 reference point is implemented between UPF 124 and DN 126. The N7 reference point is implemented between the SMF 1 16 and PCF 1 18. The N8 reference point is implemented between UDM 112 and AMF 1 14. The N9 reference point is implemented between two UPFs 124. The N10 reference point is implemented between UDM 112 and SMF 1 16. The Nl 1 reference point is implemented between AMF 114 and SMF 1 16. The N12 reference point is implemented between AMF 114 and AUSF 110. The N13 reference point is implemented between UDM 112 and AUSF 1 10. The N14 reference point is implemented between two AMFs. The N15 reference point is implemented between PCF 118 and AMF 1 14 in the case of a non-roaming scenario. The N22 reference point is implemented between NSSF 113 and AMF 114.

AMF 114, SMF 116, PCF 1 18, UPF 124, etc., of architecture 100 are referred to herein as "elements" or "network elements". An "element" includes functions, operations, etc., and the underlying hardware or physical devices (e.g., processors) that are programmed to perform the functions. The elements are part of a system within the next generation network that provide connectivity and other functions.

Architecture 100 also includes a charging system 140. Charging system 140 comprises a server, device, apparatus, circuitry, equipment (including hardware), means, etc., that provides charging for services provided in a next generation network, such as a 5G network. One charging method provided by charging system 140 is offline charging.

Offline charging is a process where charging information for resource usage is collected concurrently with resource usage. Offline charging can be of two types: session-based or event-based. In event-based charging, a Charging Trigger Function (CTF) reports the usage or the service rendered where the service offering is rendered in a single operation. For example, the CTF may report the usage in an Accounting Request (ACR) EVENT.

Session-based charging is the process of reporting usage for a service, and uses the START, INTERIM, and STOP accounting data. During a service, a CTF may transmit multiple ACR Interims depending on the proceeding of the session. A further discussion of charging principles is described in 3GPP TS 32.240 (vl4.4.0), which is incorporated by reference as if fully included herein. Charging system 140 may be a combined online and offline charging system. Architecture 100 is enhanced with interfaces defined between charging system 140 and elements of the control plane. For instance, an N20 reference point is implemented between AMF 1 14 and charging system 140. An N21 reference point is implemented between UDM 112 and charging system 140. An N-CH reference point is implemented between SMF 116 and charging system 140. An N-Sy reference point is implemented between PCF 1 18 and charging system 140. A unified charging interface (N-CH) may be adopted between online and offline charging, with indicative flags that denote the purpose of charging messages to apply for online, offline, or both charging methods. The latter is useful when subscriber spending limits are effective, as the unified message may reduce the overall charging traffic.

The role of SMF element 116 includes control of session management, connection to UE 132 via AMF 1 14, and the control of the UPF element(s) 124 for a session. SMF element 1 16 is responsible for handling the mapping between UE location (tracking area ID/Cell-ID) and a Data Network Access Identifier (DNAI) associated with a UPF element, and selection of the UPF element that serves a PDU session. One of the mobility functions that SMF element 116 provides is related to Session and Service Continuity (SSC). Service continuity ensures an uninterrupted service experience to a user regardless whether there is a change of UE IP address or change in the core network anchor point. SSC is provided to UEs 132 based on a few factors: UE capabilities, subscription level, and associated mobility. Presently, 3 GPP SA2 has described three SSC modes: SSC mode 1, SSC mode 2, and SSC mode 3.

For SSC mode 1, the UPF acting as the PDU session anchor at the establishment of the PDU session is maintained regardless of the access technology (e.g., RATs and cells) used by a UE to access the network. The same IP address is maintained for session continuity in SSC mode 1.

For SSC mode 2, the IP address changes when a UE moves across UPFs. The same UPF is only maintained across a subset (i.e., one or more, but not all) of the access network attachment points (e.g., cells and RATs), referred to as the service area of the UPF. When a UE leaves the service area of a UPF, the UE will be served by a different UPF suitable for the UE's new point of attachment to the network. For SSC mode 2, the following principles apply: trigger redirection to a different UPF, where the network decides whether the UPF assigned to a UE's session needs to be reassigned based on UE mobility and local policies (e.g., information about the service area of the assigned UPF), and the redirection procedure, where the network redirects the UE's traffic to a different UPF by first releasing the user plane path associated with the present UPF and then setting up a user plane path corresponding to a new UPF. During this process, the UE remains attached.

SSC mode 3 is similar to SSC mode 2, except a new connection with a new IP address is established before the old connection with the old IP address is discarded. The network allows the establishment of UE connectivity via a new UPF to the same data network before connectivity between the UE and the previous UPF is terminated. When trigger conditions apply, the network selects a target UPF suitable for the UE's new point of attachment to the network. While both UPFs are active, the UE either actively rebinds applications from the previous address/prefix to the new address/prefix, or alternatively, the UE waits for flows bound to the previous address/prefix to end. For SSC mode 3, the following principles apply: trigger redirection to a different UPF, where the network decides whether the UPF assigned to a UE's session needs to be reassigned based on local configuration (e.g., information about the service area of the assigned UPF), and the redirection procedure, where the network indicates to the UE that traffic on one of the UE's active sessions needs to be redirected. The network also starts a timer and indicates the timer value to the UE. The user plane path is established towards a new UPF. The network selects a new UPF based on the UE's current point of attachment to the network. If the UE has sent a request for an additional session to the same data network without a prior indication from the network that the active session needs to be redirected, then the network rejects the UE's request. When the new user plane path associated with the new UPF has been established, the UE may actively redirect application flows bound to the previous UPF to the new UPF (e.g., by using upper layer session continuity mechanisms), and release the previous UPF when the UE has finished redirecting applications flows to the new UPF. Alternatively, the UE may steer new application flows to the new UPF, and existing flows via the previous UPF continue until the flows terminate. When all flows using the previous UPF have ended, the previous UPF is released. When the second option is used, the multi- homed session may be used to send application flows bound to the previous UPF.

SSC mode 2 is also known as "break before make" and SSC mode 3 is called "make before break". Both SSC modes 2 and 3 result in a new connection between the SMF and UPF via the N4 interface, while SSC mode 1 maintains the pre-existing SMF-UPF connection on the N4 interface.

Operators may pre-provision an SSC mode selection policy in the UE to determine the mode used for an application, or use a programmable UPF that is chosen by the SMF. This supports multi-homing, as the same session may have more than one IP address and more than one N6 interface to the same data network. The multi-homing capability is considered a way to handle service continuity. Table 1 summarizes the behavior expected for UE mobility:

Table 1

SSC Mode Anchor IP address N4 I/F

1 UPF1 IP1→IP1 SMF→ UPF

2 UPF2 IP1→IP2 SMF→ UPF 1 to SMF→ UPF2

3 UPF2 IP1→ IP2 SMF→ UPF1 to SMF→ UPF2 The "break before make" model of SSC mode 2 may cause adverse effects to charging. For example, in a sponsored data session, the UE is typically granted access to a session after watching a short advertisement. Such session accesses are paid for or subsidized by the advertiser. The data session that follows is at a reduced cost or zero cost to the subscriber. However, when sessions are broken and then re-established as with SSC mode 2, the continuation aspect is missing and the UE mobility will result in inadvertently charging the subscriber for the session in the new UPF. As another example, some service providers have subscription plans that charge subscribers for the first N minutes of access and thereupon, access is provided at zero or minimal additional cost to the subscriber for additional minutes. This model charges at different rates as the session progresses. With a change in the UPF during a session, the charging goes out of sync and would result in levying charges at the higher initial rate to the subscriber.

To further illustrate potential issues with SSC mode 2, assume a UE is managed by an SMF for a PDU session. At time tO of the PDU session, the SMF assigns UPF 1 with an IP address of IP1 , and a charging ID of CH-ID 1 for a service. At time tl, the UE moves from one dedicated core network to another dedicated core network, where the SMF assigns a new UPF2 with an IP address of IP2, and a charging ID of CH-ID2. At time t2, the UE moves to a third dedicated core network, where the SMF assigns a new UPF3 with an IP address of IP3, and a charging ID of CH-ID3. The service then ends at time t3.

In this example, the mobility of the UE would likely result in generation of three CDRs for the service provided. At time tl, the first CDR would show CH-IDl, session start at time tO, session end at time tl , and the IP address as IP 1. At time t2, the second CDR would show CH-ID2, session start at time tl , session end at time t2, and the IP address as IP2. At time t3, the third CDR would show CH-ID3, session start at time t2, session end at time t3, and the IP address as IP3. Downstream billing mediation, rating systems, or billing systems may have difficulty correlating these CDRs, as the CDRs appear to include data for three different PDU sessions even though the PDU sessions were for the same service.

The embodiments described herein provide a charging solution for service continuity. As an overview, when a PDU session is established for a service and an anchor point (i.e., UPF1) is initially selected in the user plane for the PDU session, SMF element 116 in the control plane reports charging information for the PDU session to charging system 140. SMF element 1 16 also caches the charging information for the PDU session. If SMF element 1 16 redirects the service to a new anchor point (i.e., UPF2), then a new PDU session is established and the previous PDU session is released. SMF element 1 16 reports charging information for the new PDU session to charging system 140, and also reports charging information for the previous PDU session. If SMF element 1 16 redirects the service to yet another anchor point (i.e., UPF3), then a new PDU session is established and the previous PDU session is released. SMF element 116 reports charging information pertaining for the new PDU session to charging system 140, and also reports charging information pertaining to one or more previous PDU sessions. Because of the reporting by SMF element 1 16, the CDRs generated by charging system 140 indicate the sequence or chain of information (e.g., UPF IDs, charging IDs, IP addresses, etc.) for PDU sessions established for the service. Therefore, downstream elements will be able to collate the CDRs generated for the service, and more accurately charge for the service.

FIG. 2 is a block diagram of SMF element 1 16 in an illustrative embodiment. SMF element 1 16 is an element or apparatus in the control plane of a next generation network that is configured to perform session management for sessions (e.g., PDU sessions) involving UEs. SMF element 116 includes an interface component 202 configured to directly communicate with charging system 140, and an interface component 203 configured to directly communicate with UPF elements 124. Interface components 202-203 may comprise circuitry, logic, hardware, means, etc., configured to interact with other elements via messages, signals, etc. Interface component 202 may communicate with charging system 140 via a N-CH reference point that is Diameter-based (e.g., Gy or Gz) or based on another protocol such as HTTP/2. Interface component 202 may communicate with charging system 140 via another reference point that is or may be defined for offline or online charging. Interface component 203 may communicate with UPF elements 124 via the N4 reference point (e.g., Sx).

SMF element 1 16 further includes a processor 206 and a memory 208. Processor 206 represents a component that provides the functions of an SMF element in a next generation network through physical resources, such as internal circuitry, logic, hardware, means, etc. Memory 208 is a computer readable storage medium (e.g., ROM or flash memory) or means for storing data, instructions, applications, etc., and is accessible by processor 206. SMF element 1 16 may include various other components not specifically illustrated in FIG. 2.

Processor 206 implements a CTF 210 and a service continuity manager 212 in this embodiment. CTF 210 the focal point for collecting information or data pertaining to chargeable events, assembling the information into matching charging events, and sending the charging events towards charging system 140. Service continuity manager 212 is configured to maintain service continuity over one or more PDU sessions that are established for a service.

FIG. 3 is a block diagram of charging system 140 in an illustrative embodiment. Charging system 140 is an element or system that provides charging control for sessions over a network. Charging system 140 may include functionalities of an Online Charging System (OCS) and/or an Offline Charging System (OFCS). In this embodiment, charging system 140 includes an interface component 302 configured to communicate with SMF element 1 16, and one or more processors 304. Interface component 302 may comprise circuitry, logic, hardware, means, etc., configured to exchange charging messages with SMF element 1 16 or other network functions. Processor 304 represents circuitry, logic, hardware, means, etc., configured to provide the functions of charging system 140.

Charging system 140 may include various other components not specifically illustrated in FIG. 3. In this embodiment, processor 304 implements an online charging mechanism 310 and an offline charging mechanism 320. Online charging mechanism 310 includes an Online Charging Function (OCF) 312, an account balance manager 314 (also referred to as Account Balance Management Function (ABMF)), and a rating engine 316. OCF 312 is configured to identify a charging policy or charging rules for a UE, and grant quotas of service units for sessions to network functions in the user plane (e.g., a UPF). Account balance manager 314 is configured to control or maintain one or more online or prepaid accounts for a UE. Account balance manager 314 is configured to determine a present account balance a UE, decrement the account based on chargeable events, replenish the account, or handle other account-related functions. Rating engine 316 is configured to determine a rate or tariff for network resource usage by a UE. The rate or tariff (also referred as rate plan) may comprise a static tariff or a dynamic tariff. For example, a static tariff may indicate a cost/price for a service based on a service plan. A dynamic tariff may depend on usage, service types, etc.

Offline charging mechanism 320 includes a Charging Data Function (CDF) 322 and a Charging Gateway Function (CGF) 324. CDF 322 comprises an element or module that receives charging events from CTFs, formats the charging events into CDRs, and sends the CDRs to CGF 324. CGF 324 comprises an element or module that correlates CDRs for a session, and forwards a CDR file with the correlated CDRs to a billing domain for subscriber billing and/or inter-operator accounting.

In another embodiment, charging system 140 may implement either online charging mechanism 310 or offline charging mechanism 320 individually.

FIG. 4 illustrates movement of UE 132 in an illustrative embodiment. UE 132 receives a service through a PDU session, which is a logical connection between UE 132 and DN 126. Various PDU session types are supported, such as IPv4 and IPv6. When a PDU session is first established to provide a service, SMF element 1 16 allocates or deploys a first UPF element 124 to serve the PDU session. UE 132 is in a service area of UPF element 124, and UPF element 124 handles user plane communications by UE 132. At some time, UE 132 moves out of the service area of UPF element 124. Thus, SMF element 1 16 allocates or deploys a second UPF element 424 that is suitable for the UE's new point of attachment to the network. One assumption for this embodiment may be that SSC mode 2 is implemented for service continuity as UE 132 moves, but SSC mode 3 may also be implemented. The following describes how charging may be performed when UE 132 is mobile in this manner.

FIG. 5 is a flow chart illustrating a method 500 of reporting charging information in an illustrative embodiment. The steps of method 500 will be described with reference to architecture 100 in FIG. 1 and SMF element 116 in FIG. 2, but those skilled in the art will appreciate that method 500 may be performed in other devices/architectures. The steps of the flow charts described herein are not all inclusive and may include other steps not shown, and the steps may be performed in an alternative order.

As described above, SMF element 116 is responsible for session management when UE 132 attempts to access a service in data network 126. Upon establishment of a PDU session to provide the service to UE 132, service continuity manager 212 allocates, selects, or deploys a first UPF element 124 as an anchor point of the PDU session for the service (step 502). Service continuity manager 212 may also assign an IP address to UE 132 for the PDU session, a charging ID for the PDU session, and other information.

CTF 210 in SMF element 1 16 collects charging information or charging data for the

PDU session (step 504). Charging information comprises any information or data indicating an activity utilizing telecommunications network resources for the service. CTF 210 reports the charging information for the PDU session to charging system 140 (step 506). As part of reporting, CTF 210 formats a charging request (or charging message) in response to a chargeable event during the PDU session. In one embodiment, the charging request may comprise a Diameter Credit Control Request (CCR), such as when a combined online/offline charging interface is implemented. In another embodiment, the charging request may comprise a Diameter ACR. In formatting the charging request, CTF 210 inserts the charging information in the appropriate fields or sub-fields of the charging request. For example, CTF 210 may insert a UPF ID for UPF element 124, a charging ID assigned to the PDU session, an IP address for UE 132, etc., in the charging request. CTF 210 then transmits (through interface component 202) the charging request to charging system 140.

In response to the charging request, CDF 322 in charging system 140 opens a CDR for the PDU session. CDF 322 processes the charging request to identify the charging information contained in the request, and populates fields of the CDR with the charging information. CDF 322 also responds to CTF 210 with a charging answer (e.g., Diameter Credit Control Answer (CCA) or ACA).

During the PDU session, CTF 210 may format additional (interim) charging requests, and transmit the charging requests to charging system 140. CDF 322 will update the open CDR with the information provided in the additional charging requests. CTF 210 also caches the charging information collected for the PDU session (step 508), such as in memory 208, even if the PDU session is released. CTF 210 may recall the cached charging information if the anchor point is redirected for the service, which is described in more detail below.

Service continuity manager 212 monitors for the completion status of the service

(step 510) (i.e., whether or not the service has completed or ended). If the service completes during the PDU session, then method 500 ends. It is assumed that CTF 210 will interact with charging system 140 in a conventional manner to complete charging for the service. Service continuity manager 212 also monitors for trigger conditions that may affect the user plane path (step 512). For example, service continuity manager 212 may subscribe to a "UE mobility event notification" service provided by AMF element 1 14 for reporting of UE presence in an "area of interest" (e.g., a list of Tracking Areas and/or cell identifiers) or a location change of a UE. Upon reception of a notification from AMF element 1 14, service continuity manager 212 determines how to handle the user plane to maintain service continuity. For instance, if UE 132 has left the service area of UPF element 124, then service continuity manager 212 may redirect the service to another UPF element to maintain service continuity.

In response to a trigger condition being satisfied, service continuity manager 212 allocates, selects, or deploys another UPF element 424 as an anchor point of a new PDU session for the service (step 514). For example, service continuity manager 212 may determine whether UE 132 moves outside of a service area of UPF element 124 and into a service area of UPF element 424. When UE 132 moves in this manner, service continuity manager 212 is configured to redirect the service to a new UPF element 424. In either of SSC mode 2 or SSC mode 3, redirection will result in the present PDU session being released, and a new PDU session established without interruption of the service. Service continuity manager 212 may therefore exchange control messages with UE 132 to release the previous PDU session anchored by UPF element 124, and establish a new PDU session anchored by UPF element 424. Service continuity manager 212 also assigns a new IP address to UE 132, a new charging ID for the new PDU session, and other information.

CTF 210 collects charging information or charging data for the new PDU session (step 516). CTF 210 then reports the charging information for the new PDU session to charging system 140 (step 518). In addition, CTF 210 reports the charging information for one or more previous PDU sessions to charging system 140. After redirection and a new PDU session is established, CTF 210 is programmed to report not just information for the new PDU session, but also past charging information for previous PDU sessions for the same service. As part of reporting, CTF 210 formats another charging request in response to a chargeable event during the new PDU session. In formatting the charging request, CTF 210 inserts the charging information in the appropriate fields or sub- fields of the charging request. For example, CTF 210 may insert a UPF ID for UPF element 424, a charging ID assigned to the new PDU session, an IP address for UE 132 as part of the new PDU session, or other charging information pertaining to the new PDU session anchored by UPF element 424. CTF 210 may also insert a cause code in the charging request indicating a reason for redirection of the UPF element. CTF 210 may also insert charging information pertaining to one or more previous PDU session(s). For example, CTF 210 may insert the UPF ID for UPF element 124, the charging ID assigned to the previous PDU session, the IP address for UE 132 as part of the previous PDU session, a start time of the previous PDU session, a duration of the previous PDU session, etc. CTF 210 then transmits (through interface component 202) the charging request to charging system 140.

In response to the charging request, CDF 322 opens a CDR for the new PDU session. CDF 322 processes the charging request to identify the charging information, and populates fields of the CDR with the charging information. CDF 322 also responds to CTF 210 with a charging answer.

CTF 210 may also transmit another charging request to charging system 140 indicating that the previous PDU session is released. In response to this charging request, CDF 322 may close the CDR for the previous PDU session.

During the new PDU session with UPF element 424 as the anchor point, CTF 210 may format additional (interim) charging requests and transmit the charging requests to charging system 140. CDF 322 will update the CDR with the information provided in the additional charging requests. CTF 210 also caches the charging information collected for the new PDU session (step 520), such as in memory 208.

Service continuity manager 212 again monitors for the completion status of the service (step 522). If the service completes during the present PDU session, then method 500 ends. It is assumed that CTF 210 will interact with charging system 140 in a conventional manner to complete charging for the service. Service continuity manager 212 also monitors for trigger conditions that may affect the user plane path (step 524). If a trigger condition is again satisfied, service continuity manager 212 will allocate yet another UPF element to replace the previous UPF element 424 and report charging information as discussed above. If not, this PDU session may continue with UPF element 424 as the anchor point until the service has completed. After the service is complete, CTF 210 may transmit another charging request to charging system 140, and CDF 322 will close the latest CDR. CDF 322 may forward multiple CDRs to CGF 324 (see FIG. 3), where CGF 324 may collate the CDRs for the service.

FIG. 6 is a signal diagram indicating service continuity in an illustrative

embodiment. When an end user wants to access a service through an application running on UE 132, UE 132 initiates a PDU session establishment procedure to establish a new PDU session (PDU session 1). SMF element 1 16 allocates a UPF element 124 as the anchor point for the PDU session, assigns a charging ID for the PDU session, assigns an IP address for UE 132, etc. UE 132 may then exchange uplink (UL) and/or downlink (DL) traffic with a data network 126 (not shown) through UPF element 124. SMF element 116 also reports charging information for PDU session 1 to charging system 140, which includes information on UE 132 and UPF element 124. Charging system 140 generates one or more CDRs (CDR1) for PDU session 1 based on the charging information reported by SMF element 116.

At some point during the service, SMF element 1 16 determines that relocation of the UPF for the service would be expedient from a perspective of network usage or subscriber QoE or both. This is a network trigger for UPF relocation. SMF element 116 transmits a message to UE 132 (via AMF element 1 14) to trigger UE 132 to release the present PDU session, and re-establish a new PDU session to the same DN 126. In response to the message, UE 132 initiates a PDU session release procedure to release PDU session 1. In response, SMF element 116 indicates to charging system 140 about the termination of PDU session 1 for UPF 124, and any association with the allocated IP address to UE 132 is terminated.

Because SMF element 116 is central to the charging solution, SMF element 1 16 reports the charging ID(s), the allocated IP address for UE 132 for PDU session 1, UPF information, and a cause code as invocation of SSC mode 2. In addition, SMF element 1 16 caches the charging information for PDU session 1, which will be provided to charging system 140 if/when a new PDU session is established.

For the "break before make" method of SSC mode 2, UE 132 initiates a PDU session establishment procedure to establish a new PDU session (PDU session 2) used to provide the service to UE 132. SMF element 1 16 allocates a UPF element 424 as the anchor point for the new PDU session, assigns a charging ID for the new PDU session, assigns an IP address for UE 132, etc. UE 132 may then exchange UL and/or DL traffic with data network 126 (not shown) through UPF element 424. SMF element 116 also reports charging information for PDU session 2 to charging system 140, which includes information on UE 132 and UPF element 424. In addition, SMF element 1 16 reports charging information for one or more previous PDU sessions (e.g., PDU session 1) that were used to provide the service, such as the charging ID(s), the IP address of UE 132 for PDU session 1, and previous UPF information. Charging system 140 generates one or more CDRs (CDR2) for PDU session 2 based on the charging information reported by SMF element 1 16. Because SMF element 1 16 reports charging information for a present PDU session and previous PDU sessions for the same service, charging system 140 is able to insert the charging information into the CDR(s) that is generated. For example, CDR2 generated by charging system 140 may include a charging ID, IP address, UPF ID, etc., for PDU session 2, and may also include a charging ID, IP address, UPF ID, etc., for PDU session 1. Thus, a downstream system may collate or otherwise assemble CDR2 with CDR1, which are both for the same service to UE 132, based on the charging ID, IP address, and/or UPF ID that pertains to PDU session 1.

In one embodiment, the N-CH reference point between SMF element 1 16 and charging system 140 may be based on Diameter protocol (e.g., Gy or Gz), such as described in 3GPP TS 32.299 (vl4.4.0), which is incorporated by reference as if fully included herein. The N-CH reference point is enhanced in this embodiment to support service continuity for sessions. The N-CH reference point uses Credit Control Request (CCR) and Credit Control Answer (CCA) messages, assuming a combined offline/online charging paradigm. Data delivered by Diameter protocol is in the form of Attribute Value Pairs (A VP). Some of the AVP values are used by Diameter protocol itself, while other AVPs deliver data associated with particular applications that employ Diameter. In order to support service continuity, the N-CH reference point may be extended so that the Diameter request sent from SMF element 116 to charging system 140 includes one or more new AVPs. The following illustrates a CCR of the N-CH reference point with new AVPs.

A CCR command from SMF element 1 16 to charging system 140 may contain enhanced Multiple-Services-Credit-Control (MSCC) and Service-Information AVPs as indicated in the following message format:

<CCR> ::= < Diameter Header: 272, REQ, PXY >

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Auth-Application-Id }

{ Service-Context-Id }

{ CC-Request-Type }

{ CC-Request-Number }

[ Destination-Host ]

[ User-Name ]

[ Origin-State-Id ]

[ Event-Timestamp ]

*[ Subscription-Id ]

[ Termination-Cause ]

[ Requested-Action ]

[ AoC-Request-Type ]

[ Multiple-Services-Indicator ]

*[ Multiple-Services-Credit-Control ] ###

[ CC-Correlation-Id ]

[ User-Equipment-Info ]

*[ Proxy-Info ]

*[ Route-Record ]

[ Service-Information ] ###

A "*" indicates that the AVP may occur multiple times. A "###" indicates an AVP that is extended to support service continuity. A "+++" indicates a new AVP added to support service continuity.

The "Multiple-Services-Credit-Control" AVP may be re-used to indicate a charging method for a PDU session. The "Multiple-Services-Credit-Control" AVP contains the AVPs related to the independent credit-control. The "Multiple-Services-Credit-Control" AVP may be enhanced in this embodiment with one or more new sub-AVPs as provided in the following: Multiple-Services-Credit-Control ::= < AVP Header:456>

[ online-only] +++

[ offline-only ] +++

[ online-offline ] ++4

*[ AVP ]

The "online-only" AVP is defined to indicate, deliver, or identify that online charging solely applies for a PDU session. The "offline-only" AVP is defined to indicate, deliver, or identify that offline charging solely applies for a PDU session. The "online- offline" AVP is defined to indicate, deliver, or identify that both online and offline charging apply for a PDU session.

The Service-Information AVP may be extended to deliver information on UPFs, and may have the following format:

Service-Information ::= < AVP Header:873>

*[ Subscription-Id ]

[AoC-Information ]

[ PS-Information ]

[ IMS-Information ]

[ MMS-Information ]

[ LCS-Information ]

[ PoC-Information ]

[ MBMS-Information ]

[ SMS-Information ]

[ VCS-Information ]

[ MMTel-Information ]

[ ProSe-Information ]

[ Service-Generic-Information ]

[ IM-Information ]

[ DCD-Information ]

[ M2M-Information ]

[ CPDT-Information ]

*[ UPF-Information ] +++

The "UPF-Information" AVP is defined to indicate, deliver, or identify information for an anchor point in the user plane for a PDU session. The name or label of "UPF- Information" may vary as desired. The UPF-Information AVP may have the following format:

UPF-Information ::= < AVP Header>

[ NeS-Id ]

[ UPF-Id ]

[ DN-Id ]

[ UL-Classfier-Id ]

[ IPv6MH-Prefix ]

[ Local-Indicator ]

[ SSC-Information ]

*[AVP ]

The "NeS-Id" AVP is defined to indicate, deliver, or identify a network slice ID or NeS-ID for a network slice selected for UE 132. The "UPF-Id" AVP is defined to indicate, deliver, or identify a value indicating a UPF selected as an anchor point in the user plane. The "DN-Id" AVP is defined to indicate, deliver, or identify a data network ID for the data network providing the service. The "UL-Classifier-ID" AVP is defined to indicate, deliver, or identify an Uplink Classifier that is a functionality supported by a UPF that aims at diverting some traffic matching traffic filters provided by SMF element 1 16. The

"IPv6MH-Prefix" AVP is defined to indicate, deliver, or identify an IPv6 Multi-homing Prefix for the UPF (a session may be associated with multiple IPv6 prefix's). The "Local- Indicator" AVP is defined to indicate, deliver, or identify a local area data network. The "Local-Indicator" AVP may be populated with a Local Area Data Network identifier (LADN-ID). The "SSC-Information" AVP is defined to indicate, deliver, or identify information specific to SSC.

The "SSC-Information" AVP may have the following format:

SSC-Information ::= < AVP Header>

[ SSC-Mode ]

[ SSC-SMF-ID ]

[ SSC-Charging-ID ]

[ SSC-Modification-Code ]

[ SSC-Start-Time ]

[ SSC-End-Time ]

* [ SSC-Context-Info ]

*[AVP ]

The "SSC-Mode" AVP is defined to indicate, deliver, or identify a value indicating the SSC mode for a present PDU session, such as SSC mode 1, SSC mode 2, or SSC mode 3. The "SSC-SMF-ID" AVP is defined to indicate, deliver, or identify a value indicating an SMF ID that manages a present PDU session. The "SSC-Charging-ID" AVP is defined to indicate, deliver, or identify a charging ID for a present PDU session. The "SSC- Modification-Code" AVP is defined to indicate, deliver, or identify a cause code indicating a cause for relocating or redirecting a service to a different UPF element. The "SSC-Start- Time" AVP is defined to indicate, deliver, or identify a start time of a present PDU session, and the "SSC-End-Time" AVP is defined to indicate, deliver, or identify a release time of the present PDU session. The "SSC-Context-Info" AVP is used to indicate, deliver, or identify context information related to a service. Context information comprises information specifying an existence of one or more prior PDU sessions established for providing the service to a UE.

The SSC-Context-Info AVP may have the following format:

SSC- Context-Info ::= < AVP Header>

[ SSC-SMF-ID ]

[ UPF-ID ]

[ SSC-Charging-ID ]

[ IPv6MH-Prefix ]

[ SSC-Start-Time ]

[ SSC-Interval ]

*[AVP ]

The "SSC-SMF-ID" AVP is defined to indicate, deliver, or identify an SMF ID for a previous PDU session used for the same service. The "UPF-ID" AVP is defined to indicate, deliver, or identify a UPF ID for a previous UPF element allocated to a previous PDU session. The "SSC-Charging-ID" AVP is defined to indicate, deliver, or identify a previous charging ID for a previous PDU session. The "IPv6MH-Prefix" AVP is defined to indicate, deliver, or identify an IPv6 Multi-homing Prefix for a previous UPF allocated for a previous PDU session. The "SSC-Start-Time" AVP is defined to indicate, deliver, or identify a start time of a previous PDU session, and the "SSC-Interval" AVP is defined to indicate, deliver, or identify a duration of a previous PDU session.

Any of the various elements or modules shown in the figures or described herein may be implemented as hardware, software, firmware, or some combination of these. For example, an element may be implemented as dedicated hardware. Dedicated hardware elements may be referred to as "processors", "controllers", or some similar terminology. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, a network processor, application specific integrated circuit (ASIC) or other circuitry, field

programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage, logic, or some other physical hardware component or module.

Also, an element may be implemented as instructions executable by a processor or a computer to perform the functions of the element. Some examples of instructions are software, program code, and firmware. The instructions are operational when executed by the processor to direct the processor to perform the functions of the element. The instructions may be stored on storage devices that are readable by the processor. Some examples of the storage devices are digital or solid-state memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.

As used in this application, the term "circuitry" may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry);

(b) combinations of hardware circuits and software, such as (as applicable):

(i) a combination of analog and/or digital hardware circuit(s) with software/firmware; and

(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); and

(c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

Although specific embodiments were described herein, the scope of the disclosure is not limited to those specific embodiments. The scope of the disclosure is defined by the following claims and any equivalents thereof.

Claims

What is claimed is:

1. A system comprising:

a Session Management Function (SMF) element implemented in a control plane of a next generation network, the SMF element comprising:

a service continuity manager configured to allocate a first User Plane Function (UPF) element as an anchor point of a first Packet Data Unit (PDU) session for a service accessed by User Equipment (UE); and

a Charging Trigger Function (CTF) implemented in a processor that is configured to collect charging information for the first PDU session, and to report the charging information for the first PDU session to a charging system;

wherein the service continuity manager is configured to allocate a second UPF element as an anchor point for a second PDU session for the service in response to a trigger condition;

wherein the CTF is configured to collect charging information for the second

PDU session, and to report the charging information for the second PDU session and the charging information for the first PDU session to the charging system.

2. The system of claim 1 wherein:

the CTF, in reporting the charging information for the first PDU session, is configured to format a first charging request in response to a chargeable event during the first PDU session, and to transmit the first charging request to the charging system;

the CTF is configured to format the first charging request to include the charging information for the first PDU session;

the CTF, in reporting the charging information for the second PDU session, is configured to format a second charging request in response to a chargeable event during the second PDU session, and to transmit the second charging request to the charging system; and

the CTF is configured to format the second charging request to include the charging information for the second PDU session and to also include the charging information for the first PDU session.

3. The system of claim 1 wherein:

the charging information for the first PDU session includes a UPF identifier for the first UPF element, a first charging identifier for the first PDU session, and a first Internet- Protocol (IP) address assigned to the UE for the first PDU session; and

the charging information for the second PDU session includes a UPF identifier for the second UPF element, a second charging identifier for the second PDU session, and a second IP address assigned to the UE for the second PDU session.

4. The system of claim 3 wherein:

the CTF is configured to report the charging information for the second PDU session in a Diameter charging request; and

Attribute Value Pairs (A VPs) are defined in the Diameter charging request for charging information pertaining to the second PDU session and the first PDU session.

5. The system of claim 4 wherein:

a first one of the AVPs is defined to identify the UPF identifier for the first UPF element that was the anchor point for the first PDU session;

a second one of the AVPs is defined to identify the first charging identifier for the first PDU session; and

a third one of the AVPs is defined to identify the IP address assigned to the UE for the first PDU session.

6. The system of claim 5 wherein:

a fourth one of the AVPs is defined to identify a start time of the first PDU session; and

a fifth one of the AVPs is defined to identify a duration that the first PDU session.

7. The system of claim 1 wherein the SMF element further comprises:

a first interface component configured to directly communicate with the charging system; and

a second interface component configured to directly communicate with the first UPF element and the second UPF element.

8. The system of claim 1 wherein:

the CTF is configured to cache the charging information for the first PDU session after the first PDU session is released.

9. A method in a Session Management Function (SMF) element implemented in a control plane of a next generation network, method comprising:

allocating a first User Plane Function (UPF) element as an anchor point of a first Packet Data Unit (PDU) session for a service accessed by User Equipment (UE);

collecting charging information for the first PDU session;

reporting the charging information for the first PDU session to a charging system; allocating a second UPF element as an anchor point for a second PDU session for the service in response to a trigger condition;

collecting charging information for the second PDU session; and

reporting the charging information for the second PDU session and the charging information for the first PDU session to the charging system.

10. The method of claim 9 wherein:

reporting the charging information for the first PDU session comprises formatting a first charging request in response to a chargeable event during the first PDU session, and transmitting the first charging request to the charging system;

formatting the first charging request comprises formatting the first charging request to include the charging information for the first PDU session;

reporting the charging information for the second PDU session comprises formatting a second charging request in response to a chargeable event during the second PDU session, and transmitting the second charging request to the charging system; and

formatting the second charging request comprises formatting the second charging request to include the charging information for the second PDU session and to also include the charging information for the first PDU session.

11. The method of claim 9 wherein:

the charging information for the first PDU session includes a UPF identifier for the first UPF element, a first charging identifier for the first PDU session, and a first Internet- Protocol (IP) address assigned to the UE for the first PDU session; and

the charging information for the second PDU session includes a UPF identifier for the second UPF element, a second charging identifier for the second PDU session, and a second IP address assigned to the UE for the second PDU session.

12. The method of claim 1 1 wherein:

reporting the charging information for the second PDU session comprises reporting via a Diameter charging request; and

Attribute Value Pairs (A VPs) are defined in the Diameter charging request for charging information pertaining to the second PDU session and the first PDU session.

13. The method of claim 12 wherein:

a first one of the AVPs is defined to identify the UPF identifier for the first UPF element that was the anchor point for the first PDU session;

a second one of the AVPs is defined to identify the first charging identifier for the first PDU session; and

a third one of the AVPs is defined to identify the IP address assigned to the UE for the first PDU session.

14. The method of claim 13 wherein:

a fourth one of the AVPs is defined to identify a start time of the first PDU session; and

a fifth one of the AVPs is defined to identify a duration that the first PDU session.

15. The method of claim 9 further comprising:

caching the charging information for the first PDU session after the first PDU session is released.

16. An apparatus comprising:

at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform functions of a Session

Management Function (SMF) element implemented in a control plane of a next generation network, the functions including:

allocating a first User Plane Function (UPF) element as an anchor point of a first Packet Data Unit (PDU) session for a service accessed by User Equipment

(UE);

collecting charging information for the first PDU session;

reporting the charging information for the first PDU session to a charging system;

allocating a second UPF element as an anchor point for a second PDU session for the service in response to a trigger condition;

collecting charging information for the second PDU session; and reporting the charging information for the second PDU session and the charging information for the first PDU session to the charging system.

17. The apparatus of claim 16 wherein:

reporting the charging information for the first PDU session comprises formatting a first charging request in response to a chargeable event during the first PDU session, and transmitting the first charging request to the charging system;

formatting the first charging request comprises formatting the first charging request to include the charging information for the first PDU session;

reporting the charging information for the second PDU session comprises formatting a second charging request in response to a chargeable event during the second PDU session, and transmitting the second charging request to the charging system; and

formatting the second charging request comprises formatting the second charging request to include the charging information for the second PDU session and to also include the charging information for the first PDU session.

18. The apparatus of claim 16 wherein:

the charging information for the first PDU session includes a UPF identifier for the first UPF element, a first charging identifier for the first PDU session, and a first Internet- Protocol (IP) address assigned to the UE for the first PDU session; and

the charging information for the second PDU session includes a UPF identifier for the second UPF element, a second charging identifier for the second PDU session, and a second IP address assigned to the UE for the second PDU session.

19. The apparatus of claim 18 wherein:

reporting the charging information for the second PDU session comprises reporting via a Diameter charging request; and

Attribute Value Pairs (A VPs) are defined in the Diameter charging request for charging information pertaining to the second PDU session and the first PDU session.

20. The apparatus of claim 19 wherein:

a first one of the AVPs is defined to identify the UPF identifier for the first UPF element that was the anchor point for the first PDU session;

a second one of the AVPs is defined to identify the first charging identifier for the first PDU session;

a third one of the AVPs is defined to identify the IP address assigned to the UE for the first PDU session;

a fourth one of the AVPs is defined to identify a start time of the first PDU session; and

a fifth one of the AVPs is defined to identify a duration that the first PDU session.