WO2015003125A2

WO2015003125A2 - Methods and apparatus for offloading wireless traffic to a non-3gpp access

Info

Publication number: WO2015003125A2
Application number: PCT/US2014/045394
Authority: WO
Inventors: Li-Hsiang Sun; Sudhir Kumar Baghel; Guanzhou Wang; Ulises Olvera-Hernandez; Saad Ahmad; Mahmoud Watfa; Dimitrios Karampatsis
Original assignee: Interdigital Patent Holdings, Inc.
Priority date: 2013-07-03
Filing date: 2014-07-03
Publication date: 2015-01-08
Also published as: WO2015003125A3

Abstract

Methods and apparatus for offloading wireless traffic to a non-3GPP access are described. A method includes identifying available wireless local area networks (WLANs) through WLAN network discovery, determining at least one user or application defined policy, signaling the at least one user or application defined policy to a base station, and selecting one of the plurality of available WLANs to offload the traffic corresponding to the particular application to. The selection is based at least on the at least one user or application defined policy, and the base station has obtained at least one access network discovery and selection function (ANDSF) policy or radio access network (RAN) steering rule that conflicts with the at least one user or application defined policy.

Description

METHODS AND APPARATUS FOR OFFLOADING WIRELESS

TRAFFIC TO A NON-3GPP ACCESS

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent

Application No. 61/842,686, which was filed on July 3, 2013, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] Many wireless transmit/receive units (WTRUs), such as smart phones, have the capability to connect with both a Third Generation Partnership Project (3GPP) access (e.g., Global System for Mobile Communication (GSM)/Enhanced Data Rates for Global Evolution (EDGE) Radio Access Network (GERAN), Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), and Evolved UTRAN (E-UTRAN)) and a non-3GPP access (e.g., wireless local area network (WLAN)). Sometimes, a WTRU may need to access both a 3GPP network and a non-3GPP network simultaneously. Simultaneous multi-access connectivity may be provided in one of a number of different ways, such as multiple-access packet data network (PDN) connectivity (MAPCON), internet protocol (IP) mobility (IFOM) and non-seamless wireless offload (NSWO). A WTRU that supports MAPCON may engage in simultaneous multi-access connectivity by maintaining one access point name (APN) on a 3GPP network and another APN on a non-3GPP network. A WTRU that supports IFOM may engage in simultaneous multi-access connectivity by choosing on which access each of its flows should be supported and moving seamlessly between the chosen accesses. A WTRU that supports NSWO may engage in simultaneous multiaccess connectivity by choosing on which access each of its flows should be supported on a per IP flow basis, but, for NSWO, flows over the non-3GPP access may not go through the enhanced packet core (EPC).

[0003] An access network discovery and selection function (ANDSF) has been defined to enable WTRUs to know where, when and how to choose a non- 3GPP access network for wireless communications. An ANDSF server may control distribution of ANDSF policies for use in selecting a non-3GPP access for a WTRU. For WTRUs that support MAPCON, IFOM or NSWO, the ANDSF server may distribute inter-system routing policies (ISRP), which may include prioritized rules that control which non-3GPP network a WTRU should use on a per-APN basis. For WTRUs that do not support MAPCON, IFOM or NSWO, the ANDSF server may distribute inter-system mobility policies (ISMP), which may include prioritized rules that control which non- 3GPP network a WTRU should use. An ISRP may include more than one flow distribution rule, which is one of a number of rules within an ISRP (e.g., <X>/ISRP/<X>/ForFlowBased/<X>, <X>/ISRP/<X>/ForServiceBased/<X>, <X>/ISRP/<X>/ForNonSeamlessOffload/<X>).

SUMMARY

[0004] Methods and apparatus for offloading wireless traffic to a non-

3GPP access are described. A method includes identifying available wireless local area networks (WLANs) through WLAN network discovery, determining at least one user or application defined policy, signaling the at least one user or application defined policy to a base station, and selecting one of the plurality of available WLANs to offload the traffic corresponding to the particular application to. The selection is based at least on the at least one user or application defined policy where the base station has obtained at least one ANDSF policy or radio access network (RAN) steering rule that conflicts with the at least one user or application defined policy.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0006] FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented; [0007] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;

[0008] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;

[0009] FIG. 2 is a signal diagram of an example method of a WTRU offloading traffic corresponding to a particular application to a WLAN;

[0010] FIG. 3 is a flow diagram of an example method of WTRU network selection when the WTRU is operating in a shared host radio access network (RAN);

[0011] FIG. 4A is a diagram of a wireless network illustrating an example scenario where an IP flow has been offloaded by the 3GPP network in the VPLMN to a WLAN;

[0012] FIG. 4B is a diagram of an example embodiment for offloading traffic to a newly selected WLAN provided by the HPLMN in the scenario presented in FIG. 4A;

[0013] FIG. 5A is a diagram of an example embodiment of offloading of local breakout (LBO) IFOM/MAPCON traffic to a WLAN controlled by a VPLMN;

[0014] FIG. 5B is an example embodiment where offloaded LBO

IFOM/MAPCON traffic is moved back to the 3GPP RAT;

[0015] FIG. 5C is a diagram of an example embodiment where offloaded

LBO IFOM/MAPCON traffic is handed over to an evolved packet data gateway (ePDG) provided by the VPLMN;

[0016] FIGs. 6A, 6B and 6C are diagrams illustrating example locations for insertion of an inter-system routing policies (ISRP) node into ISRP;;

[0017] FIG. 7A is a diagram of an example situation where the highest priority WLAN in the VANDSF offers connectivity to both the HPLMN and the VPLMN; and

[0018] FIG. 7B is a diagram of an example situation where the highest priority WLAN in the VANDSF offers connectivity to both the HPLMN and the VPLMN where the WTRU authenticates with the root network access identifier (NAI).

DETAILED DESCRIPTION

[0019] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0020] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0021] The communications systems 100 may also include a base station

114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0022] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple -input multiple -output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0023] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0024] More specifically, as noted above, the communications system

100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High- Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0025] In another embodiment, the base station 114a and the WTRUs

102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE-A).

[0026] In other embodiments, the base station 114a and the WTRUs

102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0027] The base station 114b in FIG. 1A may be a wireless router, Home

Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106.

[0028] The RAN 104 may be in communication with the core network

106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high- level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0029] The core network 106 may also serve as a gateway for the

WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0030] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular -based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0031] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub- combination of the foregoing elements while remaining consistent with an embodiment.

[0032] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0033] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0034] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0035] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0036] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light- emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The nonremovable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0037] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel- cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0038] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location- determination method while remaining consistent with an embodiment.

[0039] The processor 118 may further be coupled to other peripherals

138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0040] FIG. 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106.

[0041] The RAN 104 may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0042] Each of the eNode-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 1C, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0043] The core network 106 shown in FIG. 1C may include a mobility management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0044] The MME 142 may be connected to each of the eNode-Bs 140a,

140b, 140c in the RAN 104 via an Si interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0045] The serving gateway 144 may be connected to each of the eNode

Bs 140a, 140b, 140c in the RAN 104 via the Si interface. The serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0046] The serving gateway 144 may also be connected to the PDN gateway 146, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0047] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0048] When a WTRU is roaming, it may access both the ANDSF server of its home operator (HANDSF) and the ANDSF server of the visited network (VANDSF). If there is a conflict between HANDSF and VANDSF policies, the VANDSF policies normally take precedence. For example, 3GPP TS 24.302 specifies that for a WTRU that is roaming, the inter- system mobility policy from the VANDSF of a registered public land mobile network (RPLMN), if available, takes precedence over the inter- system mobility policy from the HANDSF. For another example, 3GPP TS 24.312 specifies that for a WTRU that is roaming, the ISRP received from the VANDSF take precedence over the ISRP received from the HANDSF. And for another example, 3GPP TS 24.312 describes a roaming leaf, which indicates whether an ISMP or ISRP is valid based on the roaming status of the WTRU. In this example, the WTRU may not use the node when the VANDSF provides the ISRP.

[0049] While VANDSF policies normally take precedence over HANDSF policies for a roaming WTRU when the various policies conflict, it may sometimes be desirable to use HANDSF policies when a WTRU is roaming and both HANDSF and VANDSF policies are available. Usage of HANDSF policies when VANDSF policies are also available has been considered but without consideration for real time events such as on-going application traffic. [0050] One mechanism that has been considered for facilitating usage of

HANDSF policies when VANDSF policies are also available is a WLAN selection policy (WLANSP) node. A WLANSP node may include one or more lists of preferred WLAN access networks. Each of the one or more lists may have a different priority and/or validity area, time of day, etc. Each list may also include a Hotspot 2.0 (HS2.0) managed object (MO) as selection criteria.

[0051] Another mechanism that has been considered for facilitating usage of HANDSF policies when VANDSF policies are also available is a node, such as a Prefer HPLMN WLANs node or a Prefer VPLMN WLANs node, which may be configured by the HANDSF. If, for example, a prefer HPLMN WLANs node is configured, and a WLAN provided by the HPLMN is available, a roaming ISRP-capable WTRU may switch its active ISRP from the ISRP provided by the VANDSF to the ISRP provided by the HANDSF and select the WLAN provided by the HPLMN.

[0052] Another mechanism that has been considered for facilitating usage of HANDSF policies when VANDSF policies are also available is enhancements to the ANDSF MO to include a preferred service providers list (PSPL), which may include a list of 3GPP service providers preferred by a WTRU's home operator. A WTRU may use this list to construct a network access identifier (NAI) when it attempts extensible authentication protocol- authentication and key agreement (EAP-AKA) authentication over a selected WLAN access network and to select a WLAN access network when multiple WLANs are available that best match the preferences in the WTRU's active ISMP or ISRP.

[0053] A PSPL may include a list of 3GPP service providers that may be identified as realms (e.g., with the domain name derived from a PLMN ID). A WTRU may provide preferences for selection of 3GPP service providers from the list, such as a WLAN-based provider, and may select a preferred 3GPP service provider to authenticate with from the list of 3GPP service providers that the WTRU may discover from the WLAN AP (e.g., by means of an HS2.0 access network query protocol (ANQP) query if the AP is HS2.0 capable). The WTRU may also use the PSPL to identify whether a 3GPP service provider is an equivalent HPLMN or a 3GPP roaming partner.

[0054] The PSPL may also include a policy indicating whether or not a

WTRU also prefers the 3GPP RPLMN for WLAN access. If the policy is set to prefer 3GPP RPLMN and the active ANDSF rule is provided by the 3GPP RPLMN, the WTRU may select the 3GPP RPLMN (or a PLMN equivalent to the 3GPP RPLMN) as the PLMN for WLAN access. If the active ANDSF rule is provided by a PLMN other than the current 3GPP RPLMN, or the policy is not set, the WTRU may use the PSPL as described above.

[0055] The PSPL may always be provided by the HPLMN through the

HANDSF or may be statically provisioned in the WTRU, and the WTRU may ignore any PSPL information that may be provided by the VANDSF. If the WTRU has an MO from both the VANDSF and the HANDSF, the WTRU may choose to use only the PSPL of the HANDSF MO.

[0056] As mentioned above, the mechanisms that have been considered for using HPLMN policies when conflicting HPLMN and VPLMN policies are available for a roaming WTRU, do not account for current network usage and applications. Accordingly, implementation of any of these mechanisms (or any other conceivable mechanisms for implementing an HPLMN over VPLMN policy preference) will require resolution of conflicts that may occur between HPLMN policies and current network conditions and/or applications. Embodiments described herein provide such conflict resolutions, which may include, for example, resolving inconsistencies between ANDSF policies and RAN-based offloading, development of WLAN network selection policies in a RAN sharing scenario, selection of a preferred access technology for device-to- device (D2D) communication, development of HS2.0 parameters as offloading or traffic steering criteria after WLAN selection, handling of existing NSWO traffic in the VPLMN when an HPLMN ISRP becomes active or when a new WLAN provided by the HPLMN is selected, providing a WTRU's capability to understand new ANDSF rules to the ANDSF server, developing rules for target access network validity based on selection of a WLAN service provider, provision of an RPLMN preference in the PSPL, handling undesirable base station system (BSS) load or other HS2.0 parameters in the WLAN provided by the HPLMN while prefer WLAN provided by the HPLMN is configured, applicability of individual 3GPP RATs as preferred access in the ISMP, applicability of ANQP connection capability, and WLAN indication to the home subscriber server (HSS) for its connectivity to multiple PLMNs.

[0057] With respect to resolving inconsistencies between ANDSF policies and RAN-based offloading, different possibilities have been considered, some of which may require the WTRU to follow eNB commands or eNB provided parameters to select or steer traffic to a WLAN. However, such mechanisms may be inconsistent with ANDSF selection or routing policies or may cause policy inconsistency between eNBs. For example, a WLAN AP that satisfies RAN-provided criteria or that is selected by the eNB may not be the same WLAN that the WTRU would select, for example, using ANDSF-based WLAN selection. Further, RAN-provided flow distribution rules may conflict with ANDSF-provided flow distribution rules. Such mechanisms may also require definition of policies regarding, for example, whether a roaming WTRU should follow RAN-provided rules if it can find a WLAN in its own network based on ANDSF, whether selection or steering rules should be changed immediately to a broadcasted rule of a target cell when a WTRU moves from one cell to another, and how a WTRU or network decides to move traffic back to a 3GPP RAT after a WTRU follows a RAN-based rule and moves traffic to a WLAN if the WTRU has disconnected or detached from a 3GPP RAT.

[0058] In an embodiment, when a WTRU is presented with conflicting

RAN-provided and ANDSF-provided flow distribution rules, a WTRU may be configured to completely ignore any rule provided by the ANDSF, combine ANDSF and RAN-based rules with a certain order, or completely ignore any rule provided by the RAN. For example, a WTRU may simply treat any already discovered or associated WLANs that are not selected by the RAN or that do not satisfy RAN- specified criteria as not discovered or as disassociated during WLAN network discovery. Alternatively, either the ANDSF or the eNB may specify the relative priority between a RAN-provided list of candidate WLANs and an ANDSF-provided list of candidate WLANs. As another alternative, the HANDSF may specify that RAN-based WLAN selection and flow distribution rules are not applicable when the WTRU is roaming. Here, for example, the WTRU may follow the HANDSF rule with a roaming flag and behave as though it does not support RAN-based offloading when in certain VPLMNs.

[0059] By way of one specific example, within a WLAN selection policy

(WLANSP) list of an ANDSF, there may be two place holders: one may have the highest priority and the other may have the lowest priority. The HANDSF may specify any one or more RAN-based selection rules or criteria from the HPLMN to substitute for the highest priority placeholder and one or more RAN-based selection rules or criteria from the VPLMN to substitute for the lowest priority place holder. In this scenario, a hierarchy is created such that HPLMN RAN-policy > WLANSP policy > VPLMN RAN policy. A placeholder for RAN-based rules associated with a PLMN ID may be placed anywhere within a WLANSP list.

[0060] The same approach may be applied to flow distribution rules in an ISRP. The flow distribution rule may also indicate that flow distribution rules of lower precedence may be ignored.

[0061] For RAN-based rules, several target WLANs may be grouped in the same rule but with different selection criteria. The WTRU may treat all of the WLANs with the same priority and select the first one whose criteria are met. In addition to selection criteria, entering and exiting conditions may be specified with respect to RAN-based rules. Here, the WTRU may not evaluate lower priority rules when entering criteria is met but exiting criteria has not been met. For example, an eNB may specify a WTRU that has not associated with a WLAN (the entering criteria) to perform a measurement of a BSS X chosen by the eNB. The WTRU may not select another WLAN unless the signal strength from X is less than a threshold (the exiting criteria), regardless of whether the WTRU has selected BSS X. This may prevent the WTRU from selecting to a lower priority WLAN (which may be from ANDSF and may not have any signal strength criteria) and returning to the higher priority WLAN shortly after the selection criteria is met.

[0062] In an embodiment, the selection policy may be configured such that a RAN-based rule from a target cell has a lower priority than a rule from a source cell. The rule from the source 3GPP cell may still be valid after the WTRU changes cells. Based on the exiting condition of the rule (e.g., time after selection or signal strength), the WTRU may not immediately switch to the WLAN selected by the target cell. This may allow the rule from the old cell to be aged or phased out gradually. When the exiting condition is met, the WTRU may remove the RAN-based rule from the placeholder.

[0063] With aging of a RAN-based rule (e.g., by use of timer as an exit condition), the WTRU may revisit the ANDSF rules that have lower priorities than the aged RAN-based rule. This may be used to prevent a WTRU from being stuck in the WLAN previously chosen by the RAN when the WTRU is not aware that the RAN condition has changed.

[0064] For the embodiments described above with respect to resolving inconsistencies between ANDSF and RAN-based policies, the RAN steering command may carry some indication of, for example, a mechanism to be applied. Fox example, the indication may be that RAN overrides any conflicting ANDSF rules, ANDSF overrides any conflicting RAN rules, or a combination of RAN/ ANDSF rules should be applied.

[0065] Besides the possible conflicts between ANDSF rules and RAN steering commands, there may also be conflicts between RAN steering commands and user or application defined policies. A user or application defined policy may indicate, for example, always use WiFi (or cellular data) for this application, try WiFi for this application first, or if WiFi is not available then use cellular data. The user or application rules normally do not specify which AP to choose. Nevertheless, conflicts may occur under certain conditions. For example, a conflict may occur on a condition that the ANDSF ISMP specifies that WLAN (or 3GPP) is prioritized access while some applications may only use the other access per their user or application rules. Similarly, a conflict may occur when the ANDSF ISRP specifies that some IP flows should be on a WLAN (or 3GPP) access while the corresponding applications may only use the other access per their user or application rules. As another example, a conflict may occur when the RAN steering command that specifies certain radio bearers (RBs) that may carry traffic from multiple applications should be on a WLAN while some or all of the corresponding applications may only use a 3GPP access per their user or application rules (or vice versa).

[0066] It may be desirable to respect user or application defined rules to the extent possible. Accordingly, in one embodiment, a WTRU may be configured to ignore an ANDSF or RAN command when it conflicts with a user or application defined rule. In another embodiment, a WTRU may employ a feedback mechanism to inform the eNB that the steering command has not been executed or has been only partially executed due to the conflicting rules. In yet another embodiment, the eNB may be notified of user or application defined rules so that the eNB does not issue a conflicting steering command or so that the eNB may issue a steering command based on the received user or application defined rules.

[0067] FIG. 2 is a signal diagram 200 of an example method of a WTRU offloading to a WLAN traffic corresponding to a particular application. In the example illustrated in FIG. 2, a WTRU 102 performs network discovery (202). For example, the WTRU 102 may search for one or more WLANs within range of the WTRU 102. The WTRU 102 may also determine preferences or policies (204). For example, the WTRU 102 may need to run a particular application and may determine user or application defined policies that correspond to the particular application that may, for example, indicate preferences with respect to which WLAN to select for offloading traffic corresponding to the application. The WTRU 102 may then signal at least one user or application defined policy to a base station (e.g., eNB) 140 (206). In an embodiment, the at least one user or application defined policy may indicate rules that are specific to each different application that a WTRU may run. Such rules may include, for example: for application 1, always use WiFi; for application 2, always use cellular; or for application 3, may use either cellular or WiFi. Such rules may also include more specific application- specific information, such as specifying which WLAN to use..

[0068] The eNB 140 may carry out one of a number of different procedures with the received user or application defined policy. In an embodiment, the eNB 140 may simply refrain from sending conflicting RAN steering commands to the WTRU, which may allow the WTRU 102 to select a WLAN to offload the traffic corresponding to the application to based on the user defined preference or policy. The eNB 140 may also determine an RB that carries the application (208), decide to offload traffic for the WTRU 102 and select the RB according to the user or application defined policy signaled by the WTRU 102 (210). In this case, the eNB 140 may send a steering command to the WTRU 102 (212) directing the WTRU 102 to offload the traffic using the selected RB.

[0069] With respect to development of WLAN network selection policies in a RAN sharing scenario, in a RAN sharing scenario, the owner of a RAN node (or RAN operator) may want WTRUs of hosted operators (operator using the RAN owner's resources) to use a particular set of rules or policies for network (e.g., WLAN) selection. Accordingly, the hosted operator WTRU may need to select a WLAN interface based on the policies of the host network when under the coverage of the host RAN operator eNB.

[0070] In the scenario described above, a WTRU may need to apply a different set of policies from the HANDSF policies. This set of policies may be applied, for example, on a PLMN basis (e.g., there may be different policies for each different RAN operator). A WTRU may know that it is under the coverage of a shared RAN owned by a different operator based on the PLMN ID contained in the cell ID/eNB ID parameter that the WTRU obtains (e.g., from reading SIB1). In an embodiment, a RAN operator identity (e.g., the identity of the PLMN that the WTRU authenticates with), such as PLMN ID, operator identifier (OI), or OI domain name, may be used as criteria to determine whether a flow distribution rule applies. Alternatively, a RAN operator may have a rule that the WTRU should obtain network selection polices from the ANDSF of the RAN operator. Here, whenever a WTRU is under the coverage of an eNB of the shared RAN, the WTRU may be forced to get its network selection policies from the RAN operator ANDSF and perform network selection based on these policies.

[0071] FIG. 3 is a flow diagram 300 of an example method of WTRU network selection when the WTRU is operating in a shared host RAN. In the example illustrated in FIG. 3, a WTRU authenticates with a PLMN (e.g., a shared host RAN) (302). The WTRU may obtain network selection policies (e.g., flow distribution or WLAN selection rules) (304). The WTRU may determine whether an obtained policy has a RAN network identifier (e.g., a PLMN ID, OI or OI domain name) that matches with a RAN network identifier that the WTRU obtained (e.g., read from SIB1) (306). If so, the WTRU may select that policy and apply it when selecting a network, for example, for traffic offload (308). If not, the WTRU may be free to choose another policy, for example, based on a default rule (310). In an embodiment, the default rule may be chosen based on any of the embodiments described herein, such as a user or application defined policy, the HANDSF policy, or the VANDSF policy.

[0072] With respect to selection of a preferred access technology for device-to-device (D2D) communication, an HPLMN and a VPLMN may have a preferred access technology for use in D2D communication. The preferred access technology for each PLMN may vary based on the registered PLMN (RPLMN) on which the WTRU has successfully performed location registration or based on whether the WTRU is in or out of 3GPP access coverage. The preferred access technology for D2D communication may also be configured based on the combination of the HPLMN or RPLMN of the WTRU itself and a D2D peer. Upon initiation of D2D communication, a WTRU may negotiate the access technology to be used, taking into account its own capability.

[0073] In an embodiment, a WTRU may initiate D2D communication with another WTRU. The WTRU may negotiate an access technology to use for the D2D communication with the other WTRU based on a preferred access technology of one of an HPLMN, a VPLMN or an RPLMN. [0074] With respect to development of HS2.0 parameters as offloading or traffic steering criteria after WLAN selection, 3GPP TR 23.865 describes potential rules to be used for selecting a WLAN based on HS2.0 parameters that are based on BSS load and venue name of a selected WLAN. Once a WLAN is selected based on the HS2.0 parameters, the validity of flow distribution rules may be further examined based on the selected WLAN, such as: If the BSS load < threshold X, then web traffic is offloaded to WLAN. Otherwise, it is carried by a 3GPP RAT. If the BSS load < threshold Y, then Skype traffic is offloaded to WLAN. Otherwise, it is carried by a 3GPP RAT. Y<X because the delay requirement for Skype has a more stringent delay requirement than web traffic. If the venue name of the selected WLAN indicates "3GPP meeting", then file transfer protocol (FTP) traffic is offloaded to WLAN. Otherwise, it is carried by a 3GPP RAT.

[0075] To make HS2.0 selection parameters compatible with other selection policies (e.g., HANDSF, VANDSF, user or application defined policies or D2D preferred networks), in an embodiment, HS2.0 parameters, such as BSS load and venue name, may be used as criteria in a flow distribution rule or may be specified as part of a RoutingRule node in a flow distribution rule. In a flow distribution rule, if the criteria for a selected access technology of a highest priority are not met, a WTRU may use the access technology of the next priority in the same flow distribution rule.

[0076] For example, a flow distribution rule may include entry and exit conditions related to HS2.0 parameters. In this example, the flow may only be moved to the selected WLAN if the entry condition is satisfied, and the traffic (if any) stays in a particular WLAN until the exit condition is met. The exit condition may implicitly include events such as WLAN reselection.

[0077] In embodiments where HS2.0 parameters or criteria are used, a hysteresis timer may be activated to prevent flow ping-pong where a WTRU may otherwise frequently switch back and forth between a WLAN and a 3GPP RAN due to fluctuations in BSS load, for example. With a hysteresis timer activated, no flow movement may be allowed before the timer expires. In an embodiment, the timer may be activated when a WTRU detects the change of the preferred access for a flow (e.g., when the entry condition is met). In another embodiment, the WTRU may stay in a WLAN after an exit condition is met for the duration of the timer. In this embodiment, the start of the timer may be triggered by the exit condition, and the timer may be stopped when the entry condition is met again.

[0078] In an example embodiment, use of HS2.0 criteria may be combined with other embodiments described herein. For example, with reference to FIG. 2 and the related description, a WTRU or base station may select one of a plurality of available WLANs to steer or offload traffic corresponding to the particular application to based on at least one user or application defined policy, HS2.0 criteria, and/or at least one ANDSF policy or RAN steering rule. Here, the WTRU may select the one of the plurality of available WLANs to offload the traffic corresponding to the particular application to based on the at least one user or application defined policy and apply the HS2.0 criteria to the selected one of the plurality of WLANs. If the HS2.0 criteria are met by the selected one of the plurality of WLANs, the WTRU may offload the traffic corresponding to the particular application to the selected one of the plurality of WLANs. If the HS2.0 criteria are not met by the selected one of the plurality of WLANs, the WTRU may select a lower priority WLAN from the plurality of available WLANs that meets the HS2.0 criteria. For another example, with reference to FIG. 3 and the related description, a WTRU may offload traffic to a WLAN selected based at least on an obtained network policy and HS2.0 criteria.

[0079] With respect to handling of the existing NSWO traffic in the

VPLMN when an HPLMN ISRP becomes active or when a new WLAN provided by the HPLMN is selected, 3GPP TR 28.865 describes mechanisms for selecting an active ISMP/ISRP when a WTRU is roaming. If all of the WLANs provided by the HANDSF WLAN selection policies are available, a WTRU configured to prefer WLANs provided by the HPLMN or configured with a Prefer VplmnWlans node not including the current VPLMN may select the active ISRP from the rules provided by the HPLMN and select a WLAN based on the WLANs provided by HPLMN. [0080] Issues may arise when an IP flow exists in the VLPMN ANDSF policies that matches a flow distribution rule for NSWO, but it does not match any flow distribution rule for NSWO in the active ISRP in the HANDSF policies. Issues may also arise when an IP flow exists in the VPLMN ANDSF policies that matches a flow distribution rule for NSWO, but it also matches a ForFlowBased or ForServiceBased flow distribution rule that specifies the preferred access as 3GPP access in the active ISRP in the HANDSF policies. Such an IP flow may have already been offloaded to a WLAN by the 3GPP network in the VPLMN.

[0081] FIG. 4A is a diagram of a wireless network 400A illustrating an example scenario where an IP flow has been offloaded by the 3GPP network in the VPLMN to a WLAN. In the example illustrated in FIG. 4A, a traffic flow 420 is offloaded by the VPLMN 402 through the Internet 110 via a WLAN 430. For comparison, a 3GPP flow 410 that is not offloaded to the WLAN 430 is also shown in FIG. 4A. Upon selecting HPLMN policies as the active ISRP, however, the traffic may need to be routed back to the roaming 3GPP access network, which is not intended by the VPLMN operator.

[0082] It should be noted that this issue does not come into play if the

WLAN provided by the VPLMN has sufficient signal strength. Here, the WTRU may not select a higher priority WLAN if it has already selected a lower priority one.

[0083] FIG. 4B is a diagram 400B of an example embodiment for offloading traffic to a newly selected WLAN provided by the HPLMN in the scenario presented in FIG. 4A. In the example illustrated in FIG. 4B, HPLMN policies for the HPLMN 404 allow currently offloaded NSWO traffic or the traffic configured for NSWO in the VPLMN 402 that are not specified in and/or are not in conflict with a HANDSF ISRP to be offloaded to a newly selected WLAN provided by HPLMN 404. Accordingly, as illustrated in FIG. 4B, the traffic flow that was offloaded by the VPLMN (420) is offloaded via a new WLAN 440 selected by the HPLMN 404.

[0084] The HANDSF may permit the WTRU to move the currently configured NSWO traffic in the VPLMN to the selected WLAN of the HPLMN. Such permission may be explicitly signaled to a WTRU as a new node in the ISRP or may be enabled by default. It is possible that the node/permission may only exist in a HANDSF ISRP that has a roaming flag set.

[0085] Alternatively, the ISRP from the HANDSF may specify which IP flows should be carried by the 3GPP RAT. In an embodiment, the HANDSF may specify which IP flows should be carried by the 3GPP RAT with validity conditions that the IP flows are also configured by the VANDSF to be routed to a 3GPP RAT. By default, all the rest of the traffic may be moved to the newly selected WLAN as NSWO traffic.

[0086] In another alternative, the ISRP from the HANDSF may specify which IP flows should be moved to the newly selected WLAN provided by the HPLMN as NSWO. In an embodiment, the ISRP from the HANDSF may specify which IP flows should be moved to the newly selected WLAN provided by the HPLMN as NSWO with validity conditions that the IP flows that are also configured by the VANDSF to be routed to the 3GPP RAT should be moved to the newly selected WLAN provided by HPLMN as NSWO. By default, the existing NSWO traffic in the VPLMN may also be moved to the selected WLAN provided by the HPLMN.

[0087] The WTRU may treat the VPLMN ISRP as an amendment to the

HPLMN ISRP, with a RulePriority for each flow distribution rule from the VPLMN determined as having a lower priority than the RulePriority of any of the flow distribution rules from the HPLMN. This may allow the flows unspecified by the HPLMN to be offloaded as permitted by the VPLMN.

[0088] In one embodiment, if a conflict occurs between traffic flow policy from the VANDSF and policy from the HANDSF, the WTRU may prepare a message that includes the conflicting VANDSF policy and send it to the HANDSF. The HANDSF may in turn provide a modified policy so that the issue may be resolved. Alternatively, the WTRU may provide conflicting HANDSF policy to the VANDSF, and the VANDSF may provide a modified policy to resolve the issue.

[0089] In yet another embodiment, an interface may be defined between the HANDSF and the VANDSF, which may be used to harmonize policies so that there is no conflict. Alternatively, when the WTRU sends a message to either the HANDSF or the VANDSF reporting a conflict, the HANDSF (or VANDSF) may provide this update to a peer ANDSF (e.g., HANDSF or VANDSF) at the time of the modified policy is provided to the WTRU.

[0090] In yet another embodiment, when a WTRU reports a conflict in policy and receives a modified policy in return from the HANDSF, the WTRU may inform the HANDSF of any change of VPLMN (e.g., from VPLMN1 to VPLMN2) or of the WTRU returning to the HPLMN. This may allow the HANDSF to restore the modified policy to the original policy. Alternatively, the WTRU itself may restore the original HANDSF policy if it is changing the VPLMN or returning to the HPLMN and may also inform the HANDSF of the change. In yet another embodiment, the WTRU may inform the HANDSF of any change of VPLMN or return to the HPLMN or may restore the original policy on its own when changing its PLMN only if the WTRU reported the conflict and received a modified policy in return for a certain validity time. The validity time may be handled by use of a timer provided by the HANDSF that is fixed or configurable.

[0091] 3GPP TR 23.865 further describes a preferred service provider list (PSPL) that includes a list of providers preferred by a WTRU's 3GPP home operator. This list may be used by the WTRU to construct an NAI when it attempts authentication over a selected WLAN access network and to select a WLAN access network when multiple WLANs are available that best match the preferences in the active ISMP or ISRP.

[0092] Issues may arise in certain scenarios. For example, an issue may arise when local breakout (LBO) IFOM/MAPCON traffic is offloaded to a WLAN controlled by a VPLMN. This scenario is illustrated in the diagram 500A of FIG. 5A, where the LBO IFOM/MAPCON traffic 540 is offloaded through the Internet 110 via a WLAN 510 selected by the VPLMN 402 (502). For another example, an issue may arise when a WTRU is configured to prefer WLANs provided by the HPLMN and selects a WLAN provided by the HPLMN. The WTRU may use the ISRP provided by the HANDSF as its active ISRP. For another example, an issue may arise when a WTRU is not configured to prefer WLANs provided by the HPLMN. It may select to a higher priority WLAN based on the WLAN selection policy (WLANSP) provided by the VPLMN. The selected WLAN may be connected to the HPLMN (and may also be connected to the VPLMN). The WTRU may perform authentication by providing the NAI of its HPLMN (root NAI) based on the configuration of the PSPL.

[0093] After the WTRU selects the WLAN and successfully authenticates, the seamless LBO traffic may not be continued unless the traffic is moved back to the 3GPP RAT of the VPLMN. This may not be intended by the VPLMN operator. This scenario is illustrated in the diagram 500B of FIG. 5B, where traffic that was originally offloaded through the Internet 110 via the WLAN 510 selected by the VPLMN 402 (540) is moved back to the 3GPP RAT of the VPLMN 402 (550).

[0094] It should be noted that the issues described above may not come in to play if the WLAN provided by the VPLMN has sufficient signal strength. Here, the WTRU may not select a higher priority WLAN if it has already selected a lower priority one.

[0095] FIG. 5C is a diagram 500C of an embodiment where offloaded

IFOM/MAPCON local breakout traffic is handed over to an evolved packet data gateway (ePDG) provided by the VPLMN. In the example illustrated in FIG. 5C, HPLMN and/or VPLMN policies allow offloaded LBO IFOM/MAPCON traffic 502 configured by VPLMN policies to be handed over to an ePDG 590 provided by the VPLMN 402 (508) on a condition that the ePDG is reachable from the newly selected WLAN provided by the HPLMN 404. The NSWO PDN connection may be used for a tunnel to the ePDG 590 so that the traffic to the LBO packet gateway (LBO-PGW) 512 does not need to travel through the HPLMN 404 core network.

[0096] Currently, the tunnel to an ePDG only applies when the WLAN is un-trusted and is not used for connecting to a VPLMN PDN from an HPLMN access network. If the selected WLAN is a WLAN that offers connectivity to an HPLMN but is provided by a non-3GPP partner, the WLAN may indicate itself as un-trusted to the WTRU during access authentication. The WTRU may need to connect to an HPLMN ePDG. Currently, it may not be possible to use another ePDG to access the VPLMN simultaneously.

[0097] In the embodiment described above with respect to FIG. 5C, the

VANDSF may configure whether it allows the WTRU to use an ePDG of the VPLMN, for example, via an NSWO PDN connection provided by another operator. The VANDSF/VPLMN may further configure the protocols supported for establishing a tunnel between the ePDG and the WTRU, such as an IP security (IPsec) tunnel or a firewall traversal tunnel (FTT). In addition, the VANDSF/VPLMN may provide an identity, such as an IP addresses or a fully qualified domain name (FQDN) of the ePDG. Further, the VANDSF may configure whether the DNS lookup of the ePDG should take place on the 3GPP RAT of the VPLMN or on the selected WLAN of the HPLMN. In the latter case, the VANDSF may also configure an IP address of a separate domain name server (DNS) controlled by the VPLMN, which may be used for querying an ePDG IP address. The IP address of the DNS server may be an any-cast address, by which a nearest DNS/ePDG may be determined from the WLAN selected by the WTRU.

[0098] The HANDSF ISRP may configure whether it allows the use of a tunnel to a VPLMN ePDG via WLAN provided by the HPLMN, regardless of the trust status of the WLAN or whether a separate ePDG has already been used for home-routed traffic. Further, if the WTRU supports IFOM/S2c, the VANDSF may be configured to allow the WTRU to use the NSWO IP address of the HPLMN as the outer IP address for the dual stack mobile IPv6 (DSMIPv6) tunnel to the PGW of the VPLMN without using an ePDG provided by the VPLMN. An FTT ePDG may be configured as a backup if the DSMIPv6 tunnel cannot traverse through the selected WLAN.

[0099] In another embodiment, the ANDSF may specify that certain

LBO flows may be converted to NSWO flows if the WTRU has selected to a WLAN that does not offer connectivity to the VPLMN.

[0100] The WTRU may determine whether the PDN connection is LBO according to the following. A VANDSF ISRP flow distribution rule may carry a special condition that the IP flow may only be offloaded to the WiFi network (with IP address preservation) of certain NAI realms/OIs /PLMNs. The MME of a 3GPP network in the VPLMN may return a full access point name (APN) when the PDN connectivity is accepted in the VPLMN. The terrestrial wide area network (TWAN) or ePDG of the HPLMN may indicate that the APN is not allowed. Here, the TWAN or ePDG of the HPLMN may indicate to the WTRU a list of APNs to which handover is possible based on information returned from the authentication authorization and accounting (AAA) database during authentication. The cause for the failure of a handover attach to the APN may be indicated. Whether the PDN connection is LBO may also be pre-configured in the WTRU (e.g., certain APN-NI is always LBO when roaming).

[0101] With respect to providing a WTRU's capability to understand the new ANDSF rules to the ANDSF server, an ANDSF server may not be aware of a WTRU's capability to understand the new ANDSF rules. An ANDSF server may need to know the WTRU's capability to understand the new ANDSF rules for several reasons, including, for example, that separate 3GPP access (e.g., LTE, UTRAN, and GERAN) may be specified as the target access in the ISRP or ISMP and that the service set identification (SSID) or homogenous SSID (HESSID) of the preferred WLANs in an NSWO ISRP flow distribution rule may be ignored by the WTRU in certain circumstances. The ANDSF server may not be aware of this WTRU behavior when issuing ANDSF policies.

[0102] Alternatively, the individual 3GPP RATs may be used together with the old 3GPP access technology in <X>/Policy/<X>/PrioritizedAccess. The legacy WTRU may not interpret the newly defined 3GPP access while a Release 12 WTRU may not interpret the old 3GPP access.

[0103] In an embodiment, a UE_Profile node or a new node within the

ANDSF may be further expanded to define a WTRU's capability for ANDSF enhancement. The UE_Profile may be sent to an ANDSF server in open mobile alliance device management (OMA-DM) package #1. If the DeviceDetail node from the HS2.0 MO is sent from the WTRU, then the ANDSF may assume that the WTRU supports the new ANDSF structure and procedures.

[0104] With respect to developing rules for target access network validity based on selection of a WLAN service provider, in some situations the validity of the flow distribution rule may be based on the service provider the WTRU selected during authentication.

[0105] For example, an IP flow that satisfies a flow distribution rule may not be offloaded to the selected WLAN because the WLAN of the selected service provider may have no connectivity to the PGW of the IP flow. In this example, a condition may need to be conveyed to the WTRU for determining the preferred access or the validity of the flow distribution rule based on the selected WLAN service provider.

[0106] For another example, the VPLMN may not have a roaming agreement with the HPLMN for non-3GPP access. Hence, all home-routed traffic may not be offloaded to a WLAN provided by the VPLMN. However, the VANDSF may still be able to specify home-routed-traffic offloading if the same WLAN provides connectivity to the HPLMN. A condition may need to be conveyed to the WTRU with regard to the validity of the rule based on how the WTRU authenticates to the selected WLAN.

[0107] For another example, an operator preference for offloading may change based on the service provider of the selected WLAN.

[0108] Currently, in each flow distribution rule, the SSID may be specified to resolve the issue described above. However, it may be possible that the SSID is from a WLAN shared by multiple operators. It is also possible that the 3GPP operator providing the ISRP does not know the SSID configured by its WLAN partner. In these situations, an alternative method for identifying the selected WLAN service provider may be needed.

[0109] FIGs. 6A, 6B and 6C are diagrams 600A, 600B and 600C illustrating example locations for insertion of an ISRP node into ISRP (for example, in an ISRP tree such as an ISRP tree provided in 3GPP TS 24.312 v 4.2, which FIG. 6C references with respect to Figures 4.2.6, 4.2.7 and 4.2.8). FIG. 6A is a diagram 600A of an example embodiment where a service provider identity (e.g., the PLMN ID of the PLMN the WTRU authenticates with, the 01, the OI of the roaming consortium, the NAI realm, or the domain name) may be used as criteria to determine whether a flow distribution rule applies. The criteria may be placed under a RoutingRule node or may be placed as one of the validity conditions under a RoutingCriteria node (for example, in an ISRP tree such as an ISRP tree provided in 3GPP TS 24.312 v 4.2). For example, the PLMN ID is currently used only for identifying the validity area of the 3GPP access. However, the PLMN ID of the selected WLAN may also be a condition for validity. FIG. 6B is a diagram 600B of an example embodiment where the determination of the active ISRP rule may be based on the service provider of the selected WLAN by introducing a node identifying the service provider under the ISRP node (for example, in an ISRP tree such as an ISRP tree provided in 3GPP TS 24.312 v 4.2).

[0110] A similar approach may be applied to the UE_Location node such that the ANDSF server may be based on a WTRU-selected-WLAN-service- provider to configure appropriate ANDSF policies. The service provider ID node may include a list of service provider IDs. The list may either be a white list or a black list. The service provider ID node may represent a test condition. The outcome of the test may indicate whether the rule or preferred access is not applicable, for example: WLAN service provider==3GPP RPLMN may be used by the VPLMN to indicate the flow as LBO; WLAN service provider==any service provider listed in the PSPL; WLAN service provider==any PLMN listed in the equivalent PLMN list of the current 3GPP access; the WTRU may be authenticated via a 3GPP access authentication to the WLAN service provider; and WLAN service provider ==HPLMN or EHPLMN.

[0111] With respect to provision of an RPLMN preference in the PSPL, it is currently possible for a HANDSF to configure in the PSPL whether a WTRU prefers the 3GPP RPLMN for WLAN access. If the policy is set to prefer 3GPP RPLMN, and the active ANDSF rule is provided by the 3GPP RPLMN, the WTRU may select the RPLMN (or a PLMN equivalent to the 3GPP RPLMN) for WLAN access if possible. If the active ANDSF rule is provided by a PLMN other than the current 3GPP RPLMN, or the policy is not set, the WTRU may use the PSPL.

[0112] FIG. 7A is a diagram 700A of an example situation where the highest priority WLAN 714 in the VANDSF offers connectivity to both the HPLMN 706 and the VPLMN 704 via a subscription service provider network (SSPN) interface 708. In the example illustrated in FIG. 7A, after the discovery of the WLAN 714, the WTRU 702 may authenticate to the WLAN 714 with either a root NAI or a decorated NAI constructed from the VPLMN ID. A policy of prefer 3GPP RPLMN may force the WTRU 702 to connect to or authenticate with the WLAN 714 via the VPLMN or decorated NAI via a home-routed PDN connection 712. With a different configuration, the LBO PDN connection 710 may be offloaded to the WLAN 714.

[0113] If the configuration of prefer 3GPP RPLMN is set to true, the

HPLMN 706 may configure this attribute not knowing what the VPLMN policy is. For example, if the VANDSF ISRP does not configure any ForFlowBased and ForServiceBased flow distribution containers, the VPLMN 704 may not intend to offload anything other than traffic that may be handled non- seamlessly. The issue of LBO connectivity in a WLAN may not occur. Preferring RPLMN may cause a WTRU to unnecessarily select or authenticate to a WLAN provided by the VPLMN when the same WLAN may also provide more economical service based on its agreement with the HPLMN.

[0114] If the configuration of prefer 3GPP RPLMN is set to false, the

WLAN may offer connectivity to both the VPLMN 704 and the HPLMN 706 ( e.g., an ANQP query of the NAI realm may return the HPLMN and VPLMN realm), and the VANDSF ISRP may specify offloading of the LBO PDN connections to a WLAN. In this case, because the WTRU may not be aware that the PDN connection is LBO, the WTRU may attempt a handover attach of the LBO PDN connection and may fail.

[0115] In an embodiment, an ISRP-capable-WTRU may locally disable the prefer 3GPP RPLMN configuration if the active VANDSF ISRP policy only provides policies for NSWO. The WTRU may construct the NAI based on the PSPL and behave as if the prefer 3GPP RPLMN is set to false. [0116] In another embodiment, the VANDSF policy may override the prefer 3GPP RPLMN, which may help avoid the scenario 700B illustrated in FIG. 7B where the WTRU 702 authenticates with the root NAI.

[0117] In another embodiment, the WTRU may report its prefer 3GPP

RPLMN configuration or the PSPL configuration to the VANDSF. The VANDSF may, thus, avoid configuring the LBO PDN connection to be offloaded on a condition that the WTRU is configured by the HPLMN to not prefer the 3GPP RPLMN.

[0118] In yet another embodiment, a different PSPL/prefer 3GPP

RPLMN may be specified for different VPLMNs. For example: if VPLMN=x, then PSPL = x > HPLMN > y > z; and if VPLMN=y, then PSPL = HPLMN > x > y >z.

[0119] With respect to handling undesirable BSS load (or other HS2.0 parameters) in the WLAN provided by the HPLMN while prefer WLAN provided by the HPLMN is configured, prefer WLAN provided by the HPLMN may be configured when the WTRU is currently associated with a WLAN provided by the VPLMN. The WTRU may have discovered a WLAN provided by the HPLMN. The HPLMN WLAN BSS load may be much higher than the VPLMN WLAN BSS load. The selection to the WLAN may lead to congestion of the HPLMN WLAN and an undesirable user experience.

[0120] After selection to the WLAN provided by the HPLMN, it may be possible that after a short duration, the HS2.0 parameters that lead the WTRU to the WLAN provided by HPLMN, such as BSS load, may no longer be satisfied. The WTRU would likely move to the WLAN provided by the VPLMN it previously connected to. Such movement between two WLANs may continue as the HS2.0 parameters of the two networks change. Such reselection may change the active ISRP causing further ping-pongs at flow level.

[0121] In an embodiment, the WTRU may be configured to behave according to one of the following: prefer the WLAN provided by the HPLMN that has the highest precedence compared to other HS2.0 criteria; the HANDSF specifies a delta of the value of HS2.0 parameters (such as BSS load) between the WLAN provided by the HPLMN and the WLAN provided by VPLMN; the WTRU provides the observed difference between the values of HS2.0 parameters in the HPLMN and VPLMN WLANs to either the HANDSF or VANDSF and requests updated policies; or the WTRU may determine whether to perform selection to the HPLMN WLAN based on HS2.0 parameters embedded in the WLANSP from the HANDSF. With respect to prefer the WLAN provided by the HPLMN having the highest precedence compared to other HS2.0 criteria, the WTRU may always select to the WLAN provided by the HPLMN regardless of the condition of the BSS load or other HS2.0 parameters. With respect to the HANDSF specifying a delta of the value of HS2.0 parameters between the WLAN provided by the HPLMN and the WLAN provided by the VPLMN, if the value corresponding to the WLAN provided by the HPLMN is not worse than the delta compared to the value corresponding to the WLAN provided by VPLMN, then the WLAN of the HPLMN may be selected.

[0122] After selection, the WTRU may start a timer. When the timer is running, the WTRU may not select to another WLAN. The timer value may be made to be inversely proportional to the difference between the values of parameters from the WLAN provided by the HPLMN and the VPLMN if the HPLMN's parameter is worse at the time of selection.

[0123] With respect to applicability of individual 3GPP RATs as preferred access in the ISMP, individual 3GPP RATs as preferred access are currently not supported in the ISMP because of the ping-pong caused by the scenario where ISMP: LTE > WLAN > UTRAN. In LTE access, the RFSP index may have been chosen to prefer UTRAN access. The WTRU may be redirected or handed over to UTRAN. The WTRU may find a WLAN and move all PDN connections to the WLAN. The WTRU may detach from the UTRAN/3GPP. The WTRU may find an LTE network and attach to the LTE network based on ISMP priority. The WTRU may move all PDN connections to the LTE network and repeat all of the described steps.

[0124] The above issue may be caused by detaching from the 3GPP access because the WTRU may return to the LTE network following the ISMP without guidance from the 3GPP RAT when detached. Such an issue is most likely avoided in the ISRP because the WTRU is attached to a 3GPP RAT at any given time.

[0125] In one embodiment, individual 3GPP RATs may be configured in the ISMP for a circuit switched (CS)-registered-WTRU. Such a WTRU may at any given time attach to a 3GPP RAT (although it may be only in the CS domain), and the RAT reselection mechanism may ensure no ping-pong between 3GPP RATs. In the above example, the WTRU redirected to UTRAN may keep its CS registration and move all IP traffic in the WLAN. The WTRU may follow the RAT re- selection procedure in the UTRAN and may not immediately move back to the LTE network.

[0126] In another embodiment, 3GPP RAT selection or re-selection priority may be remembered for a certain duration after detaching from a 3GPP RAT. An assumed target 3GPP access based on remembered priority may be used in the ISMP to determine whether a WLAN is used to carry IP traffic. In the above example, a packet switched (PS)-only-WTRU, upon detaching from UTRAN/HSPA, may remember that LTE is of a lesser priority than UTRAN/HSPA. After the WTRU moves to the WLAN, the WLAN may still be of higher priority than UTRAN/HSPA (the assumed target 3GPP access based on remembered 3GPP priority). The WTRU may stay in the WLAN.

[0127] In yet another embodiment, the WTRU may report its CS registration status when contacting the ANDSF server. The ANDSF server may then issue the ISMP accordingly (with or without the individual 3GPP RAT).

[0128] With respect to applicability of ANQP connection capability, the connection capability element may provide information on the connection status within the hotspot of the most commonly used communications protocols and ports. For example, a firewall upstream to the access network may allow communication on certain IP protocols and ports while blocking communication on others. The elements may be returned during the ANQP procedure before authentication. Thus, it is a property not related to the PLMN the WTRU selects.

[0129] The WTRU that connects to a WLAN for evolved packet core

(EPC) access via S2b/S2c may not be subject to such a capability restriction as long as the hotspot has the capability to establish an IPsec/TLS tunnel. The WTRU that connects to a WLAN for EPC access (e.g., via S2a) may not be subject to the connection capability restrictions since the SSPN interface may be tunneled to the selected SSPN. The blocking of the traffic may be based on the policies of the PDN connection or the selected PLMN.

[0130] In an embodiment, ANDSF policy may specify, or the WTRU may be configured with, the scope of the connection capability. The scope may be different for each WLAN/PLMN/service provider the WTRU selects to. For example, NSWO traffic specified in the ISRP may need to satisfy the connection capability of the hotspot. Otherwise, the flows may be carried by the 3GPP RAT. For another example, traffic for seamless offload (e.g., MAPCON) may not be subject to HS2.0 connection capability.

[0131] With respect to WLAN indication to HSS for its connectivity to multiple PLMNs, in FIG. 7B, after the WTRU 702 has authenticated with the WLAN based on a root NAI, the WTRU 702 may later perform a PDN connection establishment to an LBO APN. However, the AAA signaling to the HSS for the WTRU may not include a visited network identifier because the signaling of authentication did not pass through a AAA proxy, and the WLAN at the time of authentication may not be aware of the WTRU's roaming status in the 3GPP RAT. As a result, the APN and PGW data and/or charging characteristics for the LBO APN may not be returned from the HSS.

[0132] In one embodiment, the WLAN may provide a list of PLMNs to which it offers connectivity in station (STA) signaling to the AAA server upon sending an authentication request. The list may be further provided to the HSS via wireless expansion (WSX) for requesting the return of APN and PGW data and charging characteristics of the LBO APN if the HSS has decided the roaming WTRU's RPLMN is on the list. Further, the PGW identification notification for the LBO APN may be provided from the WLAN or received from the HSS without the use of the AAA proxy in the VPLMN.

[0133] In another embodiment, the HSS may always provide APN and

PGW data and/or charging characteristics of an LBO APN to the AAA server/WLAN based on the roaming WTRU's RPLMN on the 3GPP RAT regardless of whether the WLAN supports the connectivity to the WTRU's 3GPP VPLMN. The WLAN discards the APN and the PGW data, and charging characteristics or PGW identification notification, for the networks it does not have direct connectivity with.

[0134] EMBODIMENTS:

[0135] 1. A method of a wireless transmit/receive unit (WTRU) offloading traffic corresponding to a particular application to a wireless local area network (WLAN), the method comprising: identifying a plurality of available WLANs through WLAN network discovery; and determining at least one user or application defined policy.

[0136] 2. The method of embodiment 1, further comprising signaling the at least one user or application defined policy to a base station.

[0137] 3. The method of embodiment 1 or 2, further comprising selecting one of the plurality of available WLANs to offload the traffic corresponding to the particular application to based at least on the at least one user or application defined policy.

[0138] 4. The method of any one of embodiments 1-3, wherein the base station has obtained at least one access network discovery and selection function (ANDSF) policy or radio access network (RAN) steering rule that conflicts with the at least one user or application defined policy.

[0139] 5. The method of any one of embodiments 1-4, further comprising offloading the traffic corresponding to the particular application to the selected one of the plurality of available WLANs.

[0140] 6. The method of any one of embodiments 1-5, further comprising receiving a steering command from the base station directing the WTRU to offload the traffic corresponding to the particular application using a particular radio bearer (RB) selected based on the at least one user or application defined policy.

[0141] 7. The method of any one of embodiments 1-6, further comprising initiating a device-to-device (D2D) communication with another WTRU.

[0142] 8. The method of embodiment 7, further comprising negotiating an access technology to use for the D2D communication with the other WTRU based on a preferred access technology of one of a home public land mobile network (HPLMN), a visited PLMN (VPLMN) or a registered PLMN (RPLMN).

[0143] 9. A base station comprising a receive unit configured to receive, from a wireless transmit/receive unit (WTRU), at least one user or application defined policy that corresponds to a particular application run by the WTRU.

[0144] 10. The base station of embodiment 9, wherein the receive unit is further configured to receive at least one access network discovery and selection function (ANDSF) policy or radio access network (RAN) steering rule.

[0145] 11. The base station of embodiment 9 or 10, further comprising a control unit configured to compare the at least one user or application defined policy with the at least one ANDSF rule or RAN steering rule.

[0146] 12. The base station of any one of embodiments 9-11, further comprising a transmit unit configured to transmit a steering command to the WTRU to steer traffic corresponding to the particular application to a wireless local area network (WLAN) selected based at least on the at least one user or application defined policy received from the WTRU or the at least one ANDSF rule or RAN steering rule.

[0147] 13. The base station of any one of embodiments 9-12, further comprising a memory configured to store the at least one access network discovery and selection function (ANDSF) policy or radio access network (RAN) steering rule. [0148] 14. A wireless transmit/receive unit (WTRU) comprising a processing unit configured to authenticate with a public land mobile network (PLMN) and obtain at least one network selection policy for use in selecting a wireless local area network (WLAN) to offload traffic to.

[0149] 15. The WTRU of embodiment 14, wherein the processing unit is further configured to compare an identifier (ID) of the PLMN that the WTRU authenticated with with an ID provided with one of the at least one obtained network selection policy.

[0150] 16. The WTRU of embodiment 14 or 15, wherein the processing unit is further configured to select the one of the at least one obtained network selection policy on a condition that the ID of the PLMN that the WTRU authenticated with matches the ID provided with the one of the at least one obtained network selection policy.

[0151] 17. The WTRU of any one of embodiments 14-16, wherein the processing unit is further configured to offload traffic to a WLAN selected based at least on the one of the at least one obtained network selection policy.

[0152] 18. The WTRU of any one of embodiments 14-17, wherein the processing unit is further configured to select a network selection policy other than the one of the at least one obtained network selection policy on a condition that the ID of the PLMN that the WTRU authenticated with does not match the ID provided with the one of the at least one obtained network selection policy.

[0153] 19. The WTRU of any one of embodiments 14-18, wherein the

WTRU is configured to apply home access network discovery and selection function (HANDSF) policies when there is a conflict between HANDSF policies and visited ANDSF (VANDSF) policies.

[0154] 20. The WTRU of any one of embodiments 14-19, wherein the

PLMN that the WTRU authenticated with is a visited PLMN (VPLMN).

[0155] 21. The WTRU of any one of embodiments 14-20, wherein the one of the at least one obtained network selection policy is a VANDSF policy for the VPLMN that conflicts with HANDSF policies of a home PLMN (HPLMN) of the WTRU. [0156] 22. The WTRU of any one of embodiments 14-21, wherein the

PLMN that the WTRU authenticated with is a shared radio access network (RAN).

[0157] 23. The WTRU of any one of embodiments 14-22, wherein the processing unit is further configured to initiate a device-to- device (D2D) communication with another WTRU.

[0158] 24. The WTRU of embodiment 23, wherein the processing unit is further configured to negotiate an access technology to use for the D2D communication with the other WTRU based on a preferred access technology of one of an HPLMN, a VPLMN or a registered PLMN (RPLMN).

[0159] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. Further, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto -optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS What is Claimed:

1. A method of a wireless transmit/receive unit (WTRU) offloading traffic corresponding to a particular application to a wireless local area network (WLAN), the method comprising:

identifying a plurality of available WLANs through WLAN network discovery;

determining at least one user or application defined policy;

signaling the at least one user or application defined policy to a base station; and

selecting one of the plurality of available WLANs to offload the traffic corresponding to the particular application to based at least on the at least one user or application defined policy when the base station has obtained at least one access network discovery and selection function (ANDSF) policy or radio access network (RAN) steering rule that conflicts with the at least one user or application defined policy.

2. The method of claim 1, further comprising offloading the traffic corresponding to the particular application to the selected one of the plurality of available WLANs.

3. The method of claim 1, further comprising receiving a steering command from the base station directing the WTRU to offload the traffic corresponding to the particular application using a particular radio bearer (RB) selected based on the at least one user or application defined policy.

4. The method of claim 1, further comprising:

initiating a device-to- device (D2D) communication with another WTRU; and

negotiating an access technology to use for the D2D communication with the other WTRU based on a preferred access technology of one of a home public land mobile network (HPLMN), a visited PLMN (VPLMN) or a registered PLMN (RPLMN).

5. A base station comprising:

a receive unit configured to:

receive, from a wireless transmit/receive unit (WTRU), at least one user or application defined policy that corresponds to a particular application run by the WTRU, and

receive at least one access network discovery and selection function (ANDSF) policy or radio access network (RAN) steering rule;

a control unit configured to compare the at least one user or application defined policy with the at least one ANDSF rule or RAN steering rule; and a transmit unit configured to transmit a steering command to the WTRU to steer traffic corresponding to the particular application to a wireless local area network (WLAN) selected based at least on the at least one user or application defined policy received from the WTRU or the at least one ANDSF rule or RAN steering rule.

6. The base station of claim 5, further comprising a memory configured to store the at least one access network discovery and selection function (ANDSF) policy or radio access network (RAN) steering rule.

7. A wireless transmit/receive unit (WTRU) comprising:

a processing unit configured to:

authenticate with a public land mobile network (PLMN), obtain at least one network selection policy for use in selecting a wireless local area network (WLAN) to offload traffic to,

compare an identifier (ID) of the PLMN that the WTRU authenticated with with an ID provided with one of the at least one obtained network selection policy,

on a condition that the ID of the PLMN that the WTRU authenticated with matches the ID provided with the one of the at least one obtained network selection policy, select the one of the at least one obtained network selection policy, and

offload traffic to a WLAN selected based at least on the one of the at least one obtained network selection policy.

8. The WTRU of claim 7, wherein the processing unit is further configured to select a network selection policy other than the one of the at least one obtained network selection policy on a condition that the ID of the PLMN that the WTRU authenticated with does not match the ID provided with the one of the at least one obtained network selection policy.

9. The WTRU of claim 8, wherein:

the WTRU is configured to apply home access network discovery and selection function (HANDSF) policies when there is a conflict between

HANDSF policies and visited ANDSF (VANDSF) policies,

the PLMN that the WTRU authenticated with is a visited PLMN

(VPLMN), and

the one of the at least one obtained network selection policy is a

VANDSF policy for the VPLMN that conflicts with HANDSF policies of a home PLMN (HPLMN) of the WTRU.

10. The WTRU of claim 7, wherein the PLMN that the WTRU authenticated with is a shared radio access network (RAN).

11. The WTRU of claim 7, wherein the processing unit is further configured to:

initiate a device-to- device (D2D) communication with another WTRU; and

negotiate an access technology to use for the D2D communication with the other WTRU based on a preferred access technology of one of an HPLMN, a VPLMN or a registered PLMN (RPLMN).