HK1155579A - Systems and methods for multiplexing multiple connections in mobile ip network - Google Patents

Abstract

Disclosed are systems, methods and computer program products for facilitating multiplexing of simultaneous multiple connections between a mobile device and its IP mobility anchors, such as mobile IP home agents or proxy mobile IP local mobility anchors. An example method comprises assigning a unique IP mobility anchor identifier to each IP mobility anchor associated with the mobile device. The method further comprises negotiating an IP flow reservation for each IP mobility anchor identifier and signaling a request to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor. The method further comprises sending packets through each negotiated IP flow and associated IP tunnel to each IP mobility anchor.

Description

System and method for multiplexing multiple connections in a mobile IP network

Claiming priority in accordance with 35U.S.C. § 119

The present patent application claims priority of provisional application No. 61/055,387 entitled System and method for Providing Multiple IP Mobility Connectivity Over HRDP, filed on 5/22/2008, and which is assigned to the assignee of the present application and hereby expressly incorporated herein by reference.

Technical Field

The present invention relates generally to the field of wireless communications, and more specifically to a system and method for providing multiple connections in a mobile Internet Protocol (IP) network.

Background

Wireless communication systems are widely deployed to provide various types of communication content such as voice, data, and so on. These systems may be multiple-access systems capable of supporting communication with multiple mobile devices by sharing the available system resources (e.g., bandwidth and transmit power). Examples of such multiple-access systems include Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, 3GPP Long Term Evolution (LTE) systems, and the like.

Most current wireless communication systems support Internet Protocol (IP) over packet-switched networks for data and voice communications, and in particular, the two most common versions of that protocol, i.e., IPv4 and IPv 6. Both versions of the protocol provide mobility support and allow mobile devices to remain reachable while moving between various wireless networks. In general, mobile IP allows a mobile device to move from one network to another without changing the mobile device's "home address" (HoA), which is assigned to the mobile device by its Home Agent (HA) (also known as a Local Mobility Agent (LMA)) residing in the home network. This address may be used to route packets to the mobile device regardless of the point of attachment of the mobile device in the foreign network.

For example, to remain reachable in the IPv6 domain, a mobile device must create and maintain a binding between its HA-assigned HoA and its "care-of address" (CoA) in the foreign network by exchanging signaling messages with its home agent. Alternatively, the binding may be created and maintained by the network without the participation of the mobile device. In this way, a proxy server agent in the foreign network performs signaling with a Local Mobility Anchor (LMA) in the home network and mobility management on behalf of the mobile device. In turn, the HA/LMA manages the assignment of home addresses to mobile devices, manages the binding state of the devices, and specifies which services and applications are available to the mobile devices.

Different HAs/LMAs provide different types of services, e.g. IMS, public internet services, etc. To access these services, the mobile device should request simultaneous connectivity with multiple HA/LMAs. However, some wireless communication systems that support both mobile IPv4 and IPv6, such as the High Rate Packet Data (HRPD) technology implemented in CDMA2000, generally allow each mobile device to have only a single HA/LMA connection, and require all HA/LMAs to assign IPv4 addresses from the same address space to the mobile device due to the lack of available IPv4 addresses. With the increasing popularity of mobile devices and the need for differentiated services use, a solution is needed that supports simultaneous connectivity with multiple HA/LMAs via HRPD and other protocols that support Ipv4 and Ipv6 mobility.

Disclosure of Invention

The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

In accordance with one or more embodiments and corresponding disclosure thereof, various aspects are described relating to facilitating multiplexing of simultaneous multiple connections between a mobile device and its IP mobility anchor (e.g., a Mobile IP home agent or a proxy Mobile IP local mobility anchor). An example method includes: assigning a unique IP mobility anchor identifier to each IP mobility anchor associated with the mobile device; negotiating an IP flow reservation for each IP mobility anchor identifier; signaling a request to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor; and sending packets through each negotiated IP flow and associated IP tunnel to each IP mobility anchor.

To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed and this description is intended to include all such aspects and their equivalents.

Drawings

The disclosed aspects will hereinafter be described in conjunction with the appended drawings, provided to illustrate and not to limit the disclosed aspects, wherein like designations denote like elements, and in which:

fig. 1 is an illustration of a wireless communication system in accordance with various aspects set forth herein.

Fig. 2 is an illustration of an example methodology for multiplexing simultaneous multiple HA/LMA connections in a wireless communication system.

Fig. 3 is an illustration of another example method for multiplexing simultaneous multiple HA/LMA connections in a wireless communication system.

Fig. 4 is an illustration of an example method for multiple IP address assignments in a wireless communication system.

Fig. 5 is an illustration of an example methodology for providing multiple PDN contexts for a single PDN/LMA.

FIG. 6 is an illustration of example reservation flags used to facilitate multiplexing of simultaneous multiple HA/LMA connections.

Fig. 7 is an illustration of an example PDN context identifier.

Fig. 8 is an illustration of an example wireless communication system.

FIG. 9 is an illustration of an example system for multiplexing simultaneous multiple HA/LMA connections.

FIG. 10 is an illustration of an example mobile device that is operable to create and support simultaneous multiple HA/LMA connections.

Detailed Description

Various aspects are now described with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects. It may be evident, however, that such aspect(s) may be practiced without these specific details.

As used in this application, the terms "component," "module," "system," and the like are intended to encompass a computer-related entity, such as but not limited to hardware, firmware, a combination of hardware and software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the internet with other systems by way of the signal).

Furthermore, various embodiments are described herein in connection with a mobile device. A mobile device can also be called a system, a subscriber unit, subscriber station, mobile, remote station, remote terminal, access terminal, user terminal, wireless communication device, user agent, user device, or User Equipment (UE). The mobile device may be a cellular telephone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a Personal Digital Assistant (PDA), a handheld device having wireless connection capability, a laptop computer, or other processing device connected to a wireless modem.

Moreover, various aspects or features described herein may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer-readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips, etc.), optical disks (e.g., Compact Disk (CD), Digital Versatile Disk (DVD), etc.), smart cards, and flash memory devices (e.g., EPROM, card, stick, key drive, etc.). In addition, various storage media described herein can represent one or more devices and/or other machine-readable media for storing information. The term "machine-readable medium" can include, without being limited to, wireless channels and various other media capable of storing, containing, and/or carrying instruction(s) and/or data.

The techniques described herein may be used for various wireless communication systems such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other systems. The terms "system" and "network" are generally used interchangeably. A CDMA system may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), CDMA2000, etc. UTRA includes wideband CDMA (W-CDMA) and other CDMA variants. In addition, cdma2000 covers IS-2000, IS-95 and IS-856 standards. A TDMA system may implement a radio technology such as global system for mobile communications (GSM). The OFDMA system may implement radio technologies such as evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11(Wi-Fi), IEEE 802.16(WiMAX), IEEE 802.20, Flash-OFDM, etc. UTRA and E-UTRA are parts of the Universal Mobile Telecommunications System (UMTS). 3GPP Long Term Evolution (LTE) is a release of UMTS that uses E-UTRA, which uses OFDMA on the downlink and SC-FDMA on the uplink. UTRA, E-UTRA, UMTS, LTE and GSM are described in the literature from an organization named "third Generation partnership project" (3 GPP). In addition, cdma2000 and UMB are described in literature from an organization named "third generation partnership project 2" (3GPP 2). Additionally, such wireless communication systems may additionally include peer-to-peer (e.g., mobile-to-mobile) ad hoc network systems, often using unpaired unlicensed spectrum, 802.xx wireless LANs, BLUETOOTH, and any other short-range or long-range wireless communication technologies.

Various aspects or features will be presented in terms of systems that may include a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. Combinations of these methods may also be used.

Referring now to fig. 1, a wireless communication system 100 is illustrated in accordance with various embodiments presented herein. The system 100 includes one or more home networks 101 for a plurality of mobile devices 105 and a foreign network 102 where the mobile devices 105 are currently located. The home network and the foreign network may be connected by a packet-switched network 103, such as the internet. Foreign network 102 may be a Radio Access Network (RAN), such as CDMA2000, or any other type of wireless communication system. In general, foreign network 102 may include RAN controller 110, a plurality of radio base stations 115, and an access gateway 120. The radio base station 115 may include multiple antenna groups and/or transmitter/receiver chains, which in turn may include multiple components (e.g., processors, modulators, multiplexers, antennas, etc. (not shown)) associated with transmitting radio signals to and receiving radio signals from the mobile device 115. The home network 101 may be a wireless or wired network and may include a plurality of Home Agents (HA)130, the Home Agents (HA)130 also referred to herein as Local Mobility Anchors (LMAs).

More specifically, the foreign RAN 102 provides wireless connectivity to the mobile device 115 for accessing services provided by the HA/LMA in the home network 101. RAN controller 110 is a network device that provides data connectivity between mobile devices 115 and PDSN gateway 120. The primary functions of RAN controller 110 include establishing, maintaining, and terminating radio channels; radio resource management; and mobility management. The radio channel between mobile device 115 and RAN controller 110 is referred to as a Radio Link Protocol (RLP) flow. Mobile device 115 typically negotiates with RAN controller 110 reservations for different RLP flows for different services provided by the HA/LMA in its home network 101, as described in more detail below. In one example, RAN controller 110 supports a Packet Control Function (PCF) that controls the transmission of packets between RAN controller 110 and PDSN gateway 120 using a bearer connection through an a10 data interface and an a11 signaling interface.

In one aspect, the access gateway 120 aggregates data traffic from multiple RAN controllers and provides access to the packet-switched network 103 (e.g., the internet, intranets, and the home network 101 of the mobile device 115) using CDMA2000 or other radio access technology. According to one example embodiment, access gateway 120 may be implemented as a Packet Data Serving Node (PDSN). If the system 100 supports mobile IPv4 or IPv6 protocols, the access gateway 120 provides mobile IPv4 and IPv6 packet transmissions for signaling and data transmission/reception to/from the mobile device 115 and its Home Agent (HA) 130. In particular, when receiving data packets from the mobile device 115 over an a10/a11 bearer connection, the access gateway 120 uses binding state information associated with the device's home address (HoA) to identify the HA 130 of the mobile device 115, creates a bidirectional tunnel with the device's HA 130, encapsulates the received packets with the source address of the access gateway as a care-of address (CoA) in new packets, and transmits the encapsulated packets through the tunnel to the appropriate HA. When a data packet is received from HA 130 over the tunnel, PDSN gateway 120 decapsulates it based on binding state information associated with HA 130 and forwards it over the appropriate bearer connection to mobile device 115.

If the system 100 supports the proxy mobile IPv6 protocol, then, in addition to the services described above, the access gateway 120 also acts as a proxy server proxy, referred to as a Mobile Access Gateway (MAG) in the proxy Mobile IPv6 specification RFC 5213 promulgated by the Internet Engineering Task Force (IETF). As a proxy server agent, PDSN gateway 120 typically manages mobility-related signaling for mobile devices 115 attached to foreign network 102 so that bindings to the LMA for each mobile device may be created and maintained by the network without mobile device involvement. Thus, the access gateway 120 is responsible for tracking the movement of mobile devices to and from the foreign network 102 and for signaling Proxy Binding Updates (PBUs) to its LMA130 on behalf of the mobile device 115. Access gateway 120 may also provide authentication, authorization, and accounting (AAA) services and other services.

The home agent 130 (as defined in mobile IPv6 basic specification RFC 3775) is a topology anchor for the mobile device's home network prefix and is an entity that manages the binding state of the mobile device. The Local Mobility Anchor (LMA)130 HAs the functional capabilities of the HA 130 and the additional capabilities required to support proxy Mobile IPv6 specification RFC 5213. The binding is the association of the HoA of the mobile device in the home network 101 with the CoA in its foreign network 102. The HoA is the address of the home network prefix from the mobile device specified by the HA/LMA 130. For example, when there are multiple home prefixes on the home network 101, the mobile device 115 may have multiple hoas. If a mobile device uses more than one address from its home network prefix, then any of these addresses is referred to as the mobile device's home address. In mobile IPv6, home agent 130 generally knows the home address of mobile device 115. However, in proxy mobile IPv6, the mobility entities (e.g., proxy agent 120 and LMA 130) are only aware of the mobile device's home network prefix and are not aware of the exact address used by the mobile device 115 to establish a connection to the HA/LMA 130.

This lack of knowledge of the network portion regarding the exact assignment of home addresses to mobile device 115 becomes a problem when the mobile device attempts to set up simultaneous connections to multiple HAs/LMAs. This problem can best be explained as follows: in the case where a unique home network prefix is assigned to the mobile device by each HA/LMA, the connection request from the mobile device 115 will indicate its HoA selected from the assigned home network prefix, so that the access gateway 120 (which acts as a proxy server proxy in the proxy mobile IPv6 domain) will know exactly to which HA/LMA130 a given connection should be directed. However, when HA/LMA 130A and HA/LMA 130B assign home network prefixes from the same address space, mobile device 115 selects its home address from the home network prefix space associated with HA/LMA 130A and HA/LMA 130B. In this case, when data is coming from mobile device 115, access gateway 120 does not know whether to direct this data traffic to HA/LMA 130A or HA/LMA 130B.

To address this problem, an example method for multiplexing multiple simultaneous HA/LMA connections is depicted in FIG. 2. In step 210, mobile device 115 may create a unique IP mobility anchor identifier and assign a unique IP mobility anchor identifier to each HA/LMA130 to which it wants to connect. In step 220, the mobile device may negotiate IP flows (e.g., RLP flows) for each IP mobility anchor identifier with RAN 110. The RAN, in turn, may set up a corresponding bearer connection (e.g., an a10/a11 connection) to access gateway 120 to support the negotiated IP flow from mobile device 115. In step 230, mobile device 115 may signal a request to access gateway 120 to associate each negotiated IP flow with an IP tunnel to a particular HA/LMA 130. In step 240, the mobile node 15 transmits the packet to the appropriate HA/LMA130 through the negotiated IP flow and associated IP tunnel. Packets sent through each negotiated IP flow are multiplexed by the access gateway 120 into the appropriate IP tunnel based on the association of the IP flow with the specified HA/LMA 130. Thus, based on these aspects, each IP flow corresponds directly to a designated HA/LMA 130.

Figure 3 depicts another example method for multiplexing simultaneous multiple HA/LMA connections from a mobile device. In step 310, mobile device 115 creates a new IP flow reservation label for multiple HA/LMA connectivity. An example structure of the retention marker 600 is depicted in fig. 6. In one example, the reservation label 600 may be an 8-bit string, the 4 most significant bits of which may be used to store the IP mobility anchor identifier 605 of the HA/LMA130, and the 4 least significant bits of which may store the IP flow identifier 610, such as the RLP flow identifier. At the same time, mobile device 115 may create a new HRPD attribute of the new reservation label that identifies the structure of the new reservation label. An 8-bit reservation flag may be used to identify 15 different HA/LMAs and 15 different IP flows. Those skilled in the art will appreciate that the reservation label may be longer or shorter depending on system resources and requirements. In addition, the size of the IP mobility anchor identifier and the IP flow identifier may vary depending on the number of HA/LMAs 130 available for simultaneous access. The attributes of the newly retained tag may be communicated by mobile device 115 to RAN controller 110 and/or other network components so that it knows how to interpret the new tag.

In step 320, mobile device 115 may generate a unique IP mobility anchor identifier for each HA/LMA130 to which the mobile device wants to connect. For example, for a 4-bit long identifier, the mobile device may select a value in the range of 1 to 16. For a 5-bit identifier, the range is 1 to 32. It should be noted that the selection of the IP mobility anchor identifier is handled entirely by the mobile device 115 itself, and any number in the specified range may be selected as long as it uniquely identifies the HA/LMA130 that it represents. No two HA/LMA130 may have the same IP mobility anchor identifier.

In step 330, a new IP flow for the defined reservation label is negotiated between mobile device 115 and RAN controller 110. During the negotiation, the application of the mobile device identifies the specific protocol, QoS parameters, and resources from the network needed to support the IP flow requested by the mobile device. For example, the particular protocol, QoS parameters, and required resources from the network may vary with the requesting application or service, e.g., a voice call application may have one set of requirements while a data call application may have another set of requirements.

In step 340, mobile device 115 and RAN 110 set up an RLP flow for each IP mobility anchor identifier. For example, multiple reservations belonging to the same IP mobility anchor identifier may share the same RLP flow if the QoS requirements remain the same, otherwise a different RLP flow may be set up. Once RAN controller 110 has accepted the QoS request of the mobile node and from this point on, RAN controller 110 will control the configuration, activation, and association of QoS flows at the RLP layer and ultimately at the RTCMAC layer.

In step 350, RAN controller 110 creates at least one bearer connection (e.g., a10/a11 connection) for each IP mobility anchor identifier associated with the reservation label. In other words, no two reservations with different IP mobility anchor identifiers may share the same A10/A11 flow. The a11 interface carries signaling information between the Packet Control Function (PCF) and the access gateway 130. The a10 interface carries user traffic between the PCF and the access gateway 130.

In step 360, the mobile device 115 may signal an instruction to associate a reservation label with the appropriate HA/LMA130 to the access gateway 120. The reservation label is exchanged to identify which HA/LMA and which IP flow the packet corresponds to. For example, mobile device 115 may specify an ID/name of the HA/LMA device, such as "service. When the PDN gateway acts as an LMA, the mobile device may specify an Access Point Name (APN) for the PDN gateway. The signaling between mobile device 115 and access gateway 120 may be performed using PPP, RSVP, SIP, or other signaling protocols.

In step 370, the PDSN associates the a10 connection from RAN 110 established in step 350 with the name/ID of the HA/LMA specified in the signaling message from the mobile device based on the IP mobility anchor identifier specified in the reservation label. In this manner, packets transmitted from mobile device 115 via the IP flow associated with the reservation label are mapped by the access gateway into one or more IP tunnels based on the association of the IP flow with the particular IP mobility anchor.

Mobile device 115 transmits the packets to RAN controller 110 via radio network 102 using the negotiated IP flow in step 380, and RAN controller 110 places the packets on the appropriate bearer connection for delivery to PDSN gateway 120 in step 390. In steps 395A and 395B, the access gateway maps the received packet to the appropriate channel based on the association of the IP flow with the particular IP mobility anchor, encapsulates the packet and tunnels it to the IP mobility anchor (HA/LMA 130A or HA/LMA 130B). In this way, multiplexing of simultaneous multiple HA/LMA connections via a PMIP network is achieved.

In one aspect, an example method is provided for assigning multiple home addresses to a mobile device 115 in a proxy mobile ip (pmip) domain. This IP address assignment process is typically performed before mobile device 115 initiates a communication session with HA/LMA130 (as described above in diagram 300). In one aspect, the mobile device 115 may utilize a point-to-point (PPP) protocol to obtain the HoA assignment from the HA/LMA 130. In another aspect, instead of using PPP, the mobile device may use DHCP and a PDSN gateway via the secondary flow.

Figure 4 illustrates a PPP-based implementation of this method. In step 405, the mobile device executes PPP Link Control Protocol (LCP) to establish communications over the point-to-point link and configure and test the data link with access gateway 130. After the link has been established, the mobile device and access gateway may be authenticated in step 410. In steps 415 and 420, the access gateway performs authentication, authorization, and accounting (AAA) services for the mobile device. In steps 425 and 430, the mobile device exchanges PPP Internet Protocol Control Protocol (IPCP) or any network control protocol request and response messages with the PDSN gateway. At step 435, the mobile device sends the name of the LMA to the PDSN gateway that the mobile device wants to connect to and from which the mobile device wants to obtain the HoA. An example of an LMA name may be "service. If the PDN acts as an LMA, then the LMA name will be the Access Point Name (APN) of the PDN. In steps 440 and 445, PDSN gateway 130 performs PMIP binding updates with LMA2 and receives in response to the IP address to be used as the HoA for the mobile device. In step 450, PDSN gateway 130 forwards the newly assigned IP address to mobile device 115. Using the newly assigned HoA address, mobile device 115 continues to establish a TFT session with the PDSN gateway to associate the IP flow with QoS in step 455.

The method disclosed herein for providing simultaneous multiple HA/LMA connections may be extended to create multiple PDN contexts (IPv4, IPv6, IPv4/v6) with the same PDN for each type of IP address to further improve system resource allocation and utilization. Currently, assigning a unique PDN-ID to each context would consume additional PDN-IDs. Furthermore, based on current solutions, similar QoS-IP flows for PDN contexts of the same PDN are typically forced to be carried on separate RLP flows when the IP address types used are different, which is not desirable. In other words, IP flows that assign different PDN contexts of the same PDN on the same RLP flow are needed.

One example solution to this problem is to create a new identifier, i.e. a PDN-context identifier. Fig. 7 illustrates one example of the structure of a PDN context identifier 700. As depicted, the upper four bits of the PDN context ID 700 may be set to the PDN-ID 705 and the lower four bits of the PDN context ID 700 may be set to the PDN context type 710. The PDN context type may be IPv4, IPv6, IPv4/IPv6, etc. In one example, the reservation label is maintained as [ PDN-ID, flow ID ]. The reservation label may still be used for air interface purposes such as radio channel setup and RSVP signaling between the mobile device and the PDSN gateway. The access gateway 130 uses the upper four bits of the PDN context ID and matches them with the upper four bits of the reservation label to map the PDN context with the IP flow ID. The use of multiple PDN contexts (for the same PDN) remains transparent to RAN 110 and RLP flows. This allows for flexible/loose association of PDN context with IP flows for the same PDN. In other words, the IP flow does not identify the PDN context in the identifier. In this way, multiple PDN contexts with the same PDN can be created for each type of IP address, thereby further improving system resource allocation and utilization.

Fig. 5 illustrates a method for setting up a PDN context for a PDSN wireless communication system. In step 505, the mobile application requests an IPv4 address for the LMA1/PDN 1. In step 510, the mobile device generates a PDN context. PDN context ═ (PDN type | PDN _ ID). The PDN _ ID may be a 4-bit unique ID that the mobile device chooses randomly for each LMA/PDN. The PDN type is set to IPv4 type because the application has requested an IPv4 address in this case. In step 515, the generated PDN context is associated with the PDN1 for IPv4 addresses using a network control protocol, such as IPCP or vendor proprietary network control protocol (VSNCP). In step 520, the access gateway sends a binding update to the LMA 1. In step 525, the mobile device generates a reservation label based on this IPv4 connection. For example, in one aspect, the reservation flag is (PDN _ ID | Flow _ IDa). The PDN-ID is set to the PDN-ID selected at step 510 for the QoS flow corresponding to that PDN. The stream-ID may be a 4-bit unique ID that the mobile device randomly chooses for each stream. In step 530, the mobile device sets up a QoS flow, which includes the following parameters: reservation flags, QoS profiles, and others. In step 535, RAN 110 sets up an a11 bearer connection based on the QoS flow. In step 540, the RSVP program associates the reservation label created at step 525 with packet filtering/QoS. In step 545, another application requests an IPv6 address from the same PDN (PDN-1). In step 550, the PDN _ ID is set to the same PDN-ID selected at step 510. The PDN type is set to IPv6 type because the application requested an IPv6 address. In step 555, the PDN context generated at step 550 is associated with LMA1/PDN1 for IPv6 addresses using this VSNCP procedure. In step 560, the updated binding update is performed to add the IPv6 address to the IPv4 tunnel that has been set at step 525). Alternatively, a separate tunnel may be set up for IPv 6.

Fig. 8 shows an example wireless communication system 800. The wireless communication system 800 depicts one base station/forward link transmitter 810 and one mobile device 850 in a radio access network for sake of brevity. However, it is to be appreciated that system 800 can include more than one base station/forward link transmitter and/or more than one mobile device, wherein additional base stations/transmitters and/or mobile devices can be substantially similar or different from example base station/forward link transmitters 810 and mobile devices 850 described below. Additionally, it is to be appreciated that base station/forward link transmitter 810 and/or mobile device 850 can employ the systems (fig. 1) and/or methods (fig. 2-7) described herein to facilitate wireless communication there between.

At the base station/forward link transmitter 810, traffic data for a number of data streams is provided from a data source 812 to Transmit (TX) data processor 814. According to an example, each data stream may be transmitted via a respective antenna. TX data processor 814 formats, codes, and interleaves the traffic data stream based on a particular coding scheme selected for that data stream to provide coded data.

The coded data for each data stream may be multiplexed with pilot data using Orthogonal Frequency Division Multiplexing (OFDM) techniques. Additionally or alternatively, the pilot symbols may be Frequency Division Multiplexed (FDM), Time Division Multiplexed (TDM), or Code Division Multiplexed (CDM). The pilot data is typically a known data pattern that is processed in a known manner and can be used at mobile device 850 to estimate channel response. The multiplexed pilot and coded data for each data stream may be modulated (e.g., symbol mapped) based on a particular modulation scheme (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM), etc.) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream may be determined by instructions performed or provided by processor 830.

The modulation symbols for the data streams may be provided to a TX MIMO processor 820, which TX MIMO processor 820 may further process the modulation symbols (e.g., for OFDM). TX MIMO processor 820 then provides a stream of NT modulation symbols to NT transmitters (TMTR)822a through 822 t. In various embodiments, TX MIMO processor 820 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

Each transmitter 822 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. Further, NT modulated signals from transmitters 822a through 822t are transmitted from NT antennas 824a through 824t, respectively.

At mobile device 850, the transmitted modulated signals are received by NR antennas 852a through 852r and the received signal from each antenna 852 is provided to a respective receiver (RCVR)854a through 854 r. Each receiver 854 conditions (e.g., filters, amplifies, and downconverts) a respective signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding "received" symbol stream.

An RX data processor 860 can receive the NR symbol streams received from NR receiver 854 and process the NR received symbol streams based on a particular receiver processing technique to provide NT "detected" symbol streams. RX data processor 860 may demodulate, deinterleave, and decode each detected symbol stream to recover the traffic data for the data stream. The processing by RX data processor 860 is complementary to that performed by TX MIMO processor 820 and TX data processor 814 at base station/forward link transmitter 810.

A processor 870 can periodically determine which precoding matrix to utilize as discussed above. Further, processor 870 can formulate a reverse link message comprising a matrix index portion and a rank value portion.

The reverse link message may comprise various types of information regarding the communication link and/or the received data stream. The reverse link message may be processed by a TX data processor 838, which also receives traffic data for a number of data streams from a data source 836, modulated by a modulator 880, conditioned by transmitters 854a through 854r, and transmitted back to base station/forward link transmitter 810.

At base station/forward link transmitter 810, the modulated signals from mobile device 850 can be received by antennas 824, conditioned by receivers 822, demodulated by a demodulator 840, and processed by a RX data processor 842 to extract the reverse link message transmitted by mobile device 850. In addition, processor 830 can process the extracted message to determine which precoding matrix to use for determining the beamforming weights. It should be appreciated that in the case of a forward link transmitter 810, as opposed to a base station, these RX components may not be present since data is only broadcast via the forward link.

Processors 830 and 870 can direct (e.g., control, coordinate, manage, etc.) operation at base station/forward link transmitter 810 and mobile device 850, respectively. Respective processors 830 and 870 can be associated with memory 832 and 872 that store program codes and data. Processors 830 and 870 can also perform computations to derive frequency and impulse response estimates for the uplink and downlink, respectively.

It is to be understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For a hardware implementation, the processing unit may be implemented within: one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof.

When the embodiments are implemented in software, firmware, middleware or microcode, program code or code segments, they can be stored in a machine-readable medium, such as a storage component. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted using any suitable means including memory sharing, message passing, token passing, network transmission, etc.

For a software implementation, the techniques described herein may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in memory units and executed by processors. The memory unit may be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.

Turning to fig. 9, illustrated is a system 900 for multiplexing multiple simultaneous HA/LMA connections. System 900 may reside in a mobile device. As depicted, system 900 includes functional blocks that can represent functions implemented by a processor, software, or combination thereof (e.g., firmware). System 900 includes a logical grouping 902 of electrical components that facilitate multiplexing multiple simultaneous HA/LMA connections. Logical grouping 902 may include means 904 for creating and assigning a unique IP mobility anchor identifier to each HA/LMA to which the mobile device wants to connect. Further, logical grouping 902 can include means 906 for negotiating with the RAN an IP flow (e.g., RLP flow) for each IP mobility anchor identifier. The RAN, in turn, may set up a corresponding bearer connection (e.g., an a10/a11 connection) to the PDSN gateway to support the negotiated IP flow from the mobile device. Further, logical grouping 902 may comprise means for signaling a request to associate each negotiated IP flow with an IP tunnel to a particular HA/LMA to a PDSN gateway 908. Finally, logical grouping 902 may include means for transmitting the packet through the negotiated IP flow and associated IP tunnel to the appropriate HA/LMA 909. Packets sent through each negotiated IP flow are multiplexed by the PDSN gateway into the appropriate IP tunnel based on the association of the IP flow with the specified HA/LMA. Additionally, system 900 can include a memory 910 that retains instructions for executing functions associated with electrical components 904, 906, 908, and 909. While shown as being external to memory 910, it is to be understood that electrical components 904, 906, 908, and 909 can exist within memory 910.

FIG. 10 illustrates an example mobile device 1000 operable to create and support simultaneous multiple HA/LMA connections in accordance with the methods disclosed herein. The mobile device 1000 includes a processor 1010 for performing processing functions associated with one or more of the components and functions described herein. Processor 1010 may include a single or multiple sets of processors or multi-core processors. The mobile device 1000 further includes a memory 1020 coupled to the processor 1010, such as for storing a local version of an application being executed by the processor 1010. Memory 1020 may include any type of memory usable by a computer, such as Random Access Memory (RAM), Read Only Memory (ROM), magnetic disks, optical disks, volatile memory, non-volatile memory, and any combination thereof.

Additionally, mobile device 1000 includes a communication component 1030 coupled to processor 1010 for utilizing hardware, software, and services to establish and maintain communication with one or more radio access networks as described herein. For example, communications component 1030 may include transmit chain components and receive chain components associated with a transmitter and receiver, respectively, operable for interfacing with external radio networks and devices. Additionally, the mobile device 1000 may further include a data storage 1040 coupled to the processor 1010, the data storage 1040 may be any suitable combination of hardware and/or software that provides mass storage of information, databases, and programs used in connection with the aspects described herein. For example, data storage 1040 may be a data store for applications not currently being executed by processor 1010.

The mobile device 1000 may include a user interface component 1050, the user interface component 1050 coupled to the processor 1010 and operable to receive input from a user of the mobile device 1000 and further operable to generate output for presentation to the user. User interface component 1050 may include one or more input devices, including but not limited to a keyboard, a numeric keypad, a mouse, a touch-sensitive display, navigation keys, function keys, a microphone, a voice recognition component, any other mechanism capable of receiving input from a user, or any combination thereof. Additionally, user interface component 1050 may include one or more output devices, including but not limited to a display, a speaker, a haptic feedback mechanism, a printer, any other mechanism capable of presenting an output to a user, or any combination thereof.

In one example aspect, processor 1010 includes an assigner module 1070, the assigner module 1070 operable to create and assign a unique IP mobility anchor identifier to each HA/LMA to which the mobile device 1000 is intended to connect. Processor 1010 may also include a negotiator module 1070, negotiator module 1070 operable to negotiate IP flows (e.g., RLP flows) for each IP mobility anchor identifier with the access radio network. Processor 1010 may further include a signaling module 1080 for instructing communication component 1030 to signal a request to an access gateway to associate each negotiated IP flow with an IP tunnel to a particular HA/LMA. Processor 1010 may also include a transmitting module 1090 for instructing communication component 1030 to transmit packets through the negotiated IP flow and associated IP tunnel to the appropriate HA/LMA. Processor 1010 may include other modules for facilitating simultaneous multiple HA/LMA connections in accordance with the methods disclosed herein.

The various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Additionally, at least one processor may comprise one or more modules operable to perform one or more of the steps and/or actions described above.

Additionally, the steps and/or actions of a method or algorithm described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium may be coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. In addition, in some aspects, the processor and the storage medium may reside in an ASIC. Additionally, the ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal. Additionally, in some aspects, the steps and/or actions of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a machine readable medium and/or computer readable medium, which may be incorporated into a computer program product.

In one or more aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Further, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

While the foregoing disclosure discusses illustrative aspects and/or embodiments, it should be noted that various changes and modifications could be made herein without departing from the scope of the described aspects and/or embodiments as defined by the appended claims. Furthermore, although elements of the described aspects and/or embodiments may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated. Additionally, all or a portion of any aspect and/or embodiment may be utilized with all or a portion of any other aspect and/or embodiment, unless stated otherwise.

Claims (36)

1. A method for wireless communication, comprising:

assigning a unique IP mobility anchor identifier to each IP mobility anchor associated with the mobile device;

negotiating an IP flow reservation for each IP mobility anchor identifier;

signaling a request to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor; and

packets are sent through each negotiated IP flow and associated IP tunnel to each IP mobility anchor.

2. The method of claim 1, wherein negotiating an IP flow reservation comprises generating a reservation label for each IP flow, wherein a reservation label comprises at least an IP flow identifier and the IP mobility anchor identifier.

3. The method of claim 2, wherein negotiating an IP flow reservation further comprises creating an attribute identifying a structure of the reservation label and communicating the attribute to a Radio Access Network (RAN).

4. The method of claim 3, wherein negotiating an IP flow reservation further comprises negotiating an IP flow reservation with the RAN using the reservation label, and wherein for each negotiated IP flow RAN creates at least one bearer connection for each IP mobility anchor.

5. The method of claim 4, wherein signaling a request further comprises signaling a request to an access gateway to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor.

6. The method of claim 5, wherein signaling a request comprises sending a name of the particular IP mobility anchor to the access gateway, and wherein access gateway associates the name of the particular IP mobility anchor with the IP flow identified by the IP mobility anchor identifier.

7. The method of claim 6, wherein packets sent through one or more negotiated IP flows are mapped into an IP tunnel by the access gateway based on the association of the IP flow with the particular IP mobility anchor.

8. The method of claim 5, wherein the access gateway comprises one of a PDSN or an HRPD serving gateway.

9. The method of claim 1, wherein the IP mobility anchor comprises one of a mobile IP home agent and a proxy mobile IP local mobility anchor.

10. The method of claim 1, wherein an IP tunnel comprises a bidirectional proxy mobile IP (pmip) tunnel.

11. The method of claim 1, wherein negotiating an IP flow reservation comprises negotiating a quality of service (QoS) treatment for each IP flow.

12. The method of claim 1, further comprising creating an IP mobility anchor context for each IP mobility anchor identifier, the context comprising an IP mobility anchor identifier and an IP mobility anchor context type.

13. The method of claim 12, wherein the IP mobility anchor context types include one or more of IPv4, IPv6, and IPv4/IPv 6.

14. The method of claim 11, wherein the access gateway uses the IP mobility anchor identifier to correlate the associated IP mobility anchor context with the IP flow for that IP mobility anchor.

15. A mobile device, comprising:

a processor and a communication component coupled to the processor,

the processor is configured to

Assigning a unique IP mobility anchor identifier to each IP mobility anchor associated with the mobile device;

negotiating an IP flow reservation for each IP mobility anchor identifier;

signaling, using the communication component, a request to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor; and

sending packets through each negotiated IP flow and associated IP tunnel to each IP mobility anchor using the communication component.

16. The mobile device of claim 15, wherein the processor is further configured to generate a reservation label for each IP flow, wherein a reservation label includes at least an IP flow identifier and the IP mobility anchor identifier.

17. The mobile device of claim 16, wherein the processor is further configured to negotiate an IP flow reservation with a Radio Access Network (RAN) using the reservation label, and wherein for each negotiated IP flow the RAN creates at least one bearer connection to an access gateway.

18. The mobile device of claim 17, wherein the processor is further configured to signal a request to the access gateway to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor.

19. The mobile device of claim 18, wherein packets sent through one or more negotiated IP flows are mapped by the access gateway into an IP tunnel based on the association of the IP flow with the particular IP mobility anchor.

20. The mobile device of claim 19, wherein the processor is further configured to create an IP mobility anchor context for each IP mobility anchor identifier, the context comprising an IP mobility anchor identifier and an IP mobility anchor context type.

21. The mobile device of claim 20, wherein the access gateway uses the IP mobility anchor identifier to correlate the associated IP mobility anchor context with the IP flow for that IP mobility anchor.

22. At least one processor configured to provide wireless communication, the at least one processor comprising: a first module for assigning a unique IP mobility anchor identifier to each IP mobility anchor associated with a mobile device;

a second module for negotiating IP flow reservations for each IP mobility anchor identifier;

means for signaling a request to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor; and

a fourth module for sending packets through each negotiated IP flow and associated IP tunnel to each IP mobility anchor.

23. The at least one processor of claim 22, wherein said second module is further for generating a reservation label for each IP flow, wherein a reservation label includes at least an IP flow identifier and the IP mobility anchor identifier.

24. The at least one processor of claim 23, wherein the second module is further for negotiating an IP flow reservation with a Radio Access Network (RAN) using the reservation label, and wherein for each negotiated IP flow the RAN creates at least one bearer connection to an access gateway.

25. The at least one processor of claim 24, wherein the third module is further for signaling a request to the access gateway to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor.

26. The at least one processor of claim 25, wherein packets sent through one or more negotiated IP flows are mapped by the access gateway into an IP tunnel based on the association of the IP flow with the particular IP mobility anchor.

27. A computer program product, comprising:

a computer-readable medium, comprising:

a first set of codes for causing a computer to assign a unique IP mobility anchor identifier to each IP mobility anchor associated with a mobile device;

a second set of codes for causing the computer to negotiate an IP flow reservation for each IP mobility anchor identifier;

a third set of codes for causing the computer to signal a request to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor; and

a fourth set of codes for causing the computer to send packets through each negotiated IP flow and associated IP tunnel to each IP mobility anchor.

28. The computer program product of claim 27, wherein the second set of codes further comprises codes for causing the computer to generate a reservation label for each IP flow, wherein a reservation label comprises at least an IP flow identifier and the IP mobility anchor identifier.

29. The computer program product of claim 28, wherein the second set of codes further comprises codes for causing a computer to negotiate an IP flow reservation with a Radio Access Network (RAN) using the reservation label, and wherein for each negotiated IP flow, RAN creates at least one bearer connection to an access gateway.

30. The computer program product of claim 29, wherein the third set of codes further comprises codes for causing a computer to signal a request to the access gateway to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor.

31. The computer program product of claim 30, wherein packets sent through each negotiated IP flow are mapped by the access gateway into one or more IP tunnels based on the association of the IP flow with the particular IP mobility anchor.

32. An apparatus, comprising:

means for assigning a unique IP mobility anchor identifier to each IP mobility anchor associated with the mobile device;

means for negotiating an IP flow reservation for each IP mobility anchor identifier;

means for signaling a request to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor; and

means for sending packets through each negotiated IP flow and associated IP tunnel to each IP mobility anchor.

33. The apparatus of claim 32, wherein the means for negotiating an IP flow reservation comprises means for generating a reservation label for each IP flow, wherein a reservation label comprises at least an IP flow identifier and the IP mobility anchor identifier.

34. The apparatus of claim 33, wherein the means for negotiating an IP flow reservation further comprises means for negotiating an IP flow reservation with a Radio Access Network (RAN) using the reservation label, and wherein for each negotiated IP flow RAN creates at least one bearer connection to an access gateway.

35. The apparatus of claim 34, wherein the means for signaling a request further comprises means for signaling a request to the access gateway to associate each negotiated IP flow with an IP tunnel to a particular IP mobility anchor.

36. The apparatus of claim 35, wherein the packets sent through each negotiated IP flow are mapped by the access gateway into one or more IP tunnels based on the association of the IP flow with the particular IP mobility anchor.