Voice over LTE support for non-UICC devices attached to an LTE mobile router

In one embodiment a router connects to a cellular network using at least one authentication credential stored on a smart card of the router. The router receives, from a client device coupled to the router, a Session Initiation Protocol (SIP) request to register with an Internet Protocol Multimedia Subsystem (IMS) network coupled to the cellular network. The router sends a SIP registration request for the client device to the IMS network, the SIP registration request comprising authorization information associated with the router, wherein the authorization information associated with the router is used by the IMS network to register the client device with the IMS network.

TECHNICAL FIELD

This disclosure relates in general to the field of communications and, more particularly, to voice over Long-Term Evolution (VoLTE) support for non-Universal Integrated Circuit Card (UICC) devices attached to an LTE mobile router.

BACKGROUND

A service provider's cellular network may provide endpoints with access to various networks attached to the cellular network, such as the Internet, an Internet Protocol Multimedia Subsystem (IMS) network, an enterprise network, or other network. These networks may provide various services to the endpoints, such as voice services (e.g., Voice over Internet Protocol) or other media services. In some situations, the endpoints and devices within these networks may communicate using different versions of a protocol.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

In one embodiment a router connects to a cellular network using at least one or more of a plurality of authentication credential stored on a smart card of the router. The router receives, from a client device coupled to the router, a Session Initiation Protocol (SIP) request to register with an Internet Protocol Multimedia Subsystem (IMS) network coupled to the cellular network. The router sends a SIP registration request for the client device to the IMS network, the SIP registration request comprising authorization information associated with the router, wherein the authorization information associated with the router is used by the IMS network to register the client device with the IMS network.

Example Embodiments

FIG. 1illustrates a block diagram of a system for providing VoLTE support for non-Universal Integrated Circuit Card (UICC) client devices102and104attached to an LTE mobile router108in accordance with certain embodiments. System100includes client devices102and104coupled to router108through network106. Router108is coupled to IMS network118through LTE access network110and LTE core network114. LTE core network114may also be coupled to one or more other networks such as the Internet116or a corporate network120. LTE access network may also provide network access to any suitable number of UICC client devices112.

UICC client devices112and LTE mobile router108may include a UICC. A UICC is a smart card that may be installed in a device to allow the device to access a cellular network based upon subscriber identity information stored by the card. Non-UICC client devices102and104are devices that do not include a UICC. Accordingly, non-UICC devices102and104are not able to directly access LTE access network110.

In various embodiments of the present disclosure, LTE mobile router108may function as a proxy for non-UICC client devices102and104and may use its own UICC to access the LTE access network110and associated services (e.g., services provided by IMS network118) on behalf of multiple non-UICC client devices. In various embodiments, router108may also modify messages between particular non-UICC client devices102and the IMS network118to allow client devices102to use services provided by the IMS network118(e.g., the router may intercept SIP signaling from non-UICC client device102and convert the signaling to 3GPP IMS signaling before sending towards IMS network118). The 3GPP IMS architecture specified in 3GPP TS 23.228 and TS 24.229 uses Session Initiation Protocol (SIP) as the base protocol for voice and other media services. Although IMS uses the standard SIP protocol, the protocol is used and extended to work with certain assumptions on the capabilities of devices functioning as IMS clients. For example, possible assumptions used in deploying IMS network118may include the IMS client being a UICC device, supporting IMS-specific calls flows, understanding 3GPP QoS bearer semantics, having the capability to react on events related to bearer establishment and bearer termination, or being able to perform Proxy-Call Session Control Function (P-CSCF) discovery. However, many SIP phones are non-UICC devices that are based on the standard SIP protocol which lacks such capabilities. For example, such 3GPP system-specific awareness and capabilities are not present in a generic RFC-3261 compatible SIP endpoint, especially when such a device does not have a direct 3GPP protocol interface. In various embodiments of the present disclosure, LTE mobile router108includes logic to provide the aforementioned functionalities to allow a standard SIP device (e.g., phone) coupled to the router to utilize SIP services provided through the IMS network118.

Various embodiments of the present disclosure may allow mobile service providers to extend new LTE/IMS based services to enterprise branch offices of an organization. For example, particular embodiments of the present disclosure may enable a small enterprise branch office with an LTE mobile router to leverage a service provider's IMS infrastructure to allow voice services between enterprise sites.

Client devices102,104, and112may be any suitable computing devices operable to send and receive network traffic (e.g., data packets). In various embodiments, a “computing device” may be or comprise, by way of non-limiting example, a cellular telephone, IP telephone (e.g., an enterprise IP phone that uses SIP to communicate voice data), smart phone, computer, tablet computer, workstation, server, mainframe, embedded computer, embedded controller, embedded sensor, personal digital assistant, laptop computer, convertible tablet computer, computing appliance, network appliance, virtual machine, virtual appliance, or any other electronic, microelectronic, or microelectromechanical device for processing and communicating data. A client device may include an appropriate operating system, such as Microsoft Windows, Linux, Android, Mac OSX, Apple iOS, Unix, or similar operating system. Client devices102,104, and112may be communicatively coupled to one another and to other network resources via the networks.

In the embodiment depicted, client device102is a non-UICC SIP client device. As used herein, a non-UICC SIP client device is a device that does not include a UICC and is capable of communicating using a SIP protocol (e.g., is compliant with RFC 3261), but is not compliant with IMS (e.g., is not compliant with TS 23.228 and TS 24.229). For example, the non-UICC SIP client device102may not be configured to send IMS compliant messages.

As described above, a UICC is a smart card that may be installed in a device to allow the device to access a cellular network based upon subscriber identity information stored by the card. A UICC may include a processor or other logic, memory, and a communication interface to run one or more applications and communicate with the device in which it is installed. A UICC may run a software application, such as a Universal Subscriber Identity Module (USIM). A USIM may provide access to information identifying the subscriber, such as an international mobile subscriber identity (IMSI) number and an associated key, which may be used to identify and authenticate the subscriber to a service provider's cellular network. A UICC may also store information about the local network, a list of services the user has access to, contacts of the subscriber, or other information associated with the subscriber.

In the embodiment depicted, client device104is a non-UICC IMS client device. As used herein, a non-UICC IMS client device is a device that does not include a UICC, is capable of communicating using a SIP protocol (e.g., is compliant with RFC 3261), and is compliant with IMS (e.g., is compliant with TS 23.228 and TS 24.229). For example, the non-UICC IMS client device104may be configured to send IMS compliant messages.

In the embodiment depicted, client device112is a UICC IMS client device. As used herein, a UICC IMS client device is a device that includes a UICC, is capable of communicating using a SIP protocol (e.g., is compliant with RFC 3261), and is compliant with IMS (e.g., is compliant with TS 23.228 and TS 24.229). Client device112may directly connect to LTE access network110(and access LTE core network114and IMS network118or other networks coupled to LTE core network114through the LTE access network110) utilizing the UICC of client device112.

LTE mobile router108is a router that includes a UICC for connecting to a mobile network. In the embodiment depicted, router108couples to the LTE access network110(e.g., via a wireless connection with a transceiver of the access network), LTE core network114, and one or more other networks coupled to the LTE core network114. The router108may act as a proxy for the client devices102and104to allow the devices to access the IMS network118via mobile network credentials (e.g., an IMSI) stored by a UICC of router108. The router may enable Voice over Internet Protocol (VoIP) calling by client devices102and104to each other and to other devices within a network attached to the LTE core network. Router108may function as a gateway to provide IP connectivity and Evolved Packet Core (EPC) access to the LTE network to client devices102and104and to other suitable devices. In various embodiments, router108may be compliant to 3GPP TS 23.401 for S5/S8 based EPC connectivity. In various embodiments, router108may use its UICC to couple to other mobile networks if the LTE network is unavailable. Router108may enable client devices102and104to have their own phone numbers, despite lacking UICCs.

In various embodiments, router108may be operable to process and/or forward network traffic. Router108may include any suitable hardware, software, components, modules, interfaces, or objects that facilitate operations associated with processing and/or forwarding network traffic. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange of data or information. In some embodiments, router108includes a multi-port network bridge that processes and routes data at a data link layer (Layer 2). Additionally or alternatively, router108may process and/or route data at other various layers such as a Layer 3 network layer, Layer 4 (with network address translation and load distribution), Layer 7 (load distribution based on application specific transactions), or at multiple layers (e.g., Layer 2 and Layer 3). In certain embodiments, router108may include functionalities of a switch and/or gateway.

The networks described herein (e.g., networks106,110,114,116,118, and120) may be any suitable network or combination of one or more networks operating on one or more suitable networking protocols. A network may represent a series of points, nodes, or network elements and interconnected communication paths for receiving and transmitting packets of information that propagate through a communication system. For example, a network may include one or more firewalls, routers, switches, security appliances, antivirus servers, or other useful network devices. A network offers a communicative interface between sources and/or hosts, and may comprise any local area network (LAN), wireless local area network (WLAN), metropolitan area network (MAN), Intranet, Extranet, Internet, wide area network (WAN), virtual private network (VPN), cellular network, or any other appropriate architecture or system that facilitates communications in a network environment depending on the network topology. A network can comprise any number of hardware or software elements coupled to (and in communication with) each other through a communications medium. In some embodiments, a network may be as simple as a connection such as a cable (e.g., an Ethernet cable), air, or other transmission medium. For example, in a particular embodiment, network106may comprise Ethernet cords or wireless connections coupling client devices102and104to router108.

LTE access network110may comprise a network of transceivers, such as Evolved Node B (eNodeB) transceivers coupled together in any suitable manner, such as through X2 interfaces. In one embodiments, access network110may be an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN). Any suitable component of the access network110may be coupled to one or more components of the LTE core network114(e.g., a serving gateway (SGW) or mobility management entity (MME)) in any suitable manner, such as through one or more S1 interfaces. LTE access network110may be responsible for radio-related functions of the LTE network, such as radio resource management (e.g., radio bearer control, radio admission control, scheduling and allocation of resources to user endpoints), header compression (e.g., compression of VoIP packet headers), and encryption of data sent over the radio interface.

LTE core network114is responsible for the overall control of endpoints and establishment of the bearers that will carry data between client devices102,104, and112and various networks coupled to the core network114, such as the Internet116, IMS network118, or an enterprise network120. LTE core network114will be explained in more detail in connection withFIG. 3.

Internet116comprises a global system of interconnected computer networks to which various devices using any suitable protocols may be attached. Enterprise network120may comprise a network belonging to a particular entity, such as a company, government, education institution, or other group and may comprise one or more LANs or other networks. In one embodiment, enterprise network120may represent an enterprise's main site, while client devices102and104may be located at a branch site of the enterprise.

IMS network118may comprise components adapted to provide control of any suitable IP multimedia services (e.g., VoIP, instant messaging, videoconferencing, video on demand, etc.) to client devices102,104, and112. IMS network118may rely on SIP as a signaling mechanism, thereby allowing voice, text and multimedia services to traverse networks coupled to IMS network118. IMS network118may include a control plane based on a SIP infrastructure and a user plane based on Real-time Transport Protocol (RTP). In various embodiments, IMS network118may enable real-time consumer and enterprise communication services over a variety of access technologies, including LTE, Wi-Fi, High Speed Packet Access (HSPA), or other suitable access technology. IMS network118will be explained in more detail in connection withFIG. 4.

FIG. 2illustrates non-UICC client devices102and104and an LTE mobile router108in accordance with certain embodiments. In various embodiments, non-UICC client devices102and104and LTE mobile router108may include one or more portions of one or more computer systems. In particular embodiments, one or more of these computer systems may perform one or more steps of one or more methods described or illustrated herein. In particular embodiments, one or more computer systems may provide functionality described or illustrated herein. In some embodiments, encoded software running on one or more computer systems may perform one or more steps of one or more methods described or illustrated herein and/or provide functionality described or illustrated herein. The components of the one or more computer systems may comprise any suitable physical form, configuration, number, type, and/or layout. Where appropriate, one or more computer systems may be unitary or distributed, span multiple locations, span multiple machines, or reside in a cloud, which may include one or more cloud components in one or more networks.

In the embodiment depicted, client devices102and104and router108include a computer system to facilitate performance of its operations. In particular embodiments, a computer system may include a processor, memory, and one or more communication interfaces, among other components. As an example, client device102comprises a computer system that includes one or more processors202, one or more memories208, and one or more communication interfaces214; client device104comprises a computer system that includes one or more processors204, one or more memories210, and one or more communication interfaces216; and router108comprises a computer system that includes one or more processors206, one or more memories212, and one or more communication interfaces218. These components may work together in order to provide functionality of their respective systems as described herein.

Processors202,204, or206may be a microprocessor, controller, or any other suitable computing device, resource, or combination of hardware, stored software and/or encoded logic operable to provide, either alone or in conjunction with other components of their constituent devices, the functionality of the respective devices. In some embodiments, client devices102or104or router108may utilize multiple processors to perform the functions described herein.

Memory208,210, or212may comprise any form of volatile or non-volatile memory including, without limitation, magnetic media (e.g., one or more tape drives), optical media, random access memory (RAM), read-only memory (ROM), flash memory, removable media, or any other suitable local or remote memory component or components. The memory may store any suitable data or information utilized by its constituent device, including software embedded in a computer readable medium, and/or encoded logic incorporated in hardware or otherwise stored (e.g., firmware). The memory may also store the results and/or intermediate results of the various calculations and determinations performed by its associated processor.

A communication interface214,216, or218may be used for the communication of signaling and/or data between client devices102and104, router108, and one or more networks (e.g.,106,110,114,116,118, and120) and/or network nodes coupled to a network or other communication channel. For example, the communication interface may be used to send and receive network traffic such as data packets. The communication interface may send and receive data and/or signals according to any suitable standard such as Asynchronous Transfer Mode (ATM), Frame Relay, Gigabit Ethernet (or other IEEE 802.3 standard), IEEE 802.11 standard, or other suitable wireline or wireless standard.

In various embodiments, the computer system of router108may execute any suitable operating system such as Cisco IOS, Cisco NX-OS, or other suitable operating system. In addition to a computer system, router108may include routing logic224, UICCC226, and digital signal processing (DSP) logic228, among other components. Routing logic224may include logic to receive data packets, determine where to send the data packets to, modify the data packets if necessary, and to send the data packets towards their destination. In some embodiments, routing logic224may include dedicated logic for performing routing and/or switching functions (e.g., at wire speed). Router108may also comprise a UICC as described above. Router108may also comprise DSP logic228which may include one or more specialized processors to perform DSP operations, such as filtering, compressing, decompressing, transcoding, or other suitable operations. As one example, DSP logic228may include one or more codecs, such as a G711 ALaw Media codec and an AMR Media codec, to encode data in a desired format.

FIG. 3illustrates an LTE core network114in accordance with certain embodiments. In the embodiment depicted, core network114includes MME302, SGW304, Packet Data Network Gateway (PGW)306, Home Subscriber Server (HSS)308, and PCRF310, though other embodiments may include any other suitable components. In some embodiments, one or more components of the core network can be implemented on the same gateway or chassis. In various embodiments, LTE core network114may be an Evolved Packet Core (EPC).

The MME302may reside in the control plane of the LTE core network114(e.g., EPC) and manages session states, authentication, paging, mobility with 3GPP 2G/3G nodes, roaming, and other bearer management functions. The MME302can be a standalone element or integrated with other core network elements, including, e.g., the SGW304, PGW306, and Release 8 Serving GPRS Support Node (SGSN). The MME302can also be integrated with 2G/3G elements, such as the SGSN and GGSN. This integration may facilitate mobility and session management interworking between 2G/3G and 4G mobile networks.

The MME302is a control-node for the LTE access network110. The MME302is responsible for UE (e.g., router108or client device112) tracking and paging procedures including retransmissions. The MME302handles the bearer activation/deactivation process and is also responsible for choosing the SGW304for a UE at the initial attachment and at time of an intra-LTE handover as well as selecting an appropriate PGW (e.g., PGW306). The MME302also authenticates the user by interacting with the HSS308. The MME302also generates and allocates temporary identities to UEs and terminates Network Access Server (NAS) signaling. The MME302checks the authorization of the UE to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. The MME302is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. Lawful interception of signaling is also supported by the MME302. The MME302also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME302from the SGSN (not shown). The MME302also terminates the S6a interface towards the home HSS308for roaming UEs.

The SGW304sits in the user plane where it forwards and routes packets to and from an eNodeB and PGW306. The SGW304also serves as the local mobility anchor for inter-eNodeB handover and mobility between 3GPP networks. The SGW304routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PGW306). For idle state UEs, the SGW304terminates the down link data path and triggers paging when down link data arrives for the UE. The SGW304manages and stores UE contexts, e.g. parameters of the IP bearer service and network internal routing information. The SGW304also performs replication of the user traffic in case of lawful interception.

The PGW306acts as the interface between the LTE network and other packet data networks, such as the Internet116, SIP-based IMS network118, and enterprise network120. The PGW306serves as the anchor point for intra-3GPP network mobility, as well as mobility between 3GPP and non-3GPP networks. The PGW306acts as the Policy and Charging Enforcement Function (PCEF), which manages Quality of Service (QoS), online/offline flow-based charging data generation, deep-packet inspection, and lawful intercept. The PGW306provides connectivity to the UE to external packet data networks (PDNs) by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one PGW for accessing multiple PDNs. The PGW306performs policy enforcement, packet filtering for each user, charging support, lawful interception, and packet screening. The PGW306also provides an anchor for mobility between 3GPP and non-3GPP technologies such as WiMAX and 3GPP2 standards (CDMA 1X and EVDO).

The HSS308may be a master user database that supports IMS network entities that handle calls. The HSS308stores subscription-related information (subscriber profiles), performs authentication and authorization of the user, and can provide information about the subscriber's location and IP information. The HSS308also maintains binding information on which gateway is currently serving a UE. Even when the UE is detached from the network, the HSS308maintains the binding information until the UE re-attaches itself and updates the binding information. An HSS may sometimes be collocated with an Authentication, Authorization, and Accounting (AAA) server that can provide authentication, access control, and accounting to the network. The authentication can involve verification of the subscriber, the access control can involve granting or denying access to specific services, and the accounting can track the use of network resources by subscribers.

Policy and Charging Rules Function (PCRF)310may determine policy rules in the network. PCRF310may access subscriber databases and other specialized functions (e.g., a charging system) in a centralized manner. PCRF may support the creation of rules and policy decisions for each active subscriber on the network. PCRF may be integrated with one or more other components of core network114or may operate as a stand-alone entity.

The elements of core network114may include any suitable logic, such as one or more computer systems, network processing units, line cards, packet and voice processing cards, or other suitable logic.

FIG. 4illustrates an IMS network118in accordance with certain embodiments. In the embodiment depicted, IMS network118comprises Proxy Call Session Control Function (P-CSCF)402, Serving Call Session Control Function (S-CSCF)404, Interrogating Call Session Control Function (I-CSCF406), Breakout Gateway Control Function (BGCF)408, and Emergency Call Session Control Function E-CSCF410. IMS network118may include any other suitable components in other embodiments.

P-CSCF402is the entry point to IMS network118and may serve as the outbound proxy server for a UE. A UE attaches to the P-CSCF402before performing IMS registrations and initiating SIP sessions. P-CSCF402may forward SIP messages to other elements of IMS network118. For example, the P-CSCF402may route incoming SIP messages to an IMS registrar server hosted by S-CSCF404. P-CSCF402may also generate charging data records (CDRs), maintain a security association with the UE (e.g., by setting up IPSec Security associations with UEs), may authorize bearer resource QoS via an Application Function toward PCRF310, may facilitate the provision of local services (e.g.,411or emergency calls), may provide lawful interception, may compress SIP headers, or perform any other suitable functions.

S-CSCF404may provide IMS user authentication for UEs. S-CSCF404may also act as an SIP registrar server. When a UE registers with the IMS network118, S-CSCF404may load the user profile of the US from the HSS308. The user profile may indicate which services (e.g., call forwarding, call forwarding when busy, ringback tone, etc.) the subscriber has. S-CSCF404may provide address translation support, may generate charging CDRs, and may provide lawful interception. The S-CSCF404may also facilitate the routing path for mobile originated or mobile terminated session requests.

I-CSCF406functions as an inbound SIP proxy server. During IMS registration by a UE, I-CSCF406may query the HSS to select the appropriate S-CSCF404to serve the UE. During an IMS session, I-CSCF406may function as the entry point to terminating session requests and may route incoming session requests to the S-CSCF of the called party. I-CSCF406may also generate charging CDRs and perform a Topology Hiding Function (THIG).

BGCF408is an SIP proxy which processes requests for routing from an S-CSCF when the S-CSCF has determined that the session cannot be routed using DNS. For example, BGCF408may perform routing based on a telephone number of the destination endpoint when the destination endpoint is attached to a public switched telephone network (PSTN).

E-CSCF410may receive SIP messages from the P-CSCF402when the P-CSCF determines the SIP messages are associated with an emergency call. The P-CSCF402may also send location data along with the SIP messages. The E-CSCF410may then route the call to a local Public Safety Access Point (e.g., a 911 Center).

The elements of IMS network118may include any suitable logic, such as one or more computer systems, network processing units, line cards, packet and voice processing cards, or other suitable logic.

As described earlier, router108may enable non-UICC SIP client devices102and non-UICC IMS client devices104to communicate with IMS network118. Such features may be provided by a function of the router referred to herein as Voice over LTE-Mobile Router (VoLTE-MR). VoLTE-MR functionality may be provided by any suitable logic of router108. VoLTE-MR may provide various functionalities for non-UICC SIP client devices102and non-UICC IMS client devices104.

With respect to non-UICC SIP client devices102, the VoLTE-MR may terminate SIP signaling from the non-UICC SIP client devices102attached to the mobile router108and for each SIP session from a client device102may initiate a corresponding IMS session to IMS network118. The mobile router108may appear like a RFC-3261 compatible SIP Proxy server to client devices102and may appear like an IMS client to the IMS network118. The VoLTE-MR function may attach to an Evolved Packet Core (e.g., network114) to provide PDN connectivity to IMS network118; perform bearer management for signaling and media sessions; manage IP Address and other configuration for the client devices102; behave as an outbound proxy server for client devices102; present client devices102as IMS hosts to the IMS network118; and enable client devices102to interoperate with IMS Network118through signaling management (e.g., header modifications of SIP messages from client devices102, insertion of additional SIP messages conforming to the IMS call flows), media management (e.g., performing transcoding services), and resource management (e.g., dedicated bearer setup and bearer management of IMS media and signaling traffic); provide failure handling & other services (e.g., PDN detach, bearer failure/drop, P-CSCF failure, re-authentication, de-registration from IMS network118); and/or handle IMS message security for client devices102. In one embodiment, the VoLTE-MR uses the UICC of the mobile router108to create a single PDN connection for IMS Access Point Name (APN) and allows the connection to be shared by any number of non-UICC SIP client devices102and non-UICC IMS client devices104coupled to the mobile router108.

VoLTE-MR may participate in message handling on behalf of client devices102and IMS network118. For example, client device102may send a normal RFC 3261 SIP Register message to an outbound proxy address matching the address of the VoLTE-MR. VoLTE-MR may modify the received Register message and send an IMS Compliant SIP Register message to IMS. The VoLTE-MR may also subscribe to a RegEvent Package on behalf of client device102. VoLTE-MR may store the p-access-network info and p-associated-uri fields on behalf of the IMS subscriber. The p-associated-uri may contain an implicitly registered public user identity (PUI). If the VoLTE-MR receives a call for the p-associated-uri, the call will be forwarded to the client device102. VoLTE-MR may also create transport mode IPSec security associations on behalf of client device102.

With respect to non-UICC IMS client devices104, VoLTE-MR may attach to network114(which in some embodiments is an EPC) to provide PDN connectivity to IMS network118, perform bearer management for signaling and media sessions, manage IP Address and other configuration for the client devices104, provide the IMS configuration to the client devices104, and perform failure handling & other services (e.g., PDN detach, bearer failure/drop, P-CSCF Restoration, etc.).

In various embodiments, the VoLTE-MR does not modify the IMS signaling messages received from the client device104, but rather routes the messages on the signaling bearer. IMS call signaling is tied to the Bearer Setup indication, however, for a non-UICC device such as client device104without a direct interface to the 3GPP network, there is no such indication present. Various embodiments may utilize DHCP/ND to deliver the Bearer Setup, Bearer Failure, and P-CSCF Restoration related events.

FIG. 5illustrates a method for providing VoLTE support for non-UICC client devices102and104attached to an LTE mobile router108in accordance with certain embodiments. At step502, router boot configuration is performed. The router108may boot up by reading a configuration file stored in memory of the router. As part of the bootup, the router108may activate a radio link to the LTE access network110based on identification and configuration information stored on a UICC226of the router.

At step504, the router108initiates a PDN connection setup to the LTE core network114and a default bearer setup. The router108may be configured with a default APN for the PDN connection or a trigger received from a client device102or104may prompt the router108to connect to a particular APN. If no APN is provided by the router to the core network114, the MME may connect to a default APN based on the s6a interface.

The default bearer may establish a logical connection for a data flow which may be used to carry IMS control signaling between the IMS network118and the router108. The default bearer may be associated with an IP address of the router108. The default bearer may be associated with a set of network parameters that describe how data transferred using the default bearer will be treated. For example, a default bearer might receive best effort traffic delivery. All non-UICC client devices102and104sitting behind the router108share the same default bearer for SIP signaling. For example, all IMS control messages sent between the router108and IMS network118on behalf of client devices102and104may use the default bearer. The default bearer setup procedure is described in more detail in connection withFIG. 29. During the default bearer setup, router108receives an IP address and QoS policies, among other information.

At step506, a client device102or104is connected to router108. The client device may be connected in any suitable manner, such as through a wired connection (e.g., an Ethernet cord) or a wireless connection. The router may perform local authentication on the client device102, to ensure that the router does not provide services to rogue devices. At step508, the router assigns the client device an IP address. In one embodiment, a local address may be assigned by the router108to each non-UICC client device102and104and the router may perform network address translation (NAT) based on prefixes received from the router's PDN connection. For example, the IP prefixes configured on the ingress interfaces of the router108may be private addresses (e.g., in accordance with RFC1918 or RFC4193 Unique Local Addresses). The client devices102and104attached to the router108(or specific VLAN/interface of the router) will be able to obtain address configuration from these delegated prefixes, using standard IPv6 ND/DHCP. NAT/PAT functions will be enabled on the ingress interface, thus there will be translation between the private IP space and the IP address obtained for the PDN connection.

In another embodiment, the non-UICC client devices102and104may each be assigned an IPv6 prefix using DHCP-PD. For example, the IP prefixes configured on the ingress interfaces of the router108may be the delegated prefixes obtained from the LTE core network114. After completing the PDN connection/default-bearer establishment on the IMS APN, the router108will use DHCP PD for obtaining delegated mobile network prefixes (e.g., by using the Rel-10 Prefix Delegation feature). These prefixes will be dynamically configured on the ingress interface of the router108. The client devices102and104attached to the router108(or specific VLAN/interface of the router) will be able to obtain address configuration from these delegated prefixes, by using standard IPv6 ND/DHCP for address configuration.

At step510, the client device registers with the IMS network118. During this step the client device may provide its identity and IP address to the IMS network118. A client device may be assigned IMS subscription information (e.g., Home Domain, IPSec security keys) including an IMS Private User Identity (IMPI) and one or more IMS Public User Identities (IMPUs) by an IMS service provider. An IMPI may be assigned by the home network operator as a unique identity for the IMS subscription and may be authenticated during IMS registration by the client device. An IMPI is normally in the form of NAI@realm and is included in all registration/re-registration/de-registration requests. An IMPU is a public identity used by any user for requesting communications with other users. An IMPU is not authenticated during registration and may be in the form of a SIP URI (e.g., SIP:user@domain.com) or a telco URI (e.g., Tel:+18001234567). In some embodiments, multiple IMPUs with different service profiles may be associated with a single IMPI. If a client is a non-UICC SIP client device102, during this step it may provide a SIP public user identity (e.g., SIP URI) and SIP private user identity (e.g., username) to the mobile router108. Upon receiving a request from a client, the mobile router108may identify the subscriber based on an SIP URI (or IMPU if client is capable of IMS compliant messaging) of the client and use security credentials associated with the subscriber to modify messages sent to the IMS network118.

After the client device is registered to the IMS network, it can use media services provided by the network (e.g., to initiate or receive calls). As long as the client devices remains registered to the IMS network, it can make or receive any number of calls (i.e., participate in any number of media sessions).

At step512, an IMS media session is setup between the client device and the IMS network118. During setup and during the media session itself, a client device102will use SIP signaling (e.g., as defined in RFC 3261) in its communications with mobile router108and a client device104will use IMS signaling in its communications with mobile router108. This signaling will be described below in connection with additional figures.

Some of the steps illustrated inFIG. 5may be repeated, combined, modified or deleted where appropriate, and additional steps may also be included. Additionally, steps may be performed in any suitable order without departing from the scope of particular embodiments.

FIG. 6illustrates an example method600for communicating with non-UICC client devices102and104and an IMS network118in accordance with certain embodiments. The steps of method600may be performed by any suitable device, such as router108. At step602, a SIP request is received from a client device102or104. The SIP request may be a standard SIP request from client device102that is compliant with RFC 3261 but is not compliant with IMS (e.g., is not compliant with TS 23.228 and TS 24.229), or it may be a SIP request sent from client device104that is compliant with both RFC 3261 and IMS. At step604, it is determined whether the request is IMS compliant. For example, if the request is received from a non-UICC SIP client device102, the router may judge the request to be non-compliant with IMS, whereas if the request is received from a non-UICC IMS client device104, the router may judge the message to be compliant. In other embodiments, the router may look at the headers or payload of the request to determine whether the request is IMS compliant. If the request is IMS compliant, the request is sent without modification to the IMS network118at step610. If it is not, the request is converted to an IMS compliant request at step606. In various embodiments, this may involve adding one or more headers to the message, adding additional SIP messages, transcoding media data, or performing resource management (e.g., making sure that guaranteed bitrate requirements are met on behalf of the client devices102and104) associated with the request. With respect to transcoding media data, media data received from client devices102may be transcoded by the router108into IMS compliant media data for IMS network118and vice versa. For example, media data coming from or going to a non-UICC SIP client may be encoded by a G711 ALaw Media codec while media data coming from or going to the IMS network may be encoded by an AMR Media codec. At various points during communication, additional messaging may be performed at step608by the router108(e.g., the router may send proxy acknowledgment or update messages to the IMS network on behalf of the client device102). The modified request is then sent to IMS network118at step610.

At step612, a response destined for a client device102or104from the IMS network118is received. At step614, it is determined whether the response is compatible with the client device102or104that the response is addressed to. In general, the response may contain SIP messaging that is IMS compliant. Accordingly, if the response is for a non-UICC IMS client device104, it may be determined that the response is compatible with the client device104and may be sent to the client device at step618. However, if the response is for a non-UICC SIP client device102, it may be determined that the response is not compatible with the client device102and the response may be converted to standard SIP signaling at step616. In some instances, step616may also involve transcoding of media data to a format that is compatible with client device102. At step618, the response is delivered to the client device102. In various embodiments, after the media session is complete, a media session tear down procedure may be performed wherein the mobile router modifies a SIP tear down message received from client device102to be IMS compliant.

Some of the steps illustrated inFIG. 6may be repeated, combined, modified or deleted where appropriate, and additional steps may also be included. Additionally, steps may be performed in any suitable order without departing from the scope of particular embodiments.

The remaining figures depict detailed call flows for various messages that may be sent between components of system100.

FIG. 7illustrates an example IMS registration procedure that may be performed for a non-UICC SIP client device102in accordance with certain embodiments. In various embodiments, mobile router108may perform an IMS registration process for each client device102of any number of client devices. Messages1-10may comprise messages for performing IMS registration on behalf of the client device102while messages13-20comprise messages for subscribing to Registration Events on behalf of the client device102.

In the embodiment depicted, client device102send a SIP Registration message to the router108. The router converts the SIP Registration message into an IMS compliant SIP Registration message and sends the converted message to the P-CSCF, which then sends it to one or more nodes in the IMS network118. The IMS network118may then challenge the client device with a 401 unauthorized message. In response, the client device102will send another SIP Registration message with the necessary authentication information. The IMS network will then authenticate the client device102and send a 200 OK message back to the client device102.

The router then subscribes with the IMS network for notifications of events (e.g., registration, re-registration, deregistration events). Thus, if an event occurs, the IMS network will notify router108. Under RFC 3261 or RFC 3665 (which describes basic SIP call flows for RFC 3261 compliant devices), such registration by the SIP client is not required and thus a device102might not include registration capability.

FIGS. 8-11illustrates example messages of the IMS registration procedure ofFIG. 7in accordance with certain embodiments. The various components of the messages shown in the call flows herein may be understood by reference to the appropriate SIP specification (e.g., RFC 3261 and other RFCs as accessible via http://www.iana.oreassignments/sip-parameters/sip-parameters.xhtml). As depicted inFIG. 8, the Register message sent from the client device may include various headers and accompanying information indicating the entity (i.e., client device102) that is requesting IMS registration (e.g., the public user identity or SIP URI of client device102in connection with the “From” header), the IP address of the entity requesting IMS registration, and the server at the IMS network which it would like to be registered to. The modified Register message sent from router108to IMS network118may include additional information (e.g., packet access network information, authorization information, security information) making the modified Register message IMS compatible. In various embodiments, some of the additional information in the modified Register message (e.g., the security information) is obtained from the UICC of the router108(e.g., if the negotiated authentication mode is SIM based authentication (e.g., EAP-SIM/EAP-AKA) then the mobile router108will obtain the security credentials from its UICC). The packet access network information may specify the access network type (e.g., UTRAN) and cell in which the router is located. The authorization information may include identity information of the router (e.g., a SIP username of the router (i.e., user1_private@home1.net)), the realm (domain in which the user may be validated), and the URI of the registrar server that will perform validation of the username. The security information includes information used to establish a secure connection for the SIP signaling between the IMS network118and the router108(e.g., using the IPSec protocol). In the401authentication message sent back to the client device102, the router108may strip out security information as depicted inFIG. 9. In response to the401authentication message, the client device102will send a register message with an authorization header (including the private user identity or username of the client device102) and accompanying information. The authorization information may also include a realm or other suitable information. The router108may add additional headers and send the modified register message to the IMS network118. The IMS network may then send a 200 OK and router may strip out various information (such as a P-CSCF identifier indicating the P-CSCF to which future requests should be sent, a S-CSCF identifier indicating the S-CSCF that will process the calls, and a P-Associated-URI indicating all the aliases (e.g., IMPUs) with which client device102may access the IMS network118).

FIG. 12illustrates an example SIP media session between a non-UICC SIP client device and an IMS network in accordance with certain embodiments. The SIP media session may involve the transfer of voice, the transfer of other media (e.g., video), or a combination thereof. The SIP media session may take place after the IMS registration procedure has been performed.

In the SIP Invite message sent by the client device102, the client device will specify the called party. The router108will modify this message to be IMS compliant and then send it towards the IMS network118. The IMS network118then sends a session progress message back indicating that it is currently processing the SIP Invite request.

A non-UICC SIP client device102may or may not have support for sending the Proxy Acknowledgement message, so in the embodiment depicted, the router108will send the Proxy Acknowledgement message to the IMS network118. The IMS network will then respond with a SIP 200 OK message.

The router then sets up a dedicated bearer. The dedicated bearer may establish a logical connection for a data flow which may be used to carry media information (e.g., voice or video traffic) associated with a particular SIP call (as opposed to the default bearer which is used to carry the control signaling for the SIP sessions). The dedicated bearer may reserve a particular bandwidth for the session based on a QoS value associated with the session (e.g., higher bandwidths may be reserved for premium subscribers) which may be obtained from the PCRF or other suitable source. A dedicated bearer may provide a dedicated tunnel for specific traffic and may be associated with the default bearer (and thus does not need its own IP address). In particular embodiments, a dedicated bearer may be shared by any suitable number of client devices102and104to carry traffic for SIP sessions involving the client devices. After the dedicated bearer is setup, the router sends an UPDATE message to the IMS network118indicating that bandwidth for the call has been reserved. The IMS network118will then ring the destination phone and send a notification of the ringing back to the client device102. The router108will send a proxy acknowledgement message to the IMS network118in response to the notification of the ringing. Once the destination endpoint answers the call, the IMS network sends a 200 OK message to the client device102and the flow becomes active. An acknowledgement message will be sent from the client device102to the IMS network118and the media session will begin.FIGS. 13-20illustrates example messages of the example SIP media session ofFIG. 12in accordance with certain embodiments.

FIG. 21illustrates an example network initiated de-register procedure performed with respect to a non-UICC SIP client device102in accordance with certain embodiments. The example call flow may occur when the IMS deregisters client device102from the IMS network118thus preventing client device102from making or receiving calls. In one embodiment, the router108may notify the client device102that it has been de-registered from the IMS network via a new vendor specific extension (VSE) information element and the client device102may re-register. In another embodiment, the router108may automatically re-register with the IMS network on behalf of the client device102without requiring and messaging from the client device102.

FIG. 22illustrates an example network initiated re-authorization procedure performed with respect to a non-UICC SIP client device102in accordance with certain embodiments. Similar to the flow shown inFIG. 21, in one embodiment, the router108may notify the client device102that re-authentication is required via a new vendor specific extension (VSE) information element and the client device102may re-register. In another embodiment, the router108may automatically re-register with the IMS network on behalf of the client device102without requiring any messaging from the client device102.

FIG. 23illustrates an example P-CSCF restoration procedure performed with respect to a non-UICC SIP client device102in accordance with certain embodiments. In this flow, the router108may register with a different P-CSCF of the IMS network118if the original P-CSCF fails.

FIG. 24illustrates an example call flow involving a resource reservation failure with respect to a non-UICC SIP client device102in accordance with certain embodiments. For example, if the dedicated bearer setup fails, router108may disconnect the call.

FIG. 25illustrates an example IMS registration procedure that may be performed for a non-UICC IMS client device104in accordance with certain embodiments andFIG. 26illustrates an example SIP media session between a non-UICC IMS client device104and an IMS network in accordance with certain embodiments. In various embodiments, mobile router108may perform an IMS registration process and participate in SIP media sessions for each client device104of any number of client devices. In such embodiments, the router108provides transport of IMS compatible SIP messages received from client device104without modifying the messages. In various embodiments, the mobile router would offer PDN connections, resource reservation, and media transcoding services for non-UICC IMS client devices104without modifying the control signaling received from or sent to devices104.

FIG. 27illustrates an example call flow involving a resource reservation failure with respect to a non-UICC IMS client device104in accordance with certain embodiments. In such an embodiment, the router108may notify the client device104of the bearer establishment status.

FIG. 28illustrates an example P-CSCF restoration procedure performed with respect to a non-UICC IMS client device104in accordance with certain embodiments. In such an embodiment, when an original P-CSCF goes down, the router108notifies the client device104of a new P-CSCF address list that it receives in a PCO option from the LTE core network114.

FIG. 29illustrates a default bearer setup procedure in accordance with certain embodiments. Although, a non-UICC IMS client device104is depicted in the call flow, the default bearer setup procedure may be performed to provide communication for client devices102and/or client devices104. The router may initiate the attach procedure by sending an attach request to an eNodeB of the access network110. The message may include the router's voice capabilities and preferences. For example, the voice domain preference for UTRAN may have a preferred value of IMS PS Voice and a secondary value of CS voice; the usage setting may be set to voice-centric, and the SRVCC to GERAN/UTRAN capability may be set to SRVCC from UTRAN HSPA or E-UTRAN to GERAN/UTRAN supported. In a particular embodiment, the voice domain preference and usage setting would be fixed for the router108and will not vary for individual client devices coupled to the router. The eNodeB may forward the attach request message to a selected MME in an S1-MME control message. The MME may then initiate a procedure for authenticating the router108by matching authentication information received from the router108with information stored in the HSS. The MME may then send an update location request message to the HSS to update the records for the router (based on the IMSI associated with the router). The subscription profile may then be downloaded from the HSS. The subscription profile for the router108may have a default APN matching the IMS network118and QoS parameters used for SIP signaling. The MME will select the SGW and PGW for the connection and will initiate the creation of a default bearer for the router108by sending a Create Session Request to the selected PGW. The PGW will interact with the PCRF and obtain default PCC rules, bearer authorization, and QoS parameters for the IMS PDN connection. The PGW will also assign an IPv6 prefix or IPv4 address to the router108. The PGW will send a response to the SGW with an address of the P-CSCF of the IMS network118. The SGW will forward this response to the MME which then responds to the router108with an attach accept message via the eNodeB. The bearer information, bearer QoS, router IP address, and P-CSCF address are sent to the router108.

The eNodeB may send the initial context response message to the MME. The router108sends a direct transfer message including an attach complete indication to the eNodeB. The eNodeB forwards the attach complete message to the MME in an uplink NAS transport message. The MME sends a modify bearer request message to the SGW and the SGW acknowledges by sending a modify bearer response message to the MME. The default bearer is now established and ready to exchange uplink and downlink packets.

FIG. 30illustrates a client device authentication procedure in accordance with certain embodiments. In such an embodiment, a client device102or client device104may be authenticated with a local AAA server while the router108behaves as an AAA proxy. In this flow, the client devices may indicate their communication capabilities (e.g., whether they are IMS compliant or not).

“Logic” as used herein may refer to hardware, firmware, software and/or combinations of each to perform one or more functions. In various embodiments, logic may include a microprocessor or other processing element operable to execute software instructions, discrete logic such as an application specific integrated circuit (ASIC), a programmed logic device such as a field programmable gate array (FPGA), a memory device containing instructions, combinations of logic devices (e.g., as would be found on a printed circuit board), or other suitable hardware and/or software. Logic may include one or more gates or other circuit components. In some embodiments, logic may also be fully embodied as software.

Although the examples described herein have focused on the LTE access and core networks, the features of the various embodiments may be used with any suitable cellular networks (such as a 3G network) that is capable of coupling router108to an IMS network118and supporting IMS compatible SIP signaling.

It is also important to note that the steps inFIGS. 5-6illustrate only some of the possible scenarios that may be executed by, or within, the devices described herein. Some of these steps may be deleted or removed where appropriate, or these steps may be modified or changed considerably without departing from the scope of the present disclosure. In addition, a number of these operations may have been described as being executed concurrently with, or in parallel to, one or more additional operations. However, the timing of these operations may be altered considerably. The preceding operational flows have been offered for purposes of example and discussion. Substantial flexibility is provided by the devices in that any suitable arrangements, chronologies, configurations, and timing mechanisms may be provided without departing from the teachings of the present disclosure.

Additionally, it should be noted that with the examples provided above, interaction may be described in terms of one or more devices. However, this has been done for purposes of clarity and example only. In certain cases, it may be easier to describe one or more of the functionalities of a given set of flows by only referencing a limited number of devices. It should be appreciated that the systems described herein are readily scalable and, further, can accommodate a large number of components, as well as more complicated/sophisticated arrangements and configurations. Accordingly, the examples provided should not limit the scope or inhibit the broad techniques disclosed herein, as potentially applied to a myriad of other architectures.