Patent Application
20060146781
Wireless local area network (WLAN) access networks (AN) are being deployed in public places such as, e.g., but not limited to, airports, hotels, shopping malls, and coffee shops. WLAN access points (APs), commonly referred to as, e.g., “hotspots” provide low cost public access to data services, but are generally used indoors have only a minimal range intended for local area network (LAN) applications. Third (3rd) generation (3G) wireless networks provide broader coverage for 3G users than do WLAN networks. The cost advantage of WLAN networks make WLAN access desirable to 3G users when available. Thus interworking between WLAN and 3G networks is useful. A WLAN AN may have direct or indirect roaming agreements with one or more 3G home operator networks to enable 3rd generation partnership project (3GPP) network users connected to the WLAN AN to access services provided by the home operator networks of the 3GPP users. Conventionally 3G operators control access to 3G services through a mechanism that allocates a different Internet Protocol (IP) address, i.e., a packet data protocol (PDP) context, for each different class of service. Meanwhile, conventional user equipment (UE) devices running conventional operating systems do not assign multiple IP addresses to a single network card instance, but rather assign only a single IP address for every connected network card. Lack of support for assigning more than one IP address to a single IP client leads to a situation where 3G operator services are conventionally inaccessible to a user through a WLAN access point (AP).
Various exemplary features and advantages of the invention will be apparent from the following, more particular description of exemplary embodiments of the present invention, as illustrated in the accompanying drawings wherein like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The left most digits in the corresponding reference number indicate the drawing in which an element first appears.
Exemplary embodiments of the invention are discussed in detail below. While specific exemplary embodiments are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the invention.
In an exemplary embodiment, communication between the WLAN and 3G networks may comply with any of a number of relevant standards. One exemplary architecture of an exemplary WLAN-3GPP interworking may be specified by, e.g., but not limited to, 3GPP Technical Specification Group Services and System Aspects; 3GPP system to Wireless Local Area Network (WLAN) Interworking; System Description (Release 6), 3GPP TS 23.234 V2.4.0(2004-01), of the 3GPP SA2 working group, etc. Yet another is the TR 22.934 of the 3GPP SA1 working group.
The present invention may enable mobile node 102 clients to use a single IP address (such as, but not limited to, an IPv4 or IPv6 address) while accessing 3G services 120, where each of the 3G services 120 may be associated with different PDP IP addresses. 3G applications 207 (discussed further below with reference to
Mobile IP nodes may comply with any of a number of relevant standards, including, e.g., but not limited to, Request For Comments (RFC) 3344, IP Mobility Support for IPv4, Network Working Group, version August 2002, etc.
Enhanced HA 110, in accordance with an exemplary embodiment of the present invention, may maintain one or more PDP IP addresses assigned to the MIP-enabled client 201 by the GGSN 118 (as a result of one or more PDP context activations issued by the MIP-enabled client 201) in a binding table of the HA 110. According to the present invention, all applications running on the MIP-enabled client 201 MN 102, may bind to a single IP address (i.e., the MIP home address). Upon the receipt of an IP packet from a MIP-enabled client 201 MN 102, the HA 110 may replace the source IP address of the IP packet with the appropriate PDP IP address based on the destination IP address of the IP packet, and then may forward the packet on to the SGSN 114. When the HA 110 receives an inbound IP packet from a 3GPP server (such an IP packet originating at a 3G server and destined for a client may be referred to herein as an “inbound IP packet”, whereas an IP packet originating from a client, destined for a 3G server may be referred to as an “outbound IP packet”), via the SGSN 114, from GGSN 118, where the IP packet is destined to an MIP-enabled client 201 MN 102 of the HA 110, the HA 110 may in accordance with an exemplary embodiment of the present invention replace the destination IP address of the inbound IP packet with the home address of the MIP-enabled client 201 MN 102, and may then forward the inbound IP packet on to the MIP-enabled client 201 MN 102.
Enhanced MIP-enabled client 201 software of MN 102, in accordance with an exemplary embodiment of the present invention, may implement an API that may be called by 3G applications to make a service request through a PDP-context activation request. Upon receipt of a service request from a 3G application through the API, the MIP-enabled client software 201 may create a new registration request message to relay a PDP context activation/deactivation request to the HA 110, which may include a registration request extension (RRQE) (as discussed further with reference to reference numeral 210 in
Enhanced 3G applications, in accordance with an exemplary embodiment of the present invention, may call the MIP-enabled client software 201 API to make service requests, and the 3G applications may also implement a callback API that may be called by the MIP-enabled client 201 software to inform the result of a service request.
3G Applications
The 3G applications, in accordance with an exemplary embodiment of the present invention, may implement a callback API that may call a mobile IP (MIP) client 201 user-mode software that may pass a result of a PDP context activation/deactivation request. The callback API may include, e.g., but not limited to, at least two parameters: 1) a PDP context activation/deactivation reply; and 2) a Success/Failure status.
On startup, the 3G application may call into the MIP client 201 to initiate a service request, as illustrated by reference numeral 208 in
Mobile IP Client
The MIP client 201 user-mode software may implement the service request (SR) API as illustrated by reference numeral 208 in
Upon invocation of the 3G SR API, the Mobile IP client 201 user-mode software may, as illustrated by reference numeral 210 in
MIP client 201 user-mode software may bind each entry in a registration pending table of the MIP client 201 with the appropriate service request identifier (SRI).
The MIP client 201 user-mode software may be able to process the registration reply for a PDP context activation/deactivation request and may call the appropriate callback API implemented by the 3G applications. The RRPE, as illustrated in reference numeral 226 of
Mobile IP Home Agent
In an exemplary embodiment of the invention, the home agent 110 may require deployment of an enhanced Mobile IP Home Agent (HA) 110 in the operator network. For example, a MIP HA compliant with standard RFC 3344, August 2002 (discussed above), etc. may be used. The HA, in an exemplary embodiment, may include, e.g., but is not limited to, the following described features.
The HA 110 of
The HA 110, as illustrated in 212 of
The HA 110 may, in an exemplary embodiment, be able to create an IP packet containing the PDP context activation/deactivation request (received in the RRQE) and may send the PDP context activation/deactivation request to the SGSN, e.g., but not limited to, through layer 2 or 3 encapsulation, or, e.g., but not limited to, an appropriate API implemented by the SGSN 114, if, e.g., but not limited to the case where, HA 110 and SGSN 114 are combined in another exemplary embodiment.
The HA 110 may, in an exemplary embodiment, implement a callback API that may be called by the SGSN 114 to pass the result of PDP context activation/deactivation to the HA 110, as illustrated by 222 in
On receiving a reply for a PDP-context activation/deactivation request from the SGSN 114 through the callback API, the HA 110 may, in an exemplary embodiment, be able to update the appropriate entry in a binding table of the HA 110, with the received PDP context IP address, and may create a registration reply (RRP) with a new extension that may contain, e.g., but is not limited to, at least 3 parameters: 1) PDP context activation/deactivation reply; 2) the SRI; and 3) Success/Failure status.
For a given registered MIP client 201, the HA 110 may be able to bind one or more PDP context IP addresses to an entry in a binding table of the HA 110.
On receiving a MIP encapsulated data packet from a client, the HA 110 may be able to remove the outer IP header (as specified in RFC 3344), may map the source IP address of the inner IP packet to the corresponding PDP context IP address stored in the binding entry, and may forward the IP packet to the SGSN 114, using, e.g., but not limited to, a layer-2 forwarding mechanism, or inside a tunnel established between the HA 110 and SGSN 114.
The HA 110, in an exemplary embodiment, may enforce reverse tunneling for Mobile IPv4.
SGSN
In an exemplary embodiment of the present invention, the SGSN 114 may implement an SGSN-HA API, as illustrated by reference numeral 214 in
On receiving a reply, as illustrated by 220 of
The SGSN 114, in an exemplary embodiment, may maintain a table (referred to as Hotspot UE table) of PDP addresses that are being serviced by the HA 110. Whenever the SGSN 114 terminates a GPRS tunneling protocol (GTP) tunnel for a data packet that is destined to an address in the Hotspot UE table, the SGSN 114 may send the data packet to the HA 110. The packet may be sent via, e.g., but not limited to, a layer-2 forwarding interface, or through a tunnel established between the HA 110 and the SGSN 114, for this purpose.
Control Packet Flow
Referring to
In 208, 3G application 207 may call a service request (SR) API, implemented by the MIP client 201 user-mode software, to issue a PDP context activation/deactivation request.
In 210, the MIP client 201 user-mode software may generate a unique SRI for this request, may create a RRQ containing a new RRQE (as defined above), may create a new entry in a registration pending table of MN 102 and may associate the new entry with the SRI and a 3G application callback API address, and may send the RRQ to the HA 110.
In 212, when the HA 110 receives the RRQ with the new RRQE, the HA 110 may create a new entry in a registration pending table of the HA 110 (if a registration pending table entry does not already exist).
In 212, the HA 110 may associate the new entry with the SRI received in the RRQE of 210.
In 214, the HA 110 may call an API implemented by the SGSN 114 (hereafter, referred to as SGSN-HA API) that may relay the PDP context activation/deactivation request, the SRI, and the HA callback API address to the SGSN 114.
In 216, the SGSN 114 may create a new PDP context activation/deactivation request, as defined in the 3GPP specification, and may send the PDP context activation request to the GGSN 118. The SGSN 114 may also associate each pending PDP context activation/deactivation request with the SRI and the HA callback API address received through the SGSN-HA API.
In 218, the GGSN 118 may process the request, completing the service request, updating a home location register (HLR), and creating an address assignment.
In 220, the GGSN 118 may send the PDP context activation/deactivation reply to the SGSN 114.
In 222, the SGSN 114 may call a SGSN-HA callback API, that may pass the PDP context activation/deactivation reply, the SRI, the PDP context IP address, and the request status to the HA 110.
In 224, the MIP HA 110 binding table may be updated with the PDP address(es).
In 226, the HA 110 may create an appropriate registration reply (corresponding to the appropriate pending RRQ-this may be determined by the SRI) containing the new RRPE (specified above), and may send the RRP to the MIP client 201.
In 228, when MIP client 201 user-mode software receives a RRP with the new RRPE, the MIP client 201 may extract the information from the RRPE, may determine the 3G application callback API address from its pending RRQ using the SRI, and may call the callback API to pass the PDP context activation/deactivation reply to the 3G application 207.
Data Packet Flow
As shown in diagram 400 of
On the way up from the server to the MN, when the SGSN receives GTP tunneled packets from the GGSN, it may first (de)capsulate the packet. Then, it may determine whether it should forward the packet to the HA (or not) based on its source IP address (i.e., PDP context IP address). When the HA receives the packet, it may replace its source IP address with the appropriate MN home address (which may be obtained from its enhanced registration binding table), may apply MIP forward encapsulation, and may send it to the MN.
In an exemplary embodiment of the present invention, the solution may be based on open IP protocols for WLAN based access to cellular core services.
An exemplary embodiment of the present invention may not introduce a new protocol. The exemplary embodiment, may piggy back on the Mobile IP standard. In the exemplary embodiment, no operator protocols may be mandated on the client device MN 102. At the same time, the exemplary embodiment of the present invention may ensure that the operator's core network is not impacted. No changes to the GGSN 118 may be necessary. The GGSN 118 may be the main anchor router in the PLMN 108. No changes may be required of SGSNs 114 in the PLMN 108 other than those that may be made to the SGSN 114 that may be facilitating hotspot 104 access in concert with the HA 110, according to an exemplary embodiment of the present invention.
The exemplary embodiment of the present invention may be symmetrical for access irrespective of whether the hotspot 104 is owned by a home or a visitor PLMN 108.
The exemplary embodiment of the present invention may allow for service authorization on a per service granularity. Already authorized services may continue to be running while a new service may be requested and authorized (or, for that matter, deauthorized).
The exemplary embodiment of the present invention may not require any modifications or enhancements to network stack architecture or the driver model of the client device MN 102.
The exemplary embodiment of the present invention may make use of services provided by 3G operators transparent to IP-based client devices and the applications of the client devices.
The exemplary embodiment of the present invention may provide IP mobility where users may move from one WLAN network such as, but not limited to, an 802.11 based wireless network, to another, while accessing different 3G services where each of the different 3G services may be associated with a different PDP context.
The present invention may provide service access forconventional client devices and OSs by allowing a client to bind a single network interface card (NIC) card to multiple addresses.
Moreover, in an exemplary embodiment, GPRS routing mobility mechanisms may be preserved and may be used to a furthest extent, and may introduce no routing and data overhead within a GPRS network.
An exemplary embodiment of the present invention may require no changes to GGSN 118 and deployed SGSNs 114 (except the SGSN 114 that in conjunction with the HA 110 may enable the access).
The exemplary embodiment of the present invention may be deployed in stages, i.e., not all PLMNs 109 may need to introduce a new MIP-enabled HA 110/SGSN 114 entity-instead, the MIP-enabled HA 110/SGSN 114 may be introduced in a single PLMN 108 initially, and may be phased in to other PLMNs 108, at a later time. The exemplary embodiment of the present invention may place control in the hands of an operator of the GPRS PLMN 108, i.e., there may be no dependence on an external internet service provider (ISP) to deploy a HA 110.
The exemplary embodiment of the present invention may consequently be used where a cellular operator that may provide the service may control all entities that may make the service access possible. In the absence of the exemplary embodiment of the present invention, the cellular operator may need to negotiate a multitude of agreements with various ISPs and/or may deploy multiple interworking entities in different hotspots 104 to enable similar functionality.
The exemplary embodiment of the present invention may allow the HA 110 to be active only when the Mobile Node 102 may access the GPRS network from a WLAN. The HA 110 also may not need to advertise. Thus an exemplary embodiment of the present invention may not be tied to deploying a HA 110 per subnet. Multiple subnetted operators may support service access without any external dependencies.
There may be few components in the network infrastructure to manage.
An exemplary embodiment of the present invention may work with IP networks (such as, e.g., but not limited to, IPv4 or IPv6, etc.) and/or with transition networks.
An exemplary embodiment of the present invention may be deployed on, e.g., but not limited to, an IXP blade with a micro-engine performance extension.
In another exemplary embodiment, an MN 102 may include a modified version of an operating system (OS), which may support multiple addresses per network interface card (NIC) and may allow services to be associated with the multiple supported addresses. The modified OS embodiment, may lead to fragmentation of OS platforms.
In another exemplary embodiment, the present invention may degrade gracefully including, e.g., in an event of breaking down of the HA 110 functionality, the present invention may allow normal GPRS traffic to flow unhindered.
An exemplary embodiment of the present invention may be scalable including, e.g., but not limited to, introducing one or more entities as may be deemed needed. The present invention may not further load an existing network device in the PLMN 108.
An exemplary embodiment of the present invention may include flexibility and may be implemented in a collocated or non-collocated manner.
In an exemplary embodiment of the present invention, multiple WLANs and/or roaming between multiple IP based networks may be supported by a single instantiation of the present invention.
Although in the exemplary embodiment a user 101 (not shown) may be described as using a device referred to as a client or MN 102 that may be coupled to a device referred to as a server device, the client 102 and server devices 110, 120 need not have a client/server relationship. For example, client 102 and the server devices may be similar devices and/or may communicate in a peer-to-peer manner. Alternatively, client device 102 and the server device may be labeled first device 102 and second device, respectively. Further the devices 102, 110, 120 as described may be coupled via one or more communications links, such as, e.g., but not limited to wireless communications links. Other ways of coupling client 102 and the server may equally be used to accomplish communication such as, e.g., (but not limited to) a wired network connection, a local connection, a local area, wide area, or metropolitan area network connection, a community access television (CATV, or cable TV) connection, a satellite connection, a bus connection, an optical connection, a parallel or serial data bus, universal serial bus (USB) connection, or other bus, etc.
The computer system 500 may include one or more processors, such as, e.g., but not limited to, processor(s) 504. The processor(s) 504 may be connected to a communication infrastructure 506 (e.g., but not limited to, a communications bus, cross-over bar, or network, etc.). Various exemplary software embodiments may be described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures.
Computer system 500 may include a display interface 502 that may forward, e.g., but not limited to, graphics, text, and other data, etc., from the communication infrastructure 506 (or from a frame buffer, etc., not shown) for display on the display unit 530.
The computer system 500 may also include, e.g., but may not be limited to, a main memory 508, random access memory (RAM), and a secondary memory 510, etc. The secondary memory 510 may include, for example, (but not limited to) a hard disk drive 512 and/or a removable storage drive 514, representing a floppy diskette drive, a magnetic tape drive, an optical disk drive, a compact disk drive CD-ROM, etc. The removable storage drive 514 may, e.g., but not limited to, read from and/or write to a removable storage unit 518 in a well known manner. Removable storage unit 518, also called a program storage device or a computer program product, may represent, e.g., but not limited to, a floppy disk, magnetic tape, optical disk, compact disk, etc. which may be read from and written to by removable storage drive 514. As will be appreciated, the removable storage unit 518 may include a computer usable storage medium having stored therein computer software and/or data.
In alternative exemplary embodiments, secondary memory 510 may include other similar devices for allowing computer programs or other instructions to be loaded into computer system 500. Such devices may include, for example, a removable storage unit 522 and an interface 520. Examples of such may include a program cartridge and cartridge interface (such as, e.g., but not limited to, those found in video game devices), a removable memory chip (such as, e.g., but not limited to, an erasable programmable read only memory (EPROM), or programmable read only memory (PROM) and associated socket, and other removable storage units 522 and interfaces 520, which may allow software and data to be transferred from the removable storage unit 522 to computer system 500.
Computer 500 may also include an input device such as, e.g., (but not limited to) a mouse or other pointing device such as a digitizer, and a keyboard or other data entry device (none of which are labeled).
Computer 500 may also include output devices, such as, e.g., (but not limited to) display 530, and display interface 502. Computer 500 may include input/output (I/O) devices such as, e.g., (but not limited to) communications interface 524, cable 528 and communications path 526, etc. These devices may include, e.g., but not limited to, a network interface card, and modems (neither are labeled). Communications interface 524 may allow software and data to be transferred between computer system 500 and external devices. Examples of communications interface 524 may include, e.g., but may not be limited to, a modem, a network interface (such as, e.g., an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communications interface 524 may be in the form of signals 528 which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 524. These signals 528 may be provided to communications interface 524 via, e.g., but not limited to, a communications path 526 (e.g., but not limited to, a channel). This channel 526 may carry signals 528, which may include, e.g., but not limited to, propagated signals, and may be implemented using, e.g., but not limited to, wire or cable, fiber optics, a telephone line, a cellular link, an radio frequency (RF) link and other communications channels, etc.
In this document, the terms “computer program medium” and “computer readable medium” may be used to generally refer to media such as, e.g., but not limited to removable storage drive 514, a hard disk installed in hard disk drive 512, and signals 528, etc. These computer program products may provide software to computer system 500. The invention may be directed to such computer program products.
References to “one embodiment,” “an embodiment,” “example embodiment,” “various embodiments,” etc., may indicate that the embodiment(s) of the invention so described may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrase “in one embodiment,”or “in an exemplary embodiment,” do not necessarily refer to the same embodiment, although they may.
In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Rather, in particular embodiments, “connected” may be used to indicate that two or more elements are in direct physical or electrical contact with each other. “Coupled” may mean that two or more elements are in direct physical or electrical contact. However, “coupled” may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
An algorithm is here, and generally, considered to be a self-consistent sequence of acts or operations leading to a desired result. These include physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like. It should be understood, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.
Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices.
In a similar manner, the term “processor” may refer to any device or portion of a device that processes electronic data from registers and/or memory to transform that electronic data into other electronic data that may be stored in registers and/or memory. A “computing platform” may comprise one or more processors.
Embodiments of the present invention may include apparatuses for performing the operations herein. An apparatus may be specially constructed for the desired purposes, or it may comprise a general purpose device selectively activated or reconfigured by a program stored in the device.
Embodiments of the invention may be implemented in one or a combination of hardware, firmware, and software. Embodiments of the invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by a computing platform to perform the operations described herein. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others.
Computer programs (also called computer control logic), may include object oriented computer programs, and may be stored in main memory 508 and/or the secondary memory 510 and/or removable storage units 514, also called computer program products. Such computer programs, when executed, may enable the computer system 500 to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, may enable the processor 504 to provide a method to resolve conflicts during data synchronization according to an exemplary embodiment of the present invention. Accordingly, such computer programs may represent controllers of the computer system 500.
In another exemplary embodiment, the invention may be directed to a computer program product comprising a computer readable medium having control logic (computer software) stored therein. The control logic, when executed by the processor 504, may cause the processor 504 to perform the functions of the invention as described herein. In another exemplary embodiment where the invention may be implemented using software, the software may be stored in a computer program product and loaded into computer system 500 using, e.g., but not limited to, removable storage drive 514, hard drive 512 or communications interface 524, etc. The control logic (software), when executed by the processor 504, may cause the processor 504 to perform the functions of the invention as described herein. The computer software may run as a standalone software application program running atop an operating system, or may be integrated into the operating system.
In yet another embodiment, the invention may be implemented primarily in hardware using, for example, but not limited to, hardware components such as application specific integrated circuits (ASICs), or one or more state machines, etc. Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s).
In another exemplary embodiment, the invention may be implemented primarily in firmware.
In yet another exemplary embodiment, the invention may be implemented using a combination of any of, e.g., but not limited to, hardware, firmware, and software, etc.
The exemplary embodiments of the present invention may make reference to WLANs. Examples of a WLAN may include a shared wireless access protocol (SWAP) developed by Home radio frequency (HomeRF), and wireless fidelity (Wi-Fi), a derivative of IEEE 802.11, advocated by the wireless ethernet compatibility alliance (WECA). The IEEE 802.11 wireless LAN standard refers to various technologies that adhere to one or more of various wireless LAN standards. An IEEE 802.11 compliant wireless LAN may comply with any of one or more of the various IEEE 802.11 wireless LAN standards including, e.g., but not limited to, wireless LANs compliant with IEEE std. 802.11, such as those referenced above, etc.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should instead be defined only in accordance with the following claims and their equivalents.
