Patent Application
20110142015
In an increasingly networked world, more and more traffic, such as data, voice, and video, is transmitted over public and proprietary networks. Wireless networks, in particular, are becoming increasingly popular as networks through which subscribers obtain both voice services (e.g., telephone calls) and data services (e.g., email and web surfing).
Internet Protocol (IP) multimedia subsystem (IMS) is a standard used to deliver IP multimedia to client devices. Under IMS, communication devices, such as mobile telephone devices, may connect to a control server that monitors and controls the connectivity of the mobile device to the telecommunication network. The telecommunications network may include a number of instances of the control servers. When the mobile device first connects to the network, it may connect to one of the control servers, with which it will subsequently interact.
The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention.
Implementations described herein may include a telecommunication network for interconnecting a number of client devices. The telecommunication network may be, for example, a long term evolution (LTE) based network or a 3rd Generation Partnership Project (3GPP or 3G) based network, that provides IMS services to the client devices. When initially registering for the IMS services, a fully qualified domain name (FQDN) may be used to identify a session initiation protocol (SIP) server with which the client device may subsequently communicate. IP addresses corresponding to the FQDN may be resolved via a lookup at a domain name system (DNS) server, to obtain one or more numeric IP address that the client may use to communicate with the SIP server. If the client device is unable to connect or loses connection with the SIP server, the client device may try to reconnect with another SIP server using an alternative one of the returned IP addresses.
As shown in
Client devices 110 may generally include devices designed to communicate with network 105. Client devices 110 may include, for example, mobile telephones, smart phones, electronic notepads, laptops, personal computers, and/or personal digital assistants (PDAs). Client devices 110 may establish wireless communication sessions with network 105. The wireless communication sessions may be used for voice (e.g., telephone calls) or data sessions.
As previously mentioned, first network 105 may include components of a wireless network. In one exemplary implementation, and as illustrated, first network 105 may include components that implement IMS services based in an LTE network. Other network technologies, such as International Mobile Telecommunications-2000 (“3G”), or second-generation wireless telephone technology (“2G”), may alternatively or additionally be implemented.
As particularly shown in
Base station 120 may provide an interface for client devices 110. Base station 110 may include, from a network access perspective, the PHYsical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data control protocol (PDCP) layer. Base station 110 may also offer radio resource control (RRC) functionality corresponding to the control plane. Base station 110 may perform many functions including radio resource management, admission control, scheduling, cell broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of user plane packet headers.
P-CSCF servers 130 may each implement a SIP proxy server that processes SIP signaling packets in first network 105. Each P-CSCF server 130 may generally act as the first point of contact for client device 110 for IMS services. Each client device 110 may be assigned a P-CSCF server 130 during registration of the client device. P-CSCF server 130 may subsequently operate in the signaling path of IMS messages.
HSS 140 may include computing devices that implement a master database that supports network entities, such as P-CSCF servers 130. HSS 140 may store subscription-related information for subscribers and may perform authentication and authorization services for the subscribers. HSS 140 may additionally store and provide information about the subscriber's location and IP information. As described in more detail below, HSS 140, during initial registration processing of a client device 110, in network 105, may provide, based on a domain name (e.g., a FQDN), the client device with IP addresses of P-CSCF servers 130 to which the client device should connect.
PGW 150 may provide connectivity to external networks, such as second network 180. A client device 110 may have simultaneous connectivity with more than one PGW to multiple additional networks. PGW 150 may perform, for example, policy enforcement, packet filtering for each user, charging support, lawful interception, and/or packet screening.
DNS server 160 may include one or more servers that act to translate text-based domain names into numerical IP addresses that are used to route information in networks, such as networks 105 and 180. DNS server 160 may be implemented in networks 105 and/or 180 as a distributed server system in which different servers handle different portions of a hierarchy of domains.
Second network 180 may include, for example, a public packet-based network, such as the Internet. Second network 180 may include DNS servers, such as DNS server 160.
Although
Bus 210 may include a path that permits communication among the components of device 200. Processor 220 may include a processor, a microprocessor, or processing logic (e.g., an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA)) that may interpret and execute instructions. Main memory 230 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor 220. ROM 240 may include a ROM device or another type of static storage device that may store static information and instructions for use by processor 220. Storage device 250 may include a magnetic and/or optical recording medium and its corresponding drive, or a removable form of memory, such as a flash memory.
Input device 260 may include a mechanism that permits an operator to input information to device 200, such as a keyboard, a mouse, a button, a pen, a touch screen, voice recognition and/or biometric mechanisms, etc. Output device 270 may include a mechanism that outputs information to the operator, including a display, a light emitting diode (LED), a speaker, etc. Communication interface 280 may include any transceiver-like mechanism that enables the client/server entity to communicate with other devices and/or systems. For example, communication interface 280 may include mechanisms for communicating with another network device. In some implementations, input device 260 and/or output device 270 may not be implemented by device 200. For example, device 200 may represent a network device such as base station 120, P-CSCF 130, HSS 140, PGW 150, or DNS server 160. In these situations, device 200 may be a “headless” device that does not explicitly include an input or an output device.
As will be described in detail below, device 200 may perform certain operations relating to the registration of a client device 110 for IMS services. Device 200 may perform these operations in response to processor 220 executing software instructions contained in a computer-readable medium, such as main memory 230. A computer-readable medium may be defined as a logical or physical memory device. A logical memory device may include a space within a single physical memory device or spread across multiple physical memory devices.
The software instructions may be read into main memory 230 from another computer-readable medium, such as storage device 250, or from another device via communication interface 280. The software instructions contained in main memory 230 may cause processor 220 to perform processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
In one particular implementation, software instructions, such as instructions stored in main memory 230 of device 200 implementing HSS 140, may be designed to respond to initial requests from client devices 110, such as IMS registration requests, with a FQDN corresponding to one or more P-CSCF servers 130. Software instructions, such as instructions stored in main memory 230 of device 200 implementing PGW 150, may be designed to respond to the FQDN received from HSS 140 to issue a DNS query to DNS server 160 and on behalf of client device 110.
Although
Available CSCF servers storage component 310 may receive and maintain information relating to P-CSCF servers 130 that are available to be used by client devices 110 in first network 205. Available CSCF servers storage component 310 may store this information in, for example, a database or a file. In one implementation, the information relating to available P-CSCF servers 130 may be manually entered by a network administrator. In another implementation, information relating to the available P-CSCF servers 130 may be automatically determined using, for example, a network discovery protocol implemented by HSS 140 or another device 200.
FQDN field 410 may include the fully qualified domain name corresponding to a particular P-CSCF server 130 or set of P-CSCF servers 130. In table 400, three exemplary rows are given, corresponding to three P-CSCF server sets 130 that have the domain names: (1) cscf1.abc.com, (2) cscf2.abc.com, and (3) cscf3.abc.com.
Number of active clients field 420 may store a value indicating the number of active client devices 110 assigned to the P-CSCF servers 130 for a domain name. Field 420 may generally be used to store an indication of the load being processed by a particular domain name. In one implementation, HSS 140 may increment or decrement the number of active clients field 420 as new client devices 110 register with HSS 120 or as client devices 110 are no longer served by the IMS system. Additionally, in some implementations, P-CSCF servers 130 may periodically or occasionally disseminate load information to HSS 140, which may be used to update number of active clients field 420.
Status field 430 may store a label indicting the current status of one or more of the corresponding P-CSCF servers 130. The status information may include, for example, a label such as “available” or “offline,” potentially indicating that the corresponding P-CSCF server(s) are functioning normally or are not functioning. In one implementation, P-CSCF servers 130 may occasionally communicate with HSS to inform HSS 140 of its current status.
Referring back to
IMS registration component 510 may operate to register client device 110 for IMS services in network 105. The registration may occur, for example, when device 110 initially communicates with network 105. IMS registration component 510 may send a registration request message to HSS 140. As part of the registration process, HSS 140 may send a FQDN to DNS server 160 on behalf of client device 110. In one implementation, HSS 140 may send the FQDN to PGW 150, which may act as the DNS resolver that makes the actual DNS query to DNS server 160 on behalf of client device 110. Alternatively, HSS 140 may send the FQDN to client device 110, which may resolve the FQDN using DNS server 160.
IP address selection component 520 may receive one or more IP addresses in response to the DNS query made by PGW 150. The received addresses may correspond to P-CSCF servers 130 in network 105. IP address selection component 520 may select one of the received IP addresses and initially connect to the P-CSCF server 130 corresponding to the selected IP address. If the connection to the selected P-CSCF server 130 is lost, such as if the P-CSCF server goes offline, IP address selection component 520 may select another one of the received IP addresses and connect to the P-CSCF server 130 corresponding to that IP address. In one implementation, IP address selection component 520 may select the first IP address received as the IP address to use. In another possible implementation, IP address selection component 520 may select another IP address to use, such as one randomly chosen from the received IP addresses.
Process 600 may include receiving an IMS registration request from one of client devices 110 (block 610). From the point of view of the client device, the registration may generally include the client device “attaching” to the radio access network (e.g., the wireless portion of network 205) and then forming a connection with one of P-CSCF servers 130, which may serve as the initial SIP proxy for the client device into the IMS system. In one implementation, client registration response component 320 of HSS 140 may receive the registration request.
Process 600 may further include looking up a FQDN, corresponding to one or more P-CSCF servers 130, for client device 110 (block 620). The FQDN may be determined based on table 400. For example, client registration response component 320 may choose an available FQDN from table 400 based on, for instance, network load, the location of the client device, the roaming status of the client device, other network-based information, or client-based policy information. In an alternative implementation, client registration response component 320 may be configured to use a single FQDN for all IMS registration requests. In this situation, the “lookup” performed in block 620 may correspond to a memory access for the parameter or variable that holds the FQDN.
Process 600 may further include resolving of the FQDN on behalf of client device 110 (block 630). Resolving the FQDN may include translating the FQDN into a numerical IP address. In one implementation, HSS 140 may transmit a message to PGW 150 that passes the FQDN to PGW 150. PGW 150 may then perform the DNS resolution, such as by submitting a DNS query to DNS server 160. Alternatively, the FQDN may be forwarded to client device 110 for resolution. Forwarding the FQDN to PGW 150 may be particularly beneficial, however, as it may keep the DNS interactions off the radio access portion of network 105 (e.g., the wireless portion between base stations 120 and client devices 110), thus reducing the load on the radio access network.
Process 600 may further include forwarding the IP address obtained from the FQDN resolution to client device 110 (block 640). For example, PGW 150 may receive one or more IP addresses from DNS server 160 and forward the IP addresses to client device 110. In implementations in which client device 110 performs the DNS query, client device 110 may directly receive the IP addresses from DNS server 160. The association of multiple IP addresses with a single FQDN is supported by existing DNS server protocols. Typically, a DNS server may return all of the IP addresses associated with a FQDN to a requesting device.
Process 700 may include contacting HSS 140 to begin network attachment of the client device to the network (block 710). The attachment process may be performed by IMS registration component 510 of client device 110. It can be appreciated that attaching to the network may include additional communications not particularly discussed herein. For example, client device 110, upon initialization, may first authenticate and attach itself to a base station 120.
Process 700 may further include receiving one or more IP addresses corresponding to P-CSCF servers 130 (block 720). As mentioned previously in reference to process 600, the IP addresses may be received as the result of a DNS resolution for a FQDN that corresponds to one or more of P-CSCF servers 130. IP address selection component 520 may receive the one or more IP addresses.
Process 700 may further include selecting an IP address from the received IP addresses (block 730). IP address selection component 520 may, for example, select the first IP address in the received set of IP addresses. Other techniques for selecting an IP address may be used, such as a random selection.
Process 700 may further include connecting to the P-CSCF server corresponding to the selected IP address (block 740). Client device 110 may, for example, send a REGISTER message to the P-CSCF, which may result in connection of client device 110 with the P-CSCF.
The connection with the network may fail, or the REGISTER message sent to the P-CSCF may not result in registration. In this situation, (block 750—YES), client device 110 may select another IP address from the received IP addresses (block 760). This IP address may correspond to an alternative P-CSCF server 130 (block 760). Process 700 may further include connecting to the alternative P-CSCF (block 770). Client device 110 may, for example, send a REGISTER message to the alternate P-CSCF, which may result in the registration of client device 110 for IMS services.
As shown in
As described above, a domain name, such as a FQDN, may be used to manage SIP servers (e.g., P-CSCF servers 130) to which client devices connect. By using a domain name to manage the SIP servers, traffic management and the possibility of SIP server failure can be effectively managed. For example, if the SIP server happens to be out-of-service or congested, a different SIP server may be automatically contacted. This may allow the network to select the SIP servers for a mobile device based on location-based factors or other factors. A location-based selection may be based on the location of the subscriber or the roaming status of the subscriber. The other factors may include network traffic conditions or other network device features.
The foregoing description provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention.
While a series of blocks has been described with regard to
It will be apparent that embodiments, as described herein, may be implemented in many different forms of software, firmware, and hardware in the embodiments illustrated in the figures. The actual software code or specialized control hardware used to implement embodiments described herein is not limiting of the invention. Thus, the operation and behavior of the embodiments were described without reference to the specific software code—it being understood that software and control hardware may be designed to implement the embodiments based on the description herein.
Further, certain portions, described above, may be implemented as a component that performs one or more functions. A component, as used herein, may include hardware, such as a processor, ASIC, or FPGA, or a combination of hardware and software (e.g., a processor executing software).
Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.
No element, act, or instruction used in the present application should be construed as critical or essential unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
