Method And Apparatus For Improving The Efficiency Of Resource Utilisation In A Communications System

TECHNICAL FIELD

p-0002The invention relates communications systems, and more specifically to the assignment of transport policies to communications sessions in a communications system.

BACKGROUND

p-0003In the past years, the Internet has gradually merged with telecommunication services—both in mobile and fixed telecommunication systems. In the third generation mobile radio communications networks, the two vastly successful concepts of cellular networks and the Internet are closely connected. Similarly, convergence of the fixed telecommunications networks and the Internet is also currently being standardised by the Telecoms & Internet converged Services and Protocols for Advanced Networks (TISPAN).

p-0004The convergence of the Internet with telecommunications services opens up for a whole range of new applications, each of which has its own requirements on transmission conditions such as bandwidth and quality of service. In order to improve the service provided to users of a communications network, as well as to optimise the utilisation of communication resources, it is desirable that the transmission conditions can be adapted to the requirements of the application for which the communication resources are being used.

p-0005According to the 3GPP standard, as well as for other standards allowing IP based communication, such as the IP-TV standard, an application function (AF) provides a connection between the control signalling plane and the traffic media plane. The AF is generally connected to a Policy Decision Function (PDF), and can send so called transport policy requests to the Policy Decision Function, wherein particular transmission requirements for a session can be requested (see e.g. 3GPP Technical Specification (TS) 23.203 version 7.2.0). However, the flexibility in the policy requests that can be generated by the AF is limited, and a greater flexibility in the allocation of resources and other policy related events is desired in order to improve the efficiency of the utilisation of resources.

SUMMARY

p-0006A problem to which the present invention relates is how to improve the utilisation of communication resources in a communications system by increasing the flexibility of the assignment of transport policy to communications sessions.

p-0007This problem is addressed by a transport policy requesting node (TPRN) for requesting a transport policy for a bearer of a session to a user equipment in a communications system comprising a policy decision function. The TPRN comprises an event handling mechanism adapted to detect a triggering event triggering the selection of a transport policy for the bearer of a service; and a transport policy selection mechanism adapted to select a transport policy and transmit a policy request indicative of the transport policy to a policy decision function. The TPRN is characterised by a context information handling mechanism adapted to receive information relating to a context relevant to the session.

p-0008The problem is further addressed by a method for assigning a transport policy for a bearer of a session in a communications system. The method comprises: detecting a triggering event triggering the selection of a transport policy; selecting a transport policy for the bearer; and transmitting a policy request indicative of the selected transport policy to a policy decision function. The method further comprises receiving context information relating to the session and using the received context information in the assigning of a transport policy.

p-0009By the inventive method and apparatus is achieved that the assignment of a transport policy to a session can be dynamically adjusted to context parameters that are relevant to the session—hence, the efficiency of the utilisation of communication resources will be improved.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0010For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

p-0011<figref idrefs="DRAWINGS">FIG. 1</figref> is an overview of a communications system.

p-0012<figref idrefs="DRAWINGS">FIG. 2</figref> schematically illustrates traffic media plane signalling and control plane signalling in a communications system providing session based IP communication according to the prior art.

p-0013<figref idrefs="DRAWINGS">FIG. 3</figref> schematically illustrates traffic media plane signalling and control plane signalling in a communications system using the IP Multimedia Subsystem (IMS) according to the prior art.

p-0014<figref idrefs="DRAWINGS">FIG. 4</figref> is a signalling diagram illustrating transport policy handling in a communications system using the IP Multimedia Subsystem according to the prior art.

p-0015<figref idrefs="DRAWINGS">FIG. 5</figref> is an illustration of the functionality of an inventive transport policy requesting node.

p-0016<figref idrefs="DRAWINGS">FIG. 6</figref> is an illustration of an example of a workflow to be executed in relation to the transport policy selection for a session.

p-0017<figref idrefs="DRAWINGS">FIG. 7</figref> is a flowchart illustrating an inventive method for transport policy selection.

p-0018<figref idrefs="DRAWINGS">FIG. 8</figref> is an illustration of a communications system including an transport policy requesting node according to the invention.

p-0019<figref idrefs="DRAWINGS">FIG. 9</figref> is a signalling diagram illustrating transport policy handling upon session initiation in a system comprising an inventive transport policy requesting node.

p-0020<figref idrefs="DRAWINGS">FIG. 10</figref><i>a </i>is an example of a session initiation message including a flag indicating whether or not an application function node shall initiate a policy decision.

p-0021<figref idrefs="DRAWINGS">FIG. 10</figref><i>b </i>is a flowchart illustrating a method for determining whether or not an application function shall initiate a policy decision.

DETAILED DESCRIPTION

p-0022An example of a communications system <b>100</b> including a user equipment <b>105</b> and a network <b>110</b> offering session based Internet Protocol (IP) communications is schematically illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref>. The session based IP communications supported by the network <b>110</b> could for example be based on the Internet Protocol Multimedia Subsystem (IMS) standard, the Real Time Streaming Protocol (RTSP), the Session Initiation Protocol, the Simple Object Access Protocol (SOAP), or other standard providing session based IP communication. The term session should be construed as a sequence of IP packets sharing a common denominator, such as a port number. For a description of the IMS standard, see e.g. 3GPP Technical Specification 23.228, version 8.0.0.

p-0023User Equipment (UE) <b>105</b> of <figref idrefs="DRAWINGS">FIG. 1</figref> is capable of communicating within network <b>110</b> via physical interface <b>115</b>, which may be a radio connection or a fixed connection. Network <b>110</b> could provide one or several Internet Protocol Connectivity Access Network (IP-CAN) bearers such as a General Packet Radio Service (GPRS), a Wireless Local Area Network (WLAN) service, or any other bearer service.

p-0024Session based IP communications generally operate according to a layered architecture in the sense that the session signalling is separated from the traffic flow. Hence, the physical interface <b>115</b> is used for transmission of session signalling messages in the control signalling plane as well as for transmission of media traffic in the traffic media plane.

p-0025In <figref idrefs="DRAWINGS">FIG. 2</figref>, routes in the control signalling plane <b>200</b>, as well as in the traffic media plane <b>205</b>, are schematically illustrated for a prior art system. A network <b>110</b> is arranged to provide IP session based communication, e.g. by means of IMS functionality. The physical interface <b>115</b> providing connectivity to the user equipment <b>105</b> to the network <b>110</b> is illustrated to include a control signalling interface part <b>115</b><i>a </i>and a media traffic interface part <b>115</b><i>b. </i>

p-0026Network <b>110</b> comprises one or more Policy Enforcement Functions (PEF) <b>210</b>. The transport policy, or policy for short, that applies to a session should here be construed to represent the setting of quality of service (QoS) parameters and/or resource reservation rules for the transport media of the session. The transport policy of a session normally depends on the type of service to which the session relates, as well as on the type of subscription held by the user(s) of the user equipment(s) <b>105</b> involved in the session. The prior art policy assignment involves a negotiation between the end points where the end points are able to express there requirements depending on end user requests and the capabilities of the user equipment <b>105</b>. The transport policy of a session is, according to the prior art, often expressed in terms of bandwidth requirements, priority, and/or gating restraints.

p-0027A PEF <b>210</b> is arranged to enforce different policies for different IP sessions in the traffic media plane <b>205</b>. The media components in the traffic media plane <b>205</b> are for example identified by packet filters. The PEF <b>210</b> may provide different treatments in the routing logic to different media flows. When network <b>100</b> provides GPRS as an Internet Protocol Connectivity Access Network (IP-CAN) bearer, the PEF is generally located in a Gateway GPRS Support Node (GGSN), and when the IP-CAN bearer is based on W-LAN, DSL, G-PON etc, the PEF <b>210</b> is located in a corresponding node in the traffic media plane <b>205</b>.

p-0028Network <b>110</b> of <figref idrefs="DRAWINGS">FIG. 2</figref> is further shown to comprise an Application Function (AF) <b>215</b> and a Policy Decision Function (PDF) <b>220</b> for signalling of control messages within network <b>110</b>, as well as an application server system <b>225</b>. The application server system <b>225</b> provides application layer functionality and is adapted to provide services to user equipments <b>105</b>. In many cases, the application server system <b>225</b> is part of both the control signalling plane <b>200</b> and traffic media plane <b>205</b>, but in order to simplify the illustration, the application server system <b>200</b> is shown in <figref idrefs="DRAWINGS">FIG. 2</figref>, as well as in <figref idrefs="DRAWINGS">FIGS. 3 and 8</figref>, to be part of the control signalling plane <b>200</b> only. The application server system <b>225</b> includes application functionality that operates in the media layer, such as for example Push-To-Talk functionality, Voice-over-IP functionality, gaming applications, content creation functionality, etc. The application server system <b>225</b> may also include service enablers such as charging systems, positioning systems and so forth. Furthermore, the application server system <b>225</b> often includes functionality for session handling. The application server system <b>225</b> of <figref idrefs="DRAWINGS">FIG. 1</figref> communicates session information to the traffic media plane via the AF <b>215</b>.

p-0029The PDF <b>220</b> of <figref idrefs="DRAWINGS">FIG. 2</figref> makes decisions about a policy that should be applied to a particular session, based on information received via the AF <b>220</b> over interface <b>245</b>—that is, the policy rules for a session are generated by the PDF <b>220</b>. The policy rules are then forwarded to the PEF <b>210</b>, where they are enforced. The PDF <b>220</b> provides an interface between the signalling plane <b>200</b> and the traffic media plane <b>205</b> via the PEF <b>210</b>.

p-0030<figref idrefs="DRAWINGS">FIG. 2</figref> further provides an illustration of an example of different functions in a user equipment <b>105</b>, by means of which IP session communication can be realised. The user equipment <b>105</b> of <figref idrefs="DRAWINGS">FIG. 2</figref> comprises an application <b>240</b> connected to an IP Session client <b>235</b>. The IP session client <b>235</b> is adapted to communicate control signals relating to the execution of a service provided by an application server system <b>225</b> to/from the application <b>240</b> of user equipment <b>105</b>. IP session client <b>235</b> is further adapted to communicate traffic to/from the network <b>110</b> in the traffic media plane <b>205</b>.

p-0031According to the prior art (see e.g. 3GPP TS 23.203 version 7.2.0), the AF <b>215</b> provides, via the PDF <b>220</b>, a connection between the control signalling plane <b>200</b> and the traffic media plane <b>205</b>. The AF <b>215</b> is adapted to relay the session signalling between the session end points and to generate request for resource modification in the PEF <b>210</b>. The AF <b>215</b> operates as a proxy—that is, AF <b>215</b> relays requests, and services these requests internally and/or forwards the requests on to other nodes, but has very limited knowledge of the context in which the requests are being transmitted. For example, when a session request is being transmitted as part of the invocation or execution of a service, the AF <b>215</b> has no other knowledge about the properties and requirements of the service than what is included in the session request. The information included in requests serviced by the AF <b>215</b> is generally very limited. This limits the flexibility and exactness in the allocation of resources and other policy related events.

p-0032In <figref idrefs="DRAWINGS">FIG. 3</figref>, an example of a prior art system <b>100</b> is given in terms of an IMS based system, wherein the IP Session client <b>235</b> of the user equipment <b>105</b> is an IMS client <b>335</b>, the AF <b>215</b> is a Proxy Call/Session Control Function (P-CSCF) <b>315</b> and the PDF <b>220</b> is a Policy and Charging Rule Function (PCRF) <b>320</b>. IMS based system <b>100</b> of <figref idrefs="DRAWINGS">FIG. 3</figref> further comprises an S-CSCF <b>325</b> for communication between the P-CSCF <b>315</b> and the application server system <b>225</b>. The S-CSCF <b>325</b> is a Session Initiation Protocol (SIP) server. The P-CSCF <b>125</b> can communicate with the S-CSCF <b>325</b> in the signalling plane <b>200</b>. In the embodiment of <figref idrefs="DRAWINGS">FIG. 3</figref>, the S-CSCF <b>325</b> is connected to an application server system <b>225</b> comprising hardware and/or software for the execution of services, such as for example Voice over IP, Push-to-talk, billing services or gaming.

p-0033PCRF <b>320</b> of <figref idrefs="DRAWINGS">FIG. 3</figref> comprises a policy database <b>355</b> which includes a table that defines the mapping of services to bearer policies. PCRF <b>320</b> may, according to the current 3GPP IMS standard (see inter alia 3GPP TS 23.203 v. 7.2.0 &amp; 23.228 v. 8.0.0), be implemented as part of P-CSCF <b>315</b>, or be implemented as a separate entity. When PCRF <b>320</b> is implemented as a separate entity, the P-CSCF <b>315</b> can communicate with PCRF <b>320</b> over an interface referred to as the Rx interface <b>345</b>. PCRF <b>220</b> can further communicate with PEF <b>310</b> via an interface referred to as the Gx interface <b>350</b>.

p-0034The IMS-based system <b>100</b> of <figref idrefs="DRAWINGS">FIG. 3</figref> is only an example of a system <b>100</b> to which the invention is applicable. For illustration purposes, some features of the invention will in the following be described in terms of the IMS-based system of <figref idrefs="DRAWINGS">FIG. 3</figref>. It should be kept in mind, however, that the invention is equally applicable to IP session communications systems of other standards, such as for example RTSP or plain SIP (non-IMS-based).

p-0035When a media session is initiated in the traffic media plane <b>205</b> of a system <b>100</b>, a binding procedure is used to associate the service data flow of the session to an IP-CAN bearer that is deemed to transport the service data flow. In a system <b>100</b> that is uses the IMS standard, the service data flow is set up by means of a Session Description Protocol (SDP). This is further illustrated in relation to <figref idrefs="DRAWINGS">FIG. 4</figref>, wherein the initiation of a media session is illustrated in a schematic signalling diagram. The initiation of a media session in an IMS system <b>100</b> is signalled by use of the Session Initiation Protocol (SIP) in the control signalling plane <b>200</b> according to the Session Description Protocol (SDP) offer/answer model.

p-0036When setting up an IMS session, or any other session that relies on SDP to describe the session, the session end points (e.g. application <b>240</b> of two different user equipments <b>105</b>, or application <b>240</b> of a user equipment and an application server in an application server system <b>225</b>) negotiate the resources to be used on the traffic media plane <b>205</b> by sending SIP messages in the control signalling plane <b>200</b>.

p-0037An example of a successful session initiation scenario according to the prior art is schematically illustrated in the signalling diagram of <figref idrefs="DRAWINGS">FIG. 4</figref>. Here, the application <b>240</b> in user equipment <b>105</b> serves as the session initiating node. In the scenario of <figref idrefs="DRAWINGS">FIG. 4</figref>, the user equipment <b>105</b> is already connected to the network <b>110</b>, and has established an IP-CAN session, e.g. using a default bearer, when a service is requested by the application <b>240</b> at <b>4</b>A. The following events are included in the signalling diagram of <figref idrefs="DRAWINGS">FIG. 4</figref>:

p-0038<b>4</b>A: The application <b>240</b> in the user equipment <b>105</b> enters, into a SIP invite signalling message, applicable values of any parameters that are necessary for running the service to be initiated. Such parameters include inter alia an IMS Class of Service Indicator (ICSI), indicating which type of service the session to be initiated intends to use. The initiating node then sends the SIP invite signalling message to the other session end point.

p-0039<b>4</b>B: The SIP invite message is first sent via the P-CSCF <b>315</b>. The P-CSCF <b>315</b> then forwards the SIP invite message to the S-CSCF <b>325</b>.

p-0040<b>4</b>C: The S-CSCF <b>325</b> performs service control, which for example may include the checking of the subscriber data to find out any service restrictions etc that might apply. Furthermore, the S-CSCF <b>325</b> routes the SIP invite to the relevant application server that can provide the requested service.

p-0041<b>4</b>D: Since <figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a successful scenario, the requested service is allowed, and the SIP invite message is sent from the S-CSCF <b>325</b> to the terminating session end point.

p-0042<b>4</b>E: An offer response message (typically a SIP <b>200</b> OK) is received at the S-CSCF <b>325</b> from the other end point. The offer response message includes at least some of the parameters that were included in the SIP invite, of which parameters the values have possibly been modified by the terminating end point. The offer response is then forwarded to the P-CSCF <b>315</b>.

p-0043<b>4</b>F: The P-CSCF <b>315</b>, which operates as a proxy, generates a policy request to the PCRF <b>320</b> in accordance with the parameter values. In the current IMS standard, this policy request is an Access Authentication Request (AAR)-message which is transported over the Rx-interface <b>345</b>.

p-0044<b>4</b>G: The PCRF <b>320</b> analyses the received policy request message in terms of the requested policy, and compares the requested policy to the policies that are allowed for the involved end points. A resource reservation request message is sent by PCRF <b>320</b> to the PEF <b>210</b>, requesting the PEF <b>210</b> to set up a bearer with the requested policy.

p-0045<b>4</b>H: A message to initiate the modification of the IP-CAN bearer is sent from the PEF <b>120</b> to the user equipment <b>105</b>.

p-0046<b>4</b>I: Acknowledgement messages are sent from the user equipment <b>105</b>, the PEF <b>310</b> and the PCRF <b>320</b>.

p-0047<b>4</b>J: P-CSCF <b>315</b> forwards the offer response message to the user equipment <b>105</b>.

p-0048The prior art policy allocation for a session for a system <b>100</b> based on IMS as shown above is based on the Session Description Protocol (SDP). The corresponding prior art signalling diagrams representing session initiation in systems operating according to other standards are very similar. Any allocation or modification of the resources to be used by a session is performed by means of session initiation negotiations sent via the AF <b>215</b> (in <figref idrefs="DRAWINGS">FIG. 4</figref>: P-CSCF <b>315</b>) to the Policy Decision Function (in <figref idrefs="DRAWINGS">FIG. 4</figref>: PCRF <b>320</b>). The information which can be included in a session initiation message (in <figref idrefs="DRAWINGS">FIG. 4</figref>: a SIP invite message with SDP) is limited, and the parameters included in the session initiation message may not be sufficient for determining the QoS of a session at the desired granularity.

p-0049According to the invention, the flexibility in terms of transport policy for a particular session, or a particular part of a session, can be greatly improved by introducing a transport policy requesting node comprising a context information handler adapted to receive information relating to a context in which a service is to be executed by means of the session or the session part. Such context information handler allows for the policy requesting node to receive information on the context in which a service is to be executed, and the transport policy of the session by means of which the service will be executed can be adjusted to such context. In the following, the term session should be construed to include both entire sessions and parts of a session for which a transport policy may be assigned.

p-0050As will be seen below, the receipt of new context information can be a triggering event triggering the selection of a new transport policy for a session. Context information can also be used in determining which transport policy to select for a session in situations when the selection of transport policy has been triggered by other events, such as the receipt of a session initiation or session modification message.

p-0051Examples of context information that may be used in the triggering of a transport policy request can for example be the position of one or both of the session end points; instant resolution or bandwidth requirements of a particular application such as for example a game; the time of day; which other services are currently being used by the user equipments <b>105</b> involved in the session; the status of the billing account related to the user equipments <b>105</b> involved; information on the current traffic load in the network or parts of the network (e.g. the current load of a particular cell in a mobile radio system; or the load of a particular type of access technology (e.g. a particular type radio technology) that may be overloaded; information on which applications the user of a user equipment <b>105</b> regularly uses; any connections to associated applications, etc. For example, if a user of a game presses a button on a user equipment <b>105</b> whereby the game goes into a more (or less) resolution requiring mode, the transport policy requesting node can receive information about this event via the context information interface, and a request for a transport policy of higher (or lower) bandwidth can be sent to the relevant policy decision point. In this way, the bandwidth used by the session can be optimised for the application carried by the session at any point in time, and the bandwidth utilisation and/or quality perceived by the user of the application is improved and customised for a particular occasion. Since the transport policy assignment for a session will be updated upon receipt of a triggering event, the transport policy of a session can vary with the different transport requirements of the session at different points in time during the life-time of the session.

p-0052Many other situations can be conceived where dynamic context dependent allocation of transport policy is desirable. For example, when a mobile user equipment <b>105</b> enters a particular area, the transport policy can be amended according to a transport policy selection rule for the entered area. Such an area could for example be an area where the traffic load is usually high (or low), and a new transport policy of lower (or higher) bandwidth consumption could be selected upon entry into this area.

p-0053As seen above, the context information to be used in relation to the transport policy selection for a session can originate from an application for which the session is going to be used, such as for example a game, or originate from external sources, such as a positioning server or a traffic load monitoring node.

p-0054A transport policy requesting node (TPRN) <b>500</b> according to the invention is schematically illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref>. The system is configured to facilitate for the TPRN to participate in the control signalling plane <b>200</b>, and when needed, in the traffic media plane <b>205</b>. The TPRN <b>500</b> of <figref idrefs="DRAWINGS">FIG. 5</figref> comprises an event handler <b>505</b> adapted to receive, via interface <b>510</b>, a triggering signal triggering the request for a transport policy for the bearer, or bearers, of the traffic associated with a session. TPRN <b>500</b> further comprises a context information handler <b>515</b> adapted to receive, via interface <b>520</b>, information relating to a context relevant to a session or part of a session for which a transport policy is to be requested. Such context information could be received from an application server system <b>225</b>, or from other nodes in system <b>100</b>. Moreover, TRPN <b>500</b> comprises a policy selection mechanism <b>525</b> adapted to select a particular transport policy as the desired transport policy and transmit a policy request indicative of the transport policy to a policy decision function <b>220</b> via interface <b>530</b>. The different functionalities of the TPRN <b>500</b> can be implemented by suitable hardware and/or software.

p-0055Context information handler <b>515</b> of TPRN <b>500</b> is adapted to receive information relating to a context relevant to a session. The context information handler <b>515</b> could, in an embodiment of the invention, be arranged to request such context information from nodes external to the TPRN <b>500</b>, such as for example positioning nodes, content creation nodes traffic load monitoring nodes, charging nodes, etc. The context information handler <b>515</b> could alternatively, or in combination with the possibility of requesting context information, include functionality for parsing ongoing signalling in order to detect context information in terms of events that occur in relation to an on-going session, such as for example the sending of gaming instructions from a user of a user equipment <b>105</b>; the sending of instructions to change the transmitted channel from a user equipment <b>105</b> in a scenario where the session is used for the transmission of IP-TV, etc. Such parsing functionality could advantageously be based on a sniffer adapted to intercept/parse signalling that occurs in system <b>100</b> between nodes that are relevant for the session. Such a sniffer would be adapted to intercept the relevant protocol: for example http, protocols relating to IP-TV, VoIP, MSN, Skype, chatting protocols etc. Moreover, context information handler <b>515</b> could also be arranged to receive context information sent to TPRN <b>500</b> by other nodes when the sending of context information was initiated by the other nodes. Context information handler <b>515</b> may or may not include storage means for storage of context related data.

p-0056The event handler <b>505</b> of TPRN <b>500</b> is adapted to detect events that would trigger the selection of a transport policy for a session, and upon detection of a triggering event, trigger the selection of a transport policy for the session. Event handler <b>515</b> is further adapted to trigger the transport policy selection mechanism <b>525</b> to select a transport policy for a particular session.

p-0057The triggering events could advantageously include the initiation of a new session. For this purpose, event handler <b>500</b> could for example include a session initiation sniffer adapted to intercept/parse session set up signalling (for example a SIP sniffer if the relevant session initiation is performed by use of SIP), or event handler <b>500</b> could be adapted to receive and relay the session initiation signalling (for example signals from the S-CSCF <b>325</b> in an system <b>100</b> using the IMS standard).

p-0058The triggering events by which the selection of a transport policy for a session would be triggered could advantageously include the receipt of particular context information, such as for example the sending of gaming instructions from a user of a user equipment <b>105</b>; the sending of instructions to change the transmitted channel from a user equipment <b>105</b> in a scenario where the session is used for the transmission of IP-TV; information that a user equipment <b>105</b> has entered a particular area, etc. Hence, the event handler <b>505</b> is advantageously arranged to detect when such particular context information is received by the context information handler <b>515</b>. When the triggering event is the receipt of context information in context information handler <b>515</b>, the triggering signal received by the event handler <b>505</b> would be received over an internal interface <b>520</b>. The event handler <b>505</b> could then (at least partly) be implemented as a part of the context information handler <b>515</b> adapted to transmit a trigger to the transport policy selection mechanism <b>525</b> upon detection of the receipt of such particular context information, or could be implemented as a separate mechanism.

p-0059The policy selection mechanism <b>525</b> of TPRN <b>500</b> is adapted to select a transport policy for a particular session upon receipt of a trigger from the event handler <b>505</b>. The policy selection mechanism <b>525</b> can advantageously be adapted to use the context information received by the context information handler in the selection of the transport policy. The selection of a transport policy could for example be performed by checking the value of one or more context parameters, and select the transport policy in accordance with the context parameter values. In an embodiment of TPRN <b>500</b> wherein the context information handler <b>515</b> can send requests for context information to external nodes, the policy selection mechanism could be adapted to instruct the context information handler <b>515</b> to request the value of a relevant context parameter if such value is not already known by TPRN <b>500</b>.

p-0060The policy selection mechanism <b>525</b> comprises hardware and/or software for executing instructions by means of which the selection is to be performed. In one embodiment of TPRN <b>500</b>, the TPRN <b>500</b> comprises an interface <b>535</b> for receiving a new set of instructions by means of which the transport policy should be selected. Such instructions could for example be expressed by means of a dynamic workflow, for example a script, to be executed by the policy selection mechanism <b>525</b>. The policy selection mechanism <b>525</b> will in most implementations have access to a plurality of different sets of instructions for selecting the transport policy, wherein a set of instructions applies to one or more triggering events, and other sets of instructions apply to other triggering events. Which set of instructions that applies in a particular situation could also depend on other parameters, such as for which type of session (text/video/speech . . . ) the transport policy is to be selected.

p-0061By allowing a new set of readily executable instructions to be received by the TPRN <b>500</b> via interface <b>535</b>, the policy selection mechanism <b>525</b> can easily be adapted to new scenarios which may require a different policy selection procedure. This is for example useful in application design environments wherein new applications can easily be designed by combining different existing application components. An operator of an application server could e.g. design a script to be downloaded to the policy selection mechanism <b>525</b> by means of interface <b>535</b> only minutes or seconds before the new instructions on how to select a transport policy for a session carrying a service provided by the application server should start to apply.

p-0062The transport policy selection mechanism <b>525</b> could utilize a table or database comprising a list of different quality classes to which a session may belong, with corresponding transport policies that should be selected for a session of a particular service class. The checking of relevant context parameters for a session could in this embodiment result in a value representing the Quality Class to which the session currently belongs. Such value could be indicated by means of a Quality Class Indicator (QCI). In other implementations of the invention, policy selection mechanism <b>525</b> could select a policy for a session directly based on the values of context parameters, without assigning the session to a particular class.

p-0063The transport policy selection mechanism <b>525</b> would in many implementations take other parameters into account than dynamic context parameters when selecting a transport policy for a session, such as user subscription related parameters. The TPRN <b>500</b> may be connected to a subscription database comprising information on subscription policies relating to subscriptions of services provided by system <b>100</b>. Such subscription policies could for example include information on which policies or types of policies a subscription is allowed to access, what functions or type of functions the subscription is allowed to invoke, etc. A workflow <b>600</b>, of which an example is illustrated below in <figref idrefs="DRAWINGS">FIG. 6</figref>, can for example include a step where a check in the subscriber database is performed.

p-0064<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates an example of a workflow <b>600</b> that could be used by policy selection mechanism <b>525</b> in selecting a transport policy. The workflow <b>600</b> illustrates a scenario wherein the parameters “user policy”, “required resolution” and “position of the user equipment” are relevant for the policy decision. In step <b>605</b>, the user policy, the required resolution and the position of the user equipment are checked for the relevant session. If any of these parameters are unknown, the policy selection mechanism <b>525</b> could, as discussed above, in an embodiment of the invention send a request to the context information handler <b>515</b> for the missing information. When the value of the relevant parameters have been determined, step <b>610</b> is entered, wherein it is checked whether the parameter values fulfil certain criteria, in this case whether the user policy is “premium voice”, the position is “the city”, and bandwidth requirements are “extremely high”. If so, a Quality Class Indicator (QCI) is set to a predetermined value (in this case “10”), indicating a particular service class for which a particular transport policy should be requested. The workflow <b>600</b> is then ended in step <b>615</b>. If the relevant parameter values do not fulfil the criteria of step <b>610</b>, the criteria of other quality classes could similarly be checked, i.e. several sets of parameter values that would result in the QCI being set to a different value may be used in the workflow <b>600</b>.

p-0065The example workflow illustrated in <figref idrefs="DRAWINGS">FIG. 6</figref> can be modified in a multitude of ways, and only illustrates one of numerous examples. Any number of parameters can be relevant for the policy decision, and any values of the relevant parameters may be used as triggers for the setting of a particular policy.

p-0066An alternative to using a work flow <b>660</b> for the transport policy selection performed by the transport policy selection mechanism <b>525</b> could for example be to use a policy database by means of which policy decisions may be taken, wherein the policy database could advantageously contain a table by means of which different values of for example services and/or subscription categories could be mapped to different QCIs.

p-0067The TPRN <b>500</b> may optionally further include a notification handler <b>540</b> which is adapted to receive notifications from the PEF <b>210</b> or PDF <b>220</b> relating to the bearer of a session. Such notifications could advantageously be received over the interface <b>530</b>. A PDF <b>220</b> is often capable of communicating information from the traffic media plane <b>205</b> to the control signalling plane <b>200</b>. For example, according to the 3GPP TS 23.203 standard, the AF <b>215</b> may subscribe to information from the bearer informing the AF <b>215</b> of events such as loss of bearer, etc. However, an AF <b>215</b> is a proxy, and has limited possibilities to act on such notifications. If the AF <b>215</b> is informed of any changes in the bearer layer, the AF <b>215</b> has the choice of either disconnecting the session, or ignore the notification and let the session continue.

p-0068Upon session initiation, or while a session is on-going, the notification handler <b>540</b> could send, to the PDF <b>220</b>, a notification initiation message, informing the PDF <b>220</b> that the notification handler <b>530</b> would like to subscribe to notifications relating to the bearer. Alternatively, the PDF <b>220</b> could be arranged to always send any notifications to the TPRN <b>500</b>.

p-0069The notification handler <b>540</b> of TPRN <b>500</b> could preferably be arranged to determine how to act upon a notification relating to the bearer of a session. For example, the notification handler <b>540</b> could include a determination mechanism for determining whether the session should be closed when the bandwidth requirement cannot be fulfilled, or whether a triggering signal should be sent to the event handler <b>505</b> in order to trigger the selection of a new transport policy for the session. The notification handler <b>540</b> could be arranged to act as a session signalling end point (e.g. as a SIP Back-to-Back User Agent (B2BUA)). In the determination of how to act upon a notification received by the PDF <b>220</b>, notification handler <b>540</b> would take into account parameters which depend on the application by which the relevant session is being used: for example, applications using real time services, monitoring of whether a loss of bearer has occurred may be crucial, whereas for best-effort services, such monitoring may not be necessary.

p-0070The notification handler <b>540</b> could also be arranged to forward notifications from the PDF <b>220</b> to the application server system <b>225</b>, where appropriate. The application server system <b>225</b> can for example include functionality for requesting changes in the policy of the session to policy of a lower QoS level if the notification includes information that the requested QoS level cannot be fulfilled. Furthermore, if the application server system <b>225</b> acts as a SIP end point or SIP Back-to-Back User Agent (B2BUA) for the session, the application server system <b>225</b> may initiate a re-negotiation of the SIP session. This may for example be appropriate when the application of the application server system <b>225</b> to which the session relates is a video-on-demand session or a conference service session, or other real-time sessions.

p-0071In the above, the notification handler <b>540</b> is described to be arranged to receive notifications from the PDF <b>220</b>. The notification handler <b>540</b> could similarly be arranged to receive notifications from any other traffic media nodes in system <b>100</b> that are capable of transmitting notifications.

p-0072A flowchart schematically illustrating a policy requesting method performed by the inventive TPRN <b>500</b> in relation to a session is shown in <figref idrefs="DRAWINGS">FIG. 7</figref>. In step <b>700</b> of <figref idrefs="DRAWINGS">FIG. 7</figref>, a session is initiated between two end-points in a system <b>100</b>. In step <b>703</b>, relevant processes are started in event handler <b>505</b> of TPRN <b>500</b>. The procedure described by <figref idrefs="DRAWINGS">FIG. 7</figref> will be run at the same time for a plurality of different on-going sessions in the same TPRN <b>500</b>. For each of these, the events that can trigger the transport policy selection may differ from the other sessions, depending for example on which application is run on the session, the subscriptions of the involved user equipments <b>105</b>, etc. Hence, the event handler(s) that are adapted to detecting the type of triggering events that are relevant for the session initiated in step <b>700</b> will be started in step <b>703</b>. As mentioned above, a triggering event could for example be that a SIP request has been detected, that the clock has struck a particular hour, that a user equipment has entered a particular geographical region, or that a program (for example a game) that is executed by the application server system <b>225</b> has entered a particular process. For a session relating to HTTP-signalling, an event handler capable of detecting relevant HTTP signals could be started in step <b>703</b>, for a session relating to MSN messaging, an event handler capable of detecting relevant MSN signalling could be started in step <b>703</b>, etc.

p-0073Step <b>705</b> is entered, in which relevant context parameters are checked. This step could for example include selecting a workflow that applies to the triggering event detected in step <b>700</b>, and check the value of the context parameters that are relevant to the selected workflow. If the values of the context parameters are not already known, the context information handler <b>515</b> could be instructed to request such information from external nodes.

p-0074In step <b>710</b>, a transport policy is selected for the session by the transport policy selection mechanism <b>525</b>. This can for example be performed by means of a workflow of the type illustrated in <figref idrefs="DRAWINGS">FIG. 6</figref>. Based on the value of the relevant parameters—context parameters and other parameters such as subscription related parameters—a transport policy for the session is selected. The selection of transport policy could for example include assigning a quality class to the session, and identify a transport policy that has been assigned to apply to the relevant quality class. Such a quality class of a session would be dynamic in the sense that the quality class of the session might change during the life-time of the session, when other triggering events occur.

p-0075When a transport policy has been selected, the selected transport policy is requested in step <b>715</b> by sending a policy request to the PDF <b>220</b>.

p-0076Step <b>720</b> is then entered, wherein a new triggering event or session close-down is awaited, after which step <b>725</b> is entered. In step <b>725</b>, it is checked whether the session is still on-going. If not, then step <b>730</b> is entered, wherein the process is ended. However, if the session is still on-going, step <b>705</b> is re-entered.

p-0077The method illustrated above assumes that the session initiation of step <b>700</b> acts as a triggering event for transport policy selection. However, this may not always be the case, such as for example in scenarios where a default transport policy is selected for a session upon session initiation. In such cases, step <b>720</b> may be entered straight after step <b>703</b>.

p-0078The TPRN <b>500</b> can be implemented in a different node than the AF <b>215</b>, so that a system <b>100</b> comprises both a policy requesting node according to the invention and an AF <b>215</b>. An AF <b>215</b> should preferably have very efficient proxy related properties, and as such, should comprise a minimum of functionality that does not relate to the relaying of requests between the end nodes of a session. Such restrictions do not apply to the new policy requesting node when implemented separately of the AF <b>215</b>.

p-0079Furthermore, by implementing the dynamic context dependent transport policy requesting mechanism in a node which is (at least logically) separate from the AF <b>215</b>, a higher granularity of the values of different policy parameters can easily be introduced, as well as new transport policy parameters. The AF <b>215</b> is restricted to communicating session requests (e.g. in an IMS system <b>100</b>, the AF <b>215</b> is restricted to communicating SIP messages), and the introduction of new parameters or parameter values would require substantive re-design of the session signalling protocol, which is generally not desired. The SIP protocol is intended for communication between SIP end points and introducing new parameters purely intended for communication between the application server system <b>225</b> and the PEF <b>210</b> would be regarded as a violation of the SIP protocol.

p-0080When a greater variety of policies may be requested by means of a greater range of policy parameters and parameter values, the exactness of the policy enforcement can also be increased due to a possibility of applying a smaller granularity in the policy parameters, as well as a larger variety of parameters.

p-0081<figref idrefs="DRAWINGS">FIG. 8</figref> illustrates an exemplary (logical) configuration of a system <b>100</b> including both an AF <b>215</b> and a TPRN <b>500</b>. The TPRN <b>500</b> can communicate in a logically direct manner with the PDF <b>220</b> over interface <b>530</b>. Interface <b>530</b> provides an alternative connection between the application server system <b>225</b> and the PDF <b>220</b>, or, in other words, an alternative connection between the media layer and the policy determination function of system <b>100</b>. In contrast to the interface between the AF <b>215</b> and the PDF <b>220</b>, the interface <b>530</b> is not limited to communication by means of session protocols, such as SIP/SDP, for the communication of policy related information, but a more flexible format may be used. Since the TPRN <b>500</b> is not restricted by the requirements and limitations that apply to a proxy and to the SIP/SDP protocol and other session protocols, the level of detail of the policy selection function of TPRN <b>500</b> and the ability to activate the correct transport can be greater than that of the policy selection function of an AF <b>220</b>. Hence, the number of parameters (context parameters as well as other parameters) that are taken into account in the policy selection process can be greater, the number of parameters which may be included in the policy request may be greater, as may the granularity of the possible values for the parameters in the policy request.

p-0082As discussed above, the TPRN <b>500</b> has an interface <b>520</b> by which context information may be received. In <figref idrefs="DRAWINGS">FIG. 8</figref>, this is illustrated as a connection between the TPRN <b>500</b> and a context information domain <b>800</b>, of which the application server system <b>225</b> may or may not form a part.

p-0083The application server system <b>225</b> could comprise one or several application servers. Examples of different server types that can be included in an application server system <b>225</b> are Push-to-talk servers, an IP-TV servers, chat servers etc in a service server domain; content servers and content creation servers in a content server domain; billing servers, customer relationship management servers, and a digital rights management server in a business support server domain.

p-0084A TPRN <b>500</b> may have a (logically) direct interface to the application server system <b>225</b> by which interface the communication of policy related information to the PDF <b>220</b> over interface <b>530</b> may be initiated by the application server system <b>225</b>. Since the interface <b>530</b> allows the application server system <b>225</b> to initiate the communication of policy related information to the PDF <b>220</b>, the policy may in this configuration be adjusted by the application server system <b>225</b> to changes in parameters that affect the policy requirements of the service. If the session relates to gaming, a change in policy may be triggered by events in the game—for example, if a gaming scenario requires higher bandwidth than other gaming scenarios, the policy may be adjusted to the gaming scenario that is currently active. The application server system <b>225</b> can initiate transport policy selection by sending a trigger to the TPRN <b>500</b>. The possibility of communicating policy related information directly from the application server system <b>225</b> to the PDF <b>220</b> via the interface <b>530</b> facilitates for the allocation of correct media resources to the session/session part, since the media layer implemented as the application server system <b>225</b> can add, to the policy decision process, additional input parameters that are relevant for the policy decision.

p-0085In other configurations of system <b>100</b>, the TPRN <b>500</b> is arranged to act independently of the application server system <b>225</b>. In a system <b>100</b>, the TPRN <b>500</b> could be arranged to both passively await a trigger from the application server system <b>225</b> &amp; other nodes, and/or to actively search for triggers by means of for example sniffers, as discussed above.

p-0086The invention is particularly useful when the application server system <b>225</b> is based on a Service Oriented Architecture (SOA), wherein a new application can be built by combining different application components late in the design process. An application component could for example be a positioning server, a Voice over IP server, a messaging server, a push-to-talk server, etc, which preferably are involved in the control signalling in the control signalling plane <b>200</b> that is required to set up a multimedia packet flow in the traffic media plane <b>205</b>. When application components are added or deleted from a session, it may be desired to modify the resources used by the session in order to optimise the user experience or bandwidth utilization. Such modification of resources can be efficiently achieved by means of the interface <b>530</b>. According to the current IMS standard, the modification of resources of a session requires SIP signalling through the P-CSCF <b>315</b>. By means of the new interface <b>530</b>, modification of resources may be achieved via the interface <b>530</b>, and no SIP signalling is required.

p-0087<figref idrefs="DRAWINGS">FIG. 9</figref> schematically illustrates a session initiation scenario similar to that of <figref idrefs="DRAWINGS">FIG. 4</figref> for a system <b>100</b> including an AF <b>215</b> as well as a TPRN <b>500</b> having an interface <b>530</b> to the PDF <b>220</b>. As in the scenario shown in <figref idrefs="DRAWINGS">FIG. 4</figref>, the user equipment <b>105</b> is already attached to the network <b>110</b>, e.g. using a default bearer. The following events are included in the signalling diagram of <figref idrefs="DRAWINGS">FIG. 9</figref>:

p-0088<b>9</b>A: The application <b>240</b> of user equipment <b>105</b> enters, into a session initiation message, applicable values of any parameters that are necessary for running the service to be initiated, for example in an SDP or other session description protocol. Relevant parameters could for example be supported codec types, bandwidth and service type.

p-0089<b>9</b>B: A session initiation message including the applicable values is sent towards the session end point via the AF <b>215</b>.

p-0090<b>9</b>C: A session response message is received at the TPRN <b>500</b> from the end point. The session response message can include some or all of the parameters of the session initiation message, of which parameters the values may have been modified by the terminating end point.

p-0091<b>9</b>D: The TPRN <b>500</b> performs transport policy selection (cf. <figref idrefs="DRAWINGS">FIG. 7</figref>).

p-0092<b>9</b>E: A policy request is sent by the TPRN <b>500</b> to the PDF <b>220</b> over interface <b>530</b>.

p-0093<b>9</b>F: The PDF <b>220</b> sends a resource reservation request to the PEF <b>210</b>.

p-0094<b>9</b>G: A message informing the user equipment <b>105</b> of the IP CAN bearer modification is sent from the PEF <b>120</b> to the user equipment <b>105</b>.

p-0095<b>9</b>H: Acknowledgement messages are sent from the user equipment <b>105</b>, the PEF <b>210</b> and the PDF <b>220</b>.

p-0096<b>9</b>I: The TPRN <b>500</b> forwards the session response message to the user equipment <b>105</b>.

p-0097<b>9</b>J: The TPRN <b>500</b> initiates the event handler(s) that are relevant to the initiated session (cf. step <b>703</b> in <figref idrefs="DRAWINGS">FIG. 7</figref>).

p-0098In the signalling diagram of <figref idrefs="DRAWINGS">FIG. 9</figref>, the triggering event for the TPRN <b>500</b> to generate a policy request is session initiation signalling. Whether the transport policy selection of event <b>9</b>D is triggered by the receipt of the session initiation message or the session response message is of no importance—both alternatives could be implemented. As discussed above, the policy request can also be triggered by a great variety of events other than session initiation signalling—and the events that can trigger a policy request may vary from session to session. In response to the event handler <b>505</b> of a TPRN <b>500</b> detecting any policy request triggering event, the events of <figref idrefs="DRAWINGS">FIG. 9</figref> referred to as events <b>9</b>D-<b>9</b>H would be executed.

p-0099The event <b>9</b>D, in which the TPRN <b>500</b> performs transport policy selection, would typically include signalling between the TPRN <b>500</b> and nodes in the application server system <b>225</b>, in order to determine values of context parameters relevant to the session. Such signalling is illustrated by the events <b>9</b>Da: context request, and <b>9</b>Db: Context response.

p-0100A comparison of the signalling diagrams of <figref idrefs="DRAWINGS">FIGS. 4 and 9</figref> shows that the amount of signalling required in the two scenarios are similar, and hence, the advantages of the scenario of <figref idrefs="DRAWINGS">FIG. 9</figref> can be achieved without any delay in set up time as compared to the scenario of <figref idrefs="DRAWINGS">FIG. 4</figref>.

p-0101The policy request of event <b>9</b>E is transmitted over the interface <b>530</b> (as opposed to the prior art scenario illustrated in <figref idrefs="DRAWINGS">FIG. 4</figref>, where the policy request is transmitted over the Rx-interface <b>245</b>, which in an IMS-based system <b>100</b> would be the Rx interface <b>345</b>). An interface <b>245</b> between an AF <b>215</b> and a PDF <b>220</b> is generally standardised to support the transmission of a limited number of parameters. However, such limitations do not apply to the interface <b>530</b>.

p-0102In order to minimise the required re-design of the PDF <b>220</b>, the protocol used for signalling over the interface <b>530</b> could advantageously be based on the prior art protocol used for signalling over the interface <b>245</b>. In a system using the IMS standard, the protocol used for signalling over the interface <b>530</b> could advantageously be based on the Rx protocol. However, as mentioned above, it would often be advantageous to increase the number of policy related parameters in the policy request, and/or increase the granularity of the values of already existing parameters. Therefore, an extended version of the protocol used for signalling over interface <b>245</b> could advantageously be used for signalling over interface <b>530</b>.

p-0103Below, a list of possible attributes of a policy request message in accordance with such an extended protocol is given: <ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0103">Transfer delay in the media plane (can for example indicate the maximum transfer delay allowed for a certain percentile of the packets)</li><li id="ul0002-0002" num="0104">Reliability (can for example indicate the probability that packets will not be lost)</li><li id="ul0002-0003" num="0105">Maximum resource costs (can for example give a relative value of the cost of transfer for a certain volume of traffic on the selected resources (e.g. Low/Medium/High))</li><li id="ul0002-0004" num="0106">Mobility requirements (handover efficiency, for example expressed as “seamless”/“session continuity but some interrupt is ok”/“mobility not required”)</li><li id="ul0002-0005" num="0107">Application Identifier (e.g. Class of Service Indicator (CSI))</li><li id="ul0002-0006" num="0108">Codec type</li><li id="ul0002-0007" num="0109">Type Of media (e.g. voice/video/text)</li><li id="ul0002-0008" num="0110">Codec data (e.g. AMR/G.711 . . . )</li><li id="ul0002-0009" num="0111">Flow usage</li><li id="ul0002-0010" num="0112">Requested Access Type (e.g. (Robust Audio Ttool (RAT)/Intelligent Wireless Local Area Network (I-WLAN)/Long Term Evolution (LTE)/Digital Subscriber Line (x-DSL), etc)</li><li id="ul0002-0011" num="0113">Requested Bandwidth (“bit error on maximum bandwidth”/“max and min of Guaranteed bandwidth”)</li><li id="ul0002-0012" num="0114">Charging identifier</li><li id="ul0002-0013" num="0115">Reservation Priority</li><li id="ul0002-0014" num="0116">Flow status (Gating)</li><li id="ul0002-0015" num="0117">UE destination IP address+port</li><li id="ul0002-0016" num="0118">Expiry of the requested policy.</li><li id="ul0002-0017" num="0119">Etc.</li></ul></li></ul>

p-0104The introduction of one or several of the above listed attributes into a policy request would result in an extended policy request by which the flexibility of the policy assignment could be enhanced.

p-0105One of the examples in the list above of attributes that could be included in a policy request <b>9</b>E is the expiry of the requested policy. By including information on expiry of the requested policy in the policy request, the amount of signalling in the network <b>110</b> can be reduced. The expiry could for example be expressed as a time period, or in terms of an event at the occurrence of which the requested policy should cease to be valid. When the policy request <b>9</b>E includes information on expiry of the requested policy, the policy request could also include information on which policy should apply when the requested policy expires. Alternatively, the PDF <b>220</b> could be arranged to apply a default transport policy upon expiry of a requested policy.

p-0106Furthermore, some of the functionality that according to the prior art located in the PDF <b>220</b> could be moved to the TPRN <b>500</b>, such as for example the identification of an applicable QCI value. In this case, an attribute representing the QCI would be included in the extended protocol used over interface <b>530</b>.

p-0107The number and complexity of the attributes used for policy requests on the interface <b>530</b> may be adapted according to implementation needs. For example, a policy database (cf. database <b>355</b> of <figref idrefs="DRAWINGS">FIG. 3</figref>) or translation table may be used in order to simplify the policy request, so that less attributes are required—in fact, only one attribute that defines a policy class may be used.

p-0108The functionality of the TPRN <b>500</b> could be co-located with any of the other nodes in system <b>100</b>—in an IMS-based system <b>100</b>, such nodes could for example be the S-CSCF <b>325</b>, or any of the application servers in application server system <b>225</b>. However, by implementing the TPRN functionality in a separate logical node, S-CSCF <b>325</b>, which is standardised nodes, does not have to be altered. Furthermore, since an application server system <b>225</b> may have more than one application server and only one TPRN <b>500</b> required, having the TPRN <b>500</b> as a separate node provides a simpler solution than co-locating the TPRN <b>500</b> with an application server.

p-0109In a system <b>100</b> implementing the invention, it is likely that the policy decision for some services best be initiated by the AF <b>215</b> according the prior art (cf. <figref idrefs="DRAWINGS">FIG. 4</figref>), whereas the policy decision for other services best be initiated by the application server system <b>225</b> (cf. <figref idrefs="DRAWINGS">FIG. 9</figref>). In order for the AF <b>220</b> to distinguish between these two cases upon initiation of a session by a user equipment <b>105</b> or other end node, a flag or other means of notifying the AF <b>220</b> whether or not the policy decision shall be initiated by the AF <b>220</b> could advantageously be included in the session invitation message sent from the initiating end point to the AF <b>220</b>.

p-0110An example of a session initiation message <b>1000</b> comprising an AF policy decision flag <b>1010</b> as a policy decision indicator is illustrated in <figref idrefs="DRAWINGS">FIG. 10</figref><i>a</i>. The message <b>1000</b> further comprises a header <b>1005</b> and other info <b>1015</b> relating to the session initiation. When an application <b>240</b> of a user equipment <b>105</b> generates a session initiation message, the policy AF policy decision flag of the session initiation message is set to the value appropriate for the session to be set-up.

p-0111Alternatively, a parameter or combination of parameters in the other info <b>1015</b> of message <b>1000</b> could be used as the AF policy decision indicator, such as for example a Class Service Indicator (CSI), or similar service identifier in the session initiation message. The AF <b>220</b> could store information relating to for which services the AF <b>220</b> should initiate the policy decision, and/or for which services the policy decision should be initiated by the application server system <b>225</b>. Such information could for example be a list of the service identifiers of the services for which the AF <b>220</b> should or should not initiate the policy decision.

p-0112<figref idrefs="DRAWINGS">FIG. 10</figref><i>b </i>is a flowchart that schematically illustrates the process in the AF <b>220</b> used for determining whether or not the policy decision should be initiated by the AF <b>220</b>. In step <b>1050</b>, a session initiation message, or a session initiation response message, is received (depending on whether the policy decision is triggered by the session initiation message or the session initiation response message). Step <b>1055</b> is then entered, in which it is checked whether the AF policy decision indicator indicates that the AF <b>220</b> should initiate the policy decision. If so, step <b>1060</b> is entered, in which the AF <b>220</b> initiates the policy decision. Step <b>1065</b> is then entered, in which a policy request is forwarded to the appropriate node. If the AF policy decision indicator indicates that the policy decision should not be made by the AF <b>220</b>, step <b>1060</b> is never entered, but step <b>1065</b> is entered directly after step <b>1050</b>.

p-0113The functionality of the TPRN <b>500</b> could be co-located with any of the other nodes in system <b>100</b>—in an IMS-based system <b>100</b>, such nodes could for example be the S-CSCF <b>325</b>, or any of the application servers in application server system <b>225</b>. However, by implementing the TPRN functionality in a separate logical node, S-CSCF <b>325</b>, which is standardised nodes, does not have to be altered. Furthermore, since an application server system <b>225</b> may have more than one application server and only one TPRN <b>500</b> required, having the TPRN <b>500</b> as a separate node provides a simpler solution than co-locating the TPRN <b>500</b> with an application server.

p-0114One skilled in the art will appreciate that the present invention is not limited to the embodiments disclosed in the accompanying drawings and the foregoing detailed description, which are presented for purposes of illustration only, but it can be implemented in a number of different ways.