System and method for routing calls in a wireless network using a single point of contact

[0001] This invention relates to the art of telecommunications and more particularly to a system and method for routing a call in a wireless communications network made to a called party universal destination identifier.

[0002] Wireless communications networks, also known as cellular networks, have been widely adopted around the world. These telecommunications systems can do more than transfer voice calls. A wide variety of different calls transferring a wide variety of different types of media can now be made over a wireless communications network.

[0003] A user, also known as a subscriber, can have a wide variety of devices on which they wish to receive calls. Currently, each device can only be reached by the calling party using the corresponding destination identifier for that device. A calling party placing a call to the subscriber, also referred to as the called party, will have to keep track of the plurality of different “numbers” for reaching the appropriate called party device.

[0004] It is desirable to provide a called party with a single point of contact whereby the called party can receive different call types at different destinations, each destination corresponding to a specific device intended for receiving that particular call type.

[0005] A system and method of routing calls in a wireless communications network using a single point of contact is provided.

[0006] In accordance with a first aspect of the invention, the method includes determining the call type, selecting a call-type-specific destination identifier for the call from a plurality of called party destination identifiers based on the call type, and routing the call to the called party using the selected call-type-specific destination identifier.

[0007] In accordance with a second aspect of the invention, the step of determining the call type can include determining the call protocol, determining the media type, and determining the call type from the call protocol and the media type.

[0008] In accordance with another aspect of the invention, the system includes means for determining the call type, means for selecting a call-type-specific destination identifier for the call from a plurality of called party destination identifiers based on the call type, and means for routing the call to the called party using the selected call-type-specific destination identifier.

[0009] Further scope of the applicability of the present invention will become apparent from the detailed description provided below. It should be understood, however, that the detailed description and specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only, since various changes and modifications within the spirit and scope of the invention will become apparent to those skilled in the art.

[0016] For simplicity and ease of reference, the following acronyms shall be used in the present specification to refer to structural and/or functional network elements and/or entities, relevant telecommunications standards, protocols and/or services, terminology, etc., as they are commonly known in the telecommunications art, except to the extent they have been modified in accordance with aspects of the present invention:

• • [0017] 3G—3^rd Generation
  • [0018] 3GPP—3^rd Generation Partnership Project
  • [0019] 3GPP2—3^rd Generation Partnership Project 2
  • [0020] AAA—Authentication/Authorization/Accounting
  • [0021] AH—Address Handling
  • [0022] AS—Application Server
  • [0023] BGCF—Border Gateway Control Function
  • [0024] CCF—Call Control Function
  • [0025] CDMA—Code Division Multiple Access
  • [0026] CSCF—Call Session Control Function
  • [0027] HLR—Home Location Register
  • [0028] HSS—Home Subscriber Server
  • [0029] ICGW—Incoming Call Gateway
  • [0030] IMS—IP Multimedia Subsystem
  • [0031] IP—Internet Protocol
  • [0032] MGCF—Media Gateway Control Function
  • [0033] MGW—Media Gateway
  • [0034] MMT—Multimedia Terminal
  • [0035] MRFC—Multimedia Resource Function Controller
  • [0036] MRFP—Multimedia Resource Function Processor
  • [0037] PDN—Public Data Network
  • [0038] PLMN—Public Land Mobile Network
  • [0039] PSDN—Packet Switched Data Network
  • [0040] PSTN—Public Switched Telephone Network
  • [0041] PTT—Push-to-Talk
  • [0042] RAN—Radio Access Network
  • [0043] SIP—Session Initiation Protocol
  • [0044] SMS—Short Message Service
  • [0045] SMT—Single Media Terminal
  • [0046] SPD—Serving Profile Database
  • [0047] UMTS—Universal Mobile Telecommunications System
  • [0048] VOIP—Voice over IP
  • [0049] WLAN—Wireless Local Area Network

[0050] With reference to FIG. 1, an optionally 3GPP/3GPP2 compliant telecommunications environment or network 10 is equipped and/or arranged to manage and/or route multimedia communications between terminals employing the same. Other suitable telecommunications environments, however, may be employed. The network 10 includes an IMS 20 that incorporates in the usual manner a number of network entities and/or elements, namely, one or more of a CSCF 22, AS 24, MGW 26, MGCF 28, BGCF 30, MRFP 32, MRFC 34, HSS 36. As is known in the art, the IMS 20 manages call sessions and provides and administers packet switching for multimedia communications within the network 10.

[0051] For exemplary purposes, an MMT 40 also referred to as the calling party terminal or calling party, is shown as a mobile MMT (namely, a multimedia enabled mobile phone as is commonly known) that is operatively connected to the IMS 20 via a RAN 42. The RAN 42, as it is known, is that portion of a mobile network that handles subscriber access, including radio base stations and control and concentration nodes, i.e., the portion relating to “over the air” communications between the mobile terminal and the network base station. A packet data subsystem 44 interfaces the RAN 42 with the IMS 20 and PDN 52 in the usual manner.

[0052] Another MMT 50, referred to a the called party terminal is shown as a laptop or notebook type computer operatively connected to the IMS 20 via a PDN 52. The MMT 50 optionally employs a WLAN or wire line, in the usual manner, to operatively connect to the PDN.

[0053] An SMT 60, also referred to as the called party terminal is shown as an ordinary telephone equipped to handle only voice communications. The SMT 60 is operatively connected to the IMS 20 via a PSTN/PLMN 62.

[0054] Only a first 50 and second 60 called party terminal are shown in FIG. 1 for the purpose of simplicity herein. However, it is to be appreciated that typically a plurality of called party terminals are similarly situated. Additionally, while depicted as a specific type of MMT or SMT, other suitable terminals capable of communicating over the wireless communications network 10 are also contemplated.

[0055] With continuing reference to FIG. 1, the bearer paths, as are known in the art, that carry and/or relay the communication traffic and/or user information intended to be transmitted from one terminal to another are shown as solid lines. Control paths, as are known in the art, carry and/or relay associated signaling and/or control commands or messages to and between appropriate network elements and/or entities such that call sessions are properly managed-and routed. The control paths are shown as dashed lines in FIG. 1. Suitably, SIP and/or other appropriate known protocols are used on the control and bearer paths, respectively, e.g., the known H.248 protocol is suitably employed for media gateway controls. The CSCF 22, BGCF 30, MGCF 28, MRFC 34 and AS 24 comprise the call control and signaling functionality for the IMS 20, while the bearer paths interface with the MRFP 32 and MGW 26 to provide and support interconnectivity to external networks and/or subsystems, such as, the packet data subsystem 44, PDN 52 and PSTN/PLMN 62.

[0056] The CSCF 22 supports and controls multimedia sessions. The CSCF 22 invites the MGCF 28 and/or MRFC 34 to call sessions to control the establishment and maintenance of bearer paths for call sessions, e.g., by adding, modifying or deleting appropriate bearer paths for respective call sessions. The CSCF 22 is the signaling entity for call session control. It manages sessions (e.g., using SIP and/or other appropriate call/session establishment protocols), provides features and services and coordinates with other network elements for session control, service control and resource allocation. The CSCF 22 performs several functions including Incoming Call Gateway (ICGW) in which it acts as a call session entry point and routes incoming calls to the called party destination.

[0057] The CSCF 22 also performs Call Control Function (CCF) in which it executes call setup/termination and state/event management. It interacts with the MGCF 28 for calls to/from the PSTN/PLMN 62, and with the BGCF 30 for calls to the PSTN/PLMN 62 to determine the appropriate MGCF 28 to use. It also controls the MRFP 32 via the MRFC 34 (which interprets information or signals coming from the CSCF 22 and controls the MFRP 32 accordingly) in order to support conferencing and other multi-party services. SIP level registrations from subscribers are processed in CCF. The CCF may provide service trigger mechanisms to the AS 24 to invoke services provided thereby (either locally, at the AS 24, or elsewhere). It also reports call events for billing, auditing, intercept or other purposes, and may query the AS function to check whether a requested communication is allowed given the current subscription.

[0058] The CSCF 22 also provides a Serving Profile Database (SPD) in which it interacts with the HSS/AAA 36 to receive and cache user profile information.

[0059] The CSCF 22 also performs Address Handling (AH) in which it performs address analysis, translation, modification (when appropriate) and mapping.

[0060] The MGW 26 acts as a bearer path interface between the IMS 20 and externals networks and/or subsystems, and provides translation resources and resources for modifying the bearer stream (e.g., encoding, transcoding, compression, packetization, depacketization, etc.). It interacts with the MGCF 28 (which interprets signaling coming from the CSCF 22 and controls the MGW 26 accordingly) in order to achieve resource allocation, bearer path control, and payload processing. The MGCF 28 communicates with the CSCF 22 in order to control the call state for media channels on one or more MGWs and performs conversions between legacy and 3G UMTS/CDMA network call control protocols. Similarly, the MRFC 34 controls the media stream resources in the MRFP 32 which also acts as a bearer path interface between the IMS 20 and external networks and/or subsystems, however, being able to provide for conferencing or multiple party communications or other more advanced media services (relative to the MGW 26).

[0061] The HSS 36 maintains subscriber and system related data, user profiles, locations, etc. Optionally, the HSS 36 also contains what is known as the HLR functionality and/or AAA function. Suitably, the HSS database can include: user identification, via numbering and addressing information; user security information, including network access control information for authentication and authorization; user location information for user registration and locating; and a user profile, including identification of the services subscribed to and other service specific information. The HSS 36 also includes one or more call-type-specific destination identifiers associated with a called party by a single point of contact as described below.

[0062] Referring now to FIGS. 2 and 3, a method of routing a call in a wireless communications network using a single point of contact, also referred to as a Subscriber Universal Destination Identifier (SUDI), is shown generally at 100. The method 100 includes calling a called party SUDI at 102. The SUDI can be a phone number or a Uniform Resource Identifier (URI). A URI can be used to identify points of content, such as a page of text, a video or sound clip, a still or animated image, or a program. Examples of a URI can include, but are not limited to, a Uniform Resource Locator (URL) such as an Internet Protocol (IP) address, a Uniform Resource Name (URN), a Session Initiation Protocol (SIP) address, or an E164 number.

[0063] A URI can describe the mechanism used to access the resource at the destination, such as the specific computer that the resource is housed in at that destination, and the specific name of the resource, such as for example a file name on the computer. As an example, a URI may be: http://www.w3.org/Icons/WWW/w3c_main.gif. This URI identifies a file that can be accessed using the Web protocol application, Hypertext Transfer Protocol, (“http://”) that is housed on a computer named “www.w3.org” (which can be mapped to a unique Internet address). In the computer's directory structure, the file is located at the pathname of “/Icons/WWW/w3c_main.gif.” Character strings that identify File Transfer Protocol FTP addresses and e-mail addresses are also URLs and thus are URIs. A URN is a form of URI that has “institutional persistence,” such that its exact destination may change from time to time, but an agency accessed by the URN will be able to find it.

[0064] A wireless subscriber can use a single SUDI to receive plurality of different call types over the wireless communications network 10. Examples of the call types can include, but are not limited to, voice calls, a data session for transferring data over the wireless communications network, and SMS text messages, video sessions, or a combination of these which can be referred to as multimedia sessions. The single SUDI can be used to route calls of different call types to different destinations indicated by corresponding call-type-specific destination identifiers. Examples of these destinations can include, but are not limited to a wireless communications terminal or a wireline terminal for voice calls, a computer or a multimedia wireless terminal for data transmissions. The called party can specify the different destinations for different call types using call-type-specific destination identifiers. More than one call type can be sent to a destination identified by a call-type-specific destination identifier.

[0065] Calling the called party SUDI at 102 generates one or more call control commands, referred to generally as a “call request”, at 104. As shown by way of example in FIG. 4, the call request 202 is sent to the CSCF 22. The call request 202 can be made using any suitable call control command or commands using any suitable protocol. The call request 202 typically includes a session ID, an indicator of the Originating Host (the calling party), and an indicator of the Destination Host (as identified by the SUDI). The call request 202 can include a media descriptor as described below.

[0066] The method 100 also includes determining the call type at 106. The CSCF 22 can determine the call type at 106 from the call request 202. Referring to FIG. 3, the step of determining the call type at 106 is shown in further detail. The CSCF 22 determines the call protocol used in the call control signaling of the call request at 108. If the call protocol does not support multiple call types at 110, the call type is determined from the protocol used for the call request at 112. In an example, which should not be considered limiting, if the call request is made using ISUP signaling which supports only voice calls then the CSCF 22 determines that the call type is an ISUP voice call from the call protocol at 112.

[0067] If the call protocol used for the call request does support multiple call types at 110, the method 100 also includes determining the media type at 114. The media type is the type of media that will be transferred by the call, examples of which can include, but are not limited to “audio”, “video”, “application”, “data” and “control”, among others. The difference between “application” and “data” is that the former is a media flow such as whiteboard information, and the latter is bulk-data transfer such as multicasting of program executables which will not typically be displayed to the user. “Control” is used to specify an additional conference control channel for the session.” The media type can be determined from the media descriptor included in the call request 202. The media descriptor can be any indicator of the media type to be transferred in the call that is included in the call request.

[0068] The CSCF 22 uses the call protocol and the media type to determine the call type at 116. In an example, which should not be limiting, the call request is made using SIP signaling call control protocol when the calling party calls the called party SUDI at 102. The SIP protocol can support more than one call type. Therefore, the CSCF 22 determines the media type to be transferred in the call from the media descriptor included in the call request at 114. In SIP, the media type is described within the Session Description Protocol (SDP) which is defined in IETF (Internet Engineering Task Force) RFC 2327. The SDP indicates the media type using a media descriptor media line, such as for example a line starting with ‘m=’ that indicates the media type. However, other conventions/protocols can be used and the media type can be determined from the media descriptor used therein.

[0069] The media may be transferred as a media payload type as defined in the RTP (Real-Time Transport Protocol) AudioNideo Profile. In this example, a subfield contains a payload type number which is used to identify a particular payload type format. There can be additional attribute lines to define details of the format, such as for example attribute lines commencing with ‘a=’. An example of the media type from the RFC2327 protocol, which should not be considered limiting, can include a static payload type u-law PCM coded single channel audio sampled at 8 KHz, as defined in the RTP AudioNideo profile as payload type 0. The media descriptor used to determine the media type for such a stream sent to UDP port 49232 is:
m=video 49232 RTP/AVP 0
The call type is determined to be an RTP call having the media type described above.

[0070] As another example, a dynamic payload type, such as for example 16 bit linear encoded stereo audio media sampled at 16 KHz, can include a media type as defined by a media descriptor using a dynamic RTP/AVP payload type 98 with:
m=video 49232 RTP/AVP 98; and
a=rtpmap:98 L16/16000/2
The call type is determined to be an RTP call having the media type described above.

[0071] Referring now to FIGS. 2 and 4, the method 100 also includes determining a call-type-specific destination identifier (CDI) at 120. The CDI identifies the destination that the call having the call type as determined at 106 is routed to. The CDI can identify any destination suitable to the call type to which a call can be routed to over a wireless communications network 10. Examples can include, but are not limited to a phone number of a wireless communications terminal, the phone number of a wireline terminal, an IP address, etc.

[0072] The CDI can be determined by the CSCF 22, the HSS 36, or any other suitable network node in the wireless communications network 10. In the examples described herein, which should not be considered limiting, the CDI is determined by the HSS 36. After determining the call type at 106, the CSCF 22 sends a Location_Info_Request 204 to the HSS 36. The Location_Info_Request 204 includes the call type, the originating host and the SUDI. The HSS determines the CDI at 120 using the SUDI and the call type. For example, the CDI can be determined via a table lookup once the SUDI and call type are known. A plurality of CDIs can be provisioned at the HSS for a variety of call types, by the subscriber or by the network provider. The subscriber can provide the network 10 with a CDI for each corresponding call type. For example, all call types transferring data are to be sent to a destination identified by CDI #1 (e.g. IP address of computer), all ISUP voice calls are to be sent to a destination identified by CDI #2 (e.g. a wireline terminal phone number), for all SMS messages are to be sent to a destination identified by CDI #3 (e.g. a wireless terminal), etc.

[0073] The HSS 36 sends a Location_Info_Answer 206 back to the CSCF 22 which includes the CDI for the call type determined at step 106. The CSCF 22 then routes the call to the call-type-specific destination as identified by the CDI at 122.

[0074] Referring now to FIG. 5, a message flow illustrating another example is shown generally at 300. In this example, the calling party 40 places an audio call, that is a normal voice call, to the called party using a SIP SUDI=sip:[email protected].

[0075] As shown in part A of the message flow 300, the call request 202 is an INVITE message from the calling party terminal 40 to the CSCF 22. The call request (INVITE message) includes a media descriptor:
m=audio xxxx RTP/AVP 0.

[0076] The CSCF 22 uses the call request to determine that the call protocol is SIP. Further, since the SIP call protocol can support more than one call type by being able to transfer more than one media, the CSCF 22 determines the media type from the media descriptor as an ‘audio’ call on port number xxxx and the codec is 0 which stands for G711 mu-law. The CSCF 22 therefore determines the call type to be a SIP audio/G711 call.

[0077] In part B, The CSCF 22 makes the Location Info Request (LIR) query to the HSS 36 which includes the call type (SIP audio/G711) and the SUDI. The HSS 36 determines the CDI at 120 using the call type and SUDI and responds to the Location Info Request query by sending a Location Info Answer (LIA) back to the CSCF 22 which includes the CDI for that call type. In this example, the CDI is a telephone number, 212-555-1212, for a terminal where the called party wants to receive SIP audio/G711 calls.

[0078] In part C, the call is routed to the destination using the CDI in a known manner. The CSCF 22 sends an INVITE message to the appropriate MGCF 28 to route to the call to destination telephone number. The MGCF 28 in turn sends an IAM (initial address message) to the PSTN 62 to set up the call. H.248 messages are sent to the MGW 26 to set up the bearer interconnection from IP to TDM. 83 Session Progress and 180 Ringing messages are returned to the calling party 40 to indicate that the call is being set-up. Once the call is answered by the PSTN 62 an ANM (Answer Message) is returned to the MGCF 28, which in turn sends a 200OK SIP message to the CSCF 22 and then to the calling party 40. And ACK (Acknowledge message) is returned and the bearer path for the call is established and the call is routed to the destination/device indicated by the call-type-specific destination identifier.

[0079] It is also to be appreciated that particular elements or components described herein may have their functionality suitably implemented via hardware, software, firmware or a combination thereof. Additionally, it is to be appreciated that certain elements described herein as incorporated together may under suitable circumstances be stand alone elements or otherwise divided. Similarly, a plurality of particular functions described as being carried out by one particular element may be carried out by a plurality of distinct elements acting independently to carry out individual functions, or certain individual functions may be split-up and carried out by a plurality of distinct elements acting in concert. Alternately, some elements or components otherwise described and/or shown herein as distinct from one another may be physically or functionally combined where appropriate.

[0080] The above description merely provides a disclosure of particular embodiments of the invention and is not intended for the purposes of limiting the same thereto. As such, the invention is not limited to only the above-described embodiments. Rather, it is recognized that one skilled in the art could conceive alternative embodiments that fall within the scope of the invention.