Method and apparatus for selected internet protocol (IP) traffic offload (SIPTO) and local IP access (LIPA) mobility

Methods and apparatus are described for supporting wireless transmit/receive unit (WTRU) mobility between Home (evolved) Node Bs (H(e)NBs) that are configured to communicate with a Local Gateway (L-GW). The H(e)NBs and/or L-GW may belong to one or more Local H(e)NB Networks (LHNs). A WTRU may receive services including Selected Internet Protocol (IP) Traffic Offload (SIPTO) or Local IP Access (LIPA) services from the L-GW via one or more H(e)NBs. The WTRU may continue to receive SIPTO or LIPA services after a handover to another H(e)NB that may be in communication with the same L-GW and may belong to the same LHN. The WTRU may receive information related to the LHN or the L-GW to allow continuation of SIPTO or LIPA services as the WTRU moves among H(e)NBs and/or out of the LHN. The WTRU may receive and/or maintain one or more LHN Lists.

BACKGROUND

Selected Internet Protocol (IP) traffic offload (SIPTO) is a method to offload traffic from a wireless communication system operator's core network (CN) to a defined IP network that is close to a point of attachment to the access point of a wireless transmit receive unit (WTRU). The traffic may be offloaded to another path based on the geographical (or topological in terms of IP) location of a WTRU. Thus, a goal of SIPTO is to offload some of the IP traffic from traversing nodes at the CN. Local IP Access (LIPA) is a method for providing access for IP-capable WTRUs that are connected via an H(e)NB (for example, using H(e)NB radio access) to other IP capable entities in the same residential or enterprise IP network. Traffic for LIPA typically does not traverse the mobile operator's network except for accessing particular information at the H(e)NB. A packet data network (PDN) connection established for the WTRU may be used for SIPTO and/or LIPA without the WTRU being aware of the use of SIPTO and/or LIPA.

In a wireless network capable of providing SIPTO or LIPA services, a Local Gateway (L-GW) may be located apart from an H(e)NB. Accordingly, a WTRU may be capable of moving between H(e)NBs while still maintaining a connection to one L-GW. The WTRU may therefore be able to continue to receive SIPTO or LIPA services while moving between H(e)NBs. Local H(e)NB Networks (LHNs) are networks that include one or more H(e)NBs that are in communication with a given L-GW. A LHN may also include H(e)NBs that belong to more than one Closed Subscriber Group (CSG). Based on the separation of the L-GW from the H(e)NBs and the potential handover of the WTRU between more than one H(e)NB, methods are needed to support WTRU mobility between H(e)NBs and to support SIPTO and/or LIPA services during WTRU mobility.

SUMMARY

Methods and apparatus are described for supporting wireless transmit/receive unit (WTRU) mobility between Home (evolved) Node Bs (H(e)NBs) that are configured to communicate with a Local Gateway (L-GW). The H(e)NBs and/or L-GW may belong to one or more Local H(e)NB Networks (LHNs). A WTRU may receive services including Selected Internet Protocol (IP) Traffic Offload (SIPTO) or Local IP Access (LIPA) services from the L-GW via one or more H(e)NBs. The WTRU may continue to receive SIPTO or LIPA services after a handover to another H(e)NB that may be in communication with the same L-GW and may belong to the same LHN. The WTRU may receive information related to the LHN or the L-GW to allow continuation of SIPTO or LIPA services as the WTRU moves among H(e)NBs and/or out of the LHN. The WTRU may receive and/or maintain one or more LHN Lists.

DETAILED DESCRIPTION

When referred to hereafter, the terminology “wireless transmit/receive unit (WTRU)” includes but is not limited to a user, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a computer, or any other type of user device capable of operating in a wireless environment. When referred to hereafter, the terminology “base station” includes but is not limited to a Node-B, an evolved Node-B (eNB), a site controller, an access point (AP), or any other type of interfacing device capable of operating in a wireless environment.

The serving gateway144may also be connected to the PDN gateway146, which may provide the WTRUs102a,102b,102cwith access to packet-switched networks, such as the Internet110, to facilitate communications between the WTRUs102a,102b,102cand IP-enabled devices.

Selected Internet protocol (IP) traffic offload (SIPTO) and local IP access (LIPA) services may be provided in any type of network and may use any type of radio access technology. For example, SIPTO and LIPA may be used in a universal mobile telephone system (UMTS) terrestrial radio access network (UTRAN) as well as an LTE network. The architecture used for SIPTO and LIPA in a UTRAN or LTE network may be similar. Accordingly, although descriptions herein may refer to a particular technology, the descriptions are for exemplary purposes only and one skilled in the art will appreciate that the descriptions may be applied to any technology capable of using SIPTO or LIPA services.

As described above, SIPTO is a method to offload traffic from a CN to a defined IP network. When reference is made to a core network with respect to the data plane, the nodes under consideration may include the serving gateway (S-GW) and the packet data network (PDN) gateway (P-GW) in, for example, an LTE-compliant system, or the serving general packet radio service (GPRS) support node (SGSN) and gateway GPRS support node (GGSN) in a UTRAN, although the disclosure herein is not limited to any one network architecture or technology. SIPTO may require that a WTRU processes both offloaded traffic and non-offloaded (non-SIPTO) traffic that goes through the operator's network. SIPTO may be used in, for example, a UTRAN, an evolved UTRAN (E-UTRAN), and/or a macro cell with a home eNodeB (HeNB), for example.

FIG. 2shows an example wireless network200configured to provide SIPTO services. The network200includes a WTRU210in communication with an eNB220that is located in a radio access network (RAN)225. The eNB220is also in communication with an S-GW230, which is also in communication with a local packet gateway (L-PGW)235and a core network (CN)240. The CN240includes an MME245and a packet data network (PDN) gateway (P-GW)250.

The WTRU210communicates with the eNB220over a wireless air interface255. The eNB220also communicates with the S-GW230over an S1-U interface260. The S-GW230communicates with the L-PGW235over an S5 interface265, and with the P-GW250over an S5 interface270. The S-GW230also communicates with the MME245over an S11 interface275. Two traffic streams are also shown, a SIPTO traffic stream280that is routed through the S-GW230to the L-PGW235, and a CN traffic stream285that is routed through the S-GW230to the P-GW250in the CN240.

The eNB220may also be a HeNB configured to perform SIPTO in a home network of the user of the WTRU210. In that case, traffic may be offloaded locally to a user's home network. The home network may be an IP network that is connected to other devices such as a printer, a television, and a personal computer, for example. These nodes on the home network may be using private addressing.

Also, the wireless network200may be configured to provide Local IP Access (LIPA). While many of the features disclosed herein are described with regard to SIPTO, they may also be applied to LIPA and SIPTO systems for HeNBs. For example, SIPTO or LIPA may include single or multiple PDN connections, deployment behind network address translation (NAT), and the like.

Furthermore, for traffic going through the mobile operator's core network, the S-GW230user plane functions may be located within the CN240. Also, mobility management signalling between a WTRU210and the network may be handled in the CN240. Session management signalling, such as bearer setup for SIPTO or LIPA traffic, and traffic going through the CN240may terminate in the CN240. Also, reselection of a WTRU's offload point for SIPTO traffic that is geographically or topologically close to the WTRU210may be possible during idle mode mobility procedures.

The SIPTO system may include a local gateway (L-GW) that is close to a WTRU's point of attachment to the access network. The L-GW may perform IP traffic offload based on some policy or configuration, for example, based on the IP address destination. IP traffic may go through the L-GW rather than through the operator's core network via, for example, an S-GW and a P-GW or via an SGSN and a GGSN (not shown).

Depending on the network technology, a local break point or local gateway may be in the HeNB subsystem or in a radio network controller (RNC). Also, the SGSN may be responsible for both control and user planes in some networks, while the user and control planes may be taken care of by a MME and an S-GW in others.

An L-GW, such as the L-PGW235, may have certain functionalities of a PDW/GGSN. For example, the L-GW may have the following functionalities: IP address allocation; direct tunneling with the RAN225in connected mode; per WTRU policy-based packet filtering; or rate policing/shaping. In order to perform SIPTO transfers to a network, such as a local network or Intranet, for example, a proper PDN connection may be required. A WTRU may set an access point name (APN) to a specific value when requesting a PDN connection or when requesting the establishment of a packet data protocol (PDP) context.

FIG. 3shows an example wireless network300configured to provide LIPA services. A WTRU310may be in communication with a HeNB320. The HeNB320may be collocated with an L-GW325. The HeNB320and the L-GW325may be located at a home network330. A MME335and an S-GW340may be located at the Evolved Packet Core (EPC)345. A Security Gateway (SeGW)350may be located at the edge of an operator's core network. The SeGW350may maintain a secure connection with the HeNB320across an IP backhaul network355. A Home Router/NAT device360may be located at a boundary of the home network330and the IP backhaul network355. A P-GW365is also shown.

The L-GW325may communicate with the S-GW340over an S5 interface370. The WTRU310may be paged by sending a packet (for example, a downlink user packet or any other packet) to the L-GW325over the S5 interface370. Downlink user packets may be buffered in the L-GW325. Packets buffered at the L-GW325may be forwarded to the HeNB320over a direct link. The HeNB320may communicate with the S-GW340over an S1-U interface375. Packets buffered at the S-GW340may be forwarded to the HeNB320over the S1-U interface375. The MME335may communicate with the HeNB320over an S1-MME interface380. Communications over the S5 interface370, the S1-U interface375, and the S1-MME interface380may be tunneled via an IPSec Tunnel385.

To perform mapping of enhanced radio access bearer (E-RAB) IDs at the HeNB320with the Evolved Packet System (EPS) Bearer IDs at the L-GW325, the S5 interface370P-GW tunnel endpoint identifier (TEID) (user plane) parameter may be used as correlation information. For example, the TEID may be signaled across the S1-MME interface380to the HeNB320. Candidate messages may include an INITIAL CONTEXT SETUP REQUEST, an E-RAB SETUP REQUEST, or the like. IKEv2 mechanisms may be used to request one IP address each for the HeNB320and the L-GW325function. The assigned L-GW address may be signaled to the MME335via the S1-MME interface380in, for example, WTRU-associated signaling messages. The MME335may use the information from the HeNB320to override the normal L-GW325selection algorithm. The S-GW340may communicate with the P-GW365over an S5 interface370. The S-GW340may communicate with the MME335over an S11 interface390.

FIG. 4shows an example of a wireless network400configured to perform SIPTO or LIPA services. A WTRU405may communicate with one of a plurality of HeNBs4101 . . . n. The WTRU405and the plurality of HeNBs4101 . . . nmay be located at an Enterprise Network415. An L-GW420is also located at the Enterprise Network415. Each of the HeNBs4101 . . . nmay be in communication with the L-GW420. The L-GW420may also be in communication with the Internet425. Each of the HeNBs4101 . . . nmay be in communication with an MME430over an S1-MME interface435. Each of the HeNBs4101 . . . nmay also be in communication with an S-GW440and a P-GW445over an S1-U interface450. The S-GW440and the P-GW445may be collocated. The MME430, the S-GW440, and the P-GW445may be located at a Mobile Operator Network455. An eNB460may be in communication with the MME430over an S1-MME interface435and may be in communication with the S-GW440and P-GW445over an S1-U interface450. The eNB460may be located at an LTE Macro Network465.

Traffic offload may be performed at the L-GW420. In addition to being in communication with the Internet425, the L-GW420may be in communication with Enterprise IP Services470. The traffic offload may be performed from the WTRU405through the HeNBs4101 . . . nand the L-GW420to the Internet425. As shown inFIG. 4, the WTRU405may handover from one HeNB4102to another HeNB4101and may continue to perform traffic offload via the L-GW420.

As shown inFIG. 4, a HeNB subsystem may support SIPTO to provide access from the WTRU405connected via a HeNB4101 . . . nvia HeNB radio access to a network, such as the Internet425. SIPTO may be performed without traversing the Mobile Operator Network455. A mobile operator or a HeNB hosting party may enable or disable SIPTO on a HeNB-by-HeNB basis. Based on SIPTO policies set by, for example, the mobile operator, the network may be able to allow a user of the WTRU405to accept or decline offload before traffic is offloaded. SIPTO policies may be defined per APN, per IP Flow class under any APN, or per IP Flow class under a specific APN. The mobile operator may configure the SIPTO policies either statically or dynamically.

As shown inFIG. 4, the WTRU405, in communication with at least one HeNB4101 . . . n, may have a LIPA connection that provides an IP connection to the Enterprise IP Services470. The WTRU405may also have a SIPTO connection that is offloaded at a RAN, via the L-GW420, to the Internet425. Thus, inFIG. 4, the L-GW420is at the RAN and is standalone. Therefore, in this example, SIPTO for use with the HeNB subsystem may be offloading IP traffic from the HeNB subsystem to the Internet. Thus, SIPTO service may be “closer” to the WTRU because it is available at the RAN. In other examples, traffic offload may be available beyond the RAN.

FIG. 5shows an example of a wireless network500that includes a plurality of Local H(e)NB Networks (LHNs). The wireless network500may be configured to perform SIPTO or LIPA services.FIG. 5shows a plurality of H(e)NBs5101-n, two L-GWs5201-2, and two Packet Data Networks (PDNs)5301-2. In the example shown inFIG. 5, the plurality of H(e)NBs5101-nand the two L-GWs5201-2comprise two LHNs5401-2. As described above in detail, each of the L-GWs5201-2is not collocated with each of the H(e)NBs5101-n, which may allow continuity of a PDN connection as a WTRU (not shown) moves between the coverage area of more than one of the H(e)NBs5101-n. Thus, multiple H(e)NBs5101-nmay connect to one of the L-GWs5201-2. As an example, the wireless network500may allow a WTRU (not shown) with a SIPTO or LIPA PDN connection to move between any of the H(e)NBs5101-n(referred to, for example, as an H(e)NB subsystem) while maintaining the PDN connection with SIPTO or LIPA services. As shown inFIG. 5, each LHN5401,5402may include one L-GW5201,5202, and each L-GW5201,5202may be in communication with at least one of the H(e)NBs5101-n. If a WTRU moves away from one of the LHNs5401,5402(for example, the WTRU moves out of the coverage of all H(e)NBs5101-3that connect to one L-GW5201), the PDN connection for SIPTO or LIPA services may be deactivated.

FIG. 6shows an example600of WTRU mobility among one or more H(e)NBs that connect to the same L-GW. The L-GW605may be in communication with one or more H(e)NBs6101-n. Each of the one or more H(e)NBs6101-nmay be in communication with one or more WTRUs6151-n. For example, at a particular time, a WTRU6151may be in communication with a first H(e)NB6101. The WTRU6151may in communication with the L-GW605via the first H(e)NB6101. The WTRU6151may be receiving services (including, for example, SIPTO and/or LIPA services) from the L-GW605. The potential communication paths are shown inFIG. 6. The WTRU6151may disconnect from the first H(e)NB6101and may, at some point in time, connect to a second H(e)NB6102(shown as WTRU6152). The WTRU6152may be in communication with the L-GW605via the second H(e)NB6102. Because the second H(e)NB6102may be in communication with the L-GW605, the WTRU6152may receive and/or resume services that the WTRU6152was previously receiving via the first H(e)NB6101. The potential communication paths are shown inFIG. 6. The services may include SIPTO and/or LIPA services to allow for SIPTO and/or LIPA service continuity, for example, after a handover. The change in the communication paths based on mobility of the WTRU6152is also shown via for example, the arrows shown inFIG. 6. Similarly, the WTRU6152may handover to a third H(e)NB6103(shown as WTRU6153) and may receive or resume services from the L-GW605via the third H(e)NB6103. The WTRU6153may handover to a fourth H(e)NB6104(shown as WTRU6154) and may receive or resume services from the L-GW605via the fourth H(e)NB6104.

The examples and architecture shown inFIG. 6are for purposes of example, and other combinations of nodes, devices, or handovers are possible. For example, a WTRU may receive services from one or more H(e)NBs at a particular time and may connect and/or disconnect from the H(e)NBs in any order at any time.

FIGS. 7-12show examples of architectural structures for supporting an L-GW in a wireless network. an L-GW may be a standalone L-GW or a standalone L-GW located along an S1/Iu path. The examples shown inFIGS. 7-12may be applicable to any technology, such as, for example but not limited to, LTE or UMTS systems or wireless networks.

FIG. 7shows an example wireless network700with a standalone logical L-GW configured to provide SIPTO or LIPA services. The L-GW705may be used, for example, as part of a HeNB subsystem. The L-GW705may be in communication with a HeNB710over an Sxx interface715. The L-GW705may also be in communication with an S-GW720over an S5 interface725. A SeGW730is shown between the L-GW705and the S-GW720and the SeGW730may maintain a secure connection between the L-GW705and the S-GW720. The L-GW705may also communicate with any other node or device over an SGi interface735.

The HeNB710may also be in communication with a WTRU740over a Uu interface745. The HeNB710may be in communication with the S-GW720over an S1-U interface750. The SeGW730is shown between the HeNB710and the S-GW720and may maintain a secure connection between the HeNB710and the S-GW720. A HeNB-Gateway (HeNB-GW)755is also shown between the HeNB710and the S-GW720and may maintain a secure connection between the HeNB710and the S-GW720. The HeNB710may be in communication with an MME760over an S1-MME interface765. The SeGW730is shown between the HeNB710and the MME760and may maintain a secure connection between the HeNB710and the MME760. The HeNB-GW755is also shown between the HeNB710and the MME760and may maintain a secure connection between the HeNB710and the MME760. The HeNB710may also communicate with any other node or device over an X2 interface770. The S-GW720and the MME760may be in communication over an S11 interface775.

FIG. 8shows an example wireless network800with a standalone logical L-GW configured to provide SIPTO or LIPA services. The L-GW805may be used, for example, as part of an HNB subsystem. The L-GW805may be in communication with an HNB810over an Sxx interface815. The L-GW805may also be in communication with an S-GW820over an S5 interface825. A SeGW830is shown between the L-GW805and the S-GW820and the SeGW830may maintain a secure connection between the L-GW805and the S-GW820. The L-GW805may also communicate with any other node or device over an SGi interface835.

The HNB810may also be in communication with a WTRU840over a Uu interface845. The HNB810may be in communication with the S-GW820. The SeGW830is shown between the HNB810and the S-GW820and may maintain a secure connection between the HNB810and the S-GW820. An HNB-Gateway (HNB-GW)855is also shown between the HNB810and the S-GW820and may maintain a secure connection between the HNB810and the S-GW820. The HNB810may communicate with the HNB-GW855over an Iuh interface850. The HNB-GW855may communicate with the S-GW820over an Iu-UP interface860. The HNB810may be in communication with an S4-SGSN865. The SeGW830is shown between the HNB810and the S4-SGSN865and may maintain a secure connection between the HNB810and the S4-SGSN865. The HNB-GW855is also shown between the HNB810and the S4-SGSN865and may maintain a secure connection between the HNB810and the S4-SGSN865. As described above, the HNB810may communicate with the HNB-GW855over an Iuh interface850. The HNB-GW855may communicate with the S4-SGSN865over an Iu-CP interface870. The HNB810may also communicate with any other node or device over an Iurh interface875. The S-GW820and the S4-SGSN865may be in communication over an S4 interface880.

FIG. 9shows an example wireless network900with a standalone logical L-GW configured to provide SIPTO or LIPA services. The L-GW905may be used, for example, as part of a UMTS system. The L-GW905may be in communication with an HNB910over an Sxx interface915. The L-GW905may also be in communication with an SGSN920over a Gn interface925. A SeGW930is shown between the L-GW905and the SGSN920and the SeGW930may maintain a secure connection between the L-GW905and the SGSN920. The L-GW905may also communicate with any other node or device over a Gi interface935.

The HNB910may also be in communication with a WTRU940over a Uu interface945. The HNB910may be in communication with the SGSN920. The SeGW930is shown between the HNB910and the SGSN920and may maintain a secure connection between the HNB810and the SGSN920. An HNB-GW955is also shown between the HNB910and the SGSN920and may maintain a secure connection between the HNB910and the SGSN920. The HNB910may communicate with the HNB-GW955over an Iuh interface950. The HNB-GW955may communicate with the SGSN920over an Iu interface960. The HNB910may also communicate with any other node or device over an Iurh interface965.

FIG. 10shows an example wireless network1000configured to provide SIPTO or LIPA services with a standalone logical L-GW located along an S1/Iu path. The L-GW1005may be used, for example, as part of a HeNB subsystem. The L-GW1005may be in communication with a HeNB1010over an S1-U interface1015and/or an S1-MME interface1020. Thus, the L-GW1005may be located in a path between the HeNB1010and an S-GW1025and an MME1030. The L-GW1005may be in communication with the S-GW1025via the S1-U interface1015and in communication with the MME1030via the S1-MME interface1020. A SeGW1035and a HeNB-GW1040are shown between the L-GW1005and the S-GW1025, and the SeGW1035and HeNB-GW1040may maintain a secure connection between the L-GW1005and the S-GW1025. The SeGW1035and the HeNB-GW1040are shown between the L-GW1005and the MME1030, and the SeGW1035and HeNB-GW1040may maintain a secure connection between the L-GW1005and the MME1030. The L-GW1005may also communicate with the S-GW1025over an S5 interface1045. The SeGW1035may be between the L-GW1005and the S-GW1025over the S5 interface1045. The L-GW1005may also communicate with any other node or device over an SGi interface1050.

The HeNB1010may be in communication with a WTRU1055over a Uu interface1060. The HeNB1010may also be in communication with any other node or device over an X2 interface1065. The S-GW1025and the MME1030may be in communication over an S11 interface1070.

FIG. 11shows an example wireless network1100configured to provide SIPTO or LIPA services with a standalone logical L-GW located along an S1/Iu path. The L-GW1105may be used, for example, as part of an HNB subsystem. The L-GW1105may be in communication with an HNB1110over an Iuh interface1115. Thus, the L-GW1105may be located in a path between the HNB1110and an S-GW1125and an S4-SGSN1130. A SeGW1135and an HNB-GW1140are shown between the L-GW1105and the S-GW1125, and the SeGW1135and HNB-GW1140may maintain a secure connection between the L-GW1105and the S-GW1125. The L-GW1105may communicate with the HNB-GW1140over the Iuh interface1115. The SeGW1135and the HNB-GW1140are shown between the L-GW1105and the S4-SGSN1130, and the SeGW1135and HNB-GW1140may maintain a secure connection between the L-GW1105and the S4-SGSN1130. The L-GW1105may also communicate with the S-GW1125over an S5 interface1145. The SeGW1135may be between the L-GW1105and the S-GW1125over the S5 interface1145. The L-GW1105may also communicate with any other node or device over an SGi interface1150.

The HNB1110may be in communication with a WTRU1155over a Uu interface1160. The HNB1110may also be in communication with any other node or device over an Iurh interface1165. The HNB-GW1140may communicate with the S-GW1125over an Iu-UP interface1170. The HNB-GW1140may communicate with the S4-SGSN1130over an Iu-CP interface1175. The S-GW1125and the S4-SGSN1130may be in communication over an S4 interface1180.

FIG. 12shows an example wireless network1200configured to provide SIPTO or LIPA services with a standalone logical L-GW located along an S1/Iu path. The L-GW1205may be used, for example, as part of a UMTS HNB subsystem. The L-GW1205may be in communication with an HNB1210over an Iuh interface1215. Thus, the L-GW1205may be located in a path between the HNB1210and an SGSN1225. A SeGW1235and an HNB-GW1240are shown between the L-GW1205and the SGSN1225, and the SeGW1235and HNB-GW1240may maintain a secure connection between the L-GW1205and the SGSN1225. The L-GW1205may communicate with the HNB-GW1240over the Iuh interface1215. The L-GW1205may also communicate with the SGSN1225over a Gn interface1245. The SeGW1235may be between the L-GW1205and the SGSN1225over the Gn interface1245. The L-GW1205may also communicate with any other node or device over a Gi interface1250.

The HNB1210may be in communication with a WTRU1255over a Uu interface1260. The HNB1210may also be in communication with any other node or device over an Iurh interface1265. The HNB-GW1240may communicate with the SGSN1225over an Iu interface1270.

One skilled in the art will recognize that the examples shown inFIGS. 7-12are for exemplary purposes only. The nodes and elements shown (and the corresponding names) are for exemplary purposes and one skilled in the art will recognize that any node or interface capable of performing similar functions may be used. Further, the architectures shown are for purposes of example and other combinations of nodes and interfaces are possible.

In order to facilitate WTRU mobility and SIPTO/LIPA services based on the architecture described above, one or a combination of the following may be used. Initial system access, including cell search, attachment, and detachment, is described herein. A WTRU acquiring information about an L-GW and its Local Home eNB Network (LHN) to allow SIPTO and LIPA services is also described. Maintaining desired service continuity as a WTRU moves among HeNBs or out of the LHN is also described.

Methods and apparatus are described for improving identification and authorization of WTRUs and services with independent L-GWs and LHNs that support LIPA and SIPTO services. Further, methods for improving WTRU cell search and reselection are described. For example, a SIPTO and/or LIPA supporting-LHN may be identified by a WTRU. Rules and configuration details to allow a WTRU to locate and find an LHN access point to enable SIPTO and/or LIPA services are described. In addition, WTRU attach procedure details for network registration to the LHN and/or HeNB for LIPA and SIPTO are also described.

Methods and apparatus for identifying SIPTO and/or LIPA service continuity areas (SCAs) are described. For WTRUs moving between cells belonging to the same LHN and/or beyond the LHN, methods for service continuity for SIPTO and/or LIPA are provided. A WTRU (for example, a WTRU in Idle mode) may support the SIPTO/LIPA service continuity while the WTRU moves between cells and potentially between LHNs. In connected mode, for example, in an X2 handover case, the system may also determine whether the target cell may support the SIPTO/LIPA continuity before the handover is performed and before the core network (CN) initiates a path switch.

Resolutions to security issues associated with using an International Mobile Subscriber Identity (IMSI) or Mobile Subscriber ISDN Number (MSISDN) in a message are described. For example, the WTRU IMSI may be included in a CREATE SESSION REQUEST message to the L-GW from the MME if the WTRU has sent an ATTACH REQUEST to the MME. Since the L-GW may not be under direct control of the operator, the L-GW may need information related to the user. To protect the user's privacy and identity at the L-GW, WTRU-IDs such as, for example, the IMSI or the MSISDN may be protected or excluded from being included in the CREATE SESSION REQUEST message sent by the MME during the WTRU ATTACH procedure to enable SIPTO and/or LIPA services. Accordingly, methods are described for protecting user information at the L-GW.

A WTRU may reestablish or resume SIPTO and/or LIPA services after a Radio Link Failure (RLF). The WTRU may re-connect to another cell or HeNB and may re-establish the connection that existed between the old HeNB and the L-GW between the new HeNB and the L-GW.

Methods and apparatus for distinguishing and identifying the different reasons for an unsuccessful WTRU ATTACH REQUEST for SIPTO and/or LIPA to the MME are described. The MME may be in communication with the L-GW for admission details and the MME may provided a reason for an unsuccessful ATTACH procedure. For example, an L-GW in a LHN may accept a user's SIPTO request, but reject its LIPA request. Thus, special failure codes and/or cause/reason codes may be included in, for example, the Create Session Response Message. The L-GW may therefore be able to indicate the possible rejection that affected the WTRU ATTACH REQUEST outcome. Further, based on the type of rejection, the MME may use policies to handle the rejections and identify the rejection to the WTRU. LHN access permission rules are specified for WTRU handling such as, for example, updating any of the LHN Lists.

If a network wants to relocate the WTRU's bearer or the WTRU's current SIPTO bearers to an L-GW (for example, if the WTRU is not currently under an H(e)NB cell under the LHN/L-GW), the network may try to handover the WTRU to an H(e)NB within the LHN and then trigger a detach procedure and then a reattach procedure. A WTRU may not be able to select to the same cell for the re-attach procedure and WTRU may select to a cell that does not belong to the intended LHN. Methods and apparatus are described to avoid relocation failures and to allow network triggering of relocated SIPTO and/or LIPA services.

An H(e)NB may be connected to multiple LHNs or multiple L-GWs. This may occur in the case of RAN sharing or, for example, femto network sharing in public areas. It may also occur in the context of multiple carriers or multiple RATs with different carriers or RATs mapped to different LHNs. Another example is an enterprise scenario in which multiple groups of employees are in a meeting, but the groups belong to different LHNs. Methods and apparatus are described herein to allow basic access or specific service access to different LHNs through the same H(e)NB. The methods and apparatus may be applied during security and access privilege differentiation.

As an L-GW is powered up, the L-GW may inform the H(e)NB-GW that the L-GW is now available at a particular IP address and therefore may allow the HNB-GW to provide service and core network connectivity for the L-GW and possibly to the H(e)NBs connected to the L-GW. Also, since the L-GW is connected to multiple H(e)NBs, the L-GW may act as an H(e)NB aggregator. For example, if an L-GW goes down and then comes back up, the individual H(e)NB under the L-GW may re-register to the core network (via, for example, the H(e)NB-GW) or the L-GW may act as an aggregator and register its H(e)NBs toward the H(e)NB-GW.

The methods described below may apply to several system areas and/or procedures and the examples described herein are for exemplary purposes only. For example, the examples may relate to Radio Resource Control (RRC), Non-Access Stratum (NAS), or any other combination or layer. Further, the methods may be applied in combination with any other solution under any other system area.

A WTRU may be configured to find, search for, identify, or locate a LHN. To attach to a specific LHN, one or a combination of the following may be used. A LHN configuration may be broadcast or published. The WTRU may perform a LHN search. The LHN search may be a manual search. The WTRU may perform a LHN cell selection.

The WTRU may search for its LHN to support LIPA services. A network node or system may broadcast a LHN ID in a system information block (SIB) from one or more cells that are within the LHN. The WTRU may search for a LHN as an access point for its LIPA access and/or SIPTO offload point, for example, for charging or any other purpose. For example, LIPA-ALLOWED and/or SIPTO-ALLOWED flags may be added to an SIB. The flags may indicate, for example, LIPA and/or SIPTO capability of the Closed Subscriber Group (CSG) and/or LHN to member WTRUs. Hybrid cells that may support LIPA and SIPTO services for non-member WTRUs may broadcast a LIPA-ALLOWED-NONMEMBER and/or a SIPTO-ALLOWED-NONMEMBER flag in its SIB to indicate the LIPA and SIPTO capability of the CSG and/or LHN to non-member WTRUs attempting to access the hybrid cell. For example, these capability flags may be added to any message, for example SIB-1. Table 1 shows an example of a message that includes a LHN-id field, a SIPTO-ALLOWED field, a SIPTO-ALLOWED-NONMEMBER field, a LIPA-ALLOWED field, and a LIPA-ALLOWED-NONMEMBER field.

A CSG may include H(e)NBs belonging to different LHNs. Also, one LHN may span across multiple CSGs. A WTRU may search for a LHN for SIPTO or LIPA service based on a “LHN List” provided to and/or stored by the WTRU. A WTRU may only be allowed to use the SIPTO and/or LIPA services (and other derivative services) over the LHNs that have their LHN-Id included in this LHN list. The LHN List may be used to manage the list of allowed LHN IDs, Operator LHN IDs, and/or related restricted access information at a WTRU. This information may be stored, for example, in the WTRU's Universal Subscriber Identity Module (USIM) or in a non-volatile memory in the WTRU, as well as at the operator's core network in, for example, a Home Location Register (HLR)/Home Subscriber Server (HSS). A WTRU may receive a message and/or indication from a cell or H(e)NB that includes information related to a LHN. The message and/or indication may also include other information, such as for example, SIPTO/LIPA service information or identification information. The WTRU may compare any of the received information or indications with information stored in one or more LHN Lists stored at the WTRU. The WTRU may perform cell selection or reselection based on the comparison.

A WTRU may receive and/or maintain one or more CSG Lists. For example, a WTRU may maintain a CSG white list or Allowed CSG List that may include the CSG identities of CSGs that the WTRU belongs to or for which access has been granted to the WTRU. Any of the CSG Lists may include a list of allowed or previously visited CSGs or cells. CSG Lists may be received by a WTRU, for example, from upper layers or upon successful access to a CSG cell. One or more CSG Lists may be stored in the WTRU, for example in a USIM or a non-volatile memory. The WTRU may maintain and/or update the CST Lists. A WTRU may receive a message and/or indication from a cell or CSG that includes a CSG ID. The WTRU may compare the received CSG ID with CSG IDs included in one or more CSG Lists stored at the WTRU. The WTRU may perform cell selection or reselection based on the comparison. The CSG List may also include or comprise a HNB or H(e)NB List that includes a list of one or more HNBs or H(e)NBs.

An LHN List may include sublists. For example, sublists may include an “Allowed LHN List” and an “Operator's LHN List.” As referred to herein, the phrase “LHN List” may include the Allowed LHN List and/or the Operator's LHN List as well as any other sublist within the LHN List. The LHN operator, an end user, and/or any operator may manage the Allowed LHN List. The Allowed LHN List may include, for example, LHN membership granted by the LHN operator and identified and/or verified by an end user. The Allowed LHN List may also include the Operator's LHN List. The Allowed LHN List may be used, for example, in a manual LHN search. The Operator's LHN list may be managed by the service operator. The Operator's LHN List may include, for example, the LHNs that a WTRU is allowed to access. The Operator's LHN List may be used, for example, for an automatic LHN search. Any of these lists may include additional lists or elements.

FIG. 13shows an example of an LHN List object. The LHN List may be, for example, an LHN list with sublists such as the Allowed LHN List and the Operator's LHN List. Similarly, the LHN List may be any list or sublist described herein. The LHN List object shown inFIG. 13may therefore also represent an Allowed LHN List. Referring toFIG. 13, AllowedLHNEntries may include a Public Land Mobile Network ID (PLMN_ID) and/or LHN-entries. The LHN-entries may include, but are not limited to, LHN_ID, NET_CAPABILITY, or USER_CONSENT. The NET_CAPABILITY element may indicate, for example, the LHN's capability to support SIPTO and/or LIPA service. Thus, the NET_CAPABILITY element may include values such as, for example, LIPA, SIPTO, or BOTH. The USER_CONSENT element may indicate, for example, user consent for SIPTO and/or LIPA service for a particular LHN. The USER_CONSENT element may include values such as, for example, LIPA, SIPTO, or BOTH. The USER_CONSENT element may also be defined, for example, per LHN, per APN, and/or per QoS. OperatorLHNEntries may include a PLMN_ID and/or LHN-entries. The LHN-entries may include, but are not limited to, LHN_ID, NET_CAPABILITY, or USER_CONSENT. The NET_CAPABILITY element may indicate, for example, the LHN's capability to support SIPTO and/or LIPA service. Thus, the NET_CAPABILITY element may include values such as, for example, LIPA, SIPTO, or BOTH. The USER_CONSENT element may indicate, for example, user consent for SIPTO and/or LIPA service for a particular LHN. The USER_CONSENT element may include values such as, for example, LIPA, SIPTO, or BOTH. The USER_CONSENT element may also be defined, for example, per LHN, per APN, and/or per QoS. Any extensions (shown by, for example, the “EXT” node) based on the nodes and leaf objects described herein are understood to be within the contents of this example. For example, the EXT node may include vendor-specific information. The EXT node may include one or more sublists or sub-trees. One skilled in the art will recognize that the names given are for purposes of example only.

If a WTRU receives an Allowed LHN List Management Object (MO) via, for example, the OMA DM Access including the Allowed LHN List, the WTRU may update its Allowed LHN List. The Allowed LHN List may be stored at the WTRU, for example, in a USIM or in a non-volatile memory in the WTRU, as described above. If a WTRU receives an Operator's LHN List Management Object (MO) via, for example, the OMA DM Access including the Operator LHN List, it may update the Operator LHN List stored in, for example, the USIM or non-volatile memory.

A combined manual LHN and CSG cell selection procedure may be performed. A WTRU may perform a manual LHN selection procedure, for example during power-up, a user-intervention, or any other programmed trigger, such as a WTRU entering a LHN proximity area. In a manual LHN selection procedure, a WTRU, with an indication from the NAS, may scan the available bands, find relevant or available cells, and/or indicate a list of available LHNs to the user along with, for example, associated CSG IDs and PLMNs. Selection criteria for available LHNs may be sent to the WTRU, for example, by an end user, via NAS signaling, or as defined in the USIM. The criteria may include one or a combination of the following. A LHN ID may be broadcasted by a suitable cell found by the WTRU. A LHN ID may be broadcasted by a suitable cell found by the WTRU, wherein the LHN ID is in one of the WTRU's LHN Lists, for example the Allowed LHN and/or the Operator LHN list. A LHN ID may broadcasted by a suitable cell found by the WTRU, wherein the LHN ID is in the WTRU's Operator LHN List. A LHN ID may be broadcasted by a suitable cell found by the WTRU, wherein the LHN ID is in the WTRU's LHN List and the cell is either a hybrid cell or a closed CSG cell whose CSG ID is included in the WTRU's CSG List, for example either the Allowed CSG or the Operator CSG list. A LHN ID may be broadcasted by a suitable cell found by the WTRU, wherein the LHN ID is included in the WTRU's Operator LHN List and the cell is either an hybrid cell or a closed CSG cell whose CSG ID is included in the WTRU's CSG list, for example the Allowed CSG or the Operator CSG list. A LHN ID may be broadcasted by a suitable cell found by the WTRU, wherein the LHN ID is included in the WTRU's Operator LHN List and the cell is either a hybrid cell or a private CSG cell whose CSG ID is included in, for example, the WTRU's Operator CSG List

For each entry in any list, a WTRU may indicate to a user any or a combination of the following information. The WTRU may indicate the LHN ID. Alternatively or additionally, the WTRU may indicate the LHN group and/or whether or not the LHN is in the Operator LHN List or the Allowed LHN List. Alternatively or additionally, the WTRU may indicate the access cell type. The WTRU may indicate whether the cell is a hybrid cell for which the WTRU is not a member and/or whether the hybrid cell supports LHN access for non-members. The WTRU may indicate the WTRU is a member of a CSG cell. The WTRU may also indicate the CSG ID or the CSG ID group and/or whether the CSG cell is included in an Operator CSG List or an Allowed CSG List and/or whether the CSG cell is included in the CSG white list. Alternatively or additionally, the WTRU may indicate the SIPTO and/or LIPA capability of a cell.

A user may select a LHN from the indicated LHNs. If the WTRU has a PDN connection for emergency bearer services, manual LHN selection may not be performed. If the user makes a selection, the WTRU may attempt to camp on a cell with the selected LHN identity and may attempt to register from the cell to the associated PLMN.

Access Stratum (AS) layer action may be used to support LHN selection (for example, manual LHN selection). To support manual LHN selection, the AS layer of the WTRU, for example, on the request from the NAS, may scan some or all RF channels in the configured bands according to the WTRU's capabilities to find available LHN IDs. On each carrier, the WTRU may at least search for the strongest cell, read system information of the strongest cell, and/or report available LHN ID(s) together with the PLMN(s) and/or CSG ID to the NAS. The search for available LHN IDs may be stopped on request from the NAS.

A specific LHN search may also be supported in the AS layer of the WTRU. If the NAS provides a LHN ID and/or CSG ID(s) to the AS, the AS may search for an acceptable or a suitable cell belonging to the selected LHN ID and CSG ID(s) and may camp on or access that cell. If the NAS provides the LHN ID to the AS, the AS may search for an acceptable or suitable cell that broadcasts the selected LHN ID and/or belongs to a CSG group that is included in the WTRU's CSG white list. The WTRU may perform registration via the specific LHN cell.

If a user selects a LHN in a PLMN that is different from the Registered PLMN (RPLMN), one or a combination of the following may be performed. The WTRU may store a duplicate of the RPLMN and a duplicate of the current PLMN selection mode. The WTRU may enter into Manual mode for PLMN selection and may select the PLMN corresponding to the LHN. The WTRU may attempt to register on the selected LHN cell in the PLMN. If the registration fails or the WTRU is no longer within the coverage of the LHN, the WTRU may return to the stored duplicate PLMN selection mode and use the stored duplicate value of RPLMN for further action. If the registration succeeds, the WTRU may perform one or a combination of the following, depending on the cell that the WTRU camps on. If the camped cell is not included in the LHN list, the WTRU may add that cell or LHN to the Allowed LHN List. If the camped cell is not included in the CSG list, the WTRU may add the cell to the Allowed CSG list. If the registration fails, one or more of the following actions may be performed by the WTRU, for example, depending on the return code. If the return code indicates that LHN access is not allowed, the LHN ID may be removed from the Allowed LHN List. The LHN ID may be added to the Forbidden LHN List. If the return code indicates that the LHN is temporarily unavailable, the WTRU may wait for a configured or predetermined time before allowing a retry. LHNs in the Forbidden LHN List may also be indicated to the user upon a LHN manual selection process. LHNs may be removed from the list, for example, upon power off or during a successful manual selection and registration.

LHN cell reselection may also be performed. If a WTRU does not have a PDN connection to an L-GW that belongs to a LHN, the WTRU may follow any cell reselection procedure. For an IDLE mode WTRU that has or had a PDN connection to an L-GW belonging to a LHN, special idle mode cell reselection may be used to keep the SIPTO and/or LIPA PDN connection alive.

Cell selection from a LHN cell may be performed. If a WTRU has or had a PDN connection to an L-GW belonging to a LHN and/or the WTRU has camped on a suitable LHN cell (for example, the cell belongs to the LHN), and if the WTRU detects another LHN cell which ranks higher, the WTRU may reselect to the detected LHN cell. The WTRU may optionally not reselect to a non-LHN cell regardless of the rank of the cell. Alternatively or additionally, to reduce interference, the targeted LHN cell may need to be the highest ranked LHN cell on that frequency to be considered for reselection. If the radio condition of the cell that WTRU is camped on is lost or deteriorated, and if WTRU cannot find a suitable LHN cell, the WTRU may reselect to any suitable cell. After the WTRU camps on the non-LHN cell, the WTRU may maintain its local PDN connection (for example, the PDN connection to the LHN) to allow the WTRU to go back to a LHN cell. The WTRU may supply the L-GW information (for example, L-GW@LN, L-GW@CN, or correlation-Id) via the new cell, for example, to allow the supporting network to reroute the WTRU's connectivity and/or traffic to the original L-GW.

Cell selection may be performed from a non-LHN cell. If a WTRU has had a PDN connection to an L-GW belonging to a LHN and/or if the WTRU is currently camped on a cell that does not belong to the LHN, the WTRU may use an autonomous search function to detect LHN cells. The LHN cells may include at least those allowed LHN cells that the WTRU has previously visited on serving or non-serving frequencies, including, for example, inter-RAT frequencies. Any of the above may be performed alone or in combination with normal cell reselection.

If the WTRU has detected one or more suitable LHN cells on different frequencies, then the WTRU may reselect to one of the detected cells based on the ranking of those cells and/or LHN ID property. This may be performed, for example, irrespective of the frequency priority of the cell the WTRU is currently camped on. If the WTRU has detected a suitable LHN cell on the same frequency, the WTRU may reselect to that cell. Alternatively or additionally, the targeted LHN cell may be considered the highest ranked cell on that frequency. For example, this may reduce interference.

LHN cell selection and/or reselection may be triggered by an event. If a WTRU is paged from a LHN and the WTRU is currently camped on a non-LHN cell or a different LHN cell, the network may trigger the WTRU to search and reselect to a cell belonging to a LHN. The network may also trigger the WTRU to search and reselect to a cell belong to a LHN on behalf of a remote application or based on SIPTO needs. The network may use, for example, a NAS or RRC message to inform the WTRU of the LHN and/or the CSG group that the network wants the WTRU to camp on or connect to. If the WTRU receives the network message, the WTRU may release its RRC connection and select or reselect to a cell according to network's request. Optionally, certain events from the WTRU may also trigger a LHN cell selection or reselection. This may include, for example, a user's desire to do a local printing or any other local task.

A user preference may be defined and indicated by the WTRU. For example, if a WTRU is camped on a LHN cell, it may indicate to the network a preference for using LHN as its access point, for example, to the internet and/or its preference to access the LHN during an attach procedure or for a PDN connectivity procedure. A user preference may be indicated, for example, in an ESM INFORMATION RESPONSE message. A WTRU may include, for example, a LHN ID in the ESM INFORMATION RESPONSE if the user prefers to access a LHN network or access the APN via the LHN. The WTRU may indicate its preference for a LIPA service by setting the LHN ID and the APN to be the LHN's APN. If the WTRU prefers offloading its traffic on the LHN, it may set the LHN ID to the LHN that the WTRU prefers to use for offloading and may set the APN to the traffic that it would like to offload. Table 2 shows an example of an ESM INFORMATION RESPONSE that includes a LHN Identity information element.

Alternatively or additionally, a user preference may be indicated in a PDN CONNECTIVITY REQUEST message. If a user prefers to have a PDN connection to a LHN, the APN may be set to the APN of the LHN and the LHN-Identity may be set to LHN-ID. If the user prefers to establish a new PDN connection and prefers the new PDN connection to be offloaded via the LHN, the APN may be set to the APN the user prefers to establish the PDN connection with and/or the LHN-identity may be set to the LHN-ID of the preferred offload point. Table 3 shows an example of a PDN CONNECTIVITY REQUEST message that includes a LHN Identity information element.

A user's network preference may also be included in an ATTACH REQUEST. If the LHN-ID is present in the ATTACH REQUEST message, the network may establish the default PDN connection via an L-GW of the specified LHN. Table 4 shows an example of an ATTACH REQUEST message that includes a LHN Identity information element.

The information element “Local Home Network” may be in the form of a LHN-Identifier or in any other form. If one H(e)NB may only belong to one LHN, the LHN-ID may be implicitly specified if a WTRU indicates a preference for SIPTO service. A WTRU may also include a Preferred_SIPTO_Point in a PDN CONNECTIVITY REQUEST message for a new PDN connection. Alternatively or additionally, a Preferred_SIPTO_Point may be included in an ATTACH COMPLETE message. The LHN-ID for the local home network for which the WTRU is requesting connectivity may be added to an ATTACH REQUEST message or a PDN CONNECTIVITY REQUEST message sent, for example, with the ATTACH REQUEST. The LHN-ID may be included as an information element.

SIPTO and/or LIPA service continuity may be supported. The SIPTO/LIPA service continuity may be supported outside the LHN cells in the Service Continuity Area (SCA). Providing WTRUs and/or the network with SIPTO/LIPA service continuity information and where it may be maintained may help make the cell reselection and/or handover decisions in idle mode and/or in connected mode, respectively. The Service Continuity Area may be defined by one or more of the following items in any combination. For example, the SCA may be defined as a list of cell IDs, a list of CSG IDs, a list of area IDs, such as, for example, Tracking Area Identities (TAIs), and/or a list of PLMN IDs. A WTRU may acquire the SCA either by reading a system information broadcast or by being informed via messages, such as for example, dedicated RRC messages or NAS messages. Alternatively or additionally, the SCA information provided to a WTRU may include information related to only nearby relevant neighboring cells within the reach of a WTRU for cell reselection or a handover measurement scan range, either adjacent or close to the current cell. This may conserver signaling space. To maintain SIPTO/LIPA service continuity, WTRUs in Idle mode may use the SCA information to facilitate the cell reselection. Alternatively or additionally, WTRUs in connected mode may use the SCA information for mobility measurements.

SIPTO/LIPA service continuity may be maintained in Idle mode. A WTRU that does not have a PDN connection to an L-GW belonging to a LHN may follow normal cell reselection procedures. An IDLE mode WTRU that has had a PDN connection to an L-GW belonging to a LHN may use special idle mode cell reselection to keep the SIPTO/LIPA PDN connection alive.

Cell selection may be performed from a cell in the SCA. If a WTRU has had a PDN connection to an L-GW belonging to a LHN and/or the WTRU is camped on a suitable SCA cell (for example, the cell supports SIPTO/LIPA service continuity to the LHN) and/or if the WTRU detects another SCA cell that ranks higher than the current cell, the WTRU may reselect to the detected SCA cell. The WTRU may not reselect to a non-SCA cell regardless of how highly that cell is ranked. Alternatively or additionally, reselection candidacy may include a rule such that the targeted SCA cell may need to be the highest ranked cell on that frequency. This may reduce interference. If the radio condition of the cell that the WTRU is camped on is lost or deteriorated and/or if the WTRU cannot find a suitable SCA cell, the WTRU may reselect to any suitable cell. If the WTRU camps on the non-SCA cell, the WTRU may maintain its local PDN connection (for example, a PDN connection to the LHN). This may allow the WTRU to go back to SCA coverage. Alternatively or additionally, the WTRU may supply the L-GW information (for example, L-GW@LN, L-GW@CN, or correlation-Id) via the new cell to allow the network to reroute the WTRU's connectivity and/or traffic to the original L-GW.

Cell selection may be performed from a cell outside the SCA. For example, if a WTRU has had a PDN connection to an L-GW belonging to a LHN and if the WTRU is currently camped on a cell that is not in SCA coverage, the WTRU may use an autonomous search function to detect at least previously visited and/or allowed SCA cells on serving or non-serving frequencies, which may include inter-RAT frequencies. This may be performed alternatively or in addition to normal cell reselection.

If the WTRU has detected one or more suitable SCA cells on different frequencies, the WTRU may reselect to one of the detected cells irrespective of the frequency priority of the cell that the WTRU is currently camped on. To reduce interference, further restriction may be used if the concerned LHN cell is the highest ranked cell on that frequency. If the WTRU detects a suitable SCA cell on the same frequency, it shall reselect to this cell. To reduce interference, further restriction may be applied if the concerned SCA cell is the higher ranked cell than the current cell on that frequency.

WTRU-requested LHN PDN Connectivity may be performed without using an IMSI and/or MSISDN. To protect user privacy, if a WTRU requests LHN PDN Connectivity, the MME/Network may not include the WTRU's IMSI or MSISDN in the corresponding message (for example, a CREATE SESSION REQUEST message) sent to the L-GW of the requested LHN. The MME may request a temporary IMSI (T_IMSI) and/or a temporary MSISDN (T_MSISDN) from a HSS and may use the T_IMS1and T_MSISDN in the message for creating PDN connectivity with an L-GW. The HSS may store the T_IMSI and/or T_MSISDN. The stored T_IMSI and/or T_MSISDN may be released if the LHN PDN Connectivity is released.

Connectivity may be restored between the new HeNB and the L-GW after radio link failure (RLF). A WTRU may acquire the L-GW's correlation ID, which may include, for example, the L-GW@CN, the L-GW@LN, and/or Tunnel Endpoint Identifiers (TEIDs), during an attach procedure. This may be acquired via, for example, the ATTACH ACCEPT message if the WTRU attached to an L-GW. The L-GW's correlation ID may also be acquired during the PDN CONNECTIVITY REQUEST procedure, via for example, a PDN Connectivity Accept message if the WTRU activates a PDN connection at L-GW. During a NAS signaling connection recovery procedure, a WTRU may provide the L-GW's correlation ID (and optionally the L-GW@CN) to the serving eNB and the serving eNB may restore the S-XX interface towards the L-GW without going through the Core Network.

A WTRU may want to register to the network via an ATTACH REQUEST with SIPTO and/or LIPA capabilities enabled with the support of other CN PLMN services. The WTRU may be interested in the LHN services, but perhaps not any PLMN services (for example, the location services or MBMS services) except for control plane signaling. The WTRU may transmit an ATTACH REQUEST to the network with a type indicating, for example, “LHN Service only” and the LHN-ID of the LHN.

A WTRU's ATTACH REQUEST for LHN access may be rejected by the network for various reasons. A rejection may be caused by the user's related subscription or may be related in the MME/L-GW interaction process if the L-GW fails to honor the MME request due to, for example, local security issues. This may include scenarios in which the L-GW may have certain autonomous operational restrictions to WTRUs or to a particular WTRU. This may include, for example, a downgraded access privilege level. The L-GW rejection or grant with restriction may result in an MME response (such as an ATTACH REJECT) to the WTRU ATTACH REQUEST. The non-successful ATTACH results may be indicated to the WTRU in the return code, for example, by indicating “Access to the L-GW denied,” “Access to the L-GW expired,” “L-GW is temporarily unavailable,” or the like. In the case of access denial or expiration, the LHN-Id may need to be removed from the Allowed LHN List. If the L-GW is unavailable, the WTRU may refrain from accessing the same L-GW for a configured/predetermined time period.

A SIPTO/LIPA-connected WTRU may require a minimum level of service integrity. If there is an active local access, for example a LIPA service, that is ongoing and a WTRU-initiated detach is started, the Detach procedure may need to wait (for example, with a timer) for the completion of the ongoing local access. If the timer expires, the user of the WTRU may be alerted and may be prompted to wait or stop the local access and continue the Detach procedure. The MME may Detach and re-attach the WTRU if one or more of the following conditions are true. The MME may Detach and re-attach if the L-GW is out of service and the WTRU has attached to both PLMN and LIPA services. In this example, the MME may re-attach the WTRU to a P-GW for PLMN service until the L-GW is recovered. Alternatively or additionally, the MME may detach and re-attach the WTRU to the L-GW if the L-GW is recovered.

The network may trigger SIPTO and/or LIPA with a detach/reattach procedure. To support network-triggered SIPTO or LIPA bearer relocation from a core network to a LHN and/or L-GW, an indication may be included in a DETACH REQUEST message. If the detach type is, for example, “re-attach required,” the network may specify a “Reattach Target.” The Reattach Target may be one or more of the following: the current cell; a cell ID; a group of Cell IDs; a LHN ID; a CSG ID; and/or a group of CSG IDs. Table 5 shows an example of a DETACH REQUEST message that includes a Reattach Target information element.

If a WTRU receives a DETACH REQUEST with a detach type of re-attach required that includes the Reattach Target IE, the WTRU may attempt to search for cell(s) whose identity or identities are indicated in the Reattach Target IE. The WTRU may perform a (re)attach procedure after the WTRU has selected a cell belonging to the Reattach Target.

RAN sharing and EPLMN support may be provided with LHNs. In one example, traffic and signaling from multiple LHNs or L-GWs may be transmitted or received through a common cell. In another example, a cell may broadcast a list of supported LHN IDs. If multiple LHNs are broadcasting information, additional flags may be provided in, for example, SIB1as described above. The flags may be in the form of a list and the number of entries may match the number of supported LHNs. For example, if a WTRU selects a cell and initiates a connection (for example, at the RRC level or NAS level) toward the network, the WTRU may indicate to the network the selected LHN ID or any other LHN and/or L-GW related attribute to help the network correlate the WTRU to the LHN or the L-GW. In another example, the H(e)NB may store the LHN ID as part of the WTRU context information and may use this information to correctly route signaling related to this WTRU to the appropriate LHN or L-GW. This may be performed upon reception of, for example, the RRC CONNECTION REQUEST message or any other equivalent message. The H(e)NB may use the LHN information stored in the WTRU context to identify the correct LHN or L-GW for which to establish the bearers for the WTRU.

In another example, the WTRU may use the LHN ID or any other attribute or related flag to indicate the WTRU's preference or need to establish a SIPTO and/or LIPA connection, or to switch the existing PDN connections (for example, a SIPTO PDN connection) to the L-GW. These may be performed upon detection of a LHN or L-GW that the WTRU belongs to. In another example, the WTRU may report its LHN Identification or any other related information upon configuration of the network. Alternatively or additionally, the WTRU may autonomously report the LHN Identification or any other related information.

In another example, the WTRU may perform access control taking into account the LHN membership and/or the CSG membership. In one example, the WTRU is a member and may access the cell if the WTRU is a member of the CSG and the LHN, meaning that the WTRU has this LHN associated with the CSG in the WTRU's white list. In another example, the WTRU may be a member and may access the cell if the WTRU has the association of the CSG, the PLMN (or equivalent PLMN), and/or the LHN in the WTRU's white list. The operator may have control over the list of the PLMNs in the white list and the associated CSGs. The host party may have control over the associated LHNs. The LHN list may be uploaded to the operator as part of the LHN or L-GW registration procedure. In another example, access to SIPTO/LIPA may be controlled at the WTRU or the network based on the cell's CSG ID, one or several of the broadcasted LHN IDs, or the broadcasted PLMN ID being on the WTRU's white list.

The examples described above, while presented under the scenario of RAN sharing or femto network sharing by multiple LHNs or L-GWs are not to be limited to only such scenarios and are applicable to any other example or embodiment described herein and for use with any other SIPTO or LIPA service.

L-GW registration and/or multi-H(e)NB registration may be performed. As the L-GW is powered up, there may be a need for the L-GW to inform the H(e)NB-GW that the L-GW is now available at a particular IP address. The L-GW may also need to enable the HNB-GW to provide service and core network connectivity for the L-GW and possibly to the H(e)NBs connected to the L-GW. Because the L-GW may be connected to multiple H(e)NBs, the L-GW may act as an H(e)NB aggregator in some instances. For example, if an L-GW shuts down and then is powered up or turned on, the individual H(e)NB under the L-GW may need to be re-registered to the core network (via for example the H(e)NB-GW) or the L-GW may act as an aggregator and register its H(e)NB with the H(e)NB-GW. Each H(e)NB may maintain an individual Iuh connection with the H(e)NB-GW or Iuh aggregation may occur between the L-GW and the H(e)NB-GW.

The L-GW Registration Procedure may allow the L-GW to register with the H(e)NB-GW or another node in the core network such as, for example, the MME, the S-GW, or the SGSN. This may enable the H(e)NB-GW to provide service and core network connectivity for the HNB. If supported and configured, this may also enable Iurh connectivity via the H(e)NB-GW. This procedure may be triggered after the Iuh, Sxx, or S1 signaling transport has been successfully established and may optionally be the first procedure triggered after establishment. For Iuh, Sxx, or S1 signaling transport, there may be one signaling transport instance between the L-GW and the core network in support of all attached H(e)NBs. In another example, there may be a one-to-one mapping between the signaling transport bearer from any given H(e)NB to the L-GW, and from the L-GW to the core network (for example, the H(e)NB-GW).

FIG. 14shows an example call-flow diagram1400for a successful L-GW register procedure. An L-GW1405and an H(e)NB-GW1410are shown, although any other nodes or elements may be used in the procedure. The L-GW1405may send an L-GW REGISTER REQUEST1420to the H(e)NB-GW1410. The L-GW REGISTER REQUEST1420may be sent by the L-GW1405if the L-GW1405needs to commence operations and/or requires service from a core network (not shown) via, for example, the H(e)NB-GW1410. The L-GW1405may provide its LHN ID and/or transport layer address during the registration process and the LHN ID and/or transport layer address may be included in the L-GW REGISTER REQUEST1420. The L-GW1405may provide a capability, such as for example, support for SIPTO and/or LIPA services, or any restrictions with respect to SIPTO and/or LIPA services. The L-GW1405may include any capability information in the L-GW REGISTER REQUEST1420.

An HNB (not shown) may provide a list of attached H(e)NBs and/or the operational parameters included in an HNB REGISTRATION REQUEST message. As described in the examples forFIGS. 14-17, an HNB REGISTRATION REQUEST may be used instead of or in addition to an L-GW REGISTER REQUEST. An HNB and/or an L-GW may register with a core network and/or HNB-GW to provide services to a WTRU within the HNB and/or L-GW. For example, an HNB may register directly with the core network/HNB-GW and/or the L-GW may register one or more HNBs. Thus, the L-GW may include any features of the HNB REGISTER REQUEST in the L-GW REGISTER REQUEST or any other L-GW message described herein, and vice versa. If the L-GW1405supports direct interface relocation to other L-GWs (not shown), the L-GW1405may provide the direct interface signaling Transport Network Layer (TNL) Address IE to the core network (via H(e)NB-GW1410) in, for example, the L-GW REGISTER REQUEST1420.

If the registration is successful, the core network (via H(e)NB-GW1410) may respond by transmitting an L-GW REGISTER ACCEPT1430message. The L-GW REGISTER ACCEPT1430message may indicate acceptance and registration. The acceptance and/or registration may include configurations for SIPTO and/or LIPA support. If a list of attached H(e)NBs is included in the L-GW REGISTER ACCEPT1430message (or, for example, an HNB REGISTRATION REQUEST message), the core network may indicate the registration result (for example, accept or reject) for each of the attached H(e)NBs in the L-GW REGISTER REQUEST1420message. If the direct interface signaling TNL Address IE is included in the L-GW REGISTER ACCEPT1430message, the L-GW1405may, if supported, establish a transport layer session to the indicated address to support direct connectivity via the H(e)NB-GW1410. If the H(e)NB-GW1410is capable of de-multiplexing, then a MuxPortNumber IE may be included in the L-GW REGISTER ACCEPT1430message.

One skilled in the art will recognize that the messages described above with respect toFIG. 14may be any type of message and the information included in each of the messages may be included in any type of message. Similarly, the messages may be transmitted in any order and not only in the order described in the example above.

FIG. 15shows an example call-flow diagram1500for an unsuccessful L-GW register procedure. An L-GW1505and an H(e)NB-GW1510are shown, although any other nodes or elements may be used in the procedure. The L-GW1505may send an L-GW REGISTER REQUEST1520to the H(e)NB-GW1510. The L-GW REGISTER REQUEST1520may be sent by the L-GW1505if the L-GW1505needs to commence operations and/or requires service from a core network (not shown) via, for example, the H(e)NB-GW1510. The L-GW1505may provide its LHN ID and/or transport layer address during the registration process and the LHN ID and/or transport layer address may be included in the L-GW REGISTER REQUEST1520. The L-GW1505may provide a capability, such as for example, support for SIPTO and/or LIPA services, or any restrictions with respect to SIPTO and/or LIPA services. The L-GW1505may include any capability information in the L-GW REGISTER REQUEST1520.

An HNB (not shown) may provide a list of attached H(e)NBs and/or the operational parameters included in an HNB REGISTRATION REQUEST message. If the L-GW1505supports direct interface relocation to other L-GWs (not shown), the L-GW1505may provide the direct interface signaling TNL Address IE to the core network (via H(e)NB-GW1510) in, for example, the L-GW REGISTER REQUEST1520.

If the registration is unsuccessful, the core network (via H(e)NB-GW1510) may respond by transmitting an L-GW REGISTER REJECT1530message (or an HNB REGISTER REJECT message) to the L-GW1505. A typical cause value for unsuccessful registration may include radio network layer causes, such as for example, unauthorized location, unauthorized attached HNB, overload, L-GW parameter mismatch (for example, a capability mismatch considering the service level agreement between the operator and the host party of the L-GW), or an unspecified cause. Any of these causes may be included in the L-GW REGISTER REJECT1530message as a cause IE. For example, if the cause IE is set to “overload,” the HNB may not retry registration to the same H(e)NB-GW1510for at least the duration indicated by, for example, a Backoff Timer IE.

One skilled in the art will recognize that the messages described above with respect toFIG. 15may be any type of message and the information included in each of the messages may be included in any type of message. Similarly, the messages may be transmitted in any order and not only in the order described in the example above.

If a core network (via for example, an H(e)NB-GW) receives a duplicate L-GW REGISTER REQUEST message (for example, for an already registered L-GW identified by the same unique L-GW identity or LHN identity), the new L-GW REGISTER REQUEST message may override the existing registration. The handling of the new L-GW REGISTER REQUEST message may be performed according to the examples described above.

FIG. 16shows an example call-flow diagram1600for an L-GW deregistration procedure that originates at the L-GW. An L-GW1605and an H(e)NB-GW1610are shown, although any other nodes or elements may be used in the procedure. The L-GW1605may determine that it needs to terminate operations with the H(e)NB-GW1610. The L-GW1605may optionally terminate connections with attached H(e)NBs before initiating termination with the H(e)NB-GW1610. The L-GW1605may transmit an L-GW DE-REGISTER1620message to the H(e)NB-GW1610. If the core network (not shown) receives the L-GW DE-REGISTER1620message (via the H(e)NB-GW1610), the core network may clear all related resources associated with the L-GW1605. Cause values for the de-register process may include radio network layer causes, such as for example, normal or unspecified. The cause values may be included in, for example, the L-GW DE-REGISTER1620message.

One skilled in the art will recognize that the messages described above with respect toFIG. 16may be any type of message and the information included in each of the messages may be included in any type of message. Similarly, the messages may be transmitted in any order and not only in the order described in the example above.

FIG. 17shows an example call-flow diagram1700for an L-GW deregistration procedure that originates at the H(e)NB-GW. An L-GW1705and an H(e)NB-GW1710are shown, although any other nodes or elements may be used in the procedure, such as those shown inFIGS. 7-12. The core network (not shown) (via the H(e)NB-GW1710) may determine that it needs to terminate operations with the L-GW1705. The core network (via the H(e)NB-GW1710) may transmit an L-GW DE-REGISTER1720message to the L-GW1705. The core network may clear all related resources associated with the L-GW1705. Cause values for the de-register process may include radio network layer causes, such as for example, overload or unspecified causes. The cause values may be included in IEs in, for example, the L-GW DE-REGISTER1720message. If the cause IE in the L-GW DE-REGISTER1720message is set to “overload,” the L-GW may not retry registration to the same H(e)NB-GW1710for at least the duration indicated by, for example, a Backoff Timer IE.

One skilled in the art will recognize that the messages described above with respect toFIG. 17may be any type of message and the information included in each of the messages may be included in any type of message. Similarly, the messages may be transmitted in any order and not only in the order described in the example above.

Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element may be used alone or in combination with any of the other features and elements. In addition, the embodiments 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, a cache memory, a semiconductor memory device, a magnetic media, (e.g., an internal hard disc or a removable disc), a magneto-optical media, and an optical media such as a compact disc (CD) or a digital versatile disc (DVD). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, Node-B, eNB, HNB, HeNB, AP, RNC, wireless router or any host computer. Although examples are described with respect to a WTRU and/or a user, one of ordinary skill in the art will appreciate that either the WTRU or a user may perform the features or elements described in the examples.