This invention relates to signalling within a packet-based communications system to establish a connection.
Communications networks are increasingly being used to deliver a range of multimedia communications traffic via packet-based delivery protocols.
It 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.
The present invention seeks to provide an alternative architecture which is more efficient.
A 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:
receiving information about the required connection;
sending, to the policy server, application control related information for the required connection;
receiving, from the policy server, at least one application control parameter selected by the policy server.
By 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.
The 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.
Further 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.
The 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.
Embodiments of the invention will be described with reference to the accompanying drawings in which:
Referring again to
Endpoints 10, 20 can be terminals which support a packet-based connection. Alternatively, endpoints 10, 20 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 30.
An Application Manager 40 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 40 communicates 15, 25 with end points 10, 20 using a signalling protocol such as the Session Initiation Protocol (SIP).
The Application Manager 40 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 40 determines the particular QoS parameters necessary to deliver the service to the client, based on its knowledge of the requested service. The Application Manager 40 communicates with a Policy Server 50 across an interface 45. The Application Manager 40 sends a request for the required resources to the appropriate Policy Server 50 via interface 45. The Policy Manager 50 may deny the request, based on network policies, or it may process (forward) the request to entities within network 30. This process can include communicating 35, 36 with Policy Enforcement Points (PEPs) 31, 32 that are responsible for admission control and enforcement. A connection between endpoints 10, 20 may require the policy server 50 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.
Policy Enforcement Points (PEPs) 31, 32 within the network 30 act as gates, allowing certain traffic flows to pass. As part of a call establishment process, policy server 50 communicates with PEPs to ensure that sufficient resources are available to meet the request received from the Application Manager 40. If resources are available, then the Policy Server 50 returns an acknowledgement message to the Application Manager 40 across interface 45. A communication path is then established between the endpoints 10, 20 which includes path 12, between client 10 and PEP 31, a path across network 30, and a path 22 between PEP 32 and the remote client 20.
Various protocols have been proposed for use across interface 45 between the Application Manager 40 and Policy Sever 50.
Operation of the network using COPS messaging on interface 45 will now be described in more detail. Conventionally, COPS sends information on a per-flow basis. A requested service between endpoints 10, 20 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 40 receives parameters of the requested service, the capabilities of the endpoints 10, 20, and determines what bandwidth is required. Application Manager 40 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 10, 20 and choosing a preferred combination (often, but not necessarily, a codec common to both endpoints 10, 20 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.
Policy Server 50 verifies each request against network policies, determines whether network resources are available to meet the request and replies to the Application Manager 40 with an acknowledgement message.
In accordance with an embodiment of the invention, the Application Manager 40 issues a request across interface 45 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 40 does not select the preferred codec itself, but passes a list of supported codecs to the Policy Sever 50. 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.
The Policy Server 40 inspects the codec information and submits a request for resources based on a particular policy.
As the Policy Server 50 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 30 can support the group of flows, the Policy Server 50 returns an acknowledgement message to the Application Manager 40. The acknowledgement includes a codec, selected by the Policy Server 50, which is appropriate for the bandwidth reserved on network 30. 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 50 can adjust the resource reservation by choosing appropriate codecs for each flow. This is more efficient than repeated signalling exchanges between the Application Manager 40 and Policy Server 50 across interface 45 which specify single bandwidth values on a per-flow basis.
In accordance with an embodiment of the invention, the Policy Server 50 also takes part in Media Proxy control.
The above description refers to COPS. Standards bodies in other areas have considered other kinds of protocol for the interface 45 between the Application Manager 40 and Policy Server 50.
In a further alternative of the invention, a Session Initiation Protocol (SIP) invite message is sent between the Application Manager 40 and the Policy Server 50 to pass application (call) control to the Policy Server. SIP messages carry application control related information to the Policy Server 50, which the Policy Server 50 can use to make selections of application control parameters.
The invention is not limited to the embodiments described herein, which may be modified or varied without departing from the scope of the invention.