WO2005081491A1

WO2005081491A1 - Interworked network sensitive policy control

Info

Publication number: WO2005081491A1
Application number: PCT/IB2005/000323
Authority: WO
Inventors: Juha A. RÄSÄNEN; Miikka POIKSELKÄ
Original assignee: Nokia Corporation
Priority date: 2004-02-16
Filing date: 2005-02-09
Publication date: 2005-09-01

Abstract

A policy decision entity and method of a communication network system are disclosed. According to a policy decision media flows are controlled. A message from a session control entity performing session/connection control is received, and an indication indicating interworking with a specific network is detected in the received message

Description

TITLE OF THE INVENTION

Interworked Network Sensitive Policy Control

FIELD OF THE INVENTION

The present invention relates to policy control in a communication network system.

BACKGROUND OF THE INVENTION

In a communication network system offering multimedia services to users a service-based local policy control provides a way to manage an access network through dynamic policies. Policy control may be used for IMS (IP (Internet Protocol) Multimedia Subsystem) and interact with appropriate IMS and non-IMS applications. For this purpose, a general policy control over IP bearer resources and SIP (Session Initiation Protocol) services should be enabled to evolve separately. Furthermore, there should be more flexibility in engineering and policy control of IP bearer resources, policy functions should be decoupled from IMS entities, and application functions should be decoupled from IP-Connectivity Networks.

The IM Subsystem comprises a PDF (Policy Decision Function) and a P-CSCF (Proxy Call/Connection state control function) for performing policy control. Although the PDF and P-CSCF are two separate logical entities, the PDF may also be presented as being an integral part of the P-CSCF.

Opening the interface between the PDF and the P-CSCF may greatly simplify introduction of new services and enable operators to leverage their ownership of access networks by introducing opportunities for service-based control of the access for a whole range of services (potentially including third party services) in an operator controlled manner. Decoupling of the PDF from the P-CSCF enables policy control to be applied for other services than SIP IMS services.

The Policy Decision Function (PDF) acts as a Policy Decision Point for service based local policy control. The PDF makes decisions about resources allocation requests.

An Application Function (AF) is an element controlling applications that require the use of IP bearer resources. One example of an application function is the P-CSCF. The AF requests the PDF to apply restrictions on usage of the IP bearer resources. The Application Function represents the application level intelligence for any service running over the IP bearer which needs service based policy control.

For service based policy control, the AF does not interact with a gateway directly; instead, it interacts with the PDF and the PDF acts on certain events as instructed by the AF. For certain events related to SBLP (service based local policy) , the AF shall be able to give instructions to the PDF to act on its own, i.e. based on the service information currently available.

There may be links between the AF and PDF policies to authorise the use of QoS resources. The PDF uses policy rules defined by the operator who owns the PDF to authorise the use of the IP bearer resources within the limits of what has been requested by the AF.

The AF provides the service determined decision information. The PDF provides the final policy decision controlling the allocated QoS (Quality of Service) resources for the authorized session to the gateway. The final policy decision is done according to operator policy rules defined in the PDF. The Authorise QoS resources function can be invoked between PDF and AF at session establishment and/or at bearer establishment. The PDF provides a successful result to the authorization request from the AF only if the session characteristics are consistent with the policy rules defined in the PDF.

The AF may provide an application identifier when describing the session to indicate the application being used by the AF/P-CSCF. The application identifier identifies the particular service that the session belongs to. This information may be used by the PDF to differentiate QoS for different application services. For example, the application identifier may be used as additional information together with the indication of the type of service information when QoS class for the bearer authorisation in Go interface is decided. The application identifier may be used also to complete the QoS authorisation with application specific default settings in the PDF if the AF does not provide all or any of the required information.

The PDF may include a gate enabling command as part of the authorisation decision, for instance to enable early media. Alternatively, the PDF may provide a separate decision for opening the gate for the media flow(s) in the GGSN (Gateway GPRS (General Packet Radio Service) Support Node) . The gate represents a user plane function enabling or disabling the forwarding of IP packets. A gate is described by a set of packet classifiers that identify IP flows associated to the gate. The packet classifier includes the standard 5-tuple (source IP address, destination IP address, source port, destination port, protocol) explicitly describing a unidirectional IP flow. The gate is controlled by commands to open or close the gate leading to the enabling or disabling of the passage for IP packets. If the gate is closed all packets of the related IP flows are dropped. If the gate is opened the packets of the related IP flows are allowed to be forwarded.

The opening of the gate may be part of the authorisation decision event. The closing of the gate may be part of the revoke authorisation decision event.

When a session is set up from/to an IMS terminal and the IMS network uses service based local policy (SBLP) , the PDF may in general decide to open the gates for the media flows in the GGSN (Gateway GPRS (General Packet Radio Service) Support Node) only after the final answer message from the called party, in order to avoid charging fraud (i.e. a fraud of not answering the session invitation but still sending a media stream through the early opened gates) .

When a session is set up from an IMS terminal to a CS (Circuit Switched) terminal and the IMS network uses service based local policy (SBLP) , the policy decision function (PDF) is not aware of the destination being in a CS network. Opening the gates only after the answer message means that possible tones and announcements from the CS network (early media in general) will not pass through to the calling IMS terminal.

In general the problem can be described as a missing indication of the interworked network and/or the properties of the interworked network, i.e. the PDF is not aware of the interworked network and/or its properties and consequently cannot apply proper policy control measures in all interworking cases.

Currently it is left up to the PDF to decide whether to open the gates for a possible early media already at the authorization of the QoS resources or only after the answer message has been received from the called party. In documents N3-020962 and N3-020969, 3GPP TSG-CN WG3 Meeting #26 in Bangkok, Thailand, 11^th - 15^th November 2002, problems related to policy control for early media are discussed and it is proposed that in case of a mobile originating call, a Policy Control Function should include the gate enabling command for the downlink gate for audio media ("m=audio" in Session Description Protocol) as part of the authorisation decision to enable early media.

SUMMARY OF THE INVENTION

It is an object of the invention to improve policy control in a communication network system.

According to an aspect of the invention, this object is achieved by a policy decision entity according to claim 1 and a method according to claim 18.

According to another aspect of the invention, the object is achieved by a first session control entity according to claim 5 and a method according to claim 19.

According to a further aspect of the invention, the object is achieved by a second session control entity according to claim 9.

Moreover, the object is achieved by a second session control entity according to claim 10 and a method according to claim 22.

According to a still further aspect of the invention, the object is achieved by a message according to claim 14 or a message according to claim 15. According to a still further aspect of the invention, the object is achieved by a network system according to claim 17.

According to a still further aspect of the invention, the object is achieved by a computer program product according to' claim 23.

Further features of the invention are defined in the dependent claims .

According to the invention, the PDF is enabled to identify different interworking cases. CS interworking can be supported in an IMS network with service based local policy (SBLP) without losing tones and announcements from the CS network and without risking the integrity and reliability of charging in other cases (e.g. by not opening the gates before the answer message when not necessary) .

A disadvantage of sending the interworking indication/information in an SDP parameter or in a new SIP header is that anybody can insert the parameter (s) in the SIP message. This means that fraudulent behaviour is possible for example in the following way: • The called entity inserts the required interworking parameter (s) in the SIP response message; • The network (P-CSCF and PDF) deduces from the parameter (s) that this is an interworking case, e.g. PSTN interworking, and takes related measures, e.g. opens the gates; • The called entity does not send a final response, which .means that charging is not activated. • With gates open, data transmission is now possible without charging, although from the network's point of view the session has not yet been established. When the SIP contact header, and possible additional parameters appended to it, is used, the relevant information is hidden from external parties. The addresses of network elements (in this case MGCFs) is network internal information configured and agreed by operators. Fraudulent mimicking of the interworking indication/information by users is not possible.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 shows a schematic diagram illustrating network elements of a communication network system according to the invention.

Fig. 2 shows an architecture of a network system illustrating interfaces between network elements of a core network, a multimedia subsystem and a CS network.

Fig. 3 shows a schematic diagram illustrating signaling between the network elements of the network system according to an embodiment of the invention.

DESCRIPTION OF THE INVENTION

According to the invention, when a policy controlled IMS (IP Multimedia Subsystem) network interworks with a circuit switched (CS) network, a policy decision entity such as a PDF controlling the session for a related IMS terminal is made aware of the interworking with the CS network. The PDF may use the information for making a decision to open gates at least for the downlink, i.e. towards the IMS terminal already at an authorization of QoS resources in order to enable the passing through of possible tones and announcements, i.e. early media in general, from the CS network to the IMS terminal. In Fig. 1 a session control entity (first session control entity) 10, a call control entity (second session control entity) 20 and a policy decision entity 30 of a communication network system are shown. The call control entity performs call/session control e.g. between an IMS network and a specific network such as a CS network and comprises a detecting block 21 for detecting interworking with a specific network, an including block 22 for including an indication of the interworking with the specific network in a message to be sent towards the session control entity 10, and a sending block for sending the message towards the policy control entity 10. The message sent towards the session control entity 10 may be a backward message in case the session control entity 10 resides in an originating network, i.e. a network originating a session.

The including block 22 may include a parameter indicating the interworking with the specific network in the message to be sent towards the session control entity 10.

The session control entity 10 performs session/connection control and comprises a receiving block 11 for receiving a message from the call control entity 20, a detecting block 12 for detecting the indication of interworking with the specific network from the received message, an including block 13 for including in a message to be sent to the policy decision entity 30 an indication associated with controlling gates for media flows, and a sending block 14 for sending the message to the policy decision entity 30.

The session control entity 10 may further comprise a converting block (not shown) for converting the indication of interworking with the specific network into an instruction to control the gates, wherein the including block 13 includes the instruction in the message to be sent to the policy decision entity 30.

Alternatively, the including block 13 may include a parameter indicating interworking with the specific network in the message to be sent to the policy decision entity 30.

The policy decision entity 30 controls media flows and comprises a receiving block 31 for receiving a message from the session control entity 10, and a detecting block 32 for detecting an indication associated with controlling gates for media flows in the received message.

In case the indication comprises an instruction to control the gates from the session control entity 10, a controlling block 33 of the policy decision entity 30 may control the gates in accordance with the instruction from the session control entity 10.

In case the indication indicates interworking with a specific network, the controlling block 33 may control the gates in accordance with this parameter, e.g. allow early media to at least one direction in the media flow. Media flows controlled by the policy decision entity 30 may be present in a further network entity in a core network, e.g. in a gateway node (such as a GGSN) which has a policy enforcement functionality that implements the decisions made by the policy decision entity 30. Furthermore, the gateway node may also make policy decisions without the help of the policy decision entity 30, if the decisions can be made within the limits of the valid/previous authorization decision made by the policy decision entity 30. The session control entity 10 and the policy decision entity 30 may be provided either separately or as one network element.

According to an embodiment of the invention to be described in the following, a call or gateway control entity such as an MGCF, BGCF and/or S/I-CSCF puts an indication (a parameter or set of parameters) in the signalling towards the IMS, a session control entity such as a P-CSCF forwards the information to the PDF, and the PDF takes relevant measures, e.g. opens the downlink gates already at the authorization of the QoS resources.

Fig. 2 shows an architecture of a communication network system illustrating interworking between IMS and a circuit switched (CS) network, i.e. an ISUP (ISDN User Part) and BICC (Bearer Independent Call Control) based ISDN (Integrated Services Digital Network) .

As shown in Fig. 2, a user equipment UE connects to a CS network via a core network such as a 3G core network comprising a gateway such as a GGSN. The UE is an IMS capable terminal and the IMS uses service based local policy (SBLP) handled by a policy decision entity such as a PDF and a call control entity such as a P-CSCF or application function AF. A call setup is carried out from the UE via the P-CSCF, a serving control entity such as an S-CSCF and a media gateway control entity such as an MGCF to the CS network (e.g. PSTN) .

The path from the MGCF to the PDF can be seen to consist of two separate legs:

1. The leg from the MGCF to the P-CSCF which is based on SIP/SDP (Session Initiation Protocol/Session Description Protocol) signalling. Especially in an IMS to CS network session supporting tones and announcements, a SIP response

"183 Session progress" may be used for transporting interworking information from the MGCF to the P-CSCF. The SIP response "183 Session progress " is described in 3GPP TS

24.228 version 5.4.0, subclause 7.3.6.1 "PSTN Termination performed by home network of originator", communication 8 in figure 7.3.6.1-1. Furthermore, SIP response "182 queued" or any other "lxx" response message can be used for transporting the interworking information. In a more general case when interworking information needs to be transported for some other purpose, i.e. also in a PSTN originated / IMS terminated session, an INVITE message from the MGCF towards the P-CSCF can be used.

Alternatively, an S-CSCF (Serving Call/Connection State Control Function) or an I-CSCF (Interrogating CSCF) on a way between the PDF and the MGCF adds the interworking information instead of the MGCF. Moreover, instead of the MGCF and S/I- CSCF, a BGCF (Breakout Gateway Control Function) that resides between the S-CSCF and the MGCF(s) and selects the MGCF to be used for the CS interworking may add the interworking information.

2: The leg from the P-CSCF to the PDF which is known as the Gq interface. For example, the Diameter Protocol may be used with some new attributes or parameters. The interworking information may be included as a part of the application/service information provided by the AF/P-CSCF to the PDF during the session establishment.

In case the Diameter Protocol is used for the Gq interface, leg 2 can be handled with an attribute value pair to be defined for the application identifier described in the specification 3GPP TR 23.917, version 1.2.0, subclause 7.4.1.2 "Gq Data Exchange", or with a new attribute value pair (e.g. Interworking information) . The P-CSCF transfers the interworking information received from the MGCF in the SIP/SDP signalling transparently to the PDF in the information field of the Diameter attribute value pair.

In case any other protocol is used in the Gq interface, the interworking information can be transferred similarly from the P-CSCF to the PDF in a container (i.e. in an information field of a parameter) provided by the protocol.

Alternatively, the P-CSCF may manipulate the interworking information received from the MGCF before sending the information to the PDF. The P-CSCF may for example change the format of the information.

Leg 1 from the MGCF to the P-CSCF can be handled in different ways :

Primary implementation example:

A new attribute ("a") is defined for SDP. According to the IETF RFC 2327: "SDP: Session Description Protocol", M. Handley et al., April 1998, attributes are the primary means of extending the SDP. Attributes not understood by a recipient are simply ignored, which means backward compatibility. Attributes do not have to be registered by IETF (Internet Engineering Task Force) (IANA (Internet Assigned Numbers Authority)). Unregistered attributes simply start with "X-". This way the 3GPP (Third Generation Partnership Project) specific interworking information can be standardized within 3GPP even though the SDP is used as a container.

Examples of such a new SDP attribute are:

"a=interw : pstn"

"a=X-interw:pstn"

"a=pstninterw" "a=X-pstninterw"

"a=earlymedia"

"a=X-earlymedia"

Examples 1 and 2 indicate with the attribute "interw" that this is an interworking case, and with the parameter value "pstn" that the interworking partner is PSTN. Instead of "pstn" there could be a number of more detailed parameter values .

Examples 3 and 4 simply indicate with the existence of the parameter that the session comprises interworking with PSTN. Examples 5 and 6 indicate that early media is required, i.e. gates should be opened already at the authorization of QoS resources .

Other implementation examples :

A new SIP header may be defined for leg 1 to indicate the interworking. The SIP header may be transferred in a response "183 Session progress" or in an INVITE message. The INVITE message is shown in 3GPP TS 24.228 version 5.4.0, table 7.3.6.1-1, and the message 183 is shown in 3GPP TS 24.228 version 5.4.0, table 7.3.6.1-8.

The P-CSCF deduces the interworking information from the SIP contact header (of the ^λΛ183 Session progress" or INVITE message) . The P-CSCF has to identify the addresses allocated to the MGCFs to be able to deduce that this is a PSTN interworking case.

Alternatively, the P-CSCF may deduce the interworking information from the SIP contact header (of the 183 or INVITE message) and the presence of a URI (Uniform Resource Identifier) parameter. Examples for such URI parameter are: Contact: <sip: 5555 : aaaa:bbbb: cccc: dddd] : 1537;inter =pstn Contact: <sip: 5555 : aaaa:bbbb: cccc: dddd] : 1537;pstninterw Contact: <sip: 5555 : aaaa:bbbb: cccc: dddd] : 1537;earlymedia

The PDF may deduce possible interworking measures from existing SDP parameters. For example an attribute "a=recvonly" may be interpreted as a streaming service not requiring the opening of the gates until an answer message has been received. An attribute "a=sendrecv" may be interpreted as a possible CS interworking case requiring the opening of the gates already at the authorization of QoS resources.

Basically, the indication from MGCF to P-CSCF may also be any existing parameter, indicator, header or combination of them agreed to be used for this purpose.

In communication 1, a call setup using SIP INVITE is performed from a UE via a P-CSCF, an S-CSCF and an MGCF to a circuit switched network. At this stage the P-CSCF is not able to know that the call will terminate in a CS network since the S-CSCF and the MGCF have the call control (and could e.g. re-route the call) .

In block 2, the MGCF detects that the call setup will be routed to the CS network and sets an indication about CS termination in one of the backward messages towards the originating UE. For example, such backward message may be SIP response "183 Session progress".

The indication in the backward message e.g. SIP response message (communication 3a) may be a new parameter (a SIP header or an SDP parameter) or may be a combination of some existing parameters as described before.

Meanwhile a normal call setup in circuit switched side continues as indicated by communication 3b.

In block 4, the P-CSCF detects the above mentioned CS termination indication in the SIP response message.

In communication 5, the P-CSCF forwards the CS termination indication to a PDF over a Gq interface. Thus, the Gq interface may have a corresponding new parameter as needed in SIP. Alternatively, the P-CSCF may convert the CS termination indication into one or more parameter (s) in Gq interface for indicating that gates at a GGSN are to be controlled (e.g. opened or closed) .

In block 6, the PDF receives either the CS termination indication or parameters indicating gate control. In the latter case the PDF in not necessarily aware of the CS termination but can still open the gate for early media. However, if the CS termination indication is used in the Gq interface the PDF may use this information also for other purposes besides or instead of gate control.

As can be understood from the foregoing, according to the invention an indication of the interworked network and/or the properties of the interworked network can be provided to an application function, and a policy decision entity can be made aware of the interworked network and/or its properties and consequently can apply proper policy control measures in all interworking cases, e.g. can open the gates at a gateway in a core network for the transmission of early media. It is to be understood that the above description is illustrative of the invention and is not to be construed as limiting the invention. Various modifications and applications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the appended claims .

Claims

CLAIMS :

1. A policy decision entity of a communication network system, the policy decision entity controlling media flows and comprising: receiving means for receiving a message; and detecting means for detecting an indication indicating interworking with a specific network in the received message.

2. The policy decision entity according to claim 1, comprising: controlling means for controlling gates for the media flows in accordance with the indication indicating interworking with the specific network.

3. The policy decision entity according to claim 2, wherein the means for controlling the gates are configured to allow early media to at least one direction in the media flow if interworking with a circuit switched network is detected based on said received indication.

4. The policy decision entity according to any one of the preceding claims, wherein said media flows controlled by the policy decision entity are present in a further network entity.

5. A first session control entity of a communication network system, the first session control entity comprising: receiving means for receiving a first message; detecting means for detecting a first indication of interworking with a specific network from a SIP contact header of the received first message; including means for including in a second message to be sent to a policy decision entity a second indication based on the first indication received in the first message; and sending means for sending the second message to the policy decision entity.

6. The first session control entity according to claim 5, comprising: converting means for converting the first indication of interworking with the specific network into an instruction to control gates for media flows, wherein the including means is configured to include the instruction in the second message to be sent to the policy decision entity.

7. The first session control entity according to claim 5, wherein the second indication indicates interworking with the specific network.

8. The first session control entity according to any one of claims 5 to 7, wherein the session control entity and the policy decision entity are provided as one network element.

9. A second session control entity of a communication network system, the second session control entity performing session control and comprising: detecting means for detecting interworking with a specific network; including means for including an indication of the interworking with the specific network in a SIP contact header of a message to be sent towards a first session control entity; and sending means for sending the message to the first session control entity.

10. A second session control entity of a communication network system, the second session control entity performing session control and comprising: detecting means for detecting interworking with a specific network; including means for including an indication of the interworking with the specific network in a SIP contact header of a backward message to be sent towards an originating network; and sending means for sending the message to the originating network.

11. The second session control entity according to claim 10, wherein the including means is arranged to include a parameter indicating the interworking with the specific network in the message to be sent to the originating network.

12. The second session control entity according to claim 10, wherein the including means is arranged to include a header indicating the interworking with the specific network in the message to be sent to the originating network.

13. The second session control entity according to any one of claims 9 to 12, wherein the second session control entity is an I-CSCF, S-CSCF, BGCF or MGCF.

14. A message to be sent to a policy decision entity of a communication network system, the message comprising an indication indicating interworking with a specific network.

15. A message to be sent to an originating network of an interworking network system, the message comprising an indication of interworking with a specific network.

16. The message according to claim 15, wherein the message is a SIP message.

17. A network system comprising a policy decision entity according to any one of claims 1 to 4, a first session control entity according to any one of claims 5 to 8 and a second session control entity according to any one of claims 9 to 13.

18. A method in a communication network system, the method comprising the steps of: receiving an indication indicating interworking with a specific network at a policy decision entity performing gate control; and performing actions at the policy decision entity based on said indication.

19. A method in a communication network system, the method comprising the steps of: receiving a first message from an entity performing session control; detecting a first indication of interworking with a specific network from a SIP contact header of the received first message; including in a second message to be sent to a policy decision entity a second indication based on the first indication received in the first message; and sending the message to the policy decision entity.

20. The method according to claim 19, wherein said second indication comprises gate control information.

21. The method according to claim 19, wherein said second indication comprises an indication of interworked network.

22. A method in a communication network system, the method comprising the steps of: detecting interworking with a specific network; including an indication of the interworking with the specific network in a SIP contact header of a message to be sent to an originating network; and sending the message to the originating network.

23. A computer program product for a computer, comprising software code portions for performing the steps of any one of claims 18 to 22 when the program is run on the computer.

24. The computer program product according to claim 23, wherein the computer program product comprises a computer- readable medium on which the software code portions are stored.

25. The computer program product according to claim 23, wherein the computer program product is directly loadable into an internal memory of the computer.