Application control at a policy server

FIELD OF THE INVENTION

0001This invention relates to signalling within a packet-based communications system to establish a connection.

BACKGROUND TO THE INVENTION

0002Communications networks are increasingly being used to deliver a range of multimedia communications traffic via packet-based delivery protocols.

0003It is generally preferred that packet-based networks use some form of admission control which controls access to the shared network and helps to maintain a particular quality of service (QoS) for the traffic that is permitted access to the network. Admission control can be performed by policy controllers in the network, with enforcement occurring at policy enforcement points (PEP). Admitted traffic can also be policed by the PEP, during the duration of a connection, to ensure that the parameters agreed at the beginning of the connection are adhered to.

0004<figref idref="DRAWINGS">FIG. 1</figref> shows a communications system which is based around a packet-based network <b>30</b>. Terminals <b>10</b>, <b>20</b> are connected to network <b>30</b> via policy enforcement points, such as media gateways or routers, which police connections. When setting up a connection across a packet-based network, signalling <b>15</b> occurs between an endpoint <b>10</b> and an Application Manager <b>40</b>. The Application Manager <b>40</b> determines capabilities of the endpoints <b>10</b>, <b>20</b>, such as the types of codec that each endpoint supports. The Application Manager <b>40</b> makes a selection of certain parameters (e.g. selecting what it determines is the best codec and hence bandwidth for the connection) and submits a connection request to the policy server <b>50</b>. The policy server <b>50</b> determines whether a connection, with the requested parameters, can be supported and returns a reply to the Application Manager. If the connection cannot be supported, then the Application Manager <b>40</b> can either submit a further connection request or it can return an error message to the endpoint <b>10</b>. If the connection cannot be supported then further requests can be submitted by the Application Manager, which can result in a high volume of signalling messages between the Application Manager and policy server.

0005The present invention seeks to provide an alternative architecture which is more efficient.

SUMMARY OF THE INVENTION

0006A first aspect of the present invention provides a method of establishing a connection between first and second endpoints in a packet-based communication system which comprises an application manager and a policy server, the method comprising, at the application manager:

0007receiving information about the required connection;

0008sending, to the policy server, application control related information for the required connection;

0009receiving, from the policy server, at least one application control parameter selected by the policy server.

0010By sending application control information to the policy server, such as the list of codecs available at the endpoints, the policy server can use this information to decide certain application control parameters relating to the connection, such as selecting which codecs should be used by the endpoints. Making application control selections at the policy server, rather than at the application manager, can significantly reduce signalling between the application manager and the policy server compared to existing methods. This is because the policy server is better placed to make the selection.

0011The application control information can be carried between the application manager and policy server in various ways. The information can be carried by an application control protocol, such as the Session Initiation Protocol (SIP), or it can be carried by modified forms of policy control protocols such as the Common Open Policy Service (COPS), Diameter, SOAP/XML or Parlay. Conventionally, application control protocols are not used to interface with a policy server, and policy control protocols do not carry application control parameters such as a list of supported codecs.

0012Further aspects of the invention relate to a method performed by a policy server. Still further aspects of the invention relate to an application manager and a policy server which implement these methods.

0013The functionality described here can be implemented in software, hardware or a combination of these. Accordingly, further aspects of the invention provide a computer program product for implementing any combination of the steps of the methods according to the invention. It will be appreciated that the software can be installed on the host apparatus (e.g. the application manager or policy server) at any point during the life of the equipment. The software may be stored on an electronic memory device, hard disk, optical disk or other machine-readable storage medium. The software may be delivered as a computer program product on a machine-readable carrier or it may be downloaded directly to the host via a network connection.

BRIEF DESCRIPTION OF THE DRAWINGS

0014Embodiments of the invention will be described with reference to the accompanying drawings in which:

0015<figref idref="DRAWINGS">FIG. 1</figref> shows a generalised architecture of a packet-based communications system;

0016<figref idref="DRAWINGS">FIG. 2</figref> shows an equivalent architecture to <figref idref="DRAWINGS">FIG. 1</figref> for a PacketCable system;

0017<figref idref="DRAWINGS">FIG. 3</figref> shows the network of <figref idref="DRAWINGS">FIG. 1</figref> with the addition of media proxy control;

0018<figref idref="DRAWINGS">FIG. 4</figref> shows an equivalent architecture to <figref idref="DRAWINGS">FIG. 1</figref> for a 3G wireless system;

DESCRIPTION OF PREFERRED EMBODIMENTS

0019Referring again to <figref idref="DRAWINGS">FIG. 1</figref>, this shows a general overview of a system which includes a packet-based network <b>30</b>. Although not shown, network <b>30</b> includes routers which are interconnected by communication links in a conventional manner. The network <b>30</b> can be implemented by wireline, wireless or a combination of both wireline and wireless technologies. Although shown as one overall network, network <b>30</b> can comprise a number of individual networks which are interconnected. Several specific architectures for PacketCable and 3G wireless networks are described later, and these share the same general features shown here.

0020Endpoints <b>10</b>, <b>20</b> can be terminals which support a packet-based connection. Alternatively, endpoints <b>10</b>, <b>20</b> can be Media Gateways which perform conversion between the circuit-switched domain, which is used to serve terminals (such as conventional telephone terminals) local to the gateway, and the packet-switched domain used across network <b>30</b>.

0021An Application Manager <b>40</b> is a network entity which defines service control policies and co-ordinates subscriber-initiated requests for application sessions with access to the network resources that are required to meet those requests. The Application Manager <b>40</b> communicates <b>15</b>, <b>25</b> with end points <b>10</b>, <b>20</b> using a signalling protocol such as the Session Initiation Protocol (SIP).

0022The Application Manager <b>40</b> authenticates and authorizes client requests based on Service Control Domain policies. This ensures that clients making a request are entitled to use the requested services. For client requests that pass these checks, the Application Manager <b>40</b> determines the particular QoS parameters necessary to deliver the service to the client, based on its knowledge of the requested service. The Application Manager <b>40</b> communicates with a Policy Server <b>50</b> across an interface <b>45</b>. The Application Manager <b>40</b> sends a request for the required resources to the appropriate Policy Server <b>50</b> via interface <b>45</b>. The Policy Manager <b>50</b> may deny the request, based on network policies, or it may process (forward) the request to entities within network <b>30</b>. This process can include communicating <b>35</b>, <b>36</b> with Policy Enforcement Points (PEPs) <b>31</b>, <b>32</b> that are responsible for admission control and enforcement. A connection between endpoints <b>10</b>, <b>20</b> may require the policy server <b>50</b> to communicate with a larger number of PEPs, particularly if the connection spans several differently owned/operated networks. Policy decisions can be based on a number of factors, such as: parameters associated with the request and the status of available resources; the identity of the particular client and associated profile information; application parameters; security considerations.

0023Policy Enforcement Points (PEPs) <b>31</b>, <b>32</b> within the network <b>30</b> act as gates, allowing certain traffic flows to pass. As part of a call establishment process, policy server <b>50</b> communicates with PEPs to ensure that sufficient resources are available to meet the request received from the Application Manager <b>40</b>. If resources are available, then the Policy Server <b>50</b> returns an acknowledgement message to the Application Manager <b>40</b> across interface <b>45</b>. A communication path is then established between the endpoints <b>10</b>, <b>20</b> which includes path <b>12</b>, between client <b>10</b> and PEP <b>31</b>, a path across network <b>30</b>, and a path <b>22</b> between PEP <b>32</b> and the remote client <b>20</b>.

0024Various protocols have been proposed for use across interface <b>45</b> between the Application Manager <b>40</b> and Policy Sever <b>50</b>. <figref idref="DRAWINGS">FIG. 2</figref> shows a system according to the PacketCable Multimedia Specification (PKT-SP-MM-I01-030627). A cable modem <b>110</b> equates to the endpoint <b>10</b>. The interface <b>15</b> between the cable modem <b>110</b> and the Application Manager <b>40</b> is called the ‘pkt-mm7’ interface and the interface <b>45</b> between the Application Manager <b>40</b> and Policy Server <b>50</b> is called the ‘pkt-mm-3’ interface. It has been recommended that the Common Open Policy Service (COPS) is used across the pkt-mm3 interface <b>45</b>. The Common Open Policy Service (COPS) is defined in RFC 2748, to which the skilled reader is directed for further information. Policy Server <b>50</b> communicates with a Cable Modem Termination System (CMTS) <b>130</b> via a ‘pkt-mm2’ interface <b>135</b> using COPS. CMTS <b>130</b> authorizes resource requests.

0025Operation of the network using COPS messaging on interface <b>45</b> will now be described in more detail. Conventionally, COPS sends information on a per-flow basis. A requested service between endpoints <b>10</b>, <b>20</b> may comprise several related flows of traffic. As an example, a video conferencing service will include conversational voice, real-time video and data representing slides to be discussed during the conference. As part of a connection establishment process, Application Manager <b>40</b> receives parameters of the requested service, the capabilities of the endpoints <b>10</b>, <b>20</b>, and determines what bandwidth is required. Application Manager <b>40</b> individually issues requests for each of the required flows, even if they are related to one another as part of a common service. Each request includes information about the required bandwidth, QoS and Class of service. The required bandwidth is determined by finding the codecs available at each endpoint <b>10</b>, <b>20</b> and choosing a preferred combination (often, but not necessarily, a codec common to both endpoints <b>10</b>, <b>20</b> which offers the best quality (greatest bandwidth)). Once the codec has been selected, this is translated into a required bandwidth which is used in the request. To give several examples, a G.711 codec with a packetisation rate of 10 ms over an IP transmission network has a bandwidth requirement of 102 kbps whereas a G.729 codec with the same 10 ms packetisation rate over an IP transmission network has a bandwidth requirement of 46 kbps.

0026Policy Server <b>50</b> verifies each request against network policies, determines whether network resources are available to meet the request and replies to the Application Manager <b>40</b> with an acknowledgement message.

0027In accordance with an embodiment of the invention, the Application Manager <b>40</b> issues a request across interface <b>45</b> which includes information for the group of related flows. This can be carried by a modified form of COPS messaging. This allows the Policy Server to consider all of the related flows (e.g. voice, video and data) at the same time, and to request/reserve network resources based on the combination of flows. In addition, the Application Manager <b>40</b> does not select the preferred codec itself, but passes a list of supported codecs to the Policy Sever <b>50</b>. The list of codecs can be a list of codecs which is common to both endpoints (i.e. the AS looks at the codecs supported by both endpoints and only sends these), or it can be the list of codecs supported by each endpoint.

0028The Policy Server <b>40</b> inspects the codec information and submits a request for resources based on a particular policy.

0029As the Policy Server <b>50</b> interacts with the network entities responsible for reserving bandwidth, it is better placed to make a decision on what bandwidth can be supported by the network and hence what codecs can be used. If the network <b>30</b> can support the group of flows, the Policy Server <b>50</b> returns an acknowledgement message to the Application Manager <b>40</b>. The acknowledgement includes a codec, selected by the Policy Server <b>50</b>, which is appropriate for the bandwidth reserved on network <b>30</b>. If there is more than flow, then the acknowledgement includes a selected codec for each flow. By considering a set of related flows together, and knowing the candidate codecs for each flow, the Policy Server <b>50</b> can adjust the resource reservation by choosing appropriate codecs for each flow. This is more efficient than repeated signalling exchanges between the Application Manager <b>40</b> and Policy Server <b>50</b> across interface <b>45</b> which specify single bandwidth values on a per-flow basis.

0030In accordance with an embodiment of the invention, the Policy Server <b>50</b> also takes part in Media Proxy control. <figref idref="DRAWINGS">FIG. 3</figref> shows a similar network to <figref idref="DRAWINGS">FIG. 1</figref>, with the addition of a Media Proxy <b>70</b> within network <b>30</b>. As part of the connection establishment process, Application Manager <b>40</b> sends the address and port(s) of the endpoints <b>10</b>, <b>20</b> of the requested connection to the Policy Server <b>50</b>. Policy Server <b>50</b> selects a suitable media proxy <b>35</b> for the requested flow(s) and passes an address and port of the media proxy <b>70</b> that should be used by the endpoints <b>10</b>, <b>20</b>. The reason for doing this is because the Policy Server <b>50</b> has a view of the network which the application server does not, so it can select the optimal media proxy based on available resources (e.g. bandwidth).

0031The above description refers to COPS. Standards bodies in other areas have considered other kinds of protocol for the interface <b>45</b> between the Application Manager <b>40</b> and Policy Server <b>50</b>. <figref idref="DRAWINGS">FIG. 4</figref> shows a Third Generation (3G) wireless network. An endpoint is represented by a Session Initiation Protocol (SIP) client <b>310</b>. The Application Manager <b>40</b> is represented by a Proxy Call Session Control Function (P-CSCF) <b>340</b> which performs a similar function of authenticating a user's requests for services. The interface between the P-CSCF 340 and Policy Server <b>50</b> is called the Gq interface. Further information about the Gq interface can be found in the documents: 3^rdGeneration Partnership Project; Technical Specification Group Services and System Aspects; End-to-end Quality of Service (QoS) concept and architecture (3GPP TS 23.207) and 3^rdGeneration Partnership Project; Technical Specification Group Core Network; Policy control over Gq interface (3GPP TS 29.209). The 3GPP intend to use the Diameter protocol for the Gq interface, having considered the protocols SOAP/XML, COPS and Parlay. In the same manner as described above for COPS, the Diameter protocol similarly lacks support for passing call control information such as codec types between the Application Manager <b>40</b> and Policy Server <b>50</b>.

0032In a further alternative of the invention, a Session Initiation Protocol (SIP) invite message is sent between the Application Manager <b>40</b> and the Policy Server <b>50</b> to pass application (call) control to the Policy Server. SIP messages carry application control related information to the Policy Server <b>50</b>, which the Policy Server <b>50</b> can use to make selections of application control parameters.

0033The invention is not limited to the embodiments described herein, which may be modified or varied without departing from the scope of the invention.