The present invention relates to wireless communications. More specifically, the present invention relates to network discovery and selection in geographical areas wherein more than one cellular and/or IEEE 802 wireless communication system is available.
Wired and wireless communication systems are well known in the art. In recent years, widespread deployment of different types of networks has resulted in geographic areas wherein access to more than one type of network is available. Communication devices have been developed which integrate two or more different network access technologies into a single communication device. For example, there exist communication devices which integrate the ability to communicate via more than one type of wireless standard, such as IEEE 802.X compliant wireless local area network (WLAN) standards, and cellular technologies such as Code Division Multiple Access (CDMA), Global System for Mobile communications (GSM), and General Packet Radio System (GPRS) standards. Communication via each standard is referred to as a communication mode, and devices which can communicate via more than one communication standard are called multi mode devices.
However, existing systems that support integration of two or more network access technologies into one device do not provide inter-working between the different access technologies. In addition, a communication device that supports multi mode functions does not, without more, provide the ability to determine which access technologies are accessible from the device's position, or the ability to assess the desirability of the different access technologies available at the device's position, and choose the best technology available.
In a known approach, a multimode handset can turn multiple radio modems on and scan available networks, frequencies and cells for each radio access technology. However, having two or more radios and modems perform the scanning function consumes a significant amount of power and system resources. Also, this approach does not discover the services available on each available network, and to choose the preferred network.
Thus, there is a need for evaluating and selecting a preferred network from among a plurality of available networks, without the limitations of the prior art.
The present invention includes a method and apparatus for facilitating mobility handling across different wireless technologies by efficiently discovering networks available to a wireless transmit/receive unit (WTRU), determining the services available on those networks, and selecting the most appropriate available radio access technology, depending on parameters such as service requirements, available services, location and policy settings.
A more detailed understanding of the invention may be had from the following description, given by way of example and to be understood in conjunction with the accompanying drawings, wherein:
a and 7b are a flow diagram of a method for signalling used when system authentication fails; and
a and 8b are a signalling diagram showing 802.x and 3GPP inter-working system access failure.
The present invention will be described with reference to the drawing figures wherein like numerals represent like elements throughout.
When referred to hereinafter, the term wireless transmit/receive unit (WTRU) includes but is not limited to a user equipment (UE), mobile station (MS), fixed or mobile subscriber unit, pager, or any other type of device capable of operating in a wireless environment. When referred to hereinafter, the term base station (BS) includes but is not limited to a base station, Node-B, site controller, access point (AP) or any other type of interfacing device in a wireless environment.
The present invention includes an apparatus and methods for assisting in mobility handling across different wireless technologies by efficiently performing network discovery, determining services available in discovered networks, and assisting a WTRU in selecting a preferred radio access technology from among a plurality of available radio access technologies, depending on parameters such as service requirements, available services, location and network policy settings.
The present invention enables a multi-mode WTRU, such as a dual-mode WTRU that supports both a cellular network and a Wireless Local Area Network (WLAN), to turn off WLAN scanning while the user is connected to a cellular network, thus conserving WTRU battery power. The cellular network indicates to the dual-mode WTRU when a WLAN is in its vicinity, and that it should start scanning for the WLAN. In a preferred embodiment of the present invention, the cellular network is aware of the geographic locations of the WLANs located within its service area. The cellular network also tracks the position of the WTRU. Various methods can be used to determine the location of the WTRU, such as triangulation, Universal Geographical Area Descriptions or Global Positioning System (GPS) assisted methods. Based on the cellular network's awareness of the locations of the WLANs and the position of the WTRU, the cellular network can determine if there is a WLAN in the vicinity of the WTRU. If so, the cellular network signals to the WTRU that there is a WLAN in its vicinity. The WTRU then begins WLAN discovery procedures. In a preferred embodiment, the cellular network is a 3GPP network and the WLAN is an IEEE 802.X wireless network. This approach extends battery power in the WTRU because it does not scan for a WLAN unless directed to do so by the cellular network, without compromising the effectiveness of WLAN system discovery.
Information used to determine the position of the WTRU 150 can include information derived from triangulation, Universal Geographical Area Descriptions, GPS assisted methods and the like. In addition, the 3GPP system can allocate a specific Temporary Mobile Station Identifier (TMSI) space for routing areas, location areas or service areas supporting WLAN services. Alternatively, the WTRU can use the radio frequency (RF) signature or fingerprinting to determine the availability of a WLAN system. In that case, the WTRU establishes a relationship between the 3GPP radio frequency channel signature of a channel placed at a particular location within the cellular network, and an underlying wireless land network such as a WLAN, which is overlaid by the 3GPP RF channel coverage. This relationship is used to flag the existence of the WLAN network to the WTRU when the WTRU detects the presence of the RF signature. This information is kept in a database within the WTRU, and can be dynamically updated should the relationship be modified.
Referring now to
In Step 3, relevant WLAN system 46 information extracted from the information sent by the 3GPP system 44 is forwarded to the MIHHO component 230 in a message herein designated a LINK SYSTEM INFORMATION message. Alternatively, as shown in phantom in Step 3, information gained by the WTRU 150 during periodic scanning is forwarded to the MIHHO component 230 in a message herein designated a LINK DETECTED message. If a WLAN is accessible, the WTRU 150 detects the WLAN 46 beacon frames. The beacon frames can be used to identify handover-specific information, such as whether full or partial Media Independent Handover Services are supported (e.g., as indicated through a specific 802.21 flag broadcast on the beacon frame or the like). Beacon frames can also be used to indicate other services available on the WLAN 46. The handover-specific information can be updated either manually or dynamically. As an alternative, the WTRU 150 can attempt to acquire WLAN 46 system information either through a Probe Request/Response message pair or by accessing a data base within the candidate system.
In Step 4, the MIHHO component 230 in the WTRU 150 determines that one or several WLAN networks might be suitable for reselection, based on available information (e.g., explicit indication, RF signature, geographical location, manual or automatic scanning, specific TMSI assignment, or the like). In Step 5, the MIHHO component 230 computes a list of potential candidates for handover selection. In Step 6, the MIHHO component 230 evaluates candidates based on various criteria such as system operator and known WLAN system 46 capabilities such as quality of service (QoS), data transmission speed and the like. The MIHHO component 230 determines the preferred candidate for handover, and triggers WLAN system access by sending a message, herein designated a MIH_SWITCH message, to the media access control (MAC) layer to request handover related actions.
During WLAN authentication, WTRU 150 provides the WLAN with a Network Access ID (NAI). Based on the NAI, an Access Gateway (AG) can trigger Extensible Authentication Protocol-Authentication and Key Agreement (EAP-AKA) authentication, and relay authentication messages to a 3GPP Authentication, Authorization, and Accounting (AAA) server. The AG can also route AAA messages to other servers to provide services. The AG can use the NAI to determine whether WTRU 150 requires a particular level of service, e.g., basic or premium service. The NAI can also be used to route messages to specific ports that provide specialized services, such as network capabilities available for this particular user or user class.
The AG can also determine the level of service that the WTRU requires based on the NAI that triggered the authentication procedure, or based on the authentication procedure itself. Even if authentication procedures fail for a premium level of service, the AG can determine that the WTRU can receive basic services. If the AG is not able to route the authentication request, it can respond to the WTRU by indicating available AAA servers where an authentication request can be routed. If the WTRU determines that none of them is suitable, it can decide to return to the scanning phase.
The AG can grant access to basic services (e.g., Internet service) or access to a portal that can provide WTRU 150 with further information. The AG can also choose to provide a default Packet Data Gateway (PDG) address. If this is the case the WTRU can decide to connect to the default PDG. This procedure can be automatic, or can be based on configuration parameters within the AG and/or the WTRU. Alternatively, access can be denied.
In accordance with the invention, information on system capabilities is passed by the MAC layer to the MIH function in WTRU 150 using a LINK SYSTEM INFORMATION message. The MIH function may determine that one or more values regarding an available WLAN within the system information parameters do not satisfy a necessary condition for system access. E.g., the system operator is barred, a needed service is not available, or the Quality of Service (QoS) is not adequate. If the MIH function determines that the parameters provided by the information service do not satisfy internal configured requirements, then the MIH function orders the MAC layer to return to the scanning phase using a MIH_SCAN message.
In Step 2, the information is processed and the WTRU 150 determines that a WLAN system 46 is a suitable candidate for system access. As a result MIHHO component 230 orders WLAN authentication and association with a message to the MAC layer, herein designated a MIH_SWITCH message.
In Step 3, WLAN specific authentication and associating procedures are executed on the chosen WLAN system. The MIHHO component 230 informs the 3GPP side that handover is imminent.
In Step 4, the WLAN access gateway (AG) MIHHO component 500 triggers WLAN 3GPP authentication and authorization using the EAP-AKA protocol. The WTRU's 3GPP component 240 uses its assigned Network Access ID (NAI) to indicate to the WLAN AG 46 its associated 3GPP AAA server. Successful routing results in the establishment of an IPsec tunnel that carries EAP-AKA messages.
In Step 5, upon successful authentication and authorization the WTRU 150 obtains a local IP address from the local DHCP server.
a-7b are a flow diagram showing signalling used when system authentication fails. Referring to
If authentication fails, then system access is denied, step 730. This can occur, e.g., if WEP authentication fails, or if the NAI provided does not resolve to any 3GPP server. The WTRU can then return to the scanning phase, step 740. Alternatively, if the NAI does not resolve, the AG can direct the WTRU to a local server for further processing, e.g., to provide basic services. The AG MAC can provide the MIH function with information regarding the key that was used for the WEP procedure. The MIH function can then determine, e.g., based on the default key used during WEP authentication, whether further authentication procedures are warranted, step 750. Note that in this context WEP is not considered a secured authentication procedure. Rather, here it is being used to identify users that require further authentication.
If further authentication procedures are warranted, the MIH function triggers a cellular authentication attempt, e.g., using EAPOL authentication procedures, step 760. The AAA AG component can act as an authenticator between the WTRU supplicant and the AAA authentication server, e.g., using an IPsec tunnel. The AG uses the NAI provided during the initial message exchange to determine the AAA server that can execute the authentication procedure. If the AG is not able to route the authentication request, the EAPOL cellular authentication attempt fails, step 770. The AG can respond by indicating the available AAA servers where the request can be routed. If the WTRU determines that none of them is suitable, it can decide to return the scanning phase, step 780. If the AG can find a suitable authentication server using the NAI provided by the WTRU, the WTRU can attempt authentication to that server, step 715. In that case, the AG can relay authentication messages between the WTRU and the authentication server, step 725.
Referring to
However, the cellular AAA server can successfully authenticate the WTRU, step 745. If so, the WTRU proceeds to obtain a local IP address, e.g. via dynamic host control protocol (DHCP) or address resolution protocol (ARP), step 755. Using a WLAN access point name (W-APN) network ID and operator ID, the WTRU constructs a Fully Qualified Domain Name (FQDN). The WTRU then requests IP address resolution to gain access to a packet data gateway (PDG), step 765. The WTRU attempts to get a PDG address based on the FQDN, e.g., a W-APN or public land mobile network (PLMN) ID. If the domain name server (DNS) does not resolve the FQDN to any PDG IP address, the WTRU cannot access a PDG within the existing WLAN network, step 775. The WTRU can then choose to return the scanning phase, step 776, or to settle for only local WLAN services, step 777.
However, if the DNS returns a valid PDG IP address, the WTRU establishes a tunnel toward the PDG, e.g., a L2TP tunnel, step 785. The WTRU then listens for Agent Advertisement messages from the PDG, step 713. If no Agent Advertisement messages are received, the WTRU sends an Agent Solicitation, step 723. However, if Agent Advertisement messages are received from the PDG, then the WTRU is able to obtain its care of address (COA) directly from these messages without a need to specifically request it via an Agent Solicitation message, step 714.
If no response to the Agent Solicitation is received, e.g., if MIP is not supported, the WTRU can use its local IP address for transparent access to the Internet for basic ISP services, or can request activation of a packet data protocol (PDP) context, step 733. WTRU-PDG tunnel IP traffic can be routed directly from the WTRU to the Internet via the PDG tunnel. This scenario does not provide seamless mobility beyond the PDG domain. However, if a response to an Agent Solicitation is received then the WTRU is able to update its COA in its Home Agent, step 724. Any message intended for this WTRU will be re-directed by the Home Agent to the new COA.
In Step 2, any MIH information found within a beacon frame (e.g., system operator identity, W-APN, neighboring maps and system capabilities) is passed to the WTRU's MIHHO component 230 through a LINK SYSTEM INFORMATION message. The MIHHO component 230 determines that one or more values provided within the system information parameters does not satisfy the necessary condition for system access. For example, the system operator may be barred, the QoS is not adequate or there is a better candidate identified within a potential neighboring set provided in the message. This scenario represents the first failure case. This is depicted in
In Step 3, if the MIHHO component 230 determines that the parameters provided by the information service do not satisfy internal configured requirements, then the MIHHO component 230 orders the MAC layer to return to the scanning phase with an MIH_SCAN message.
In Step 4, if instead the MIHHO component 230 determines that internal configured requirements are satisfied, the MIHHO component 230 triggers WEP authentication with an MIH_SWITCH message toward its MAC layer. Note that in order to determine whether the user requires further EAP-AKA authentication that will allow access to special services (e.g., 3GPP IMS), the WTRU 150 might use a specific WEP default key. The AG might use a specific default key to determine whether it shall proceed further with EAPOL authentication or basic Internet access can be granted.
In Step 5, the WTRU 150 is authenticated according to current 802.11 WEP procedures.
In Step 6, if WEP authentication fails, system access is denied. The WTRU 150 can then return to the scanning phase. This scenario represents the second failure case, depicted in
In Step 7, instead of the WTRU 150 returning to the scanning phase if WEP authentication fails, the AG MAC 800 can provide the AG MIHHO component 500 with information regarding the key that was used for the WEP procedure. This allows the MIH function to determine, e.g., based on the default key used during WEP authentication, whether further authentication procedures are warranted, e.g., based on the NAI provided. Note that WEP is not considered a secured authentication procedure. It this context it used primarily to identify specific users that require further authentication. If the NAI provided does not resolve to any 3GPP server, the AG 46 might reject access or direct the WTRU 150 to a local server for further processing, e.g., to provide basic services. This is depicted in
In Step 8, AG MIHHO component 500 uses a message, herein designated a MIH_SYSCAP message, to trigger EAPOL authentication procedures.
In Step 9, the AG 46 executes EAPOL procedures. The AG AAA component 800 will act as an authenticator between the supplicant (WTRU 150) and the authentication server 810 (AAA). The AG 46 uses the NAI provided during the initial message exchange in order to determine the AAA server 810 that shall execute the authentication procedure. If the AG 46 is not able to route the authentication request, it responds indicating the available AAA servers where the request can be routed. If the WTRU 150 determines that none of them is suitable, it might decide to return the scanning phase. This is depicted in
Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone (without the other features and elements of the preferred embodiments) or in various combinations with or without other features and elements of the present invention.
This application claims the benefit of U.S. Provisional Application No. 60/645,367 filed Jan. 18, 2005, which is incorporated by reference as if fully set forth.
| Number | Date | Country | |
|---|---|---|---|
| 60645367 | Jan 2005 | US |