Patent Application
20070162599
None.
Not applicable.
Not applicable.
The present disclosure relates to IP telephony. More specifically, but not by way of limitation, a method and system are provided that allow the distribution of a Policy Decision Function in an Internet Protocol Multimedia Subsystem.
Internet Protocol (IP) telephony has emerged as an alternative to the traditional telephony that uses the public switched telephone network (PSTN). IP telephony uses data packet-based technologies to exchange voice, fax, audio, video, gaming, and other data (i.e., multimedia) during a user session involving two or more users. Unlike PSTN-based calls, the messages transmitted in an IP telephony-based message exchange do not travel in a dedicated circuit between two users. Instead, a message sent by a transmitting party is broken into data packets that may travel over different paths through a network before being reassembled and delivered to a receiving party.
The IP Multimedia Subsystem (IMS) is a standardized architecture for providing both mobile and fixed multimedia services that many telephony service providers are beginning to implement. The IMS architecture is defined as a collection of different functions (i.e., network elements) that communicate using standard protocols. There is no required one-to-one mapping between these functions and network nodes (i.e., computer systems) in an actual implementation of the IMS architecture. A service provider may combine multiple functions on a single node or split a single function across multiple nodes. Therefore, systems and methods for implementing the IMS functions are desirable.
According to one embodiment, an Internet Protocol (IP) Multimedia Subsystem (IMS) is provided. The IMS includes a logical Policy Decision Function (PDF) component that includes a plurality of physical PDF network elements. The IMS also includes a front end node operable to determine which one of the plurality of physical PDF network elements is an intended recipient of a message by using identification information in an authorization token portion of the message.
According to another embodiment, a method for distributing Policy Decision Function (PDF) in an Internet Protocol (IP) Multimedia Subsystem (IMS) is provided. The method includes providing a plurality of physical PDF network elements that comprise a logical PDF. Each one of the plurality of physical PDF network elements executes on a separate central processing unit (CPU). The method includes receiving a message intended for one of the plurality of physical PDF network elements. The method includes determining from an identifier in the message which of the plurality of physical PDF network elements the message is intended for. The method also includes delivering the message to the intended one of the plurality of physical PDF network elements.
According to still other embodiments, an Internet Protocol (IP) Multimedia Subsystem (IMS) is provided that includes a plurality of separate central processing units (CPUs). The IMS also includes a logical Policy Decision Function (PDF) component comprising a plurality of physical PDF network elements, each physical PDF network element execute on separate CPUs of the plurality of CPUs. A front end node is operable to determine which one of the plurality of physical PDF network elements is an intended recipient of a message by using identification information in an authorization token portion of the message. A distribution component is operable to select one of the plurality of physical PDF network elements according to a load sharing policy.
These and other features and advantages will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.
For a more complete understanding of the presentation and the advantages thereof, reference is now made to the following brief description, taken in connection with the accompanying drawings in detailed description, wherein like reference numerals represent like parts.
Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, computer companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . .” Also, the term “couple” or “couples” is intended to mean either an indirect, direct, optical, wireless, or other electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, through an indirect electrical connection via other devices and connections, through an optical electrical connection, or through a wireless or other electrical connection.
Certain standard nomenclature known to one of skill in the art of IP telephony is used throughout the following description and claims and in the accompanying drawings. This nomenclature, along with standard abbreviations for the nomenclature, is summarized in Table 1.
It should be understood at the outset that although exemplary implementations of embodiments of the present invention are illustrated below, the present system may be implemented using any number of techniques, whether currently known or in existence. The present disclosure should in no way be limited to the exemplary implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
The IP Multimedia Subsystem (IMS) architecture decomposes current and future networking services and devices into functions that are conceptually linked by reference points. The reference points define all message traffic between two functions, including multiple protocols for the different types of message traffic. To better understand and describe aspects of the present disclosure, background including a brief description of prior art systems is provided in
The Call Center Control Function (CSCF) 110 occupies a central position in IMS. The CSCF 110 is a network element responsible for maintaining a SIP call session in the IMS network. As is shown in
The I-CSCF 200 provides a contact point within a network that allows subscriber of that network operator, and roaming subscribers, to register. Once a subscriber is registered, the S-CSCF 202 maintains the session state for all IMS services. The I-CSCF 200 typically acts as a SIP proxy. However, in IMS, the main purpose of the I-CSCF 200 is to provide a service locator function. The major functions of the I-CSCF 200 include assigning an S-CSCF to a UE (e.g., UE 100) performing SIP registration, routing a SIP request received from another network to the S-CSCF 202, and routing intra-domain SIP requests between UEs on different S-CSCFs.
The S-CSCF 202 is both a SIP server and a SIP proxy. As a SIP server, the S-CSCF 202 provides session control for subscribers. A major function of the S-CSCF 202 is interacting with network databases such as the Home Subscriber Server (HSS) 112 for mobility and the Access, Authorization and Accounting (AAA) servers (not specifically shown) for security. As a SIP proxy, the S-CSCF 202 relays signals generated by a roaming user for confirmation with the HSS of the roaming users' home network that holds the user's profile. After a user's signaling event is processed by the S-CSCF 200, it may be forwarded to any application servers (e.g., AS 114) or gateways (e.g., gateways 106, 108) required for completion of the requested action or session.
The Policy Decision Function (PDF) 206 is a logical entity of the P-CSCF 204 that functions as a Policy Decision Point (PDP) for service-based local policy control. The PDF 206 makes policy decisions based on session and media related information obtained from the P-CSCF 204 via the interface using the Diameter protocol, and communicates the decision information to the GGSN 116 via the Go Interface (COPS and COPS-PR). When a SIP session is initiated by the UE 100, the PDF 206 generates an authorization token for that session, and the P-CSCF 204 sends the authorization token to the UE 100 in SIP signaling. This authorization token is unique across all PDP contexts associated with an Access Point Name (APN) of the GGSN 116 and may contain information that identifies the PDF 206.
The PDF 206 performs numerous functions in IMS. For example, the PDF 206 receives bearer authorization requests from the GGSN 116 and authorizes these requests using stored session and media related information received from the P-CSCF 204 during SIP session initiation. The PDF 206 also updates these authorization decisions when sessions are modified. In addition, responsive to signaling information received from the P-CSCF 204, the PDF 206 sends commands to the GGSN 116 to perform such operations as opening or closing IP bearer gates (e.g., answer event, call hold event) or revoking authorization of resources (e.g., SIP session disconnect).
In some embodiments, as part of the policy decision making process, the PDF 206 may need to negotiate with a Bearer Control Function (BCF) network element (not specifically shown) of the IP Backbone network 118 before sending a decision to the requesting GGSN 120. A Bearer Control Function (BCF) performs Quality of Service (QoS) management within the IP Backbone network.
Within the access network 308, the originating PDF 328 and the originating GGSN 306, communicated via COPS, work with resources within the access network 308 to ensure quality of service. Similarly, the terminating PDF 330 and the terminating GGSN 324 work with resources in the access network 320 to ensure quality of service. If the IP call must go through resources not owned by either of the providers of the access networks 308, 320, the originating PDF 328 and the terminating PDF 330 may negotiate with the BCF 322 that controls those resources to reserve the resources for the call and to determine the QoS available in the end-to-end path between the UEs 300, 302. The protocol of the Gu interface is used for communication between the PDFs 328, 330 and the BCF 332.
In an IMS implementation, robust performance of a PDF is important. Prior systems have used only one PDF to handle all the calls originating in an area or access point. Using only one PDF create a single point of failure in the event of a problem or overload of the PDF. The message traffic to a PDF may also vary from system to system, so an implementation that supports scalability for handling varying traffic nodes is desirable. The present disclosure, according to one embodiment provides a single logical PDF, but includes multiple physical PDFs which provide redundancy and load sharing and balancing. The present disclosure also provides techniques for identifying the physical PDF and communication session.
As is explained in more detail below in reference to
In some embodiments, the authorization token comprises some number of session authorization attributes, each having the format illustrated in
In the IMS 400 illustrated in
To originate an IP call, the UE 428 sends a SIP INVITE message 612 to the P-CSCF network element 430. The P-CSCF network element 430 sends a SIP INVITE message 614 to S-CSCF network element 602 which sets up a call to the terminating side. The S-CSCF network element 602 responds to the P-CSCF network element 430 with a SIP 183 Session Progress message 616. Upon receipt of this message, the P-CSCF network element 430 calls the distribution component 414 to select a physical PDF network element 422, 424, 426 from the PDF load sharing group 412 to handle policy decisions for the call. In this illustration, the physical PDF network element 426 is selected. The P-CSCF network element 430 sends a Diameter Auth_Req message 618 containing policy setup information to the physical PDF network element 426. The policy setup information may include the IP address of the destination UE, the transport protocol identification, and various bandwidth parameters. The physical PDF network element 426 stores this policy setup information for use in future QoS policy decisions for the IP call.
The physical PDF network element 426 then sends a Diameter Auth_Resp message 620 to the P-CSCF network element 430 containing an authorization token. This authorization token comprises the IP address of the logical PDF (i.e., the PDF load sharing group 412, an identifier (e.g., n) for the physical PDF network element 426, and a PDF session identification number (e.g., 1234). The P-CSCF network element 430 then sends a SIP 183 Session Progress message 622 to the UE 428 that includes the authorization token. The authorization token is embedded in a P-Media-Authorization header.
When the UE 428 receives the authorization token, it generates a flow identifier that identifies an IP media flow associated with the SIP session. This flow identifier combined with the authorization token is sufficient to uniquely identify the IP flow during service delivery. The UE 428 then sends an Activate PDP Context message 624 to the SGSN 604 that includes the authorization token and the flow identifier. The SGSN 604 checks the user profile to authorize the requested QoS and also checks for available resources. The SGSN 604 then sends a Create PDP Context message 626 to the GGSN 606 that contains the authorization token and the flow identifier.
When the GGSN 606 receives the message 626, the Policy Enforcement Point (PEP) in the GGSN 606 sends a COPS REQ message 628 to the logical PDF of the IMS 400 using the IP address of the logical PDF included in the authorization token. The front end node 410 receives the message 628 and extracts the PDF identifier from the authorization token to determine which physical PDF network element in the PDF load sharing group 412 is the intended recipient. In this illustration, the front end node 410 routes the message 630 to the physical PDF network element 426.
The physical PDF network element 426 makes a policy decision based on the previously stored policy setup information. In some embodiments, as is illustrated in
In one embodiment, when the physical PDF network element 426 sends a Bearer Resource Request message 634 to the BCF network element 610 via the front end node 410, the message 634 contains the identifier of the physical PDF network element 426 embedded in an attribute of the request message that is also present in the Bearer Resource Allocation ACK message 636. When the front end node 410 receives the ACK message 636 from the BCF network element 610, it extracts the identifier from the message to determine which physical PDF network element is the intended recipient.
In other embodiments, a transaction-based protocol may be used for communication between the physical PDF network element 426 and the BCF network element 610. Using this protocol, when the physical PDF network element 426 sends the request message 634, the front end node maintains a mapping of an identifier for the transaction to the identifier of the physical PDF network element 426. For example, the front end node 410 may maintain a table that associates a unique transaction identifier for the request with the physical PDF identifier. This transaction identifier is included in the allocation acknowledgement message 636. When the front end node 410 receives the allocation acknowledgement message 636, it uses the transaction identifier to determine which physical PDF is the intended recipient.
After making a policy decision, the physical PDF network element 426 sends a COP DEC message 632 back to the GGSN 606 that includes QoS information. This QoS information may comprise a policy decision, a flow identifier, the maximum QoS, and the data rate. The front end node 410 extracts the Client Handle from the COPS DEC message 632 and stores it in a PDF ID mapping table that associates the handle with the identifier of the physical PDF network element 426.
In other message traffic not specifically illustrated in
The GGSN 606 also checks its own available resources. If sufficient resources are available, the GGSN 606 sends a Create PDP Context Response message back the SGSN 604 containing the negotiated QoS information. The SGSN 604 then sends an Activate PDP Context Accept message to the UE 428 that contains this QoS information. Additional message traffic ensues to enable the use of the authorized QoS resources and to allow packet flow in accordance with the policy decision of the physical PDF network element 426.
The systems described above may be implemented on one or more computer systems with sufficient processing power, memory resources, and network throughput capability to handle the necessary workload placed upon it.
The secondary storage 1338 is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM 1334 is not large enough to hold all working data. Secondary storage 1338 may be used to store programs that are loaded into RAM 1334 when such programs are selected for execution. The ROM 1336 is used to store instructions and perhaps data that are read during program execution. ROM 1336 is a non-volatile memory device that typically has a small memory capacity relative to the larger memory capacity of secondary storage. The RAM 1334 is used to store volatile data and perhaps to store instructions. Access to both ROM 1336 and RAM 1334 is typically faster than to secondary storage 1338.
I/O devices 1340 may include printers, video monitors, liquid crystal displays (LCDs), touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, or other well-known input devices.
The network connectivity devices 1312 may take the form of modems, modem banks, Ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards such as code division multiple access (CDMA) and/or global system for mobile communications (GSM) radio transceiver cards, and other well-known network devices. These network connectivity devices 1312 may enable the processor 1332 to communicate with the Internet or one or more intranets. With such a network connection, it is contemplated that the processor 1332 might receive information from a network or might output information to a network in the course of performing the above-described method steps.
Such information, which may include data or instructions to be executed using processor 1332 for example, may be received from and outputted to the network, for example, in the form of a computer data baseband signal or signal embodied in a carrier wave. The baseband signal or signal embodied in the carrier wave generated by the network connectivity devices 1312 may propagate in or on the surface of electrical conductors, in coaxial cables, in waveguides, in optical media, for example optical fiber, or in the air or free space. The information contained in the baseband signal or signal embedded in the carrier wave may be ordered according to different sequences, as may be desirable for either processing or generating the information or transmitting or receiving the information. The baseband signal or signal embedded in the carrier wave, or other types of signals currently used or hereafter developed, referred to herein as the transmission medium, may be generated according to several methods well known to one skilled in the art.
The processor 1332 executes instructions, codes, computer programs, or scripts that it accesses from hard disk, floppy disk, optical disk (these various disk-based systems may all be considered secondary storage 1338), ROM 1336, RAM 1334, or the network connectivity devices 1312.
While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein, but may be modified within the scope of the appended claims along with their full scope of equivalents. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.
Also, techniques, systems, subsystems and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as directly coupled or communicating with each other may be coupled through some interface or device, such that the items may no longer be considered directly coupled to each other but may still be indirectly coupled and in communication, whether electrically, mechanically, or otherwise with one another. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.
