Abstract:
Methods, systems, and computer program products for providing a quality of service (QoS) using E.164 number mapping (ENUM) data in a communications network. According to one method, a query message including an E.164 number can be received. Next, at least one uniform resource identifier (URI) associated with the E.164 number can be located. Afterwards, QoS data corresponding to the at least one URI is subsequently obtained. Further, the query message can be responded to with the URI and the corresponding QoS data.

Description:
TECHNICAL FIELD 
       [0001]    The subject matter described herein relates to providing Quality of Service (QoS) in a communications network. More particularly, the subject matter described herein relates to methods, systems, and computer program products for providing QoS using ENUM data in a communications network. 
       BACKGROUND 
       [0002]    The Internet Engineering Task Force (IETF) initiated the development of the E.164 Number Mapping (ENUM) system for facilitating the interconnection of communications networks that rely on telephone numbers with the communications networks that utilize the Domain Name System (DNS). In particular, the ENUM system can map a particular number referred to as an E.164 number to one or more Uniform Resource Identifiers (URIs) in the DNS. URIs are strings of characters that identify resources such as documents, images, files, databases, e-mail addresses, websites or other resources or services in a common structured format. A URI can include a SIP URI, an instant messaging (IM) identifier, an e-mail address identifier, an Internet chat session identifier, or an IP address. 
         [0003]      FIG. 1  is an exemplary communications network, generally designated  100 , utilizing the ENUM system. Network  100  includes a signaling point (SP)  102  (e.g., a gateway, switching point, etc.) for connecting the Public Switched Telephone Network (PSTN) system  104  to an IP Multimedia Subsystem (IMS)  106 . SP  102  is operable to enable communication between a conventional telephone unit or another suitable network device connected to PSTN  104  and a packet telephone unit or another suitable network device connected to IMS  106 . The mobile telephone unit can communicate to IMS  106  via session initiation protocol (SIP) proxy server  108 . The conventional telephone unit and packet telephone unit can communicate voice data, text data, or other suitable data. ENUM system can be utilized, for example, when a user of the standard telephone unit attempts to reach a subscriber associated with the packet telephone unit. 
         [0004]    Communication between the conventional telephone unit and the packet telephone unit can be initiated when a user of the conventional telephone unit dials an E.164 formatted called party number (referred to herein as an E.164 number) for reaching a subscriber associated with the packet telephone unit. The dialed E.164 number (or called party number) is communicated from the conventional telephone unit to PSTN  104 . PSTN  104  can then generate an ISUP IAM message  110  containing the E.164 number and send IAM message  110  to SP  102 . In this example, SP  102  determines that the called subscriber phone is a packet phone and that an ENUM query is required. SP  102  formulates an EN UM query  112  and sends the query to EN UM database  114 . In the ENUM query, the E.164 number is converted to ENUM message format by reversing the digit order of the dialed E.164 number and appending the highest level domain e164.arpa to the end. For example, if the original E.164 number is 123-456-7890, ENUM query  112  is converted 0.9.8.7.6.5.4.3.2.1.e164.arpa (also referred to herein as an E.164 number). ENUM server  114  uses the ENUM query to retrieve one or more naming authority pointer (NAPTR) records associated with the E.164 number. Each of the NAPTR records may identify at least one URI corresponding to the subscriber with the E.164 number. The URI may identify the mobile telephone unit. The URI is then communicated to SP  102  in an ENUM response  116  for establishing communication between the conventional telephone unit and the packet telephone unit. 
         [0005]    In addition, more than one URI can be contained in the NAPTR records for identifying one or more other network devices, services and/or addresses. For example, another URI returned to SP  102  can identify a different way of reaching the subscriber associated with the dialed E.164 number, such as via e-mail or paging. 
         [0006]    Rather than simply returning the URI or set of URIs obtained from ENUM server  114  to SP  102 , it may be desirable to obtain additional information, such as the Quality of Service (QoS) information associated with each of the obtained URIs that may be used to contact the called party. Examples of QoS information may include the sound quality and the amount of throughput or bandwidth that is available to each URI. Current mechanisms for obtaining ENUM and QoS data are distinct. For example, ENUM data is obtained using ENUM queries and QoS data may be obtained or provided by a node, such as an end office switch or HLR serving a subscriber. In addition, QoS data is not linked to ENUM data. Rather, QoS data may be stored for conventional subscriber identifiers, such as subscriber directory numbers. 
         [0007]    As described above, the mechanisms for obtaining ENUM and QoS data are separate and distinct. However, it may be desirable to combine QoS information with ENUM information in order to obtain enhanced contact information for a subscriber with multiple ENUM identities. Currently, such a combined mechanism does not exist. 
         [0008]    Accordingly, in light of these difficulties associated with conventional ENUM systems, there exists a need for improved methods, systems, and computer program products for providing a combination of ENUM and QoS services in a communications network. 
       SUMMARY 
       [0009]    According to one aspect, the subject matter described herein comprises methods, systems, and computer program products for providing QoS using E.164 number mapping (ENUM) data in a communications network. One method includes receiving a query message including an E.164 number. At least one uniform resource identifier (URI) associated with the E.164 number is located. QoS data corresponding to the at least one URI is obtained. Further, the query message can be responded to with the URI and the corresponding QoS data. 
         [0010]    The subject matter described herein for providing QoS using ENUM data may be implemented using a computer program product comprising computer executable instructions embodied in a computer readable medium. Exemplary computer readable media suitable for implementing the subject matter described herein includes disk memory devices, programmable logic devices, application specific integrated circuits, and downloadable electrical signals. In addition, a computer readable medium that implements the subject matter described herein may be distributed across multiple physical devices and/or computing platforms. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]    Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings of which: 
           [0012]      FIG. 1  is an exemplary communications network utilizing the ENUM system; 
           [0013]      FIG. 2  is an exemplary system for providing QoS using ENUM data in a communications network according to an embodiment of the subject matter described herein; 
           [0014]      FIG. 3  is a diagram of an exemplary ENUM query message according to an embodiment of the subject matter described herein; 
           [0015]      FIG. 4  is a flow chart illustrating exemplary steps for providing QoS service using ENUM data in a communications network according to an embodiment of the subject matter described herein; 
           [0016]      FIG. 5  is a diagram of an exemplary ENUM response message according to an embodiment of the subject matter described herein; 
           [0017]      FIG. 6  is a network diagram illustrating an exemplary system including a QoS server operable to provide QoS data to an ENUM flexible numbering (E-Flex) node according to an embodiment of the subject matter described herein; 
           [0018]      FIG. 7  is a block diagram illustrating an exemplary E-Flex node according to an embodiment of the subject matter described herein; 
           [0019]      FIG. 8  is a network diagram illustrating an exemplary system including a QoS server operable to provide QoS data to an E-Flex node to compare QoS levels between called and calling parties according to an embodiment of the subject matter described herein; and 
           [0020]      FIG. 9  is a network diagram illustrating an exemplary system including an E-Flex node receiving QoS data from a QoS server and presence data from a presence server according to an embodiment of the subject matter described herein. 
       
    
    
     DETAILED DESCRIPTION 
       [0021]      FIG. 2  illustrates an exemplary network, generally designated  200 , for providing QoS using ENUM data in a communications network according to an embodiment of the subject matter described herein. Referring to  FIG. 2 , network  200  can include an ENUM server  202  in operable communication with network  200 . Network  200  can include an SP  206  for providing communication between a PSTN  208  and an IMS  210 . Notably, the SP  206  may include, but is not limited to, a media gateway controller (MGC), softswitch (SS), mobile switching center (MSC), Tandem office (TO), End office (EO), and the like. Further, SP  206  can receive a call signaling message  226  for establishing communication between an end device in communication with PSTN  208  and IMS network  210 . A call signaling message  226  may be an SS7 ISUP message (e.g., IAM), an SS7 TCAP message, an SS7 MAP message, a SIGTRAN signaling message (e.g., M3UA, SUA, etc.), a session initiation protocol (SIP) message, or other call signaling message. For example, SP  206  can receive signaling message  226  from PSTN  208  for establishing communication between a telephone unit  212  connected to PSTN  208  and a subscriber identified in the message, e.g., by an E.164 number. Alternatively, SP  206  can receive messages from any suitable source for establishing communication with a subscriber identified by an E.164 number. 
         [0022]    SP  206  may determine whether an ENUM query is required based on whether the called party number corresponds to a subscriber of IMS network  210 . If SP  206  determines that an ENUM query is required, SP  206  can transmit an ENUM query  228  to ENUM server  202 . ENUM query  228  may contain an E.164 number. The E.164 number may be a called party telephone number. ENUM server  202  may also include an ENUM application  216  for performing a lookup in an ENUM database  218  for retrieving one or more URIs associated with the received E.164 number. For example, ENUM database  218  can maintain naming authority pointer (NAPTR) records associated with the URIs. The URIs are associated with the subscriber identified by the E.164 number. In one embodiment, the ENUM server  202  may also include a QoS database  240  where QoS information corresponding to each of the URIs may be stored. 
         [0023]    In one exemplary scenario, SP  206  receives an ISUP IAM signaling message (i.e., signaling message  226 ) and formulates an ENUM query message  228  that is based on the received IAM message. In one embodiment, the CdPN (called party number) value of 234-234-2341 is included (in reverse dotted notation) in a “question” section of the ENUM query message as shown in  FIG. 3 , which depicts an exemplary query message. ENUM query message  228  is routed to ENUM server  202 . ENUM server  202  is adapted to receive ENUM query message  228 , extract the E.164 called party subscriber identifier, and perform a lookup in ENUM database  218  that contains ENUM translation information. A QoS manager  250  may perform a lookup in QoS database  240  using the ENUM translation information. For example, QoS manager  250  may query QoS database  240  to obtain QoS data for each URI returned in the ENUM database access. 
         [0024]    In the example illustrated in  FIG. 2 , QoS data is stored on the same server or platform as the ENUM data. In an alternate embodiment, the QoS information may be stored on a QoS server separate from ENUM server  202  (not shown in  FIG. 2 ). In yet another alternate embodiment, the ENUM and QoS data may be maintained in the same database such that both ENUM and corresponding QoS data can be obtained in a single access. 
         [0025]    Table 1 below depicts an exemplary ENUM data structure, which may be found in database  218 , that maps an E.164 subscriber identifier to one or more URI values and that associates a QoS value with each respective URI value. 
         [0000]                                      TABLE 1                   ENUM URIs and QoS Data                E.164 Subscriber ID   URI   QoS                       234 234 2341   SIP URI A   Premium           234 234 2341   SIP URI B   Medium           234 234 2341   SIP URI C   Basic                        
In table 1, each URI maps to a QoS value. In an alternate embodiment, the ENUM data structure may map an E.164 subscriber identifier to an ENUM Service Type (in lieu of a URI Type), and a QoS value may be associated with the ENUM service type. An example of this embodiment is presented in Table 2.
 
         [0000]                                      TABLE 2                   ENUM Service Types and QoS Data                E.164 Subscriber ID   URI/Service Type   QoS                       234 234 2341   SIP   Premium           234 234 2341   Mailto   Medium                        
The sample data presented in Tables 1 and 2 includes an “abstract” QoS indicator value that is text-based (e.g., “Premium,” “Medium,” and “Basic”). In an alternate implementation, abstract QoS values may be numeric. For instance, a QoS indication system based on an arbitrary numeric range (e.g., 0-255, where 0 is interpreted as indicating the lowest QoS level and 255 is interpreted as indicating the highest QoS level) may be implemented. As defined herein, an abstract QoS indicator value is a QoS value that is not directly associated with a network-protocol-specific QoS mechanism, such as IP Precedence, Reservation Protocol (RSVP), multi-protocol label switching (MPLS), or other end-to-end QoS mechanisms. Regardless of the indication system used, it is the responsibility of the querying gateway that receives the abstract QoS indicator value to interpret the abstract value. For example, the gateway can associate the abstract QoS value (i.e., numeric, text-based, etc.) with a QoS level of service within a particular underlying network QoS mechanism (e.g., IP Precedence, RSVP, MPLS, etc.).
 
         [0026]    As opposed to being represented in an abstract manner, a QoS indicator value may instead be represented as a value that can be directly used within the context of a network-protocol-specific QoS mechanism. Specifically, the QoS indicator data associated with a given URI may be a protocol-specific QoS indicator. For example, a QoS indicator value may be a 3-bit value corresponding to the three most significant bits (MSB) of an IPv4 Type of Service (ToS) parameter. The 3-bit value may be used by a core network that employs IP precedence signaling as a means for implementing the core network QoS service. Depicted below in Table 3 is an example of ENUM QoS indicator data that is based on a three MSB IPv4 ToS. RFC 2475, which contains requirements for IPv6, increases the number of ToS bits to six bits. Thus, the present subject matter may support QoS indicators compatible with IPv6. 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                 TABLE 3 
               
             
             
               
                   
               
               
                 E.164 Numbers and Corresponding Protocol-Specific QoS Data 
               
             
          
           
               
                   
                 E.164 Subscriber ID 
                 QoS 
               
               
                   
                   
               
               
                   
                 234 234 2341 
                 7 
               
               
                   
                 234 234 2342 
                 4 
               
               
                   
                 234 234 2343 
                 0 
               
               
                   
                   
               
             
          
         
       
     
         [0027]      FIG. 4  is a flow chart illustrating exemplary steps for providing a quality of service using ENUM data in communications network  200  according to an embodiment of the subject matter described herein. Referring to  FIG. 4 , in step  400 , a network device, such as SP  206 , can generate a query message after receiving a call signaling message. In one embodiment, the query message may include an E.164 number or called party number. Pursuant to IETF ENUM specifications, the network device can convert the E.164 number to an ENUM message format. For example, if the E.164 number or called party number is 123-456-7890, an ENUM query message may read 0.9.8.7.6.5.4.3.2.1.E164.arpa. In this conversion example, the digit order of the telephone number is reversed and the highest level domain E164.arpa is appended at the end. 
         [0028]    At step  402 , SP  206  can communicate ENUM query message  228  to ENUM server  202  as described above. In one embodiment, the ENUM query  228  may be implemented utilizing a signaling protocol, such as session initiation protocol (SIP). 
         [0029]    At step  404 , ENUM application  216  can utilize ENUM query message  228  for performing a lookup in ENUM database  218  to retrieve one or more URIs associated with the received E.164 called party number. Exemplary URIs associated with E.164 number 0.9.8.7.6.5.4.3.2.1.E164.arpa may include sip:john@companydesk.com and mailto:john@serviceprovider.com. 
         [0030]    Next, at step  306 , ENUM server  202  can obtain corresponding QoS data for the one or more URIs. In one embodiment, ENUM server  202  accesses local QoS database  240  using the previously obtained URIs. In another embodiment, the QoS data may instead be obtained from a separate QoS server. In response to receiving a query message from ENUM server  202 , the QoS server may perform a lookup in a local database for retrieving QoS information for one or more of the URIs contained within the received query message. The QoS server may communicate to ENUM server  202  a QoS response message containing the retrieved QoS information for one or more of the URIs. Based on received message, ENUM application  216  can generate an ENUM response message  234  containing QoS information for one or more URIs associated with the E.164 number in the original ENUM message. For example, an ENUM response message may indicate that the URIs sip:john@companydesk.com and mailto:john@serviceprovider.com are associated with QoS levels of “Premium” and “Basic,” respectively. 
         [0031]    At step  408 , ENUM server  202  can communicate an ENUM response message with the corresponding QoS data to SP  206 . An exemplary ENUM response message is depicted in  FIG. 5 . In  FIG. 5 , the ENUM response includes an answer section with two URIs. The ENUM response also includes an additional section with two QoS values, one for each URI. 
         [0032]    In  FIG. 2 , the ENUM and QoS applications and databases are located on the same network node. In another embodiment, a QoS server (or database application) may be implemented as a separate network node from the ENUM server and a third node, referred to herein as the E.164 flexible numbering (E-Flex) node, that may provide access to both databases.  FIG. 6  illustrates such an embodiment. In the example shown in  FIG. 6 , SP  206  is adapted to generate an ENUM query message that contains a called party identifier, such as an E.164 number. The ENUM query is received (or intercepted) by an E-Flex function or node  604 , which may be implemented as a hardware component or a software function. E-Flex node  604  is adapted to relay the ENUM query or a copy of the ENUM query (i.e., message  629 ) to ENUM server  602 . The associated ENUM response  634  from ENUM server  602 , which contains one or more URI values, is received or intercepted by E-Flex node  604 . In one embodiment, E-Flex node  604  is not required to receive or intercept the ENUM query, but instead may simply receive or intercept the ENUM response  639 . 
         [0033]    E-Flex node  604  may be configured to buffer the ENUM response message  634  and to generate a QoS query message  635  that is routed to a QoS server  640 . The QoS query message may contain the called party identifier (e.g., E.164 number) and/or a URI value(s) extracted from the buffered ENUM response message  634 . 
         [0034]    Presented in  FIG. 7  is an exemplary E-Flex node  604 , which is adapted to provide the aforementioned E-Flex functionality. E-Flex node  604  includes a communication interface  704  that is adapted to send and receive messages, such as ENUM query and response messages, via a communications network, such as an IP network or an SS7 network. In the illustrated example, communication interface  704  includes an IP stack  705  and a distribution function  706  that is adapted to distribute a received ENUM query message to an E-Flex processor module  708 . Multiple E-Flex processor modules may be provisioned within an E-Flex node. An E-Flex processor module  708  includes a processing manager function  710 , an E.164-to-ENUM address mapping data structure  712 , and a routing function  714 . E-Flex processor  708  is adapted to receive an ENUM query message from the distribution function  706 . Processing manager function  710  is adapted to extract an E.164 subscriber identifier from the query message and use the extracted subscriber identifier to search the E.164-to-ENUM address mapping data structure  712  for a matching entry. If a matching entry is found, manager function  710  is adapted to modify the ENUM query message so as to address the ENUM query message to the ENUM database/server address returned from the matching entry. The modified ENUM query message is then passed to the routing function  714 , which determines on which outbound communication link/socket/SCTP association/etc. the modified ENUM query message is to be transmitted. Routing function  714  then passes the modified message to the appropriate communication interface/module for transmission towards the “target” ENUM database/server. 
         [0035]    E.164-to-ENUM address mapping data structure  712  may include exception and range-based components, and in which case the manager function  710  is adapted to search the exceptions data first, followed by the range-based or default data. For example, a first group of entries in databases  712  may be indexed by E.164 numbers that are exceptions to ranges of E.164 numbers by which a second group of entries are indexed. For example, the E.164-formatted number 9194605001 may correspond to a subscriber that has been ported out of a service provider&#39;s network. The service provider may own a block of E.164 formatted numbers ranging from 9194605000 to 9194605999. An entry may be provisioned in databases  712  for the ported out subscriber so that ENUM query messages for the subscriber are routed to the new service provider. The entry for 9194605001 represents an exception to the range 9194605000-9194605999 because it is indexed by a number within the range but may point to a different ENUM database or network. 
         [0036]    In one implementation, E-Flex node  604  may be an SS7 signal transfer point (STP) with or without SS7/IP gateway functionality. An exemplary STP platform on which E-flex node  604  can be implemented is the Eagle® platform available from Tekelec of Morrisville, N.C. 
         [0037]    Returning to  FIG. 6 , the called party identifier may be used to perform a lookup in a QoS database  642  at the QoS server  640  and return a subscriber-specific QoS value. In this scenario, the QoS database  642  may contain data similar to that previously shown in Table 3. In an alternate embodiment, the URI value(s) may be used to perform a lookup in a QoS database  642  at the QoS server  640  and return a URI-specific QoS value(s). In this instance, the QoS database  642  may contain data similar to that previously shown in Tables 1 and 2. 
         [0038]    Upon receipt of a QoS response message  636 , the E-Flex node  604  is adapted to extract QoS information from the QoS response message and incorporate at least some of the QoS information into the buffered ENUM response message. The modified ENUM response message  639  is then routed to originating SP  606 . The QoS information may be incorporated in the additional section of the ENUM response, as illustrated in  FIG. 5 . In an alternate embodiment, QoS server  640  may return modified URI values that incorporate URI-specific QoS information. For example, the modified URI values may be Pete_High_QoS@tekelec.com. 
         [0039]    In  FIG. 6 , QoS data is obtained using called party information. In an alternate embodiment, QoS information may be obtained using called and calling party information, and a rule may be applied to determine whether to apply the calling or called party QoS to a communication.  FIG. 8  depicts such an embodiment. In  FIG. 8 , an E-Flex node  604  is adapted to receive (or intercept) an ENUM query and/or response. The E-Flex node  604  may also be configured to query QoS server  640  for QoS information associated with the called party identifier or URI identifier(s) from the ENUM query  828  or ENUM response  834 . In this embodiment, the E-Flex node  604  is further adapted to query QoS server  640  for QoS information associated with the calling party (message  837  and message  838 ). Upon receiving QoS information from QoS server  640  for the called party/URI identifiers and for the calling party, E-Flex node  604  is adapted to modify the ENUM response message to include the highest QoS value among the called party/calling party QoS values returned by QoS server  640 . In this manner, a call or communication session established between a called and calling party will receive a QoS service level corresponding to the highest QoS service level available among the called and calling parties. For example, a calling party who has contracted with a service provider for a ‘Premium’-level QoS will receive ‘Premium’ QoS during a communication with a called party that has contracted with a service provider for a lesser QoS service level. More specifically, regardless of whether the QoS levels associated with the called party or the calling party involved in a particular communication, the highest QoS level will be utilized. 
         [0040]    In the example illustrated in  FIG. 8 , QoS information for the called and calling parties is maintained in QoS database  640 . In an alternate embodiment, ENUM server  602  (or associated database application) is instead adapted to store, access, and return QoS indicator information associated with the called party, while QoS server/database application  640  is adapted to store, access, and return QoS indicator information associated with the calling party. In a manner similar to that described above, E-Flex node  604  is adapted to examine QoS indicator values associated with both the called and calling parties, and to select the highest QoS indicator value thereby allowing the call/communication to be controlled by the highest QoS service level available between the called and calling parties. In an alternate embodiment, E-Flex node  604  may be adapted to select the lowest QoS indicator value. Consequently, the call is then handled by the lowest QoS service level associated with either the called or calling party. 
         [0041]    According to one enhancement of the subject matter described herein, presence data may be returned with ENUM data and QoS information may be obtained for the presence-qualified ENUN data.  FIG. 9  depicts an embodiment in which a presence server (which may be coupled to the QoS server, E-Flex function, ENUM server, the SP, and like network components) may be queried to determine the availability/preference status of a URI determined and/or returned by an ENUM database. In various embodiments, the presence query may be performed by the ENUM database, the QoS database, the E-Flex node, or the originating SP. The presence query may be used to identify available URIs such that QoS data is obtained for the available URIs. In one implementation, QoS queries may not be generated for available URIs. 
         [0042]    For example, in one embodiment (as shown in  FIG. 9 ) presence server  950  can maintain a database  952  containing presence status information for the URIs. In response to receiving the query message from ENUM server  602 , presence server  204  can perform a lookup in database  952  to retrieve presence status information of each of the URIs. The retrieved presence status information for each URI can indicate the availability or unavailability associated with the URI. Presence server  950  transmits a response message containing the presence status information for one or more of the URIs (i.e., data indicating whether a URI is available or unavailable) to ENUM server  602 . ENUM server then forwards the URI(s) and presence data to the E-Flex node  604 . In an alternate embodiment, presence server  950  may return only the available URIs in the response message to ENUM server  602 , which subsequently provides the received URIs to the E-Flex node  604 . Based on the presence status information received, ENUM server  902  can obtain QoS information for the available URIs. Once obtained, the QoS information is transmitted to SP  206  via E-Flex node  604 . 
         [0043]    It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.