Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
CHARGING SUPPORT FOR CONTINUITY IN NEXT GENERATION NETWORKS
Document Type and Number:
WIPO Patent Application WO/2019/035836
Kind Code:
A1
Abstract:
Systems, methods, and software that manage a session of User Equipment (UE) over a network. In one embodiment, a session management server implements a session management function configured to trigger a redirection of an anchor point for the session from a first User Plane Function (UPF), and to select a second UPF as the anchor point for the session. In response to redirecting the anchor point from the first UPF to the second UPF, the session management function is configured to format an interim charging request that includes information on the second UPF, and to transmit the interim charging request to a charging server to report the information on the second UPF to the charging server.

Inventors:
CAI YIGANG (US)
SHARMA RANJAN (US)
Application Number:
PCT/US2017/047376
Publication Date:
February 21, 2019
Filing Date:
August 17, 2017
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
NOKIA SOLUTIONS & NETWORKS OY (FI)
NOKIA USA INC (US)
International Classes:
H04L12/14; H04M15/00; H04W4/24
Foreign References:
US20160094722A12016-03-31
EP2023588A12009-02-11
Other References:
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System; Stage 2 (Release 15)", 3GPP STANDARD ; TECHNICAL SPECIFICATION ; 3GPP TS 23.502, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG2, no. V0.5.0, 14 July 2017 (2017-07-14), pages 1 - 153, XP051336672
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Architecture for Next Generation System (Release 14)", 3GPP STANDARD ; TECHNICAL REPORT ; 3GPP TR 23.799, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG2, no. V14.0.0, 16 December 2016 (2016-12-16), pages 1 - 527, XP051295448
Attorney, Agent or Firm:
BORNSEN, Brett (US)
Download PDF:
Claims:
What is claimed is:

1. An apparatus comprising:

a session management server that manages a session of User Equipment (UE) over a network, the session management server comprising:

a first interface component configured to communicate with a charging server; and

a processor that implements a session management function configured to trigger a redirection of an anchor point for the session from a first User Plane Function (UPF), and to select a second UPF as the anchor point for the session; the session management function, in response to redirecting the anchor point from the first UPF to the second UPF, is configured to format an interim charging request that includes information on the second UPF, and to transmit the interim charging request to the charging server through the first interface component to report the information on the second UPF to the charging server.

2. The apparatus of claim 1 wherein:

the session management function, in response to establishment of the session, is configured to select the first UPF as the anchor point for the session to format an initial charging request that includes information on the first UPF, and to transmit the initial charging request to the charging server through the first interface component to report the information on the first UPF to the charging server.

3. The apparatus of claim 2 further comprising:

a second interface component configured to communicate with the first UPF and the second UPF;

wherein the session management function is configured to transmit a first control message to the first UPF through the second interface component to release a first user plane path for the session corresponding with the first UPF, and to transmit a second control message to the second UPF through the second interface component to set up a second user plane path corresponding to the second UPF.

4. The apparatus of claim 3 wherein:

the session management function is configured to transmit the first control message to the first UPF and the second control message to the second UPF to instruct the first UPF to release the first user plane path before the second UPF sets up the second user plane path.

5. The apparatus of claim 3 wherein:

the session management function is configured to transmit the first control message to the first UPF and the second control message to the second UPF to instruct the first UPF to release the first user plane path after the second UPF sets up the second user plane path.

6. The apparatus of claim 1 wherein:

the interim charging request comprises a Diameter request; and

a first Attribute Value Pair (AVP) is defined in the Diameter request to identify information on the second UPF that is the anchor point for the session.

7. The apparatus of claim 6 wherein:

a second AVP is defined in the first AVP to identify a UPF identifier (ID) for the second UPF that is the anchor point for the session.

a third AVP is defined in the first AVP to identify a network slice ID for a network slice selected for the UE;

a fourth AVP is defined in the first AVP to identify a data network ID for a data network connected in the session; and

a fifth AVP is defined in the first AVP to identify an Internet Protocol (IP) prefix for the second UPF.

8. The apparatus of claim 7 wherein:

the Diameter request comprises a Diameter Credit Control Request (CCR); and a Multiple-Services-Credit-Control AVP of the Diameter CCR is extended to include a sixth AVP defined to identify that charging for the session is online only, a seventh AVP defined to identify that charging for the session is offline only, and an eighth AVP defined to identify that charging for the session is a combination of online and offline.

9. A method comprising:

triggering, at a session management server that manages a session of User

Equipment (UE) over a network, a redirection of an anchor point for the session from a first User Plane Function (UPF);

selecting, at the session management server, a second UPF as the anchor point for the session; and

in response to redirecting the anchor point from the first UPF to the second UPF: formatting, at the session management server, an interim charging request that includes information on the second UPF; and

transmitting the interim charging request from the session management server to a charging server to report the information on the second UPF to the charging server.

10. The method of claim 9 further comprising:

in response to establishment of the session:

selecting, at the session management server, the first UPF as the anchor point for the session;

formatting, at the session management server, an initial charging request that includes information on the first UPF; and

transmitting the initial charging request from the session management server to the charging server to report the information on the first UPF to the charging server.

11. The method of claim 10 further comprising:

transmitting a first control message from the session management server to the first UPF to release a first user plane path for the session corresponding with the first UPF; and transmitting a second control message from the session management server to the second UPF to set up a second user plane path corresponding to the second UPF.

12. The method of claim 11 wherein:

transmitting the first control message and the second control message comprises transmitting the first control message to the first UPF and the second control message to the second UPF to instruct the first UPF to release the first user plane path before the second UPF sets up the second user plane path.

13. The method of claim 11 wherein:

transmitting the first control message and the second control message comprises transmitting the first control message to the first UPF and the second control message to the second UPF to instruct the first UPF to release the first user plane path after the second UPF sets up the second user plane path.

14. The method of claim 9 wherein:

the interim charging request comprises a Diameter request; and

a first Attribute Value Pair (AVP) is defined in the Diameter request to identify information on the second UPF that is the anchor point for the session.

15. The method of claim 14 wherein:

a second AVP is defined in the first AVP to identify a UPF identifier (ID) for the second UPF that is the anchor point for the session.

a third AVP is defined in the first AVP to identify a network slice ID for a network slice selected for the UE;

a fourth AVP is defined in the first AVP to identify a data network ID for a data network connected in the session; and

a fifth AVP is defined in the first AVP to identify an Internet Protocol (IP) prefix for the second UPF.

16. The method of claim 15 wherein:

the Diameter request comprises a Diameter Credit Control Request (CCR); and a Multiple-Services-Credit-Control AVP of the Diameter CCR is extended to include a sixth AVP defined to identify that charging for the session is online only, a seventh AVP defined to identify that charging for the session is offline only, and an eighth AVP defined to identify that charging for the session is a combination of online and offline.

17. A non-transitory computer readable medium embodying programmed instructions executed by one or more processors, wherein the instructions direct the processors to implement:

a session management function that manages a session of User Equipment (UE) over a network;

the session management function triggers a redirection of an anchor point for the session from a first User Plane Function (UPF), and selects a second UPF as the anchor point for the session;

the session management function, in response to redirecting the anchor point from the first UPF to the second UPF, formats an interim charging request that includes information on the second UPF, and transmits the interim charging request to the charging server to report the information on the second UPF to the charging server.

18. The computer readable medium of claim 17 wherein:

the session management function, in response to establishment of the session, selects the first UPF as the anchor point for the session, formats an initial charging request that includes information on the first UPF, and transmits the initial charging request to the charging server to report the information on the first UPF to the charging server. 19. The computer readable medium of claim 18 wherein:

the session management function transmits a first control message to the first UPF to release a first user plane path for the session corresponding with the first UPF, and transmits a second control message to the second UPF to set up a second user plane path

corresponding to the second UPF.

20. The computer readable medium of claim 17 wherein:

the interim charging request comprises a Diameter request; and

a first Attribute Value Pair (AVP) is defined in the Diameter request to identify information on the second UPF that is the anchor point for the session.

Description:
CHARGING SUPPORT FOR CONTINUITY IN NEXT GENERATION

NETWORKS Field of the Invention

The invention 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. To provide support for different types of services, use-cases, and business models, the physical network may be partitioned into multiple virtual instances, which is referred to as network slicing. Network slicing offers an effective way to meet different use-case requirements and exploit the benefits of a common network infrastructure.

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 continuity. When an anchor point in the user plane is selected for a session involving a UE, an element in the control plane triggers a charging request to report the identity of the anchor point to a charging system. Likewise, if a replacement anchor point is selected for the UE, the element in the control plane triggers a charging request to report the identity of the anchor point to the charging system. The charging system may then handle charging for the session based, at least in part, on the identity of the anchor point. One benefit is that network operators may be able to more accurately charge for sessions within next generation networks.

One embodiment comprises a session management server that manages a session of a UE over a network. The session management server includes a first interface component configured to communicate with a charging server, and a processor that implements a session management function. The session management function is configured to trigger a redirection of an anchor point for the session from a first User Plane Function (UPF), and to select a second UPF as the anchor point for the session. In response to redirecting the anchor point from the first UPF to the second UPF, the session management function is configured to format an interim charging request that includes information on the second UPF, and to transmit the interim charging request to the charging server through the first interface component to report the information on the second UPF to the charging server.

In another embodiment, the session management function, in response to establishment of the session, is configured to select the first UPF as the anchor point for the session, to format an initial charging request that includes information on the first UPF, and to transmit the initial charging request to the charging server through the first interface component to report the information on the first UPF to the charging server.

In another embodiment, the session management server further includes a second interface component configured to communicate with the first UPF and the second UPF. The session management function is configured to transmit a first control message to the first UPF through the second interface component to release a first user plane path for the session corresponding with the first UPF, and to transmit a second control message to the second UPF through the second interface component to set up a second user plane path corresponding to the second UPF.

In another embodiment, the session management function is configured to transmit the first control message to the first UPF and the second control message to the second UPF to instruct the first UPF to release the first user plane path before the second UPF sets up the second user plane path.

In another embodiment, the session management function is configured to transmit the first control message to the first UPF and the second control message to the second UPF to instruct the first UPF to release the first user plane path after the second UPF sets up the second user plane path. In another embodiment, the interim charging request comprises a Diameter request, and a first Attribute Value Pair (AVP) is defined in the Diameter request to identify information on the second UPF that is the anchor point for the session.

In another embodiment, a second AVP is defined in the first AVP to identify a UPF identifier (ID) for the second UPF that is the anchor point for the session.

In another embodiment, a third AVP is defined in the first AVP to identify a network slice ID for a network slice selected for the UE, a fourth AVP is defined in the first AVP to identify a data network ID for a data network connected in the session, and a fifth AVP is defined in the first AVP to identify an Internet Protocol (IP) prefix for the second UPF.

In another embodiment, the Diameter request comprises a Diameter Credit Control Request (CCR), and a Multiple-Services-Credit-Control AVP of the Diameter CCR is extended to include a sixth AVP defined to identify that charging for the session is online only, a seventh AVP defined to identify that charging for the session is offline only, and an eighth AVP defined to identify that charging for the session is a combination of online and offline.

Another embodiment comprises a method that includes the steps of triggering, at a session management server, a redirection of an anchor point for the session from a first UPF, and selecting a second UPF as the anchor point for the session. In response to redirecting the anchor point from the first UPF to the second UPF, the method includes formatting an interim charging request that includes information on the second UPF, and transmitting the interim charging request from the session management server to a charging server to report the information on the second UPF to the charging server.

In another embodiment, in response to establishment of the session, the method includes selecting the first UPF as the anchor point for the session, formatting an initial charging request that includes information on the first UPF, and transmitting the initial charging request from the session management server to the charging server to report the information on the first UPF to the charging server.

In another embodiment, the method includes transmitting a first control message from the session management server to the first UPF to release a first user plane path for the session corresponding with the first UPF, and transmitting a second control message from the session management server to the second UPF to set up a second user plane path corresponding to the second UPF.

In another embodiment, transmitting the first control message and the second control message comprises transmitting the first control message to the first UPF and the second control message to the second UPF to instruct the first UPF to release the first user plane path before the second UPF sets up the second user plane path.

In another embodiment, transmitting the first control message and the second control message comprises transmitting the first control message to the first UPF and the second control message to the second UPF to instruct the first UPF to release the first user plane path after the second UPF sets up the second user plane path.

Another embodiment comprises a non-transitory computer readable medium embodying programmed instructions executed by one or more processors, wherein the instructions direct the processors to implement a session management function that manages a session of a UE over a network. The session management function triggers a redirection of an anchor point for the session from a first UPF, and selects a second UPF as the anchor point for the session. In response to redirecting the anchor point from the first UPF to the second UPF, the session management function formats an interim charging request that includes information on the second UPF, and transmits the interim charging request to the charging server to report the information on the second UPF to the charging server.

In another embodiment, in response to establishment of the session, the session management function selects the first UPF as the anchor point for the session, formats an initial charging request that includes information on the first UPF, and transmits the initial charging request to the charging server to report the information on the first UPF to the charging server.

In another embodiment, the session management function transmits a first control message to the first UPF to release a first user plane path for the session corresponding with the first UPF, and transmits a second control message to the second UPF to set up a second user plane path corresponding to the second UPF.

Another embodiment comprises an apparatus that comprises a session management server for managing a session of a UE over a network. The session management server includes a means for communicating with a charging server, and a means for implementing a session management function. The session management function triggers a redirection of an anchor point for the session from a first UPF, and selects a second UPF as the anchor point for the session. In response to redirecting the anchor point from the first UPF to the second UPF, the session management function formats an interim charging request that includes information on the second UPF, and transmits the interim charging request to the charging server to report the information on the second UPF to the charging server.

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 high-level architecture of a next generation mobile network. FIG. 2 illustrates a network slicing architecture.

FIG. 3 illustrates an initial attach procedure for a UE.

FIG. 4 illustrates a new session establishment procedure for a UE.

FIG. 5 illustrates a non-roaming architecture in a direct point-to-point reference point representation.

FIG. 6 illustrates a non-roaming architecture in a direct point-to-point reference point representation in an exemplary embodiment.

FIG. 7 is a block diagram of a session management server in an exemplary embodiment.

FIG. 8 is a block diagram of a charging server in an exemplary embodiment. FIGS. 9-10 are flow charts illustrating a method of reporting an anchor point in the user plane in an exemplary embodiment.

FIG. 11 is a flow chart illustrating a method of charging for a session in an exemplary 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 high-level architecture of a next generation network 100 as described in Third Generation Partnership Project (3GPP) TR 23.799 (version 14.0.0), which is incorporated by reference as if fully included herein. Network 100 includes a next generation (Next-Gen) core network 102 and a next generation access network and/or radio access network ((R)AN) 104. Access network 104 may support Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN) access, Wireless Local Area Network (WLAN) access, fixed access, satellite radio access, new Radio Access Technologies (RAT), etc. Core network 102 interconnects access network 104 with a data network 106. Data network 106 may be an operator external public or private data network, or an intra-operator data network (e.g., for IMS services). Next generation User Equipment (UE) 108 is able to attach to access network 104 to access services from core network 102.

One goal of next generation networks (e.g., 5G) is to enable network slicing. With network slicing, a physical network may be partitioned into multiple virtual instances so that a mobile operator can offer support for different types of services for different types of customer segments. A network slice is a logical representation of network functions and corresponding resource requirements necessary to provide the required telecommunication services and network capabilities. For example, a mobile operator may provide a network slice for Machine-Type Communications (MTC) devices or Internet of Things (IoT) devices, which offers a reliable data-only service with a given latency, data rate, and security level. The mobile operator may also provide a network slice with very high throughput, high data speeds, and low latency for real-time or on-demand services. The mobile operator may provide other network slices that provide the required telecommunication services and network capabilities. The core network part of a network slice is referred to as the CN slice, and the radio network part of a network slice is referred to as the RAN Slice.

FIG. 2 illustrates a network slicing architecture 200, as is further described in 3GPP TR 23.799. In next generation networks, control plane (CP) functions and user plane (UP) functions are separated, allowing independent scalability and evolution. The user plane carries user traffic (e.g., data flows) over bearers, and the control plane carries signaling traffic to set up, maintain, and tear down the data flows. A UP function supports various user-plane operations, such as forwarding operations to other UP functions or data networks, bitrate enforcement operations, service detection operations, etc. A CP function configures the UP functions to provide the traffic handling functionality needed for a session. One or multiple UP functions per session may be activated and configured by a CP function as needed for a given user-plane scenario.

In architecture 200, the control plane of core network 102 (see FIG. 1) is partitioned into three types of Network Functions (NFs). A network function is a processing function in a network, which may be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform (e.g., on a cloud infrastructure). One type of network function is a Slice Selection Function (SSF) 202. SSF 202 handles an initial attach request and session establishment request from UE 108 by selecting an appropriate network slice for UE 108 based on subscription information, UE usage type, service type, and UE capabilities. SSF 202 connects with a subscriber repository 206 (e.g., Home Subscriber Server (HSS) and/or Subscriber Profile Repository (SPR)), which is a database or databases that stores subscriber-related information, which may be referred to as subscriber profiles. Another type of network function is a Common Control Plane Network Function (CCNF) 204.

CCNF 204 is the control plane entry function that is shared among different network slices, and includes the Mobility Management (MM) function, the authentication (AU) function, and the NAS Proxy function. Another type of network function is a Slice-Specific Control Plane Network Function (SCNF). A SCNF is allocated to a particular network slice (i.e., not shared among network slices), and has no direct interface with access network 104. The NFs that are allocated to a particular network slice are configured to support a particular set of functionalities, such as session management and QoS framework. The network in FIG. 2 is partitioned into three network slices: network slice A 210, network slice B 220, and network slice C 230. SCNFs 212 are allocated to network slice A 210 for core network 102, SCNFs 222 are allocated to network slice B 220 for core network 102, and SCNFs 232 are allocated to network slice C 230 for core network 102. Slice- Specific User Plane Network Functions (SUNF) are also allocated to each network slice, such as SUNFs 214 for network slice A 210, SUNFs 224 for network slice B 220, and SUNFs 234 for network slice C 230. Each network slice 210, 220, and 230 is associated with a network slice ID (e.g., NeS-ID or slice instance ID). The NeS-ID may be separated into two parts. One part is the type of common CP (CCNF ID). When different types of network slices share a CCNF, the CCNF needs to accommodate the requirements from the different network slices. The type of common CP reflects the requirements for the CCNF. Another part of the NeS-ID is the type of slice-specific part, which indicates the type of non-shared slice CN parts.

FIG. 3 illustrates an initial attach procedure for UE 108. When UE 108 first attaches to the network, UE 108 sends an initial attach request to access network (AN) 104 including UE capabilities and the requested service (optional). Access network 104 forwards the attach request to SSF 202. SSF 202 accesses the subscriber repository 206, and

authenticates UE 108 to determine whether it is permitted to access the network. SSF 202 selects the appropriate network slice type as well as the related NeS-ID for a network slice or Network Slice Instance (NSI) based on the information received from UE 108 in the attach request and a subscriber profile retrieved from subscriber repository 206, such as UE's subscription information, UE usage type, service type, and UE capability.

SSF 202 forwards the attach request with the NeS-ID to CCNF 204 and/or to SCNF 212 of the selected network slice. CCNF 204 performs an authentication/slice authorization procedure by checking the UE identity with subscriber repository 206. The procedure determines whether UE 108 is authorized to access this network slice. At this point, UP (user plane) connections for a default or UE-specified type network slice may be set up. CCNF 204 sends an attach response to SSF 202 that includes the NeS-ID and a UE

Temporary ID. The UE Temporary ID is assigned by CCNF 204, and may consist of the routing information to CCNF 204 and a UE-specific identity (similar to an M-TMSI). SSF 202 sends the attach response to UE 108 via access network 104 with the NeS-ID and the UE Temporary ID. When UE 108 receives the NeS-ID and the UE Temporary ID, it may use this information to assist in future network slice selection (e.g., when UE 108 detaches from the network and re-attaches again). If UE 108 re-attaches to the network after receiving the NeS-ID and the UE Temporary ID, it may send an attach request to access network 104 with the NeS-ID and the UE Temporary ID. If the UE Temporary ID is valid, then access network 104 may forward the attach request directly to CCNF 204 based on the UE Temporary ID. Otherwise, access network 104 selects CCNF 204 based on the NeS-ID.

If no UP connection is setup or if only a default UP connection is setup for UE 108 and it requests a service that is provided by another network slice, then another UP connection for UE 108 is setup during a new session establishment procedure.

FIG. 4 illustrates a new session establishment procedure for UE 108. To begin, UE

108 sends a request for establishment of a new session to access network 104. Access network 104 forwards the new session establishment request to CCNF 204 based on the UE Temporary ID, which was allocated during the attach procedure. If CCNF 204 does not know which SCNF part to handle this request, then CCNF 204 forwards the new session establishment request to SSF 202 to determine which network slice to select. SSF 202 selects the appropriate new NeS-ID. It is assumed that the new NeS-ID shared the same type of CCNF, but with a different type of SCNF part. SSF 202 sends the new session establishment request with the NeS ID to CCNF 204. If UE 108 has already been authenticated and the new network slice requires the same authentication procedure, then CCNF 204 only performs the authorization procedure. If CCNF 204 is a common function for all network slices, then the authentication procedure is only performed for the first network slice that is associated with CCNF 204. CCNF 204 forwards the new session establishment request to SCNF 212. SCNF 212 performs a session management procedure to setup the UP connection, and sends a new session establishment response to UE 108 through CCNF 204 and access network 104. The UP connection includes a bearer for transporting a data flow for the session.

As part of session management, an anchor point is selected for UE 108 in the control plane and the user plane. To further discuss anchor points for mobility, FIG. 5 shows another architecture for next generation networks. FIG. 5 illustrates a non-roaming architecture 500 in a direct point-to-point reference point representation, as is further described in 3GPP TS 23.501 (version 1.0.0), such as in FIG. 4.2.3-2, which is incorporated by reference as if fully included herein. The control plane of architecture 500 includes Authentication Server Function (AUSF) 510, a Unified Data Management (UDM) element 512, an Access and Mobility Management Function (AMF) 514, a Session Management Function (SMF) 516, a Policy Control Function (PCF) 518, and an Application Function (AF) 520. The user plane of architecture 500 includes a User Plane Function (UPF) 524 that communicates with a Data Network (DN) 526. A (Radio) Access Network ((R)AN) 530 and User Equipment (UE) 532 are able to access the control plane and the user plane.

AUSF 510 is configured to support authentication of UE 532. UDM element 512 is configured to store subscription data/information for UE 532. UDM element 512 may store three types of user data: subscription, policy, and session-related context (e.g., UE location). AMF 514 is configured to provide UE-based authentication, authorization, mobility management, etc. SMF 516 is configured to provide the following functionality: session management (SM), UE Internet Protocol (IP) address allocation and management, selection and control of UPF 524, termination of interfaces towards PCF 518, control part of policy enforcement and QoS, lawful intercept, termination of SM parts of NAS messages, Downlink Data Notification (DNN), roaming functionality, handle local enforcement to apply QoS for Service Level Agreements (SLAs), charging data collection and charging interface, etc. If UE 532 has multiple sessions, different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session. PCF 518 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 520 provides information on a packet flow to PCF 518. Based on the information, PCF 518 is configured to determine policies about mobility and session management to make AMF 514 and SMF 516 operate properly.

UPF 524 supports various user plane operations and functionalities, 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 526 is not part of the core network, and provides Internet access, operator services, 3rd party services, etc.

Architecture 500 includes the following reference points. The Nl reference point is implemented between UE 532 and AMF 514. The N2 reference point is implemented between (R)AN 530 and AMF 514. The N3 reference point is implemented between (R)AN 530 and UPF 524. The N4 reference point is implemented between the SMF 516 and UPF 524. The N5 reference point is implemented between PCF 518 and AF 520. The N6 reference point is implemented between UPF 524 and DN 526. The N7 reference point is implemented between the SMF 516 and PCF 518. The N8 reference point is implemented between UDM 512 and AMF 514. The N9 reference point is implemented between two UPFs. The N10 reference point is implemented between UDM 512 and SMF 516. The Nl 1 reference point is implemented between AMF 514 and SMF 516. The N12 reference point is implemented between AMF 514 and AUSF 510. The N13 reference point is implemented between UDM 512 and AUSF 510. The N14 reference point is implemented between two AMFs. The N15 reference point is implemented between PCF 518 and AMF 514 in the case of a non-roaming scenario.

Next generation networks, as represented by architecture 500, will support access traffic switching, which is a procedure that moves traffic of an ongoing data flow from one access network to another access network. Access traffic switching is applicable between 3GPP and non-3GPP accesses. Along with access traffic switching, next generation networks will support continuity of the data flow. Continuity is part of mobility management in a network, where even though the access network may change during a data flow, service is not interrupted. Continuity may be at the service level or session level. Service continuity refers to uninterrupted user experience of a service, including the cases where the IP address and/or anchoring point changes. Session continuity refers to continuity of a session (e.g., a Protocol Data Unit (PDU) session). For a session of IP type, "session continuity" implies that the IP address is preserved for the lifetime of the session.

Next generation networks will support multiple session and service continuity (SSC) modes. The first mode is referred to as SSC mode 1, where the same UPF is maintained regardless of the access technology (e.g., RATs and cells) used by a UE to access the network.

The second mode is referred to as SSC mode 2, where 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 serving area of the UPF. When the UE leaves the serving 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 serving 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 current UPF and then setting up a user plane path corresponding to a new UPF. During this process, the UE remains attached.

The third mode is referred to as SSC mode 3, where the network allows the establishment of UE connectivity via a new UPF to the same data network (DN) 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 serving 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 DN without a prior indication from the network that the active session needs to be redirected, then the network rejects the UE's request. Once 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.

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 - UPF1 to SMF UPF2

3 UPF2 IP1 - →IP2 SMF - UPF1 to SMF UPF2

The embodiments described below provide a charging solution for session management, and more particularly, to SSC. As an overview, when an anchor point is initially selected in the user plane for a session or changes during the session, a network function in the control plane reports an identity of the anchor point to a charging server. The charging server is then able consider the identity of the anchor point when charging for the session, such as rating the session, determining tariffs, granting quotas, etc.

FIG. 6 illustrates a non-roaming architecture 600 in a direct point-to-point reference point representation in an exemplary embodiment. Some elements of architecture 600 are similar to the elements of architecture 500 shown in FIG. 5. In this embodiment, architecture 600 is enhanced with a session management server 616 and a charging server 650. As described in more detail below, session management server 616 implements a session management function (SMF) that, among other functions, performs session management. Charging server 650 is configured to charge for sessions of UEs over a network. Session management server 616 communicates with charging server 650 over a reference point or interface 656. Interface 656 may comprise a combined or unified online/offline charging interface, an online charging interface (e.g., Ro), or an offline charging interface (e.g., Ri).

FIG. 7 is a block diagram of session management server 616 in an exemplary embodiment. Session management server 616 is an element in the control plane of architecture 600 that is configured to perform session management for sessions (e.g., PDU sessions) involving UEs. Session management server 616 includes an interface component 702 configured to communicate with charging server 650, one or more processors 704, a memory 706, and an interface component 708 configured to communicate with one or more network functions in the user plane (e.g., UPF 524) and/or one or more network functions in the control plane (e.g., AMF 514 or PCF 518). Interface component 702 may comprise a hardware component or device that exchanges charging messages with charging server 650. Interface component 702 may be configured to communicate via Rf protocol, Ro protocol, a combination of Rf/Ro, or another protocol combined for online and offline charging.

Processor 704 represents the internal circuitry, logic, hardware, etc., that provides the functions of session management server 616. Memory 706 is a computer readable storage medium (e.g., ROM or flash memory) for data, instructions, applications, etc., and is accessible by processor 704. Interface component 708 may comprise a hardware component or device that exchanges control messages with network functions. Session management server 616 may include various other components not specifically illustrated in FIG. 7.

Processor 704 implements a Session Management Function (SMF) 710 that is configured to perform session management. SMF 710 is enhanced in this embodiment to report information on an anchor point in the user plane to charging server 650 so that charging server 650 is able to charge, at least in part, based on the anchor point.

FIG. 8 is a block diagram of charging server 650 in an exemplary embodiment. Charging server 650 is an element or system that provides charging control for sessions over a network. Charging server 650 may include functionalities of an Online Charging System (OCS) and/or an Offline Charging System (OFCS). In this embodiment, charging server 650 includes an interface component 802 configured to communicate with session management server 616 (or SMF 710), and one or more processors 804. Interface component 802 may comprise a hardware component or device that exchanges charging messages with session management server 616 or other network functions. Processor 804 represents the internal circuitry, logic, hardware, etc., that provides the functions of charging server 650. Charging server 650 may include various other components not specifically illustrated in FIG. 8.

In this embodiment, processor 804 implements an online charging mechanism 810 and an offline charging mechanism 820. Online charging is a charging mechanism where charging information can affect, in real-time, the service rendered and therefore a direct interaction of the charging mechanism with session/service control is required. Online charging can be of two types: session-based or event-based. In event-based charging, a Charging Trigger Function (CTF) reports a charging event for a single operation. In session-based charging, a CTF reports multiple charging events for a session. Online charging mechanism 810 includes an Online Charging Function (OCF) 812, an account balance manager 814 (also referred to as Account Balance Management Function (ABMF)), and a rating engine 816. OCF 812 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 814 is configured to control or maintain one or more online or prepaid accounts for a UE. Account balance manager 814 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 816 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 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 CTF reports the usage or the service rendered where the service offering is rendered in a single operation. 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 interim charging requests depending on the proceeding of the session. Offline charging mechanism 820 includes a Charging Data Function (CDF) 822 and a Charging Gateway Function (CGF) 824. CDF 822 comprises an element or module that receives charging events from CTFs, formats the charging events into Charging Data Records (CDRs), and sends the CDRs to CGF 824. CGF 824 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 server 650 may implement either online charging mechanism 810 or offline charging mechanism 820 individually.

In the following embodiments, it is assumed that UE 532 performs an attach procedure and/or a session establishment procedure which causes a session to be set up over a network. An anchor point in the user plane is initially selected when the session is set up. During the session, the anchor point may be changed. SMF 710 is configured to report information regarding the anchor point to charging server 650. Further details of reporting information on the anchor point are described in FIGS. 9-11.

FIGS. 9-10 are flow charts illustrating a method 900 of reporting an anchor point in the user plane in an exemplary embodiment. The steps of method 900 will be described with reference to session management server 616 in FIG. 7, but those skilled in the art will appreciate that method 900 may be performed in other servers or functions. Also, 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.

In FIG. 9, interface component 708 (see also, FIG. 7) of session management server 616 receives a request from AMF 514 regarding a session for UE 532 (step 902). The request may comprise an attach request received from AMF 514 or another network function, upon which a default session may be established. The request may alternatively comprise a session establishment request received from AMF 514 or another network function. SMF 710 initiates establishment of the session for UE 532 (step 904). As part of establishing the session, SMF 710 selects a network function in the user plane (i.e., a UPF) as an anchor point for the session (step 906). An anchor point is the point where bearer channels are established. The anchor point may be for Intra-/Inter-RAT mobility.

In response to selecting an anchor point for the session, SMF 710 may trigger a chargeable event for the session. In one embodiment, SMF 710 may include a Charging Trigger Function (CTF), which is a function that detects chargeable events for sessions, and sends the charging events to charging server 650. SMF 710 formats an initial charging request for the session with information on the anchor point (step 908). More particularly, SMF 710 inserts information or an identifier for the UPF that is selected as the anchor point for the session, into the initial charging request. As described in more detail below, one or more new parameters may be defined in the initial charging request to transport information on the UPF. Thus, SMF 710 is programmed to insert the UPF information in the new parameter(s) of the initial charging request. SMF 710 may also insert other charging information for the session into the initial charging request. SMF 710 then sends the initial charging request to charging server 650 through interface component 702 (step 910). The type of charging request may depend on the functionality of charging server 650. For example, if charging server 650 implements online charging mechanism 810, then the charging request may comprise a Diameter Credit Control Request (CCR). If charging server 650 implements offline charging mechanism 820, then the charging request may comprise a Diameter Accounting Request (ACR). If charging server 650 implements both online charging mechanism 810 and offline charging mechanism 820, then the charging request may comprise a Diameter CCR or another type of Diameter request.

FIG. 11 is a flow chart illustrating a method 1100 of charging for a session in an exemplary embodiment. The steps of method 1100 will be described with reference to charging server 650 in FIG. 8, but those skilled in the art will appreciate that method 1100 may be performed in other servers or functions.

Interface component 802 (see also, FIG. 8) receives the charging request from SMF 710 (step 1102). OCF 812 or CDF 822 processes the charging request to identify the anchor point (e.g., UPF) in the user plane for the session (step 1104). As described in more detail below, one or more new parameters may be defined in the charging request to transport information on the UPF. Thus, OCF 812 and/or CDF 822 are programmed to process the new parameter(s) in the charging request to identify the UPF information. OCF 812 or CDF 822 then performs charging functions for the session based on the information for the UPF that acts as the anchor point in the user plane for the session (step 1106), and sends a charging response to SMF 710 through interface component 802 (step 1108). For example, OCF 812 may issue/re-issue new credit for online charging, or CDF 822 may identify a service tariff for offline charging based on the anchor point.

To perform charging operations in an online charging scenario, OCF 812 may process online charging information from the charging request as well as the UPF information to determine whether credit is authorized for the session. OCF 812 may also determine whether there is a sufficient balance in the account for the subscriber. For example, OCF 812 may identify an account balance for the subscriber in account balance manager 814, which represents the amount of money or other service units that the subscriber has purchased in advance. OCF 812 (through rating engine 816) may also identify a tariff for the session based on the UPF information and other online charging information. If the account balance is sufficient based on the tariff identified for the proximity service, then OCF 812 may determine that credit is authorized for the session, and grant a quota of service units for the session when credit is authorized. OCF 812 may therefore format a charging response that indicates the granted quota, and send the charging response to SMF 710 (step 1108). In an offline charging scenario, CDF 822 receives charging events from SMF 710 (and possibly other network functions), formats the charging events into Charging Data Records (CDRs), and sends the CDRs to CGF 824. CDF 822 inserts the UPF information into one or more parameters of the CDR(s). CDF 822 also formats a charging response, and sends the charging response to SMF 710 (step 1108). The CDR generated by CDF 822 may comprise a full CDR or a partial CDR. A full CDR is a CDR that is generated after a session ends, and a partial CDR is a CDR that is generated before a session ends. For example, CDF 822 has one or more triggers for closing a CDR, such as a timer. If CDF 822 receives a charging request indicating that the session ends before expiration of the timer, then CDF 822 closes the CDR to generate a full CDR. If the CDF does not receive a charging request indicating that the session ends before expiration of the timer, then CDF 822 closes the CDR to generate a partial CDR and opens a new CDR for the session. CDF 822 will continue to generate partial CDRs when the timer expires until it receives a charging request indicating that the session has ended. At some point, CGF 824 will correlate the CDRs (partial or full) for the session based on a charging ID into a correlated CDR, and transfer the correlated CDR to the billing domain.

In FIG. 9, interface component 702 receives the charging response from charging server 650, which is an initial charging response (step 912). At this point, SMF 710 may process the initial charging response to determine whether credit has been granted, and initiate credit control (for online charging). SMF 710 may otherwise handle the initial charging response, which is beyond the scope of this description. SMF 710 (through interface component 708) also transmits a control message to the UPF, which was selected as the anchor point for the session, to set up a user plane path corresponding to the UPF (step 914).

In FIG. 10, SMF 710 monitors conditions for redirection of the anchor point in the user plane (step 916), and determines whether to trigger a redirection based on the conditions (step 918). SMF 710 may determine that a more efficient user plane path exists for the session based on movement of UE 532, congestion in the network, etc. SMF 710 may consult with PCF 518 to obtain a policy for determining when to trigger redirection. In response to a determination to trigger a redirection, SMF 710 selects another network function in the user plane (i.e., a new or replacement UPF) as the new anchor point for the session (step 920). In response to selecting a new anchor point for the session, SMF 710 triggers a chargeable event for the session. Thus, SMF 710 formats an interim charging request for the session with information on the new anchor point (step 922). More particularly, SMF 710 inserts information or an identifier for the new or replacement UPF, into the interim charging request. SMF 710 may also insert other charging information for the session into the interim charging request. SMF 710 then sends the interim charging request to charging server 650 through interface component 702 (step 924).

Charging server 650 may operate substantially as described in FIG. 10 in response to the interim charging request, and return an interim charging response to SMF 710. Thus, SMF 710 receives the interim charging response from charging server 650 through interface component 702 (step 926). At this point, SMF 710 may process the interim charging response to determine whether credit has been granted, and initiate credit control (for online charging). SMF 710 may otherwise handle the interim charging response, which is beyond the scope of this description. SMF 710 (through interface component 708) also transmits a control message to the new or replacement UPF to set up a user plane path corresponding to the replacement UPF (step 928). SMF 710 also transmits a control message to the previous UPF to release the user plane path for the session corresponding with the previous UPF (step 928). In one embodiment, SMF 710 sends the control messages to the previous UPF and the replacement UPF to instruct the previous UPF to release its user plane path before the replacement UPF sets up its user plane path. In another embodiment, SMF 710 sends the control messages to the previous UPF and the replacement UPF to instruct the previous UPF to release its user plane path after the replacement UPF sets up its user plane path.

In another embodiment, interface 656 (see FIG. 6) is enhanced to support transfer of information regarding an anchor point. Although the definitions for interface 656 may vary as desired, one assumption is that interface 656 is based on Diameter protocol. Data delivered by Diameter protocol is in the form of Attribute Value Pairs (AVP). Some of the AVP values are used by the Diameter protocol itself, while other AVPs deliver data associated with particular applications that employ Diameter. In this embodiment, interface 656 may be extended so that a Diameter request includes one or more new AVPs. A new AVP may be defined to identify information regarding an anchor point in the user plane for a session. This new AVP may identify a UPF ID or some other value that indicates the network function in the user plane that acts as the anchor point for a session. In one embodiment, interface 656 may use a Diameter Credit Control Request

(CCR) as the charging request sent from SMF 710 to charging server 650. The following describes a Diameter CCR:

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

< Session-Id >

Origin-Host }

Origin-Realm }

Destination-Realm }

Auth-Application-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 ]

AVP ]

The "Service-Information" AVP may be extended to deliver information on anchor points. The following indicates an extension to this AVP:

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 ] +++

A "*"indicates that the AVP may occur multiple times. A "+++"indicates an AVP that is newly-defined to support the reporting of an anchor point to charging server 650. The "UPF-Information" AVP is defined to indicate, deliver, or identify information for an anchor point in the user plane for a session. The name or label of "UPF-Information" may vary as desired.

In one embodiment, the "UPF-Information" AVP may have one or more sub-AVPs defined, as provided in the following:

UPF-Information : : = < AVP Header>

[ NeS-Id ]

[ UPF-Id ]

[ DN-Id ]

[ UL-Classifier-Id ]

[ IPv6MH-Prefix ]

[ Local-Indicator ]

* [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 532. 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 involved in the session. The "DN-ID" AVP may be populated with an ID or name (e.g., Data Network Name) for the data network. 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 710. 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). In another embodiment, the "Multiple-Services-Credit-Control" AVP may be reused to indicate a charging method for the 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 ] +++

*[ AVP ]

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

Session management server 616, such as through SMF 710, is configured to format the Diameter CCR to populate these AVPs if necessary (see steps 908 and 922 of FIGS. 9- 10). For example, SMF 710 may identify a NeS-ID for a network slice that is authorized for UE 532 or previously selected for UE 532, and populate the "NeS-ID" AVP in the CCR with the NeS-ID. SMF 710 may identify the UPF ID for the UPF selected as the initial anchor point or replacement anchor point for a session, and populate the "UPF-ID" AVP with the UPF ID. SMF 710 may identify the DNN for the data network involved in the session, and populate the "DN-ID" AVP with the DNN (or another identifier). SMF 710 may identify an Uplink Classifier supporting the UPF, and populate the "UL-Classifier-ID" AVP with an identifier for the Uplink Classifier. SMF 710 may identify the IPv6 Multi- homing Prefix for the UPF, and populate the "IPv6MH-Prefix" AVP with the prefix. SMF 710 may identify an LADN-ID for a local area data network, and populate the "Local- Indicator" AVP with the LADN-ID.

The AVPs described above were in the context of a Diameter CCR, which is associated with online charging. If offline charging is used and interface 656 is defined for offline charging only, then a similar "Service-Information" AVP, along with its sub- AVPs, may be defined for a Diameter Accounting Request (ACR). The enhancements to session management server 616, charging server 650, and interface 656 as described above provide a technical benefit in that SMF 710 is able to report an identity of an anchor point for a session to charging server 650. Charger server 650 may then perform charging for the session based, at least in part, on the anchor point for the session. As network operators transition to next generation networks, it is beneficial to accurately charge for sessions that occur over the network.

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.

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.