End-to-end capacity and priority management through multiple packet network segments

Abstract

Apparatus and method for management of a communications network are provided. An exemplary method includes receiving at a first network a notice of an intended communication to a called party network, wherein the intended communication requires at least one resource for supporting a streaming data protocol between a calling party network and the called party network; verifying resource availability of at least one resource in the first network; and in parallel with said verifying, forwarding the notice of an intended communication to a second network and toward the called party network prior to receiving an indication of resource availability of the at least one resource in the first network required for the intended communication.

Description

FIELD OF THE INVENTION

The invention relates to the field of communication systems, and, more specifically, to a resource control and policy-based management mechanisms adapted to implement services including priority services.

BACKGROUND INFORMATION

Often, a call may go through several service provider networks in order to connect from a calling party to a called party. Each service provider's network may include several domains (or administrative boundaries). In Time Division Multiplexed (TDM) Networks, resource clearance using signaling messages is supported through serial resource clearance on a link-by-link basis. In the serial (or sequential) case, no node transmits a message until first obtaining resource clearance within its domain. Accordingly, the total time required to set up a call or session with a link-by-link signaling method is O (τt_i) where t_i represents the time it takes for resource clearance in the i-th link.

Priority services is the name given to preferred treatment of certain kinds of traffic (e.g., media/data and signaling) over other kinds of traffic in, for example, the context of civilian or defense communication networks. Priority in a public switched telephone network (PSTN) is performed on a switch by switch basis. Calls for priority users, such as government entities pass through switches while non-priority traffic is blocked.

Three kinds of priority services exist as present; namely, wireless priority service (WPS), Government emergency telecommunications services (GETS) by national communications systems (NCS) and multi-level precedents preemption (MLPP) by the United States Department of Defense.

GETS provides an ability to preempt calls at a lower priority than MLPP. GETS also provides for buffer-type queuing of a call such that the call will be the first call to pass when a necessary resource becomes available. Call control functionality includes the decision of choosing which call to allow and which call to preempt. Resource control and policy-based management functionality includes the decision of when to preempt a call or when to buffer-type queue a call.

Within the context of voice, video and other data communications (e.g., multimedia communications and the like) via packet based networks (e.g., Ethernet, etc.) resource clearance is handled on a sequential basis. Methods for preemption and priority handling of voice calls and multimedia services are also lacking in packet based networks.

SUMMARY OF THE INFORMATION

A network element, apparatus and method for combining call admission control and priority services within different type of networks is provided. A logical functional entity denoted as a Priority Services Functional Element (PSFE) enables administration of priority services and call or session admission control policies through interactions with Call Session Control Function Element (CSCF) and Resource Access Control Facilities (RACF). Method steps in exemplary embodiments may include verifying the priority levels, receiving resource availability information, storing call admission and resource allocation information, identifying path and link information required for an originated session, checking available resources at links against required resources for the call or session establishment, and communicating resource availability indication/s (or lack thereof) based on admission control policies after resource verification.

The PSFE allows for capacity and priority management in parallel over all the links in the bearer path within a particular network. PSFEs in different networks can also communicate to enable PSFEs in each network in the path to perform resource clearance independently and in parallel (i.e., undertaking apparent or actual performance of more than one operation at a same time). Proposed methods allow both kinds of parallelization in networks of different architectures, such as IMS and SIP, and also across varied networks. The PSFE introduces obtaining parallel resource clearance across network boundaries, including heterogeneous networks. In this manner, calls or sessions may be established efficiently, and varied features provided in a multi-media network.

PSFE may use Session Initiation Protocol (SIP) messages to communicate with Signaling and Service Layer entities, such as Proxy (P-) or Interrogating (I-) CSCFs, Subscriber Information Databases (e.g., Home Subscriber Server or HSS), and Application Servers (AS). PSFE may also communicate with Transport Layer entities (such as, RACF in an all IMP Multimedia Subsystems (IMS) architecture) using, for example, Diameter messages. However, PSFE may integrate both IMS and non-IMS Next Generation Service Provider (NGSP) networks and enable efficient resource verification and allocation in the non-IMS NGSP also. Further, the PSFE may also determine resource availability using open loop control or other accounting methods in a network without a RACF.

Parallel resource clearance is useful in establishing various multi-media services in all IP-based networks regardless of the types of users and may be utilized in Enterprise, Commercial Service Provider, Civilian Government, and Military network segments of IP networks. In context of priority services, such a PSFE can provide higher priority to priority service users and queue such users' requests for resource availability ahead of resource needs from other, routine users. Priority session requests and associated priority levels can be identified by the PSFE, for example, through Resource Priority Headers (RPH) in the SIP message. It is important to note that to queue priority sessions ahead of routine sessions, no routine session can be allowed in any of the links in the priority session path. Coordination of such activities across multiple network segments, which is quite complex among CSCFs, Back to Back user Agents (B2BUAs), and Session Border Controllers (SBCs) in separate network segments, can be achieved via communicating PSFEs deployed in these segments.

Apparatus and method are provided for capacity and priority management of a communications network for use in a system having a plurality of networks. An exemplary method includes receiving at a first network a notice of an intended communication to a called party network, wherein the intended communication requires at least one resource of the first network for supporting a streaming data protocol between a calling party network and the called party network. In parallel, resource availability of at least one resource in the first network is verified and the notice of an intended communication is forwarded to a second network and toward the called party network prior to receiving an indication of resource availability of the at least one resource in the first network required for the intended communication. For example, resource availability of resources necessary for the intended communication are not queried and reserved sequentially from calling to called party but query and reservation of necessary resources occurs simultaneously or near simultaneously.

The indication of resource availability may include an indicator of resource sufficiency associated with the intended communication. Verifying resource availability of at least one resource in the first network may include reserving the resource if the resource is available. In further embodiments, the indication of resource availability of a predetermined resource required at the second network for the intended communication is received at the first network and a re-invite for the intended communication may be forwarded to the second network and toward the called party network in the event the indication of resource availability indicates resource availability for resources in each network from the calling party network to the called party network.

In another embodiment, if transit network is interposed the first network and the second network, a request is forwarded to the transit network for verifying with the transit network a predetermined Service Level Agreement (SLA) and that the SLA assures at least one requirement of the intended communication; resource availability information for the transit network is received; and a re-invite of the intended communication forwarded to the second network and toward the called party network in the event the first indication, the second indication and the resource availability information for the transit network signify resource availability for at least one resource in each network from the calling party network to the called party network. Since the calling party forwards a ringing message in response to a re-invite, in the event of receipt of a ringing message, a lock message may be forwarded. The lock message instructs use of the at least one resource verified in the first network for the intended communication.

In one embodiment, the method includes receiving at a first network a notice of intended communication from a calling party network to a called party network; determining resource availability information for the first network in response to said receiving; and reserving a resource within the first network in the event of resource availability based on the resource availability information for the first network. In parallel with the determining step and in response to said receiving, the notice is forwarded toward the called party network prior to completion of said determining resource availability information for the first network. Further, resource availability information is received for at least one other network associated with the intended communication in the event of resource availability for the other network/s associated with the intended communication and a resource availability message forwarded based on the resource availability information for the first network and the resource availability information for the other network/s indicating resource availability for the intended communication.

In embodiments, the resource availability message may be forwarded within the first network, fed-forward to the second network and fed-backward toward the calling party network. In one embodiment, resource availability is verified via at least one of an open loop control and an accounting based control. In another, the network includes a resource access control function (RACF) through which resource availability information is obtained. A transit network that provides bulk transport services and does not specifically support any individual call or session related characteristics may be interposed the first network and the second network for supporting a streaming protocol therebetween. In that embodiment, resource availability is verified for the intended communication via consult with a Service Level Agreement (SLA) with the transit network in relation to at least one requirement of the intended communication.

Based on the resource availability message, the network may forward a SDPReoffer message or a re-invitation message. In response to receiving a ringing message, reserved resources may be locked. In embodiments in which the notice of intended communication includes a priority indicator, verification of resource availability for a second intended communication having a priority indicator less than or equal to a priority indicator for a first intended communication may be prevented while verifying resource availability for the first intended communication.

One exemplary apparatus includes a session control functional element (CSCF) and a priority service functional element (PSFE). The CSCF is adapted to receive a notice of an intended communication from a calling party network to a called party network, request resource availability information for the first network in response to the notice, and propagate the notice of intended communication toward the called party network prior to receiving corresponding resource availability information for the intended communication. The PSFE is adapted to verify for the intended communication the resource availability information for the first network in response to a request, receive resource availability information for at least one other network supporting the intended communication, forward corresponding resource availability information to the CSCF, and store resource allocation information. The PSFE reserves a resource within the first network in response to verifying resource availability for the first network. The PSFE also forwards the corresponding resource availability information to the CSCF in the event the resource availability information for the first network and the resource availability information for the at least one other network indicate the intended communication has resource availability.

In one embodiment, the CSCF transmits a re-invite message for the intended communication in the event the corresponding resource availability information indicates resource availability for each network from the calling party network to the called party network.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 depicts a network topology for facilitating calls through various networks according to an embodiment of the invention;

FIG. 2 depicts an overview of a network topology for facilitating calls through an exemplary network according to an embodiment of the invention; and

FIG. 3 depicts a flow diagram of an exemplary routine according to embodiments in accord with the invention.

To facilitate understanding, identical reference numerals have been user, where possible, to designate identical elements that are common to the figures.

DETAILED DESCRIPTION

The subject invention will be primarily described within the context of voice calls. However, since the subject invention is directed to the broader issues of multimedia services (including voice calls) references to calls and communications within this specification should be broadly construed to include voice, video, audio, email and other multimedia communications.

Specific structural and functional details disclosed herein are merely representative for purposes of describing example embodiments. Example embodiments may, however, be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein.

The subject invention enables the establishment and management of VoIP traffic, including traffic of different priority levels, in a network (for example an Internet Protocol (IP) network) with parallel resource clearance and monitoring of criteria indicative of importance of a new voice call entering the network, network capability and instantaneous load. Accordingly, an exemplary telecommunications system is described as one potential environment in which a subject invention operates and exists.

Generally speaking, the invention assists in enabling the following system and network characteristics: (1) A profitable uniform architecture that addresses the requirements for both DoD and NCS; (2) A minimization in the overlap functionality in terms of development and maintenance of priority service features; (3) A minimization of the impact on existing architectures; (4) Addressing the requirements of IMS as well as non-IMS environments; (5) An ability to add on priority service at any time by a network provider; (6) An interoperability with network solutions of multiple vendors; (7) An ability to pass priority calls earlier than routine calls, when a congestion has been cleared and ability to maintain “current gets/wps voice functionality” which may require an ability to mimic priority signal queuing from a TDM environments; (8) An adaptation to IMS and non-IMS based Next Generation networks; (9) An ability to extend and support, at least architecturally, multimedia applications and mid-call features for priority services in the future; and (10) the providing of call admission control.

The present invention provides for a logical functional entity denoted as a priority services functional element (PSFE) that integrates with both IMS and non-IMS networks and environments. Within the context of network architectures adapted to utilize a PSFE, the PSFE is added to the architecture as an additional logical entity, such that the rest of the network architecture remains substantially unmodified. The PSFE interacts with the session initiation protocol (SIP) proxies, call session control functions (PCSCF), resource access control facilities (RACF), (NGSP) and other PSFE entities.

It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these term since such terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and” is utilized in the conjunctive and disjunctive senses and includes any and all combinations of one or more of the associated listed items, and the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which example embodiments belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and should not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

It is noted that the PSFE can also perform its intended function without the use of a RACF. In that instance, control of specific links is achieved via accounting based methods (whereas control of an entire network is performed with a RACF). In one embodiment, a standard or commercial network architecture is modified to use a PSFE by providers seeking NCS compliance, though mandatory use of PSFE is envisioned for DoD networks. Optionally, PSFE interaction with H323 systems is provided. The invention may be utilized within the context of SIP, H323, voice over IP (VoIP) or, more generally, X over IP network (XoIP), where X is a voice, video or multimedia communication.

The PSFE may provide priority signal message queuing (queuing tracked by links of a transport path) and preemption capabilities (i.e., it is able to identify the calls that need to be preempted to decongest certain links). Queuing in this context refers to the buffering-type queuing as is known in the prior art. Queuing in the inventive context is termed by the inventor as protocol level queuing and includes buffering-type queuing as well as call state queuing. Queuing a call or other service occurs when, for example, resource availability is verified for a link during parallel resource clearance. In this case the call is not dropped; rather, its state is stored by the PSFE until appropriate resources become available for the call in each network to be traversed by the call. Being held or stored means that the state information of the call is stored for subsequent use. The state of a call comprises the call source, the call destination, the resources needed to support the call, and so on.

Call admission control in a simple form is defined as determining which calls should be dropped and which calls should be allowed. Priority services in a simple form is defined as providing preferential treatment to some calls and not other calls. To effectively perform call admission control and priority services, the network needs to have knowledge of the calls in the system, their actual call paths (control plane and media plane paths) as well as the transport resources available in the network. One embodiment of the invention includes within one entity (the PSFE), priority and call information (e.g., number of calls in system, available transport resources and the like) needed to combine and control call admission and priority service functions. Thus, the PSFE helps to simplify network control plane architecture by combining multiple priority-related functions (e.g., call admission control and priority services) in a single functional entity.

The PSFE optionally communicates via Diameter to a RACF. The PSFE may also be call-state aware such that it can identify calls over links in a transport network (transport resource aware). In some embodiments, the PSFE continuously polls a RACF to identify availability of resource such that resource clearance of multiple call paths may be handled efficiently. In some embodiments the PSFE operates without a RACF (E.g., for open loop or accounting based controls).

In some embodiments, additional support for the PSFE is beneficial. Specifically, at times it may be appropriate for a RACF to pass link information of a media path (e.g., via a PDFE) to the PSFE. However, this will be needed only under certain cases. RACF link information is not needed when a call flows or when a priority call is cleared. For a priority call not cleared by the RACF, link information is needed for all subsequent RACF-cleared calls so that the availability of resources supporting the non-cleared priority calls can be determined.

Optionally, a P-CSCF (or a Proxy in non-IMS cases) will pass every SIP message it receives to the PSFE. Optionally, a new 5xxx message to convey network attempts (e.g., in the case of priority call queuing) is appropriate. Optionally, a protocol between the PSFE and NGSPs may be adapted to address fault tolerance issues such that fault tolerance functionality need not be distributed across a number of CSCFs.

FIG. 1 depicts a network topology facilitating calls through various networks according to an embodiment of the invention. Specifically, FIG. 1 depicts an exemplary communications system 100 according to an embodiment of the invention. In addition to architecture, FIG. 1 also depicts control and bearer signal paths, which signal paths are associated with reference numerals indicative of a temporal order of utilization in establishing and tearing down calls. FIG. 1 will be discussed in conjunction with other FIGs. to illustrate various call flow examples according to embodiments of the present invention.

Specifically, FIG. 1 depicts a plurality of networks including a calling party home network 110, a called party home network 120, a calling party visited network 130 and a called party visited network 140.

The calling party home network 110 comprises one or more application servers (AS) modules 112, a home subscriber server (HSS) 114 and a serving call session control function (S-CSCF) 116.

The called party home network 120 comprises one or more application servers (AS) 212, a home subscriber server (HSS) 214, a serving call session control function (S-CSCF) 116 and interrogating call session control function (I-CSCF) 128.

The calling party visited network 130 comprises a P-CSCF 131, a priority services functional element (PSFE) 132, a resource allocation control function (RACF) 133, a backbone packet network 136 and an access network 137. The RACF 133 includes a policy decision functional element (PD-FE) 134 and a traffic resource control functional element (TRC-FE) 135.

The called party visited network 140 comprises a P-CSCF 141, a priority services functional element (PSFE) 142, a resource allocation control function (RACF) 143, a backbone packet network 146 and an access network 147. The RACF 143 includes a policy decision functional element (PD-FE) 144 and a traffic resource control functional element (TRC-FE) 145.

The network 100FIG. 1 may be modified to represent a conventional network by removing each PSFE and RACF from the calling and called party visited networks. In this case, a call between A and B is initiated in accordance with the numbered signal paths 1-16; namely (1) a call invitation is communicated from endpoint A via access network 137 to backbone packet networks 136, then (2) to P-CSCF 131 and then to (3) S-CSCF, which (4) queries HSS 114, (5) AS 112 and (6) DNS 150 to retrieve the appropriate information pertaining to the called party and its home network. S-CSCF 116 then (7) communicates with the I-CSCF 128 of the called party home network. I-CSCF 128 propagates the request (8) to S-CSCF 126, which communicates (9) with its local HSS 124 and (10) AS 122 together necessary information regarding endpoint B. S-CSCF then (11) propagates a message to the P-CSCF 141 of the called party visited network 140 associated with endpoint B.

The above steps (1-11) are fairly conventional. In a conventional network, the P-CSCF 141 communities with a backbone packet network 146 to identify those router and other output ports within the RTP stream capable of supporting the call. This information is propagated back to the P-CSCF 131. The P-CSCF 131 and P-CSCF 141 cause their respective backbone packet networks 136 and 137 provide a communication path supporting the call within the RTP stream.

The network 100 of FIG. 1 is depicted as including a PSFE and RACF within each of the calling and called party visited networks. The interaction of these components with each other and existing infrastructure will be described in more detail below with respect to the remaining figures.

Within the context of the present invention, a SIP Proxy (or P-CSCF) continues to work as a transaction-stateful or call-stateless proxy as regards all other features. All calls, independent of priority, to or from a SIP Proxy (or P-CSCF) are locally looped to a PSFE. The PSFE optionally maintains call-state information (including link identification information for the traversed links associated with the call) for all calls. Communications between PSFE and RACF are via diameter for necessary resource clearance, and various demands and requests necessary transport path information.

Advantageously, the PSFE enables parallel resource clearance across network boundaries, queuing a call in itself until resources become available. In order to set up calls in parallel across multiple links, the following call control functions are provided: i) call-state awareness about existing and in-progress calls/sessions; ii) ability to gather information regarding resource usages at the links and network elements, and iii) ability to correlate call path within its domain from the addresses. In one embodiment, the PSFE obtains all necessary resource clearance for a particular call in one parallel operation. The PSFE performs necessary signal message queuing when it decides that resources are available with its domain for a call as part of resource verification. The PSFE routinely polls the RACF to identify resource availability. The PSFE sends back appropriate (e.g., standard SIP) error messages to the SIP Proxy (or CSCF) to signal a call that is to be blocked, if need be (e.g., a higher priority call is queued). In the event of resource availability for the PSFE's own network and receipt of an indication of resource availability for another network to be traversed by an intended call, the PSFE sends back appropriate (standard) SIP protocol messages to the SIP Proxy (or CSCF) to signal a call that is to be allowed. The PSFE initiates 3rd party calling for queued calls via the P-CSCF, as and when the resources for those calls become available. In the case of a 3^rd party call, the network operates to communicate (i.e., call back) both the calling party and the called party at a later time.

While denoted as a realtime transport protocol (RTP) stream in FIG. 1, the backbone packet networks may communicate via any streaming protocol, such as transmission control protocol (TCP), user datagram protocol (UDP) and the like. Signaling messages are sent from the call control elements in the originating network up to the call control elements in the terminating network for setting up end-to-end voice, data and video sessions across multiple networks. Different mechanisms for carrying such messages can be put in place depending on the network topology, interconnectivity, and protocols supported by the underlying network.

FIG. 2 depicts an overview of a network topology for facilitating calls through an exemplary network according to an embodiment of the invention. A method according to the invention proposes to obtain resource clearance in parallel across all links within a network boundary, as well as obtain resource clearance across several network boundaries. A conventional system employs sequential resource clearance, in which no node transmits a message until that node first obtains resource clearance within its domain. (i.e., serial resource clearance is accomplished on a link-by-link basis). In contrast, in parallel resource clearance as provided by the PSFE, the apparent or actual performance of more than one resource clearance operation occurs at a time, by the same or different devices and modules. In the parallel case, the various time requirements for resource clearance (Ti) are triggered as and when a resource availability request is received in domain i, and the domain i does not wait for the completion of Ti before sending a resource availability request to domain i+1. In this manner, multiple domains may be obtaining resource clearance without having to wait for the completion of resource clearance in a previous one/s. When there are multiple links in each domain, resources clearance within a domain may also be performed in parallel. For example, by using PSFEs for obtaining resource clearance in parallel across all links within a network boundary, as well as obtaining resource clearance across several network boundaries, the time required for resource clearance will be reduced to O(Max(t_i)), where Max(t_i) represents the maximum of all t_i, i.e., the maximum of all individual resource clearance times in individual links. Accordingly, the time required to process and transmit a message in a PSFE enabled network is much lower than the time required to wait for clearance on all links in a conventional network.

Such a methodology leads to one or more benefits. For example, setting up calls and sessions across an IP network will be more efficient and faster, which will reduce post-dial delay. Calls and sessions will have higher probability to complete set-up protocol exchanges before any particular timer expires, such as during set up when the networks are congested. For an end-to-end call which encounters multiple service provider (SP) networks, each SP network may be provided with information on resource needs and priority for the call/session, and the separate networks are able to assess and clear the calls. The time for set up of a call or a session that crosses several network domain boundaries (resulting from reasons, such as, administrative domains, geographical distribution, and population density, etc, even within a same SP network) will require only the maximum time required for setup in any of the domains.

Further, beneficial applications can be developed using the methodology provided. For example, the resource needs and priority assignment from the originating network/user may be communicated globally in a trusted manner with private mapping of such priority assignments at each separate network for specific internal usage within each network as described in U.S. patent application Ser. No. XX/XXXXXX entitled RHP Mapping And Defaulting Behavior, filed Dec. XX, 2008, which is herein incorporated by reference. Many call scenarios require connection to media servers, at times prior to call establishment and in other cases in mid-call, and the access path to media server may differ from that carrying the bearer packets from the caller to the called. The proposed methodology enables reservations and resource management across such different paths in parallel. In addition, the methodology of the invention facilitates the establishment of multiple conference legs, where call legs for an intended communication may include legs for each end point (end point referring to users, media server, conferencing server, and the like) and for each media type (e.g., video, audio, text, data, and the like, and some combination thereof) and some combination thereof. For example, if capacity is constrained to support all media types in a multi-media call, reservations across media types in parallel can be utilized to enable early establishment of calls with one media requiring lesser capacity when required capacity to support all media types is unavailable at the start of the call. Later, other media types can be added when additional capacities become available as further described in U.S. patent application Ser. No. XX/XXXXXX entitled Incremental Addition And Scale-Back of Resources Adapting to Network Resource Availability, filed Dec. XX, 2008 which is herein incorporated by reference. Further conferences with multiple end points across various network may be initially established with less than all of the multiple end points, with endpoint called back as resource become available as described in U.S. patent application Ser. No. XX/XXxxxX entitled Network Call Back To Add Conference Participants And/Or Media, filed Dec. XX, 2008, which is herein incorporated by reference.

An overview of the mechanism for the parallel resource clearance by PSFE across multiple networks is outlined in FIG. 2. For example, a call may be initiated initiated from a caller in network A to a called end in network B and will traverse network 200, which comprises networks A 210, B 220 and C 230. Alternatively stated, a call initiated from a caller to a called end will traverse networks N₁, N₂, N₃, N_i, . . . N_M., where N₁ is the head end, and N_M is the tail end of the call. The head end refers to network components like proxies, CSCF and PSFEs closest to the caller, while tail end refers to those network components closest to the called user. Also note that only three networks, namely A, B and C are illustrated for simplicity.

Each network includes a CSCF (212, 222, 232), a PSFE (212, 224, 234), a RACF (216, 226, 236), and a backbone packet network (218, 228, 238). The backbone packet network in each network may include a plurality of servers (219, 229, 239). The RACF may include a policy decision functional element (PD-FE) and a traffic resource control functional element (TRC-FE) (not shown)

All calls, independent of priority, to or from a CSCF are locally looped to a PSFE. The PSFE maintains call-state information (including link identification information for the traversed links associated with the call) for all calls. Communications between PSFE and RACF are via Diameter for necessary resource clearance, and various demands and requests necessary transport path information.

When a call passes through networks A, B and C, then the PSFE element in each of those network clouds is responsible for obtaining necessary resource clearances in its own network respectively. In parallel with the verification of resource availability within its network, the PSFE forwards the notice of an intended communication to the next network and toward the called party network. As resources become available in each of the networks, the PSFEs in that network await for the clearance to arrive from the tail end of the call. In other words, network B waits for the clearance from network C, and network A waits for the clearance from network B. Thus, network A will not receive clearance until both networks C and B have necessary resources for the call. At this point the PSFE in network A, communicates to the CSCF in network A (or the SIP proxy in network A) and triggers a re-invite from the caller to the called user. In an alternative embodiment, PSFEs in each of the networks await for the resource clearance indication to arrive from the head end direction of the call.

In each of these network segments one or multiple PSFE communicates with the corresponding CSCF and RACFs. For example, if resource clearance is propagated toward the tail end, on receiving a new session or call request through SIP INVITE and from the identification that the call or session needs to be forwarded to the CSCF in Network B, the PSFE in Network segment A forwards a resource assessment request to PSFE in Network segment B, while looking into the resource requirement versus availability in Network segment A. The PSFE in Network segment A also follows up with a message to the CSCF and PSFE in network segment B regarding resource availability in Network segment A after its determination.

The PSFE in Network segment B performs the same function as the PSFE in Network segment A, which is sending a resource assessment request to PSFE in Network segment C by recognizing that the call or session needs to be sent to Network segment C while it gets engaged in verifying resource availability in Network segment B. PSFE in Network segment B also follows up with a message to the CSCF and PSFE in Network segment C regarding resource availability in Network segment B after its determination. PSFE in Network segment B also forwards the resource availability determination that it received from PSFE in Network segment A.

The CSCF in Network segment C determines that the called end is in Network segment C. PSFE in Network segment C determines the resource availability for the requested call or session for the Network segment C and together with messages received from PSFEs in Network segments A and B, determines the end-to-end resource availability before informing its decision on call or session admission to the CSCF in Network segment C. CSCF in Network segment C then admits or disallows the call based on PSFEs' decision (based on resource availability information for PSFEs in A, B and C).

In other embodiments, a transit network may be interposed two of the Network Segments illustrated (e.g., between Network segments A and B, Network segments B and C). A transit network is used for bulk transport between networks providing user services. Such transit networks provide bulk transport services only and do not have call or session managers associated therewith but may honor Service Level Agreements (SLA), which are primarily based on statistically averaged call or session performance over time. SLAs are generally based on connectivity metrics such as, downtime, reliability and availability measures, and bytes sent/received, and Quality of Service metrics such as, delay, delay variation, packet loss and packet throughput.

Transit networks do not provide individual call or session control and management. Thus, the transit network and its partners will typically have an overall bulk transport carrying agreement but the transit networks do not support specifically any individual call or session related characteristics. For example, a transit network may be outfitted with a PSFE, RACF and a Backbone network but not have a CSCF.

For calls passing through such core transport networks or transit networks, obviously call or session management is not performed by the core transport service provider. Thus, the originating and/or terminating network service provider on either side of the transit network is responsible to provide end-to-end call or session admission, and management. Accordingly, the PSFE also is enabled to negotiate and determine resource availability from the transport-only networks. In addition, as described above, the PSFE performs resource assessment in its own network and forwards a resource assessment and clearance request through SDP offers to PSFEs in the call path as determined from the destination URI. Based on received the availability information for its own network and other networks in the call path including any interposed transit networks, a PSFE decides on call admission and instructs the Call Session Control Function Elements (CSCF) for implementing call or session admission decisions.

FIG. 3 depicts a flow diagram of an exemplary routine according to embodiments in accord with the present invention. The call blocking call flow, call queuing and call creation for the parallel resource clearance of 300 of FIG. 3 will be described within the context of the communications system 200 of FIG. 2. Specifically, control signal paths between calling endpoint-A 302 in network A (i.e., calling party network) and called endpoint-C of network C (i.e., called party network) as can be gathered from FIG. 2 comprise, in the order named, CSCF-A 212, PSFE-A 214, CSCF-B 222, PSFE-B 224, CSCF-C 232, PSFE-C 234.

Referring now to FIG. 3, at 301 an invite message is propagated from calling endpoint A to CSCF-A 212, then at 302 to CSCF-B 222, and finally at 203 to CSCF-C 232. In general, each network sends an invite message toward the called network until the called network is reached by the notice of intended communication.

In parallel with the propagation of the invite message, each PSFE (214, 224, 234) verifies resource availability for a resource required for intended communication in response to a reserve message (311, 312, 313). When an invite message enters a first network (e.g., network C), the corresponding PSFE (e.g., PSFE-C 234) attempts to reserve necessary bandwidth for the call and queues the call in its stack. The corresponding PSFE (e.g., PSFE-C 234) determines from corresponding RACF (e.g., RACF-C 236) if resources are available for all the links within the first network (e.g., network C) for this particular call. In one embodiment, if requested resources are not available, the call is queued, and no lower or equal priority call is allowed until this particular call gets a chance to obtain the requested resource capacity.

For example, in case of dynamic real-time bandwidth management, corresponding RACF (e.g., RACF-C 236) listens to the SNMP messages from multiple switch/routers in that network in parallel and determines if all the necessary link/s that constitute the call have enough resource/s available. In cases where dynamic bandwidth management is not required and mere call counting or bandwidth counting will suffice, the corresponding PSFE or the corresponding RACH may be directly involved in bandwidth or call counting and determine the availability of the necessary resource/s.

The act of queuing the call and communication with the corresponding RACH ensures that resources are obtained in parallel in first network (e.g., network C). In case of dynamic bandwidth management, all corresponding routers in the network send updates in parallel to the corresponding RACH of the first network. The corresponding PSFE then makes decisions based on the query to the corresponding RACH of the network as described above.

In another embodiment when a transport network is interposed networks A and B, the originating network's (A) PSFE learns about the network where the call/session needs to be forwarded to (i.e., network B) and the intermediate transport network (A′) from the called URI. The PSFE then verifies the SLA agreed with the transport network (A′) and determines if the SLA assures the requirements for the call/session in progress. The originating network's PSFE forwards the call/session request along with resource needs to the PSFE in the next network (B) in the call/session path (via the CSCFs).

A PSFE sends a Held message toward the next PSFE closest the head-end PSFE only when the resources in all subsequent networks are available for the intended call. If the PSFE is in the called party network (e.g., network C), at 321 the held message may be forwarded based on resource availability within the called network alone. The held message is forwarded between PSFE via corresponding CSCF at 322, 323. For PSFE in a first network other than called party network (i.e., intermediate networks (e.g., network B) and the calling party network (e.g., network A)), at 321 a Held message is forwarded toward the head-end only if each network from first network in question to the called party network have resource availability for the intended communication. Again, the held message is delivered to the head end PSFE via the corresponding CSCF of the first network at 325 and the head end network at 326. In other words, the held message is forwarded between PSFE via corresponding CSCF (325 and 326). A Held message is essentially a command that instructs the CSCF that resources are held for a user, but are not yet consumed. The Held message may be implemented as a 1xx message.

As resources become available in each of the networks, the PSFE in that network await for the clearance to arrive from the tail end of the call. In other words, when a call passes through networks A, B, and C, B waits for the clearance from C, and A waits for the clearance from B. Thus A will not receive clearance until both C and B have necessary resources. All the intermediate networks' PSFEs and the final network PSFE sends a 1xx message indicating that resources are held when the resources become available. Note that, in an embodiment with a transport network A′ interposed networks A and B, PSFE in A also has verified that the transport network A′ can assure the resources required in A′ through communication with the transport network.

In an alternate embodiment, the PSFE sends an indication of resource clearance to the head-end as soon as resources are determined to be available in its own network and the decision about final call admission may be based on resources availability across the various PSFE as determined by the PSFE at the head end network (i.e., calling party network). In another embodiment call admission may be based on minimum possible resource is available across the various PSFE.

When PSFE at the calling party network determines that there is of resource availability for end-to-end communication contemplated, at 327 that PSFE triggers corresponding CSCF to initiate a SIP Re-Invite from the calling network CSCF to the called network CSCF (328, 329, 330). Alternatively, an SDPReoffer may be triggered.

In respond to the re-invite message, a ringing message is propagated from the called endpoint to the calling endpoint (331, 332, 332). When a PSFE obtains the Re-Invite message, the necessary resource is locked in using the queued information associated with the call via lock message (335, 336, 337). A Lock message is essentially a command that instructs the PSFE that resources are now being used. The Lock message may be implemented as another 1xx message or could be piggybacked with ‘ringing’ message. Prior to the PSFE receipt of the Lock message, the call is merely queued and the resources are not being consumed. Messages need not be in SIP, but can be implemented in DIAMETER or any other protocol.

The PSFE of the present invention advantageously isolated Parallel Call Admission and Priority Services development so that such services are easier to develop and maintain. Moreover, such services may now be provided without service and software replication with respect to vendor product offerings. Parallel Call Admission and Priority Services can be an optional service required by a customer and can fit IMS and non-IMS networks, including H323. With the novel PSFE, newer DISA and NGPS features are easier to develop. In this manner, new features like “priority conference call reservation” of priority conferences may be implemented. In addition, the PSFE relieves the burden of having a CSCF or any other fully operational SIP Proxy maintain resource awareness (i.e., call states with respect to links). The PSFE provides resource control and policy-based management mechanism adapted to implement priority services in a packet network environment, such as described herein.

The above-described embodiments of the invention may be implemented within the context of methods, computer readable media and computer program processes. Generally speaking, methods according to the invention may be implemented using computing devices having a processor as well as memory for storing various control programs, other programs and data. The memory may also store an operating system supporting the programs. The processor cooperates with conventional support circuitry such as power supplies, clock circuits, cache memory and the like as well as circuits that assist in executing the software routines stored in the memory. As such, it is contemplated that some of the steps discussed herein as software processes may be implemented within hardware, for example as circuitry that cooperates with the processor to perform various steps. Input/output (I/O) circuitry forms an interface between the various functional elements communicating with the device.

A computing device is contemplated as, illustratively, a general purpose computer that is programmed to perform various control functions in accordance with the present invention. The invention also can be implemented in hardware as, for example, an application specific integrated circuit (ASIC) or field programmable gate array (FPGA). As such, the process steps described herein are intended to be broadly interpreted as being equivalently performed by software, hardware and a combination thereof in various alternative embodiments.

The invention may also be implemented as a computer program product wherein computer instructions, when processed by a computer, adapt the operation of the computer such that the methods and/or techniques of the present invention are invoked or otherwise provided. Instructions for invoking the inventive methods may be stored in fixed or removable media, transmitted via a data stream in a signal bearing medium such as a broadcast medium, and/or stored within a working memory within a computing device operating according to the instructions.

While not specifically noted, it will be appreciated by those skilled in the art that various network management system (NMS) and element management system (EMS) are used to manage the various functional elements discussed herein, including the new PSFE. Each PSFE is managed by an appropriate NMS and/or EMS, which is selected according to the network within which the PSFE operates. Thus, the PSFE is operable to provide bridge and information and protocol bridge between various management systems such that call state aware and priority state aware information may be utilized throughout a large group of networks, as discussed above.

Within the context of a NMS or EMS utilizing the present invention, an instantiation of an application such as an IMS application includes a PSFE that is logically and/or physically disposed between the RACF and CSCF of a network to perform the various functions discussed above. As such, one embodiment of the invention comprises a method for adapting a control plane of a communication network normally using a call session control function (CSCF) in communication with a resource access control function (RACF), where the method includes providing a priority service functional element (PSFE) between each RACF and its corresponding CSCF to verify a priority level for each call, receive resource allocation information from the RACF, store a resource allocation for each call, and cause the CSCF to preferentially allocate resources to high priority calls as discussed above with respect to the various figures. Instantiations supporting the PSFE may be provided on a single server or multiple servers, and/or within a single network or multiple networks.

An apparatus according to the invention is adapted for use in a system comprising a plurality of networks, each of which include a resource access control function (RACF), a call session control function (CSCF) and a packet network supporting, illustratively, a Realtime Transport Protocol (RTP) stream between the calling and the called party networks. The PSFE advantageously provides a knowledge of call-states as well as the “links” that they pass through, in order to block routine calls (both NCS and DoD), queue priority calls against the “links” that they will use (NCS) and tear down/preempt calls, under certain conditions, based on the “links” that they traverse (DoD). The PSFE also provides an ability to perform 3^rd party calling (network initiated) when queued calls are processed, and an ability to obtain “link” (i.e., transport resource paths) information from certain elements in the network. This information is then passed to the relevant management system.

Reference herein to “one embodiment”, “another embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments necessarily mutually exclusive of other embodiments. Although various embodiments which incorporate the teachings of the present invention have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings.

Claims

1. A method comprising: receiving at a first network a notice of an intended communication to a called party network, wherein the intended communication requires at least one resource for supporting a streaming data protocol between a calling party network and the called party network;verifying resource availability of at least one resource in the first network; andin parallel with said verifying, forwarding the notice of an intended communication to a second network and toward the called party network prior to receiving an first indication of resource availability of the at least one resource in the first network required for the intended communication.

2. The method of claim 1 wherein the indication of resource availability includes an indicator of resource sufficiency associated with the intended communication.

3. The method of claim 1 wherein verifying resource availability of at least one resource in the first network comprises: reserving the at least one resource in the first network if the resource is available.

4. The method of claim 1 further comprising: receiving at the first network a second indication of resource availability of at least one resource at the second network required for the intended communication.

5. The method of claim 4 further comprising: forwarding a re-invite of the intended communication to the second network and toward the called party network in the event the first indication and the second indication signify resource availability for at least one resource in each network from the calling party network to the called party network.

6. The method of claim 4 further comprising: forwarding a request to a transit network interposed the first network and the second network for verifying with the transit network a predetermined Service Level Agreement (SLA) and that the SLA assures at least one requirement of the intended communication;receiving resource availability information for the transit network; andforwarding a re-invite of the intended communication to the second network and toward the called party network in the event the first indication, the second indication and the resource availability information for the transit network signify resource availability for at least one resource in each network from the calling party network to the called party network.

7. The method of claim 1 further comprising: in the event of receipt of a ringing message, forwarding a lock message, the lock message instructing that the at least one resource in the first network is to be used.

8. A method of capacity and priority management for use in a system comprising a plurality of networks, each of the networks including a packet network for supporting a streaming data protocol between a calling party network and a called party network, the method comprising: receiving at a first network a notice of intended communication from a calling party network to a called party network;determining for the intended communication resource availability information for the first network in response to said receiving;reserving a resource within the first network in the event of resource availability based on the resource availability information for the first network;in parallel with said determining and in response to said receiving, forwarding the notice of intended communication to a second network and toward the called party network prior to completion of said determining for the intended communication resource availability information for the first network;receiving resource availability information for at least one other network associated with the intended communication in the event of resource availability for the at least one other network associated with the intended communication;forwarding a corresponding resource availability message based on the resource availability information for the first network and the resource availability information for the at least one other network indicating resource availability for the intended communication.

9. The method of claim 8 wherein forwarding a corresponding resource availability message comprises: forwarding the corresponding resource availability message within the first network.

10. The method of claim 8 wherein forwarding a corresponding resource availability message comprises: forwarding the corresponding resource availability message to a third network.

11. The method of claim 8 wherein the second network and the third network are the same network.

12. The method of claim 8 wherein determining for the intended communication resource availability information for the first network is performed via at least one of an open loop control and an accounting based control.

13. The method of claim 8 wherein determining for the intended communication resource availability information for the first network comprises: communicating with a resource access control function (RACF) to verify the resource availability information concerning the first network.

14. The method of claim 8 wherein, wherein determining for the intended communication resource availability information for the first network further comprises forwarding a request to a transit network interposed the first network and the second network for verifying with the transit network a predetermined Service Level Agreement (SLA) and that the SLA assures at least one requirement of the intended communication; andreceiving resource availability information for the transit network.

15. The method of claim 8 further comprising forwarding at least one of a SDPReoffer message or a re-invitation message for the intended communication after forwarding a resource availability message.

16. The method of claim 8 further comprising receiving a ringing message; andlocking the resource within the first network that was reserved in response to the ringing message.

17. The method of claim 8 wherein the notice of intended communication includes a priority indicator, the method further comprising, while determining resource availability for a first intended communication, preventing determining resource availability for a second intended communication having a priority indicator less than or equal to a priority indicator for the first intended communication.

18. An apparatus for managing a first network, the first network including a packet network for supporting a streaming data protocol between a calling party network and a called party network, the apparatus comprising: a call session control functional element (CSCF) for receiving a notice of an intended communication from a calling party network to a called party network, requesting resource availability information for the first network in response to the notice, and propagating the notice of intended communication toward the called party network prior to receiving corresponding resource availability information for the intended communication; anda priority service functional element (PSFE) for verifying for the intended communication the resource availability information for the first network in response to a request from the CSCF, receiving resource availability information for at least one other network supporting the intended communication, forwarding the corresponding resource availability information to the CSCF element, and storing resource allocation information;wherein the PSFE reserves a resource within the first network in response to verifying resource availability for the first network and forwards the corresponding resource availability information to the CSCF in the event the resource availability information for the first network and the resource availability information for the at least one other network indicate resource availability for the intended communication.

19. The apparatus of claim 18, wherein the PSFE supports at least one of an open loop control and an accounting based control.

20. The apparatus of claim 18, wherein the first network further includes a resource access control function (RACF), and wherein the PSFE verifies the resource availability information concerning the first network using the RACF.

21. The apparatus of claim 18, wherein the PSFE forwards the corresponding resource availability information to the CSCF in the event the resource availability information for the first network and the resource availability information for the at least one other network indicate resource availability for each network from the called party network to the first network.

22. The apparatus of claim 18, wherein the CSCF to transmits a re-invite message in the event the corresponding resource availability information indicates resource availability for each network from the calling party network to the called party network.