WO2011098155A1

WO2011098155A1 - Method and apparatus for use with ip connectivity access network

Info

Publication number: WO2011098155A1
Application number: PCT/EP2010/058633
Authority: WO
Inventors: John Stenfelt; Yong Yang
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2010-02-09
Filing date: 2010-06-18
Publication date: 2011-08-18

Abstract

There is provided a method for handling a restart of a node of an I P Connectivity Access Network, I P-CAN, where policy and charging control is in use. The method comprises, at a gateway node (10): receiving (S1) a first message from an IP-CAN node cooperating with the gateway node (10) in relation to at least one I P-CAN session, the first message comprising first information enabling identification of the cooperating node and second information enabling a determination as to whether the cooperating node has undergone a restart; including (S2) the first and second information in a second message being sent to a Policy and Charging Rules Function, PCRF (20), cooperating with the gateway node (10) for policy and charging control; and sending (S3) the second message to the PCRF (20). The method comprises, at the PCRF: receiving (S7) the second message sent from the gateway node (10); using (S8) the second information in the received second message to determine that the cooperating node has undergone a restart; using (S9) the first information in the received second message to identify a set of control sessions established between the PCRF (20) and the gateway node (10) or another gateway node that correspond to or are associated with I P-CAN sessions involving the cooperating node; and locally terminating (S10) each of the identified control sessions.

Description

Method and Apparatus for use with IP Connectivity Access Network Technical field The present invention relates to a method and apparatus for use with an Internet Protocol Connectivity Access Network, or IP-CAN.

Background Figure 1 illustrates schematically a mobile network architecture including a General Packet Radio Service (GPRS) access network and an IP Multimedia Subsystem (IMS). The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP multimedia services over mobile communication networks. IP multimedia services can provide a dynamic combination of voice, video, messaging, data, etc. within the same session. The IMS makes use of the Session Initiation Protocol (SI P) to set up and control calls or sessions between user terminals. The Session Description Protocol (SDP), carried by SIP signals, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, the IMS allows operators and service providers to control user access to services and to charge users accordingly.

As shown in Figure 1 , managing of communications of user terminals (user equipment, UE; not shown in the figure) that connect to the network of Fig. 1 can be considered as held at three layers (or planes). The lowest layer (illustrated in the figure as "Connectivity Layer, 1 "), is also referred to as the bearer or user plane, and provides the connectivity means through which signals are directed to/from UEs accessing the network. The entities within the connectivity layer (1 ) that connect a UE to a further network providing application services (e.g. allowing an IMS subscriber to access from his UE to IMS services provided by -IMS- network 3b) form a network that is referred to as an IP-Connectivity Access Network, IP-CAN. A GPRS network is an example of a IP-CAN network and, apart of the radio access nodes, includes various GPRS Support Nodes (GSNs), such as Gateway GPRS Support Nodes (GGSN) and Serving GPRS Support Nodes (SGSN). A GGSN (e.g. GGSN 2a) cooperates with one or more SGSNs, and acts as an interface between the GPRS backbone network and other networks (such as an IMS network). A middle layer (illustrated in the figure as "Control Layer, 4") implements control functions relating to the signals held by the IP-CAN network. For example, in case of an IP-CAN network comprising GPRS, part of these functions can be implemented by SGSNs and GGSNs of said IP-CAN network, and relate to the processing of signals received from, or addressing to, a UE that connects through the IP-CAN network (e.g. bearer establishment, bearer termination, etc). At the top of a UE's communication there can be further servers managing high-layer aspects of said communication (illustrated in the figure by an "Application Layer, 6" comprising one or more "Application Servers, 7"). In the illustrated example, the IMS subsystem 3 includes a core network 3a and a service network 3b. The IMS core network 3a includes nodes that send/receive signals to/from nodes in the IP-CAN network (e.g. via the GGSN 2a). In particular, the IMS 3 comprises network nodes (known as "Call Session Control Functions, CSCFs, which operate as SIP proxies , and which are arranged to communicate with nodes of an IP- CAN network that perform connectivity and control functions (e.g. with a GGSN, 2a) . An example of such a kind of CSCF in a IMS is the so called Proxy-CSCF, P-CSCF.

The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (l-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. Application Servers (AS, 7) can be provided for implementing some of IMS service functionality. For example, an AS (7) can receive and process signaling related to a UE (i.e. as received from an I P-CAN network to which said UE attaches) so as to control higher layer aspects of a service (e.g. divert an incoming call to a voice mail service, or forward it to a certain terminal, etc).

The 3GPP specification TS 23.203 (V9.3.0) discloses a Policy and Charging Control architecture (PCC). Among other functional nodes, it discloses the functionality of: the Policy and Charging Rules Function (PCRF), Policy and Charging Enforcement Function (PCEF) and Bearer Binding and Event Reporting Function (BBERF), which interact among them (through the so-called "Gx" and "Gxx" interfaces) so as to apply policy and charging rules to the data bearer(s) set up for a user terminal (UE). In short, a PCRF is a PCC rules decision node, whilst a PCEF or a BBERF are functional entities implemented in gateway nodes routing media of the related bearer(s) and enforcing said PCC rules; e.g. a GGSN or a Packet Data Network Gateway (PDN-GW , also referred herein as PGW) can implement PCEF functions. Figures 2A to 2C of the accompanying drawings are taken from 3GPP specification TS 23.203, and show an overall PCC logical architecture; Figure 2A is simplified for the case of non-roaming UEs. The architecture shown in Figure 2 is envisaged for an Evolved Packet System (EPS) which is also adapted for interworking with nodes of legacy mobile packet systems. In particular, Figure 2A illustrates an overall PCC logical architecture (non-roaming), and is derived from Figure 5.1 .1 of 3GPP TS 23.203; Figure 2B illustrates an overall PCC architecture (roaming with home routed access), and is derived from Figure 5.1 .2 of 3GPP TS 23.203; and Figure 2C illustrates an overall PCC architecture for roaming with PCEF in visited network (local breakout), and is derived from Figure 5.1.3 of 3GPP TS 23.203.

In cellular telecommunication systems that employ dynamic Policy and Charging Control (PCC), such as 3GPP-based systems like the EPS and 2G/3G-GPRS or non- 3GPP based systems like HRPD and WiMax, the PCEF interacts with the Online Charing System (OCS) over an interface known as the Gy interface. The PCEF also interacts with the PCRF over an interface known as the Gx interface. The BBERF performs so-called bearer management in the Access Network, and carries out event reporting to the PCRF over an interface known as the Gxx interface. The BBERF interacts with the PCEF via an interface known as the S5/S8 interface that is based on the Proxy Mobile IP (PMIP) protocol.

In the 3GPP PCC architecture [3GPP TS 23.203] an IP-CAN session is an association between a UE represented by an IPv4 and/or an IPv6 address, and UE identity information, if available, and a Packet Data Network (PDN) represented by a PDN identifier (e.g. an Access Point Name, APN). An IP-CAN session can incorporate one or more I P-CAN bearers. Support for multiple I P-CAN bearers per I P-CAN session is IP-CAN specific. Further on an IP-CAN session exists as long as UE IP addresses are established and announced to the IP network. There are different IP-CAN access types envisaged by the current PCC standards; for example 3GPP-EPS, 3GPP-GPRS, 3GPP2, xDSL, Wimax, etc. In particular, the specification 3GPP TS 23.401 describes a particular case of the PCC network architecture of 3GPP TS 23.203 for the so-called "3GPP accesses" (GERAN / UTRAN / E-UTRAN - abbreviations for GSM EDGE Radio Access Network / Universal Terrestrial Radio Access Network / Evolved UTRAN), also referred as "3GPP-EPS"; and the specification 3GPP TS 23.402 describes a particular case of the PCC network architecture of 3GPP TS 23.203 for the so-called "non-3GPP accesses".

An "IP-CAN domain" represents a set of access network entities which names and associated functions are dependent on the particular IP-CAN access type (IP connectivity access type). For example, an IP-CAN domain can include, among other: "e Node B" (eNB, or Evolved Node B), "Mobility Management Entity" (MME), "Serving Gateway" (SGW), "PDN Gateway" (PGW) and so on. In particular, a SGW is used to implement the BBERF functionality in case PMIP based S5/S8 is used, and a PGW uses to implement the PCEF functionality.

The PCC architecture defined in 3GPP TS 23.203 [6] is intended to apply policy and charging control (PCC) in IP-CAN networks, such as Evolved Packet System (EPS) networks that includes both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non- 3GPP accesses, according to TS 23.401 and TS 23.402. PCC functionality is basically implemented by nodes of an IP-CAN network that perform connectivity and basic control functions (e.g. gateways such as SGW, PGW or GGSN implementing PCEF or BBERF functions) in cooperation with nodes implementing policy decision functions (i.e. nodes implementing PCEF functionality). Some of the PCC functionalities described by 3GPP TS 23.203 can also be achieved in cooperation with "Application Functions" AF (e.g. application servers 7 in Fig. 1 ) which communicate with a PCEF. An example of an "Application Function" AF is a P-CSCF of an IP Multimedia Subsystem IMS.

An EPS compliant architecture needs to support both PCEF and PCRF functionality to enable dynamic policy and charging control by means of installation of PCC rules on the IP-CAN session based on user (i.e. UE user) and service. For example, in case of 3GPP-EPS network, during E-UTRAN initial attach procedure of a UE, the PCEF initiates a IP-CAN control signaling session (e.g. a session according to DIAMETER protocol for the PDN connection between PCEF and PCRF. In addition in case of PMIP based S5/S8 interface, the BBERF must also setup a DIAMETER session for that PDN connection of the UE.

Figures 3 and 4 of the accompanying drawings provide a simplified view of an EPS architecture comprising PCC functional entities and their interfaces. Figure 3 considers a GPRS Tunnelling Protocol (GTP) based S5/S8 interface, and Figure 4 considers a Proxy Mobile IP (PMIP) based S5/S8 interface.

Figure 5 of the accompanying drawings depicts the particular case of a GPRS IP-CAN access, which also comprises nodes performing PCRF and PCEF functionalities. The GPRS IP-CAN incorporates GPRS access over GERAN and UTRAN. In this access scenario, the Packet Data Protocol (PDP) context is used to provide an information transmission path of defined capacity (QoS) as an IP-CAN bearer. During IP-CAN session establishment (e.g. at primary PDP Context activation procedure) the PCEF sets up a DIAMETER session for the IP-CAN session between the PCEF and the PCRF.

The present applicant has identified the following problem with the above-described approach.

According to the "restoration procedures" described in 3GPP TS 23.007 a PCEF (PDN- GW, GGSN) or/and BBERF (SGW) shall, upon detecting a restart of a cooperating node (e.g. a restart in a MME, or in a Serving GPRS Support Node (SGSN), or in any other cooperating SGW acting as a cooperating AN-GW), delete all the affected PDN Connections/PDP Contexts (AN-GW is an abbreviation for Access Node Gateway; SGW for 3GPP and AGW for non-3GPP networks). This, obviously, implies that the corresponding DIAMETER sessions which the PCEF or BBERF has already established with the PCRF for each and every of the affected UE IP-CAN sessions shall be deleted as well. Accordingly, the corresponding DIAMETER sessions established between the PCEF (which has detected a restart of a cooperating node) and the PCRF have to be terminated one by one; i.e.: for all the affected UEs . Such massive signaling for deleting all the DIAMETER sessions for those PDN connections or PDP Contexts from the restarting entity, will cause high signaling load on the Gx and/or Gxx(Gxa, Gxc) interfaces, which can be easily overloaded. In summary, a restart in a node cooperating with a PCEF, or a BBERF (e.g. a MME, SGSN or other kind of AN-GW) will cause an intensive signaling load over "Gx" and/or "Gxx" interfaces, since the corresponding "Diameter Sessions" established for all the affected UEs have to be terminated one by one with using Gx or Gxx message, i.e. Credit Control Request (CCR)/Credit Control Answer (CCA). This intensive signaling can easily overload these interfaces ("Gx" and/or "Gxx") and, in any case, tend to overload the processing resources of the receiving PCRF.

It is desirable to address the above issue as identified and formulated by the present applicant.

Summary

According to a first aspect of the present invention there is provided a method for handling a restart of a node of an IP Connectivity Access Network, IP-CAN, where policy and charging control is in use. A first message is received at a gateway node from an IP-CAN node cooperating with the gateway node in relation to at least one IP- CAN session. The first message comprises first information enabling identification of the cooperating node and second information enabling a determination as to whether the cooperating node has undergone a restart. The first and second information is included at the gateway node in a second message being sent to a Policy and Charging Rules Function, PCRF, cooperating with the gateway node for policy and charging control. The second message is sent from the gateway node to the PCRF. The second message sent from the gateway node is received at the PCRF. The second information in the received second message is used at the PCRF to determine that the cooperating node has undergone a restart. The first information in the received second message is used at the PCRF to identify a set of control sessions established between the PCRF and the or another gateway node that correspond to or are associated with IP-CAN sessions involving the cooperating node. Each of the identified control sessions is terminated locally at the PCRF.

According to a second aspect of the present invention there is provided a method for use by a gateway node in relation to the handling a restart of a node of an IP Connectivity Access Network, IP-CAN, where policy and charging control is in use. A first message is received from an IP-CAN node cooperating with the gateway node in relation to at least one IP-CAN session. The first message comprises first information enabling identification of the cooperating node and second information enabling a determination as to whether the cooperating node has undergone a restart. The first and second information is included in a second message being sent to a Policy and Charging Rules Function, PCRF, cooperating with the gateway node for policy and charging control. The second message is sent to the PCRF, thereby enabling the PCRF to determine from the second message that the cooperating node has undergone a restart, and to identify and locally terminate a set of control sessions established between the PCRF and the or another gateway node that correspond to or are associated with IP-CAN sessions involving the cooperating node.

According to a third aspect of the present invention there is provided an apparatus for use as or in a gateway node in relation to the handling a restart of a node of an IP Connectivity Access Network, IP-CAN, where policy and charging control is in use. A receiver is arranged to receive a first message from an IP-CAN node cooperating with the gateway node in relation to at least one IP-CAN session. The first message comprises first information enabling identification of the cooperating node and second information enabling a determination as to whether the cooperating node has undergone a restart. A processor is arranged to include the first and second information in a second message being sent to a Policy and Charging Rules Function, PCRF, cooperating with the gateway node for policy and charging control. A transmitter is arranged to send the second message to the PCRF, thereby enabling the PCRF to determine from the second message that the cooperating node has undergone a restart, and to identify and locally terminate a set of control sessions established between the PCRF and the or another gateway node that correspond to or are associated with IP-CAN sessions involving the cooperating node.

The method or apparatus may comprise at the gateway node the steps of or a processor arranged for: using the second information in the received first message to determine that the cooperating node has undergone a restart; using the first information in the received first message to identify a set of control sessions established between the gateway node and the PCRF that correspond to or are associated with IP-CAN sessions involving the cooperating node; and locally terminating each of the identified control sessions. According to a fourth aspect of the present invention there is provided a method for use by a Policy and Charging Rules Function, PCRF, in relation to the handling a restart of a node of an IP Connectivity Access Network, IP-CAN. A second message is received, the second message being sent from a gateway node with which the PCRF is cooperating for policy and charging control. The second message comprises first information enabling identification of an IP-CAN node cooperating with the gateway node in relation to at least one IP-CAN session, and second information enabling a determination as to whether the cooperating node has undergone a restart. The first and second information is derived from a first message previously received at the gateway node from the IP-CAN node. The second information in the received second message is used to determine that the cooperating node has undergone a restart. The first information in the received second message is used to identify a set of control sessions established between the PCRF and the or another gateway node that correspond to or are associated with IP-CAN sessions involving the cooperating node. Each of the identified control sessions is locally terminated.

According to a fifth aspect of the present invention there is provided an apparatus configured to implement a Policy and Charging Rules Function, PCRF, in relation to the handling a restart of a node of an IP Connectivity Access Network, IP-CAN. A receiver is arranged to receive a second message sent from a gateway node with which the PCRF is cooperating for policy and charging control. The second message comprises first information enabling identification of an IP-CAN node cooperating with the gateway node in relation to at least one IP-CAN session, and second information enabling a determination as to whether the cooperating node has undergone a restart. The first and second information is derived from a first message previously received at the gateway node from the IP-CAN node. A processor is arranged to use the second information in the received second message to determine that the cooperating node has undergone a restart. A processor is arranged to use the first information in the received second message to identify a set of control sessions established between the PCRF and the or another gateway node that correspond to or are associated with IP- CAN sessions involving the cooperating node. A processor is arranged to locally terminate each of the identified control sessions.

The method or apparatus may comprise the step of or a storage arranged for storing the first and second information, and wherein the step of or processor for using the received second information to determine that the cooperating node has undergone a restart comprises the steps of or a processor arranged for using the first information in the received message to identify previously-stored second information, and comparing the second information in the received message with the identified previously-stored second information.

The first and second messages may form part of an IP-CAN session related procedure that is otherwise unrelated to the restart of the cooperating node.

The IP-CAN session related procedure may be one of: IP-CAN session establishment; IP-CAN session modification; IP-CAN session termination; Gateway Control session establishment; and Gateway Control session termination.

At least one of the set of control sessions terminated at the PCRF may correspond to an IP-CAN session other than the IP-CAN session to which the first and second messages relate.

The second information may comprise a restart counter which is updated by the cooperating node at least when the cooperating node undergoes a restart.

The first information may comprise the IP address of the cooperating node.

The gateway node may be one of: a Gateway GPRS Support Node or GGSN, a Packet Data Network Gateway or PDN-GW or PGW, and a Serving Gateway or SGW; and wherein the cooperating node is one of: a Serving GPRS Support Node or SGSN, a Serving Gateway or SGW, and a Mobility Management Entity or MME.

The control sessions may be Diameter sessions.

The term "restart" is to be understood as including within its scope a reconfiguration of or problem associated with the cooperating node that is equivalent to a restart of the cooperating node, such as a problem associated with a communications link between the cooperating node and the gateway node. It could be that the plurality of control sessions identified at the PCRF comprises only those that correspond to or are associated with IP-CAN sessions involving the gateway node that sent the second message.

The first and second information may be carried in an Attribute-Value-Pair, AVP, of the second message.

The gateway node may be configured to implement a Policy and Charging Enforcement Function, PCEF.

The second message may be sent over a Gx interface between the gateway node and the PCRF. The gateway node may be configured to implement a Bearer Binding and Event Reporting Function, BBERF.

The second message may be sent over a Gxx interface between the gateway node and the PCRF.

The gateway node may be one of: a Gateway GPRS Support Node or GGSN; a Packet Data Network Gateway or PDN-GW or PGW; and a Serving Gateway or SGW.

The cooperating node may be one of: a Serving GPRS Support Node or SGSN; a Serving Gateway or SGW; and a Mobility Management Entity or MME.

It will be appreciated that the first and second information sent in the second message need not be identical to the first and second information received in the first message, but may simply be derived therefrom or convey the same underlying information, i.e. information enabling identification of the cooperating node and information enabling a determination as to whether the cooperating node has undergone a restart, respectively.

According to a sixth aspect of the present invention there is provided a program for controlling an apparatus to perform a method according to the first, second or fourth aspect of the present invention or which, when loaded into an apparatus, causes the apparatus to become an apparatus according to the third or fifth aspect of the present invention. The program may be carried on a carrier medium. The carrier medium may be a storage medium. The carrier medium may be a transmission medium.

According to a seventh aspect of the present invention there is provided an apparatus programmed by a program according to the sixth aspect of the present invention.

According to an eighth aspect of the present invention there is provided a storage medium containing a program according to the sixth aspect of the present invention. An embodiment of the present invention offers a technical advantage of addressing the issue mentioned above relating to the prior art. Technical advantages are set out in more detail below.

Brief description of the drawings

Figure 1 , discussed hereinbefore, illustrates schematically the integration of an IP Multimedia Subsystem into a 3G mobile communications system;

Figure 2A illustrates an overall PCC logical architecture (non-roaming), and is derived from Figure 5.1 .1 of 3GPP TS 23.203;

Figure 2B illustrates an overall PCC architecture (roaming with home routed access), and is derived from Figure 5.1.2 of 3GPP TS 23.203; Figure 2C illustrates an overall PCC architecture for roaming with PCEF in visited network (local breakout), and is derived from Figure 5.1 .3 of 3GPP TS 23.203;

Figure 3 illustrates a non-roaming architecture for 3GPP accesses; Figure 4 illustrates a non-roaming architecture for 3GPP accesses within EPS using PMIP-based S5;

Figure 5 illustrates the GPRS IP-CAN; Figure 6 is a schematic diagram for use in explaining an embodiment of the present invention;

Figure 7 is a message exchange diagram derived from Figure 7.2-1 of 3GPP TS 23.203, the diagram being for use in explaining the application of an embodiment of the present invention to IP CAN Session Establishment;

Figure 8 is a message exchange diagram derived from Figure 7.4 of 3GPP TS 23.203, the diagram being for use in explaining the application of an embodiment of the present invention to GW(PCEF) initiated IP-CAN Session Modification;

Figure 9 is a message exchange diagram derived from Figure 7.3.1 of 3GPP TS 23.203, the diagram being for use in explaining the application of an embodiment of the present invention to UE initiated IP CAN Session termination;

Figure 10 is a message exchange diagram derived from Figure 7.3.2 of 3GPP TS 23.203, the diagram being for use in explaining the application of an embodiment of the present invention to GW(PCEF) Initiated IP CAN Session Termination; Figure 1 1 is a message exchange diagram derived from Figure 7.7.1 .1 -1 of 3GPP TS 23.203, the diagram being for use in explaining the application of an embodiment of the present invention to Gateway Control Session Establishment during Attach;

Figure 12 is a message exchange diagram derived from Figure 7.7.1 .2-1 of 3GPP TS 23.203, the diagram being for use in explaining the application of an embodiment of the present invention to Gateway Control Session Establishment during BBERF Relocation;

Figure 13 is a message exchange diagram derived from Figure 7.7.2-1 of 3GPP TS 23.203, the diagram being for use in explaining the application of an embodiment of the present invention to BBERF-lnitiated Gateway Control Session Termination;

Figure 14 shows a table describing suggested Diameter AVPs for the Gx/Gxx interface; Figure 15 is a flowchart illustrating the steps performed in an embodiment of the present invention by a gateway node and a PCRF; and

Figure 16 is a schematic block diagram illustrating parts of a gateway node and a PCRF embodying the present invention.

Detailed description

An embodiment of the present invention provides a mechanism that allows for a node implementing a PCEF or BBERF functionality (a gateway node) to use only a single message (e.g. a DIAMETER protocol "Credit Control Request" CCR message, CCR- Final) to inform the corresponding PCRF (cooperating with the gateway node for policy and charging control) that a system element in the core network (e.g. an MME, SGSN, AN-GW(SGW)) has been restarted. The system element is an IP-CAN node cooperating with the gateway node in relation to at least one IP-CAN session.

Upon reception of this information the PCRF is able to terminate all the relevant Diameter Sessions (control sessions) correlated with that restarting entity locally; i.e. without further signaling through the corresponding Gx or Gxx interfaces, and releases the internally related data and resources. Similarly, the sending entity (i.e. PCEF or BBERF; the gateway node), is also able to release its internally data and resources related to the affected sessions.

The message referred to above, sent from the gateway node to the corresponding PCRF, comprises: first information enabling identification of the cooperating node(s), such as an identifier of the involved cooperating node (preferably the IP-address of the involved cooperating node), and second information enabling a determination as to whether the cooperating node has undergone a restart, such as a "Restart Counter" for the cooperating node. The gateway node receives information relating to the restart via a first message from the cooperating node comprising the first information (enabling identification of the cooperating node) and the second information (enabling a determination as to whether the cooperating node has undergone a restart).

Following receipt of the second message sent from the gateway node, the PCRF is able to use the received second information to determine that the cooperating node has undergone a restart, to use the received first information to identify a set of control sessions (Diameter sessions) established between the PCRF and the or another gateway node that correspond to or are associated with IP-CAN sessions involving the cooperating node, and to terminate locally each of the identified control sessions.

Referring back to Figures 3 and 4, discussed above, the nodes affected by the present invention with reference to these two figures are: PCRF, PCEF (PGW) and BBERF (SGW); the latter two can be considered to be gateway nodes. In Figure 5, also discussed above, the nodes affected by the present invention are the PCRF and PCEF (GGSN); the latter can be considered to be a gateway node.

In an embodiment of the present invention, a new information element (e.g. an Attribute-Value-Pair, AVP) is used which contains a "Restart Counter", per IP-CAN node, in the signaling through Gx and Gxx interfaces. This information element corresponds to the "second information" mentioned above. In the current GPRS core network (SGSN and GGSN) or Evolved Packet Core (EPC) network (MME, SGW and PGW), each network element (network node) which intervenes in building up an I P- CAN session mai ntains its own Restart Cou nter and com mu n icates it to the corresponding peer network element/s (nodes) through GTP messages according to e.g. 3GPP 23.007. I n case it restarts, it shall increment the Restart Counter and communicate it to the peer node once it is up-running again. The Restart Counter may be either associated with a node level identifier or more detailed level, such as IP Address. Each IP-CAN session is preferably tagged with Restart Counter(s) from all the involved network entities/nodes which intervene in the IP-CAN session.

The current "restart counter" of the nodes that cooperate with PCEFs and/or BBERFs (e.g. SGSN, AN-GW(SGW) or MME), may be communicated from PCEFs or BBERFs to the PCRF over Gx interface or Gxx interface using three different new AVPs, during the IP-CAN session related procedures (e.g. as specified in 3GPP TS 23.203, chapters 7.2, 7.3 or 7.4), or during Gateway Control Session related procedures (e.g. as specified in 3GPP TS 23.203, chapter 7.7); wherein those restart counters are also preferably updated in case the involved network entity has changed for the IP-CAN session due to UE's mobility, e.g. inter SGSN RAU/handover which means that SGSN is changed. The PCRF preferably stores and keeps track about the latest received "restart counter" in relationship with a given (cooperating) network node, and also in relationship with the IP-CAN sessions of UEs established through said nodes. Accordingly, the PCRF can determine, based on received restart counter/s, whether a cooperating node underwent a restart and, subsequently, act upon the plurality of corresponding IP-CAN sessions related to said restarting node at once.

In particular, in case of one of cooperating network entities has been restarted, the PCEF/BBERF will receive an incremented "Restart Counter" from that network entity, (e.g. : SGSN/SGW or MM E) using existing I P-CAN signaling protocol, e.g. Echo Request/Echo Response or other IP-CAN related signaling messages in GTP protocol for GPRS network and EPS. Then, the PCEF/BBERF just need send a single Gx/Gxx message (e.g. a CCR command) to PCRF for only one of affected IP-CAN sessions, including an updated (e.g. incremented) restart counter of that restarting network entity. The PCRF can, use this information, comparing with the one it stored previously, to locally terminate (or delete) all the Diameter Sessions correlated with the restarting entity without further signaling.

An embodiment of the present invention will be explained in more detail now with reference to Figures 1 5 and 1 6. Figure 1 5 is a flowchart illustrating the steps performed in an embodiment of the present invention by a gateway node 10 and a PCRF 20. Figure 16 is a schematic block diagram illustrating parts of a gateway node 10 and a PCRF 20 embodying the present invention. Also illustrated in Figure 16 is a cooperating node 1 .

The gateway node 10 comprises a receiver R1 , processor P2, transmitter T3, and processors P4 to P6; these parts are arranged to perform the steps S1 to S6 as illustrated in Figure 15. The PCRF 20 comprises a receiver R7 and processors P8 to P10; these parts are arranged to perform the steps S7 to S10 as illustrated in Figure 15. The gateway node 10 also comprises a storage or memory M4 for use in step S4 of Figure 15, while the PCRF 20 also comprises a storage or memory M8 for use in step S8 of Figure 15.

The following steps are performed at the gateway node 10. In step S1 , a first message is received at the receiver R1 from the IP-CAN node 1 cooperating with the gateway node 10 in relation to at least one IP-CAN session. The first message comprises first information enabling identification of the cooperating node 1 and second information enabling a determination as to whether the cooperating node 1 has undergone a restart.

In step S2, the processor P2 includes the first and second information in a second message being sent to the PCRF 20. The PCRF 20 cooperates with the gateway node 10 for policy and charging control. Preferably the first and second messages form part of an IP-CAN session related procedure that is anyway being performed, and which is otherwise unrelated to the restart of the cooperating node 1. For example, the IP-CAN session related procedure could be one of: IP-CAN session establishment; IP-CAN session modification; IP-CAN session termination; Gateway Control session establishment; and Gateway Control session termination.

In step S3, the transmitter T3 sends the second message to the PCRF 20.

In step S4, the processor P4 uses the second information in the received first message to determine that the cooperating node 1 has undergone a restart. In this respect, the memory M4 is arranged for at least temporarily storing the first and second information received in each step S1 performed by the gateway node 10. As part of step S4, the first information in the message received in step S1 is used (like a key) to identify second information stored previously in the memory M4, and the second information in the message received in step S1 is compared with the identified previously-stored second information. For example, where a restart counter is used for or as part of the second information, a determination that the received counter for the cooperating node 1 is higher than a previously-stored counter value, then it is determined that a restart of the cooperating node 1 has occurred. In step S5, the processor P5 uses the first information in the received first message to identify a set of control sessions (e.g. Diameter sessions) established between the gateway node 10 and the PCRF 20 that correspond to or are associated with IP-CAN sessions involving the cooperating node 1 . Information relating to the control sessions may be stored in memory M4. In step S6, the processor P6 locally terminates each of the identified control sessions.

Steps S4 to S6 above can be considered to be optional steps according to the present invention.

The following steps are performed at the PCRF 20.

In step S7, the receiver R7 receives the second message sent from the gateway node 10 in step S3.

In step S8, the processor P8 uses the second information in the received second message to determine that the cooperating node 1 has undergone a restart. In this respect, the memory M8 is arranged for at least temporarily storing the first and second information received in each step S7 performed by the PCRF 20. As part of step S8, the first information in the message received in step S7 is used (like a key) to identify second information stored previously in the memory M8, and the second information in the message received in step S7 is compared with the identified previously-stored second information. For example, where a restart counter is used for or as part of the second information, a determination that the received counter for the cooperating node 1 is higher than a previously-stored counter value, then it is determined that a restart of the cooperating node 1 has occurred.

In step S9, the processor P9 using the first information in the received second message to identify a set of control sessions (e.g. Diameter sessions) established between the PCRF 20 and the gateway node 10 or another gateway node that correspond to or are associated with IP-CAN sessions involving the cooperating node 1 . Information relating to the control sessions may be stored in memory M8.

I n step S 1 0, the processor P 1 0 locally terminates each of the identified control sessions.

The diagram of Figure 6 provides a detailed example to explain how an embodiment of the present invention works. In the Figure 6 example, the following assumptions are made: 1 ) There are eight UEs that set up IP-CAN session.

2) There are two SGSNs and three GGSNs in the GPRS core network, those three GGSNs are all connected to the same PCRF for the policy and charging control;

3) I n the example, GGSN 1 , GGSN2 and PCRF operate according to embodiments of this invention, while GGSN3 does not.

An illustrative sequence of events is as follows. a) UE 1 sets up an IP-CAN session according to UE1 -SGSN1 -GGSN1 (i.e. the terminal UE 1 sets up an IP-CAN session through SGSN1 and GGSN1 ). SGSNI 's IP address (e.g. first information) and Restart Counter (e.g. second information) are sent to the PCRF during the IP-CAN session establishment procedure since GGSN1 supports this invention. A ("Gx") DIAMETER session between the GGSN1 and the PCRF is established for this IP-CAN session with a certain session identifier, e.g. session id=1 . b) UE 2 sets up an IP-CAN session according to UE2-SGSN1 -GGSN1 . SGSNI 's IP address and Restart Counter are sent to the PCRF during the IP-CAN session establishment procedure since GGSN1 supports this invention. A DIAMETER session is established between the GGSN1 and the PCRF for this IP-CAN session, with session id=2. c) UE 3 sets up an IP-CAN session according to UE3-SGSN1 -GGSN1 . SGSNI 's I P address and Restart Counter are sent to the PCRF during the IP-CAN session establishment procedure since GGSN1 supports this invention. A DIAMETER session is established between the GGSN1 and the PCRF for this IP-CAN session, with session id=3. d) UE 4 sets up an IP-CAN session according to UE4-SGSN1 -GGSN2. SGSNI 's IP address and Restart Counter are also sent to the PCRF during the IP-CAN session establishment procedure since GGSN2 supports this invention as well. A DIAMETER session is established between the GGSN2 and the PCRF for this IP-CAN session, with session id=4. e) UE 5 sets up an IP-CAN session according to UE5-SGSN1 -GGSN2. SGSNI 's IP address and Restart Counter are sent to the PCRF during the IP-CAN session establishment procedure since GGSN2 supports this invention as well. A DIAMETER session is established between the GGSN2 and the PCRF for this IP-CAN session, with session id=5. f) UE 6 sets up an IP-CAN session according to UE6-SGSN1 -GGSN3. SGSNI 's IP address and Restart Counter are NOT sent to the PCRF during the IP-CAN session establishment procedure since, according to the example, GGSN3 does NOT support features of this invention. A DIAMETER session is established between the GGSN3 and the PCRF for this IP-CAN session, with session id=6. g) UE 7 sets up an IP-CAN session according to UE7-SGSN1 -GGSN3. SGSNI 's IP address and Restart Counter are NOT sent to the PCRF during the IP-CAN session establishment procedure since GGSN3 does NOT support features of this invention. A DIAMETER session is established between the GGSN3 and the PCRF for this IP-CAN session, with session id=7. h) UE 8 sets up an IP-CAN session according to UE8-SGSN2-GGSN1 . SGSN2's I P address and Restart Counter are sent to the PCRF during the IP-CAN session establishment procedure since GGSN1 supports features of this invention. A DIAMETER session is established between the GGSN1 and the PCRF for this IP-CAN session, with session id=8. i) Now SGSN 1 restarts. After it recovers from the restart, it will send its incremented Restart Counter through GTP message either Echo Request/Response or normal IP-CAN signaling (PDP signaling) such as Create PDP context request for new IP-CAN setup. It is to be noticed that each of UE1 , UE2, UE3, UE4, UE5, UE6 and UE7 has lost the connection to the core network since SGSN1 restarted. j) GGSN1 receives SGSNI 's new incremented Restart Counter via Echo Request/Response message, or via or normal IP-CAN signaling, as described above. From this it knows that the SGSN1 has restarted, and that as a result the three IP-CAN sessions for the UE1 , UE2 and UE3 as well as the corresponding DIAMETER sessions with session ids 1 , 2 and 3 shall be terminated (deleted). Thus GGSN1 chooses one of the DIAMETER sessions, say that with session id 1 for the UE1 , and sends a CCR final message to the PCRF to terminate this DIAMETER session, including the incremented SGSN1 restart counter in the message. When the PCRF receives the CCR command, it determines that the SGSN1 has been restarted, and it locally terminates (deletes) the DIAMETER sessions for UE1 , UE2 and UE3 which are associated with SGSN1 and GGSN1 .

The PCRF may choose terminating all sessions related to the node that has restarted (e.g. SGSN1 ), either, related or not to the gateway node that reported the restart (e.g. GGSN1 ), or just terminating a subset of them. For example, the PCRF might choose not to delete the DIAMETER sessions for UE4 and UE5, even though they are also associated with SGSN1 , because GGSN2 (i.e. assumig it implements features of the invention) may separately be notifying the PCRF of SGSNVs new incremented Restart Counter, so that the DIAMETER sessions for UE4 and UE5 can be dealt with as part of that separate notification. Also, as described below, the PCRF may opt to not terminate sessions 6 and 7. For example, if GGSN3 does not implement the features of the invention, upon detection of restart of SGSN1 , it will send DIAMETER messages CCR-final per each affected session (i.e. as related to the restarting SGSN1 ) to terminate these corresponding ("Gx") sessions with the PCRF. k) GGSN2 receives SGSN1 's new incremented Restart Counter via GTP message Create PDP Context Request for setup a new PDP context UE4x (e.g. a new PDP Context requested by UE4). From this it knows that the SGSN1 has restarted, and that as a result the two IP-CAN session for UE4 and UE5 as well as the corresponding DIAMETER sessions with session ids 4 and 5 shall be terminated (deleted). Thus GGSN2 locally deletes the PDP Context for UE4 and UE5 and continues to set up a new DIAMETER session for UE4x. GGSN2 sends a CCR Initial message to the PCRF, including the incremented SGSN1 restart counter in the message. The PCRF then sets up a DIAMETER session for UE4x and locally deletes the DIAMETER sessions for UE4 and UE5.

I) The PCRF may choose not to delete the DIAMETER sessions for UE6 and UE7, even though they are also associated with SGSN1 , because GGSN3 will also receive SGSNI 's new incremented Restart Counter. From that, GGSN3 knows that the SGSN1 has restarted, and as a result that the two IP-CAN sessions for UE6 and UE7 shall be terminated (deleted). Since GGSN3 does not support the invention, the GGSN3 sends a CCR message to the PCRF for each DIAMETER session (in the example for sessions 6 and 7), which are then terminated (deleted) one by one. If the PCRF had already terminated any of the indicated individual sessions, it can respond with a "DIAMETER_UNKNOWN_SESSION_ID" message for each indicated session that had been terminated.

In the network set up shown in Figure 6 it will therefore be appreciated that the PCRF may keep those DIAMETER sessions which are associated with the restarting entity and PCEFs/BBERFs other than the sending PCEF/BBERF. This is because those other PCEFs/BBERFs may also send a CCR message to terminate one of affected DIAMETER session including the incremented restart counter from the same network entity. Or the other PCEFs/BBERFs might not support such a feature according to an embodiment of the present invention, so that they would still expect to terminate all affected DIAMETER session one by one. In those cases where the PCRF receives CCR messages for terminating individual sessions due to restart, and if the PCRF has already terminated (deleted) all DIAMETER sessions (IP-CAN sessions) associated with that restarting network entity, it will send "DIAMETER_UNKNOWN_SESSION_ID" failure code in the CCA answer.

A particular advantage (e.g. as described above with reference to step "j" above) is that, when a gateway node (PCEF or BBERF) has to notify the PCRF about a restart event related to a cooperating node (e.g. SGSN), said gateway node can select any one of the ("Gx") sessions it has with the PCRF for notifying it about such an event, so that a single notification allows the PCRF to identify and terminate all, or a set of, the sessions involving the restarting cooperating node.

Other advantage is that not all the gateways (e.g. GGSN) with which a PCRF communicates need to implement embodiments of the invention. Therefore, at reception of a message from a certain gateway node comprising information identifying a cooperating node (e.g. a certain SGSN) that underwent a restart and information identifying said node, the PCRF may opt by: locally terminating all the ("Gx") sessions involving the cooperating (restarting) node, or by locally terminating only those which involve said cooperating node and the gateway node that identified the restart to the PCRF. Various modifications to existing procedures, in particular for communicating the first and second information (see above) in a message being sent from the gateway node 10 to the PCRF 20, are disclosed below with reference to the 3GPP procedures as defined in 3GPP TS 23.203. Original texts from said 3GPP specification, as well as from other 3GPP specifications (as identified by foregoing description) appear in "italic" style; wherein those procedures and features that are affected by embodiments of the invention are emphasized (bold underlined text). Also, numerals with reference to signaling flows in the figures, which describe procedures related to these flows, corresponds to the numerals cited in the referred 3GPP specification(s) for these flows.

A first example is described with reference to Figure 7, which relates to IP-CAN session establishment. Figure 7 and the text below are taken from 3GPP TS 23.203, chapter 7.2, which shows the IP-CAN Session Establishment procedure. The step 3 is changed and additional information, namely 3GPP-SGSN-Restart-Counter or AN-GW- Restart-Counter, which is the current restart counter of those involved IP-CAN entities and these entities are attached (adjacent) to the PCEF, shall be included in the message. This procedure can also be used when PCEF received an incremented Restart Counter from the attached IP-CAN network entity e.g. SGSN or SGW included in a GTP message, which could be a new IP-CAN session establishment related signaling message such as Create Session Request message, the PCEF then detect the attached IP-CAN network entity has restarted, it shall locally delete all the previous established IP-CAN sessions associated with that network entity and at the same time, it allocated new resource for this incoming IP-CAN establishment request and continue to initiate a new IP-CAN Session establishment procedure over Gx interface while including the incremented Restart Counter of that restart entity, with this invention, PCRF, by comparing with the one stored previously, will detect the restart of that network entity, and delete those IP-CAN sessions associated with that restarted network entity locally.

This procedure concerns both roaming and non-roaming scenarios. In the roaming case when a Gateway Control Session is used, the V-PCRF should proxy the Gateway Control Session Establishment information between the BBERF in the VPLMN and the H-PCRF over S9 based on PDN-ld and roaming agreements.

For the Local Breakout scenario (Figure 5.1.3) the V-PCRF shall proxy the Indication and Acknowledge of IP-CAN Session Establishment over S9 between the PCEF in the VPLMN and the H-PCRF

In the non-roaming case (Figure 5.1.1) the V-PCRF is not involved. 1. The BBERF initiates a Gateway Control Session Establishment procedure as defined in clause 7.7.1 (applicable for cases 2a during initial attach and 2b, as defined in clause 7.1 ).

2. The GW(PCEF) receives a request for IP-CAN Bearer establishment. The

GW(PCEF) accepts the request and assigns an IP address for the user.

3. The PCEF determines that the PCC authorization is required, requests the

authorization of allowed service(s) and PCC Rules information. The PCEF includes the following information: UE Identity (e.g. MN NAI), a PDN identifier (e.g. APN), the IP-CAN type and the IP address(es) and, if available, the default charging method and the IP-CAN bearer establishment modes supported. The PDN identifier, IP address(es) and UE identity enables identification of the IP-CAN session. The IP-CAN Type identifies the type of access from which the IP-CAN session is established. The PCEF may also send information about the IP address and the current Restart Counter of involved IP-CAN entities in the IP-CAN domain (e.g. 3GPP-SGSN-Address and 3GPP-SGSN-Restar-Counter, or AN-GW- Address and AN-GW-Restart-Counter). If the service data flow is tunnelled at the BBERF, the PCEF shall provide information about the mobility protocol tunnelling encapsulation header. The PCEF may also include the Default Bearer QoS and APN-AMBR (applicable for case 1, as defined in clause 7.1 ). In case 2a, the PCEF may also include charging ID information.

[...] A second first example is described with reference to Figure 8, which relates to IP-CAN Session Modification. Figure 8 and the text below is taken from 3GPP TS 23.203, chapter 7.4.1 , which shows PCEF initiated IP-CAN session modification procedure, the step 5 might be impacted and additional information, namely 3GPP-SGSN-Restart- Counter or AN-GW-Restart-Counter, of those involved IP-CAN entities and these entities are attached (adjacent) to the PCEF, may be included in the DIAMETER message if the corresponding network entities have been changed due to U E's mobility. This procedure concerns both roaming and non-roaming scenarios. In the roaming case when home routed access applies (figure 5.1.2) or if case 2a applies (as defined in clause 7.1) for Local Breakout (figure 5.1.3), when a Gateway Control Session is used, the H PCRF may initiate a Gateway Control and QoS Rules Provisioning procedure towards the BBERF and proxy the information through the V PCRF over S9.

For case 2b in the Local Breakout scenario (figure 5.1.3) and if the Gateway Control Session is terminated locally at the V PCRF, the V PCRF shall initiate the Gateway Control and QoS Rules Provisioning procedure locally without notifying the H PCRF. For this case the V-PCRF shall proxy the Indication and Acknowledge of IP CAN Session Modification over S9 between the PCEF in the VPLMN and the H PCRF. If the AF is located in the VPLMN for this scenario, the V PCRF shall proxy AF session signalling over S9 between the AF and the H PCRF.

NOTE 1: The case when the AF resides in the VPLMN is not shown in the figure.

In the non-roaming case (figure 5.1.1) the V PCRF is not involved at all.

1. Optionally, the AF provides/revokes service information to the PCRF due to AF session signalling. The AF may subscribe at this point to notification of bearer level events related to the service information.

NOTE 2: For the PCRF to generate the applicable events, the PCRF instructs the PCEF to report events related to the corresponding PCC rules. Such events are not shown in this sequence diagram. 2. The PCRF stores the service information and responds with the Acknowledgement to the AF.

3. The G W(PCEF) may receive IP CAN session signalling for IP CAN Session modification.

4. The GW(PCEF) makes a decision to trigger IP CAN Session modification either caused by the previous step or based on an internal decision. 5. The GW(PCEF) determines that the PCC interaction is required and sends an Indication of IP CAN Session modification (Event Report, affected PCC Rules) to the PCRF and, if changed, the new IP CAN bearer establishment modes supported. If there is a limitation or termination of the transmission resources for a PCC Rule, the GW(PCEF) reports this to the PCRF. The PCEF may also send information about the IP address and the current Restart Counter of involved IP-CAN entities in the IP-CAN domain if there is a change (e.g. 3GPP-SGSN-Address and 3GPP- SGSN-Restar-Counter, or AN-GW-Address and AN-GW-Restart-Counter).

6. The PCRF correlates the request for PCC Rules with the IP CAN session and service information available at the GW(PCEF).

[...]

A third example is described with reference to Figure 9, which relates to IP-CAN Session Termination. Figure 9 and the text below are taken from 3GPP TS 23.203, chapter 7.3.1 , which shows UE initiated IP-CAN session termination procedure, the step 3 is impacted and additional information, namely 3GPP-SGSN-Restart-Counter or AN-GW-Restart-Counter, of those involved IP-CAN entities and these entities are attached (adjacent) to the PCEF, should be included in the DIAMETER message.

This procedure concerns both roaming and non-roaming scenarios. In the roaming case when home routed access is used (figure 5.1.2) or if case 2a applies (as defined in clause 7.1) for Local Breakout (figure 5.1.3), the V PCRF should proxy the GW(BBERF) initiated Gateway Control Session Termination or the Gateway Control and QoS Rules Provision between the BBERF in the VPLMN and the H PCRF. For those cases it is also the H-PCRF that initiates the PCRF initiated Gateway Control Session Termination procedure or the Gateway Control and QoS Rules Provision procedure and proxy the information over S9 to the BBERF through the V PCRF. For the Local breakout scenario (figure 5. 1.3) the V-PCRF shall proxy Indication and Acknowledge of IP CAN Session Termination over S9 between the PCEF in the VPLMN and the H PCRF. If the AF resides in the VPLMN, the V PCRF shall proxy AF session signalling over S9 between the AF and the H PCRF. NOTE 1: The case when the AF resides in the VPLMN is not showed in the figure.

For the same scenario if either case 1 or case 2b applies (as defined in clause 7.1), the V-PCRF may respond to/initiate the Gateway Control Session procedures locally without notifying the H PCRF.

In the non-roaming case (figure 5.1.1) the V PCRF is not involved at all.

1 .If case 2b applies, the GW(BBERF) receives a request to remove the IP CAN session. In case 2a, the request goes transparently through the GW(BBERF). In all cases, the GW(PCEF) receives a request to remove the IP CAN session.

2. If case 2b applies, the GW(BBERF)-initiated GW Control Session Termination procedure as defined in clause 7.7.2.1 is initiated. 3. The GW(PCEF) indicates that the IP CAN Session is being removed and provides relevant information to the PCRF. The GW(PCEF) may also send information about the IP address and the current Restart Counter of involved IP-CAN entities in the IP-CAN domain (e.g. 3GPP-SGSN-Address and 3GPP-SGSN- Restar-Counter, or AN-GW-Address and AN-GW-Restart-Counter).

NOTE 2: The GW(PCEF) may proceed to step 9 in parallel with the indication of IP CAN Session termination.

4. The PCRF finds the PCC Rules that require an AF to be notified and removes PCC Rules for the IP CAN session. [...]

A fourth example is described with reference to Figure 10, which relates to IP-CAN Session Termination. Figure 10 and the text below are taken from 3GPP TS 23.203, chapter 7.3.2, which shows GW (PCEF) initiated IP-CAN session termination procedure, the step 5 is impacted and additional information, namely 3GPP-SGSN- Restart-Counter or AN-GW-Restart-Counter, of those involved IP-CAN entities and these entities are attached (adjacent) to the PCE F, shou ld be i ncluded in the DIAMETER message.

This procedure can also be used when PCEF received an incremented Restart Counter from the attached IP-CAN network entity e.g. SGSN or SGW included in a GTP messages, such as Echo Request/Response in the step 1, the PCEF will then initiate the IP-CAN Session termination procedure for those IP-CAN sessions associated with that restarted network entity, according to the current specification, it has to be done per IP-CAN one by one basis. With this invention, PCEF will only do ONCE by selecting one of affected IP-CAN sessions. This procedure concerns both roaming and non-roaming scenarios. In the roaming case when home routed access is used (figure 5.1.2) or if case 2a applies (as defined in clause 7.1) for Local Breakout (figure 5.1.3), the V PCRF should proxy the GW(BBERF) initiated Gateway Control Session Termination or the Gateway Control and QoS Rules Provision between the BBERF in the VPLMN and the H PCRF. For those cases it is also the H-PCRF that initiates the PCRF initiated Gateway Control Session Termination procedure or the Gateway Control and QoS Rules Provision procedure and proxy the information over S9 to the BBERF through the V PCRF.

For the Local breakout scenario (figure 5.1.3) the V-PCRF shall proxy Indication and Acknowledge of IP CAN Session Termination over S9 between the PCEF in the VPLMN and the H PCRF. If the AF relies in the VPLMN, the V PCRF shall proxy AF session signalling over S9 between the AF and the H PCRF.

NOTE 1: The case when the AF resides in the VPLMN is not showed in the figure. For the same scenario if either case 1 or case 2b applies (as defined in clause 7.1), the V PCRF may respond to/initiate the Gateway Control Session procedures locally without notifying the H PCRF. In the non-roaming case (figure 5.1.1) the V PCRF is not involved at all.

1. The GW(PCEF) detects that IP CAN Session termination is required.

2. The GW(PCEF) sends a request to remove the IP CAN session.

3. If case 2b applies, the GW(BBERF)-initiated GW Control Session Termination procedure as defined in clause 7.7.2.1 is initiated.

4. The GW(PCEF) receives the response for the IP CAN session removal.

5. The GW(PCEF) indicates the IP CAN Session termination and provides the relevant information to the PCRF. The GW(PCEF) may also send information about the IP address and the current Restart Counter of involved IP-CAN entities in the IP- CAN domain (e.g. 3GPP-SGSN-Address and 3GPP-SGSN-Restar-Counter, or AN-GW-Address and AN-GW-Restart-Counter).

6. The PCRF finds the PCC Rules that require an AF to be notified. [...]

A fifth example is described with reference to Figure 1 1 , which relates to Gateway Control Session Establishment during Attach. Figure 1 1 and the text below are taken from 3GPP TS 23.203, chapter 7.7.1 .1 , which shows Gateway Control Session Establishment during Attach procedure, the step 2 is impacted and additional information, namely 3GPP-MME-Restart-Counter, which is the current restart counter of one of those involved entities of the IP-CAN, which is adjacent (attached) to the PCEF, should be included in the DIAMETER message.

This procedure can be used also when BBERF received an incremented Restart

Counter from the attached IP-CAN network entity e.g. MME included in a GTP message, which could be a new IP-CAN session establishment related signaling message such as Create Session Reguest message, the BBERF then detect the attached IP-CAN network entity has restarted, it shall locally delete all the previous established IP-CAN sessions associated with that network entity and at the same time, it allocated new resource for this incoming IP-CAN establishment reguest and continue to initiate a new Gateway Control Session establishment procedure over Gxx interface while including the incremented Restart Counter of that restart entity, with this invention, PCRF, by comparing with the one stored previously, will detect the restart of that network entity, and delete those IP-CAN sessions associated with that restarted network entity locally.

This procedure concerns both roaming and non-roaming scenarios. In the roaming case when a Gateway Control Session is used, the V-PCRF should proxy the Gateway Control Session Establishment between the BBERF in the VPLMN and the H-PCRF over S9 based on PDN-ld and roaming agreements.

In the non-roaming case (Figure 5.1.1) the V-PCRF is not involved.

1. The GW(BBERF) receives an indication that it must establish a Gateway Control Session.

2. The GW(BBERF) sends the PCRF a Gateway Control Session Establishment. The BBERF includes the following information: IP CAN Type, UE Identity, PDN Identifier (if known), IP address(es) (if known), an indication that leg linking shall be deferred (applicable for case 2b, as defined in clause 7.1) and, if available, the IP CAN bearer establishment modes supported. The IP CAN Type identifies the type of access used by the UE. The UE's identity and PDN Identifier requested are used to identify the subscriber and in PCRF selection to locate the PCRF function with the corresponding IP CAN session established by the PDN GW. The BBERF may also include the Default Bearer QoS and APN-AMBR (applicable for case 2b, as defined in clause 7.1). The BBERF may also include the IP address and the current Restart Counter of involved IP-CAN entity which is adjacent to BBERF in the IP-CAN domain, e.g. 3GPP-MME-Restart-Counter. An indication that leg linking shall be deferred is included to inform the PCRF that linking the Gateway Control Session to a Gx session shall occur when a matching Gx message is received as described clause 6.2. 1.0. Further information is supplied on an access specific basis, as described in the IP CAN specific Annexes.

3. For GERAN/UTRAN accesses, if the PCRF is required to interact with the GW(PCEF), the PCRF waits until it gets informed about the establishment of the corresponding IP CAN session (step 7 of the IP CAN session establishment procedure) and performs a PCRF initiated IP CAN session modification procedure with the GW(PCEF). [...]

A sixth example is described with reference to Figure 12, which relates to Gateway Control Session Establishment during BBERF Relocation. Figure 12 and the text below are taken from 3GPP TS 23.203, chapter 7.7.1 .2, which shows Gateway Control Session Establishment during BBERF Relocation procedure, the step 2 is impacted and additional information, namely 3GPP-MME-Restart-Counter, which is the current restart counter of one of those involved entities of the IP-CAN, which is adjacent (attached) to the BBERF, should be included in the DIAMETER message. This procedure concerns both roaming and non-roaming scenarios. In the roaming case when a Gateway Control Session is used, the V-PCRF should proxy the Gateway Control Session Establishment between the BBERF in the VPLMN and the H-PCRF over S9 based on PDN-ld and roaming agreements. In the non-roaming case (Figure 5.1.1) the V-PCRF is not involved.

1. The target GW(BBERF) receives an indication that it must establish a Gateway Control Session. 2. The target G W(BBERF) sends the PCRF a Gate way Con trol Session Establishment. The BBERF includes the following information: IP CAN Type, UE Identity, PDN Identifier (if known), IP address(es) (if known) and, if available, the IP CAN bearer establishment modes supported. The IP CAN Type identifies the type of access used by the UE. The UE's identity and PDN Identifier requested are used to identify the subscriber and in PCRF selection to locate the PCRF function with the corresponding IP CAN session established by the PDN GW. The BBERF may also include the Default Bearer QoS and APN-AMBR (applicable for case 2b, as defined in clause 7.1). The BBERF may also include the IP address and the current Restart Counter of involved IP-CAN entity which is adjacent to BBERF in the IP-CAN domain, e.g. 3GPP-MME-Restart-Counter. If the handover state is unknown to the GW(BBERF), as described in TS 23.402 [18], the GW(BBERF) includes an indication to inform the PCRF that linking the Gateway Control Session to a Gx session shall be deferred as described clause 6.2.1.0 (applicable to case 2b, as defined in clause 7.1). Further information is supplied on an access specific basis, as described in the IP CAN specific Annexes.

If case 2b of clause 7.1 applies and the PCRF correlates the Gateway Control Session with an existing IP CAN session, it sends an Acknowledge Gateway Control Session Establishment to the target GW(BBERF). The PCRF may include the following information: QoS Rules and Event Triggers. The QoS policy rules are employed by the GW(BBERF) to perform Bearer Binding. The Event Triggers indicate events that require the GW(BBERF) to report to the PCRF. If the BBERF supports NW/UE bearer establishment mode, the PCRF provides to the new BBERF QoS rules corresponding to existing SDFs. For a change of IP CAN type, the QoS parameters of some of the QoS rules may be changed or some QoS rules may not be provided to the new BBERF, e.g. depending of the capability of the target RAT.

If case 2a of clause 7.1 applies, the PCRF sends an Acknowledge Gateway Control Session Establishment to the target GW(BBERF). The PCRF includes packet filters and QoS information for the CoA in order to establish the initial bearer, e.g. for the DSMIPv6 signalling. The PCRF may also include Event Triggers.

NOTE: The packet filters and QoS information provided at this step conceptually are not QoS rules as they are not associated with any IP-CAN session. However, it is a stage 3 issue if the packet filters and QoS information are communicated to the BBERF with the same information elements by which QoS rules are communicated. A seventh example is described with reference to Figure 13, which relates to Gateway Control Session Termination. Figure 13 and the text below are taken from 3GPP TS 23.203, chapter 7.7.2.1 , which shows BBERF-lnitiated Gateway Control Session Termination procedure, the step 2 is impacted and additional information, namely 3GPP-MME-Restart-Counter, which is one the current restart counter of one of the involved entities of the IP-CAN, which are adjacent(attached) to the BBERF, should be included in the DIAMETER message.

This procedure can also be used when BBERF received an incremented Restart Counter from the attached IP-CAN network entity e.g. MME included in a GTP messages, such as Echo Request/Response, the BBERF will then initiate the Gateway Control Session termination procedure for those IP-CAN sessions associated with that restarted network entity, according to the current specification, it has to be done per IP-CAN one by one basis. With this invention, PCEF will only do ONCE by selecting one of affected IP-CAN sessions.

1. The GW(BBERF) is requested to terminate its Gateway Control Session.

2. The GW(BBERF) initiates a Gateway Control Session Termination towards the H- PCRF. If the GW(BBERF) is deployed in a visited network, this procedure is initiated by the GW(BBERF) to the V-PCRF. The V-PCRF forwards the information to the H- PCRF. The BBERF may also include the IP address and the current Restart Counter of involved IP-CAN entity which is adjacent to BBERF in the IP-CAN domain, e.g. 3GPP-MME-Restart-Counter.

Editor's Note: As a result of step 2, in the case where relocation is not being performed, there will be an IP CAN session termination procedure at this point.

3. The H-PCRF replies to the GW(BBERF) with an Ack Gateway Control Session Termination. If the GW(BBERF) is deployed in a visited network, this information is sent by the H-PCRF to the V-PCRF. The V-PCRF forwards the information to the GW(BBERF).

4. The GW(BBERF) removes the QoS rules and Event triggers associated with the Gateway Control Session. This means the GW(BBERF) ceases its bearer binding and other Gateway Control functions associated with the QoS rules and Event Triggers.

5. The GW(BBERF) has completed terminating the session and can continue with the activity that prompted this procedure.

[...]

The table of Figure 14 describes new suggested Diameter AVPs defined for the Gx/Gxx interface.

The 'V bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. The 'Ρ' bit indicates the need for encryption for end-to-end security.

The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. Since this invention is assumed to be optional feature, so the newly suggested AVPs are not mandatory to support.

The AVP code values shown in the table are merely illustrating exemplary values.

For the Gx message, the text below is taken from 3GPP TS 29.212, chapter 5.6.2, which specify shows CC-Request (CCR) Command. The 3GPP-SGSN-Restart- Counter and AN-GW-Restart-Counter AVP should be included in the DIAMETER message. The suggested changes are emphasized (bold underlined text).

The CCR command, indicated by the Command-Code field set to 272 and the 'R' bit set in the Command Flags field, is sent by the PCEF to the PCRF in order to request PCC rules for a bearer. The CCR command is also sent by the PCEF to the PCRF in order to indicate bearer or PCC rule related events or the termination of the IP CAN bearer and/or session.

Message Format:

<CC-Request> ::= < Diameter Header: 272, REQ, PXY >

< Session-Id >

{ Auth-Application-ld }

{ Origin-Host } { Origin-Realm }

{ Destination-Realm }

{ CC-Request-Type }

{ CC-Request-Number }

[ Destination-Host ]

[ Origin-State-Id ]

*[ Subscription-Id ]

[ Supported-Features ]

[ Network-Request-Support ]

*[ Packet-Filter-ln formation ]

[ Packet-Filter-Operation ]

[ Bearer-Identifier ]

[ Bearer-Operation ]

[ Framed-IP-Address ]

[ Framed-IPv6-Prefix ]

[ IP-CAN-Type ]

[ RAT-Type ]

[ Termination-Cause ]

[ User-Equipment-Info ]

[ QoS-ln formation ]

[ QoS-Negotiation ]

[ QoS-Upgrade ]

[ Default-EPS-Bearer-QoS ]

0^*2[ AN-GW-Address ]

fAN-GW-Restart-Counterl

[ 3GPP-SGSN-MCC-MNC ]

[ 3GPP-SGSN-Address ]

RGPP-SGSN-Restart-Counterl

[ 3GPP-SGSN-IPv6-Address ]

[ RAI]

[ 3GPP-User-Location-lnfo]

[ 3GPP-MS-TimeZone ]

[ Called-Station-ID ]

[ Bearer-Usage ]

[ Online ]

[ Offline ]

*[ TFT -Packet-Filter-Information ]

[ Charging-Rule-Report]

*[ Event-Trigger]

[ Event-Report-Indication]

[ Access-Network-Charging-Address ]

*[ Access-Network-Charging-ldentifier-Gx ] [ CoA-ln formation ]

*[ Proxy-Info ]

*[ Route-Record ]

^*[AVP ]

For the Gxx message, The text below is taken from 3GPP TS 29.212, chapter 5a.6.2, which specify shows CC-Request (CCR) Command. The 3GPP-MME-Restart-Counter should be included in the D IAM ETE R message. The suggested changes are emphasized (bold underlined text).

The CCR command, indicated by the Command-Code field set to 272 and the 'R' bit set in the Command Flags field, is sent by the BBERF to the PCRF in order to request QoS rules. The CCR command is also sent by the BBERF to the PCRF in order to indicate QoS rule related events or the termination of the Gateway Control session.

Message Format:

<CC-Request> ::= < Diameter Header: 272, REQ, PXY >

< Session-Id >

{ Auth-Application-ld }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ CC-Request-Type }

{ CC-Request-Number }

[ Destination-Host ]

[ Origin-State-Id ]

^*[ Supported-Features ]

^*[ Subscription-Id ]

[ Network-Request-Support ]

*[ Packet-Filter-ln formation ]

Packet-Filter-Operation ]

[ Framed-IP-Address ]

[ Framed-IPv6-Prefix ]

[ IP-CAN-Type ]

[ RAT-Type ]

[ Termination-Cause ]

[ User-Equipment-Info ]

[ QoS-lnformation ]

[ Default-EPS-Bearer-QoS ]

0^*2[ AN-GW-Address ]

[ 3GPP-SGSN-Address ]

i3GPP-MME-Restart-Counterl

[ 3GPP-SGSN-IPv6-Address ]

[ RAI]

[ 3GPP-User-Location-lnfo]

[ 3GPP-MS-TimeZone ]

[ 3GPP2-BSID ]

[ Called-Station-ID ]

*[ TFT-Packet-Filter-ln formation ]

*[ QoS-Rule-Report]

*[ Event-Trigger]

[ Session-Linking-lndicator ]

[ Trace-Data ]

[ Trace-Reference ]

^*[ Proxy-Info ]

*[ Route-Record ]

^*[AVP] An embodiment of the present invention has one or more of the following advantages:

(a) It saves a lot of signaling for termination of DIAMETER session in case one of IP-CAN session entity restarted and avoids the potential overload situation in the Gx and Gxx interfaces.

(b) It allows PCEF/BBERF and PCRF to free up the allocated node resource quickly.

(c) It can be used also in case of other failure cases, such as Path (link) break between SGSN/SGW and PCEF or between MME and BBERF. Such link break is with regard to the PCEF, or BBERF, and other node with which it maintain a communication for certain UEs (e.g. MME, SGSN, AN-GW, etc).

It will be appreciated that operation of one or more of the above-described components can be provided in the form of one or more processors or processing units, which processing unit or units could be controlled or provided at least in part by a program operating on the device or apparatus. The function of several depicted components may in fact be performed by a single component. A single processor or processing unit may be arranged to perform the function of multiple components (e.g. as illustrated by the dotted outlines in Figure 16). Such an operating program can be stored on a computer-readable medium, or could, for example, be embodied in a signal such as a downloadable data signal provided from an Internet website. The appended claims are to be interpreted as covering an operating program by itself, or as a record on a carrier, or as a signal, or in any other form.

It will also be appreciated by the person of skill in the art that various modifications may be made to the above-described embodiments without departing from the scope of the present invention as defined by the appended claims.

It will be appreciated that although the second information is described above as being a "restart counter", which is compared against a previous value for the restart counter to determine whether a restart has occurred in the cooperating node, the second information could include an explicit restart flag of some sort, which would indicate directly that a restart has occurred in the cooperating node.

The following references may assist the skilled person in implementing an embodiment of the present invention: 3GPP TS 23.203 v9.3.0 Policy and Charging Control Architecture (Release 8); 3GPP TS 29.212 v 9.1.0 Policy and Charging Control over Gx interface; 3GPP TS 23.401 v9.3.0 General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access; 3GPP TS 23.007 v8.5.0 Restoration procedures; 3GPP TS 23.402 v9.3.0 Architecture enhancements for non-3GPP accesses; 3GPP TS 29.274 V9.1 .0 Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2- C).

Claims

1 . A method for handling a restart of a node of an IP Connectivity Access

Network, IP-CAN, where policy and charging control is in use, the method comprising: at a gateway node:

receiving a first message from an IP-CAN node cooperating with the gateway node in relation to at least one IP-CAN session, the first message comprising first information enabling identification of the cooperating node and second information enabling a determination as to whether the cooperating node has undergone a restart;

including the first and second information in a second message being sent to a Policy and Charging Rules Function, PCRF, cooperating with the gateway node for policy and charging control; and

sending the second message to the PCRF;

and at the PCRF:

receiving the second message sent from the gateway node; using the second information in the received second message to determine that the cooperating node has undergone a restart;

using the first information in the received second message to identify a set of control sessions established between the PCRF and the or another gateway node that correspond to or are associated with IP-CAN sessions involving the cooperating node; and

locally terminating each of the identified control sessions.

2. A method for use by a gateway node in relation to the handling a restart of a node of an IP Connectivity Access Network, IP-CAN, where policy and charging control is in use, the method comprising:

receiving a first message from an IP-CAN node cooperating with the gateway node in relation to at least one IP-CAN session, the first message comprising first information enabling identification of the cooperating node and second information enabling a determination as to whether the cooperating node has undergone a restart; including the first and second information in a second message being sent to a

Policy and Charging Rules Function, PCRF, cooperating with the gateway node for policy and charging control; and

sending the second message to the PCRF, thereby enabling the PCRF to determine from the second message that the cooperating node has undergone a restart, and to identify and locally terminate a set of control sessions established between the PCRF and the or another gateway node that correspond to or are associated with IP-CAN sessions involving the cooperating node.

3. An apparatus for use as or in a gateway node in relation to the handling a restart of a node of an IP Connectivity Access Network, IP-CAN, where policy and charging control is in use, the apparatus comprising:

a receiver arranged to receive a first message from an IP-CAN node cooperating with the gateway node in relation to at least one IP-CAN session, the first message comprising first information enabling identification of the cooperating node and second information enabling a determination as to whether the cooperating node has undergone a restart;

a processor arranged to include the first and second information in a second message being sent to a Policy and Charging Rules Function, PCRF, cooperating with the gateway node for policy and charging control; and

a transmitter arranged to send the second message to the PCRF, thereby enabling the PCRF to determine from the second message that the cooperating node has undergone a restart, and to identify and locally terminate a set of control sessions established between the PCRF and the or another gateway node that correspond to or are associated with IP-CAN sessions involving the cooperating node.

4. A method or apparatus as claimed in any preceding claim, comprising at the gateway node the steps of or a processor arranged for:

using the second information in the received first message to determine that the cooperating node has undergone a restart;

using the first information in the received first message to identify a set of control sessions established between the gateway node and the PCRF that correspond to or are associated with IP-CAN sessions involving the cooperating node; and

locally terminating each of the identified control sessions.

5. A method for use by a Policy and Charging Rules Function, PCRF, in relation to the handling a restart of a node of an IP Connectivity Access Network, IP-CAN, the method comprising:

receiving a second message sent from a gateway node with which the PCRF is cooperating for policy and charging control, the second message comprising first information enabling identification of an IP-CAN node cooperating with the gateway node in relation to at least one IP-CAN session, and second information enabling a determination as to whether the cooperating node has undergone a restart, with the first and second information being derived from a first message previously received at the gateway node from the IP-CAN node;

using the second information in the received second message to determine that the cooperating node has undergone a restart;

locally terminating each of the identified control sessions.

6. An apparatus configured to implement a Policy and Charging Rules Function, PCRF, in relation to the handling a restart of a node of an IP Connectivity Access Network, IP-CAN, the apparatus comprising:

a receiver arranged to receive a second message sent from a gateway node with which the PCRF is cooperating for policy and charging control, the second message comprising first information enabling identification of an IP-CAN node cooperating with the gateway node in relation to at least one IP-CAN session, and second information enabling a determination as to whether the cooperating node has undergone a restart, with the first and second information being derived from a first message previously received at the gateway node from the IP-CAN node;

a processor arranged to use the second information in the received second message to determine that the cooperating node has undergone a restart;

a processor arranged to use the first information in the received second message to identify a set of control sessions established between the PCRF and the or another gateway node that correspond to or are associated with IP-CAN sessions involving the cooperating node; and

a processor arranged to locally terminate each of the identified control sessions.

7. A method or apparatus as claimed in claim 1 , 4, 5 or 6, comprising the step of or a storage arranged for storing the first and second information, and wherein the step of or processor for using the received second information to determine that the cooperating node has undergone a restart comprises the steps of or a processor arranged for using the first information in the received message to identify previously- stored second information, and comparing the second information in the received message with the identified previously-stored second information.

8. A method or apparatus as claimed in any preceding claim, wherein the first and second messages form part of an IP-CAN session related procedure that is otherwise unrelated to the restart of the cooperating node.

9. A method or apparatus as claimed in claim 8, wherein the IP-CAN session related procedure is one of: IP-CAN session establishment; IP-CAN session modification; IP-CAN session termination; Gateway Control session establishment; and Gateway Control session termination.

10. A method or apparatus as claimed in claim 8 or 9, wherein at least one of the set of control sessions terminated at the PCRF corresponds to an IP-CAN session other than the IP-CAN session to which the first and second messages relate.

1 1 . A method or apparatus as claimed in any preceding claim, wherein the second information comprises a restart counter which is updated by the cooperating node at least when the cooperating node undergoes a restart.

12. A method or apparatus as claimed in any preceding claim, wherein the first information comprises the IP address of the cooperating node.

13. A method or apparatus as claimed in any preceding claim, wherein the gateway node is configured to implement a Policy and Charging Enforcement Function, PCEF, or a Bearer Binding and Event Reporting Function, BBERF, and wherein the second message is sent over a Gx or Gxx interface between the gateway node and the PCRF.

14. A method or apparatus as claimed on claim 13, wherein the message signaling through the Gx or Gxx interfaces is according to the Diameter protocol.

15. A method or apparatus as claimed in any preceding claim, wherein the gateway node is one of: a Gateway GPRS Support Node or GGSN, a Packet Data Network Gateway or PDN-GW or PGW, and a Serving Gateway or SGW; and wherein the cooperating node is one of: a Serving GPRS Support Node or SGSN, a Serving Gateway or SGW, and a Mobility Management Entity or MME.

16. A program for controlling an apparatus to perform a method as claimed in any one of claims 1 , 2, 4, 5 and 7 to 15, optionally being carried on a carrier medium such as a storage medium or a transmission medium.

17. A storage medium containing a program as claimed in claim 16.