WO2015120048A1

WO2015120048A1 - System and method for populating closed subscriber group lists

Info

Publication number: WO2015120048A1
Application number: PCT/US2015/014459
Authority: WO
Inventors: John Cartmell; Kenneth F. Lynch; Jun Li; Alexander Reznik; Nicholas J. Podias; Ulises Olvera-Hernandez
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2014-02-04
Filing date: 2015-02-04
Publication date: 2015-08-13
Anticipated expiration: 2016-08-04

Abstract

Methods, apparatuses, and systems are disclosed for populating closed subscriber group (CSG) lists based on contact lists. The owner of a small cell may enable the CSG list associated with the small cell to be populated by allowing access to a contact list. Wireless transmit receive units (WTRUs) owned by people on the contact list may be added to the CSG list to permit access to the small cell. The contact list may be a contact list residing on the owner's mobile phone, a contact list associated with a social media account, a contact list associated with an app account, etc.

Description

SYSTEM AND METHOD FOR POPULATING CLOSED SUBSCRIBER

GROUP LISTS

CROSS REFERENCE TO RELATED APPLICATIONS

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

No. 61/935,701 filed on February 4, 2014, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] Closed Home eNode Bs (H(e)NBs) may be an example of a closed femtocell. A closed H(e)NB may restrict access to those subscribers who are expressly permitted access. Hybrid H(e)NBs may be an example of a hybrid femtocell. An H(e)NB may allow access to all users, but may give preferential treatment, e.g., higher data rates or lower latency, to specific subscribers. An Open H(e)NB may be an example of an open femtocell. An open H(e)NBs may allow access to all users.

[0003] Each H(e)NB may have a unique ID, which may allow for identification of a specific H(e)NB. Each closed or hybrid H(e)NB entity, or group thereof, may have a Closed Subscriber Group (CSG) ID.

[0004] Each WTRU may maintain two lists related to access control of closed and hybrid femtocells. The first, the Allowed CSG List, may be under end-user control. This may allow a user to enter the ID of a H(e)NB/CSG it wishes to access. The second, the Operator CSG List, may be under network control. This may allow the network operator to control which femtocells a user device may connect to. Access to a femtocell may be based on Operating Rules (OR) of these two lists. For example, a user may be able to access a closed or hybrid femtocell if that femtocell's ID or CSG ID is on one of the two lists within the WTRU. While the Operator CSG List and the Allowed CSG List may be depicted and/or described as two separate lists, it should be understood that one management object may be used to store one list with two different sections. An example of one list with two different sections is described in 3^rd Generation Partnership Project (3GPP) Technical Specification (TS) 24.285. The lists may be stored on the universal subscriber identity module (USIM) of the device and may be updated by procedures defined in 3GPP TS 31.111.

[0005] An access check may be done in the network to ensure that only

UEs may augment their Allowed CSG List with identities of authorized femtocells. If an access check is not performed, any end-user may augment their Allowed CSG List to include any femtocell ID, allowing the end-user the ability to gain access to any femtocell on the CSG List. This would obviate the fundamental concept of a closed or hybrid femtocell. In order to perform an access check, a list may be maintained either in the core network, within the H(e)NB itself, within the H(e)NB Gateway or within some other network element. This list may contain which users are allowed to connect to each cell. The form of this list may be in a variety of arrangements. It may be indexed by CSG ID and may list which subscribers can connect to each CSG ID, or it may be indexed by user and may list the allowed CSG IDs for each user.

SUMMARY

[0006] Embodiments of methods and apparatuses for populating an operator closed subscriber group (CSG) list are disclosed. In one example, the Operator CSG list is populated from the contact list of a wireless transmit/receive unit (WTRU). The method may comprise a server that receives an authorization message from a WTRU. The authorization message may indicate that contacts on the contact list of the WTRU are authorized to access a small cell. The server may send a request to the WTRU for the contact list to be sent to the server. The WTRU may send the contact list to the server. Upon receipt of the contact list, the server may determine which contacts on the WTRU's contact list are also subscribers to the core network. The server may update the network-based Operator CSG list with the contacts that are determined to be subscribers to the core network.

[0007] Embodiments of methods and apparatuses for populating an

Operator CSG list using a contact list from a social media website or application are also disclosed. Embodiments of methods and apparatuses for populating an Operator CSG list using small cell services are disclosed. Embodiments of methods and apparatuses for updating Operator CSG lists on non- subscriber devices are also disclosed. Embodiments of methods and apparatuses for removing contacts from a CSG list are also disclosed. Embodiments of methods and apparatuses for controlling access to a machine- to-machine (M2M) gateway and M2M sensor network using a contact list from a social media website or application are also disclosed.

[0008] An embodiment of populating a CSG list may include a method of populating the CSG list and Home evolved Node B (H(e)NB), which may include an H(e)NB server, for executing the method. The H(e)NB may include a transmitter, a receiver, and a processor for executing the method. The method may include receiving an access contact list. The method may further include updating a network-based CSG list to allow one or more wireless transmit receive units (WTRUs) corresponding to respective one or more phone numbers from the access contact list to access the H(e)NB. The access contact list may include at least one of a contact list residing on an owner WTRU, a social media network account contact list, an email account contact list, and an app account contact list.

[0009] In another embodiment of populating a CSG list, the method may include receiving an association between the owner WTRU and the H(e)NB.

[0010] In another embodiment of populating a CSG list, the method may include receiving a key for pulling the access contact list from a contact source, wherein the access contact list is associated with the owner WTRU. The method may further include transmitting the key to the contact source.

[0011] In another embodiment of populating a CSG list, the method may include determining one or more international mobile subscriber identities (IMSIs) based on respective one or more phone numbers from the access contact list and updating the network-based CSG list to allow the respective one or more WTRUs based on the one or more IMSIs.

[0012] In another embodiment of populating a CSG list, method may include transmitting an update to an Operator CSG list residing on each of the one or more WTRUs that are attached to a same core network as the H(e)NB server. [0013] In another embodiment of populating a CSG list, a WTRU including a transmitter, a receiver, and a processor may transmit login information to log into an account, the account having a contact list including the one or more contacts. The WTRU may further receive a key corresponding to the account. The WTRU may further transmit the key to a server of the small cell to enable the server to receive the contact list and populate the network-based CSG List with identities corresponding to WTRUs owned by the one or more contacts.

[0014] In another embodiment of populating a CSG list, the identities corresponding to the WTRUs may be IMSIs.

[0015] In another embodiment of populating a CSG list, the account may be one of a social media network account, an email account, and an app account.

[0016] In another embodiment of populating a CSG list, the small cell may correspond to a Home evolved Node B (H(e)NB).

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

[0019] 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;

[0020] 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;

[0021] FIG. 2 is a diagram of an example network deployment;

[0022] FIG. 3 is a depiction of an example network topology for populating an Operator CSG list population via an end-user contact list; [0023] FIG. 4 is an example message sequence chart for populating an

Operator CSG list population via an end-user contact list;

[0024] FIG. 5 is a depiction of an example network topology for populating an Operator CSG list population via an end-user social media contact list;

[0025] FIGs. 6 and 7 are an example message sequence chart of a direct method for populating an Operator CSG list population via an end-user social media contact list;

[0026] FIGs. 8 and 9 are an example message sequence chart of a indirect method for populating an Operator CSG list population via an end- user social media contact list;

[0027] FIG. 10 is a depiction of an example femtozone API network topology for populating Operator CSG lists via Small Cell Services;

[0028] FIG. 11 is an example message sequence chart for populating

Operator CSG lists via Small Cell Services;

[0029] FIG. 12 is a depiction of an example network topology for updating the Operator CSG list on non- subscriber devices in an inter core network;

[0030] FIG. 13 is an example message sequence chart for updating the

Operator CSG list on non- subscriber devices in an inter core network;

[0031] FIG. 14 is an example message sequence chart for updating the

Operator CSG list on non- subscriber devices in an inter core network;

[0032] FIG. 15 is a depiction of an example network topology for depopulating Operator CSG lists via end-user contact lists;

[0033] FIG. 16 is an example message sequence chart for de-populating

Operator CSG lists via end-user contact lists;

[0034] FIG. 17 is a depiction of an example network topology for depopulating Operator CSG lists via end-user social media contact lists;

[0035] FIG. 18 is an example message sequence chart for de-populating

Operator CSG lists via end-user social media contact lists;

[0036] FIG. 19 is a diagram of an example method for accessing an M2M sensor network-based on social media contacts; and [0037] FIG. 20 is a diagram of an example method for accessing an M2M

Gateway based on social media contacts.

DETAILED DESCRIPTION

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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).

[0043] 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).

[0044] 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).

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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).

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] A WTRU may maintain one or more Closed Subscriber Group

(CSG) lists to track which small cells the WTRU may access. Though the embodiments described herein may reference an H(e)NB, one should appreciate that any cell, including any small cell, may equivalently apply. For example, a CSG may be stored to track access to a Node B, eNode B, H(e)NB, small cell, femtocell, a macrocell, or any other type of cell for which a CSG list may apply. Therefore, a reference to a specific type of cell in any of the embodiments herein is meant as an example and the embodiment should not be construed to be restricted to only the example cell described in the embodiment.

[0068] The CSG lists may be maintained in the WTRU for efficiency reasons. For example, if a WTRU knows that it cannot access a specific cell, instead of camping on it and then having the network reject the initial attachment, the WTRU may read the broadcast channel, decode the cell ID and compare it to the lists within the WTRU. If the cell ID is not on the allowed or operator lists, then the WTRU may not attempt to attach to it.

[0069] While there may be a standard defined method for populating the

Operator CSG List in the WTRUs there is no standard defined procedure on how the operator of a CSG causes these updates to occur. Current methods may involve the operator of a CSG logging into a website within the mobile core network for the management of the CSG list and manually adding or removing whichever users and/or their WTRUs they wish to grant/deny access. In an example embodiment of a method and system for populating a CSG list, the core network or WTRU of the femtocell owner/administrator/operator may contact a social media site to take advantage of contact lists within social media sites.

[0070] Conventionally, the owner or administrator of a small cell (or cluster of small cells) manually enters the information for population of the CSG list maintained in the H(e)NB or in the core network. The update of the WTRUs allowed access to this small cell (or small cell cluster) would be done manually by the end-user of each WTRU updating his or her Allowed CSG List or having the core network push updates to each end-user's Operator CSG List using Open Mobile Alliance (OMA) Device Management (DM) as defined in 3GPP TS 31.111. The use of manual updates has a high potential for introducing errors.

[0071] An example embodiment of a network deployment utilizing a social media site for CSG list population is shown in FIG. 2. Referring to FIG. 2, there may be a small cell network that is comprised of one H(e)NB 222 that may be owned by the end-user of WTRU A 221. This end-user may have a contact list 223 on his/her WTRU. There may be a single core network, for example an evolved packet core (EPC) 214. The H(e)NB 222 may connect to the EPC 214 via serving gateway (SeGW) 213. There may be a server, for example H(e)NB Owner server 215, in the EPC 214 dedicated to managing access to closed/hybrid femtocells that allows the owner or administrator to manage their small cell network. There may also be a macro network 230, with some users (WTRU B 231 and WTRU C 232). There may also be other users, e.g., (WTRU D 233), who are not subscribers of this operator's network. Each of these WTRUs may have both an Operator CSG List and an Allowed CSG List. There may also be a network list that may be maintained in either the core network or at the H(e)NB itself. For explanation purposes, the network list is assumed to be in the core network. However, the solutions described herein are applicable to any placement of the network list.

[0072] In addition, there may be a social media site, e.g., Linkedln, which may have a contact list 212 for each user. The contact list 212 may include the mobile number of each contact. So, for example, if the user of WTRU A 221 also has a Linkedln account and if he or she is connected to the user of WTRU B 231, then WTRU B's mobile number is in the Linkedln database. A Linkedln application program interface (API) 211 may be used to gain access to the Linkedln database. The storage of the mobile number of each user is not currently a requirement for being a member of Linkedln, but it may be a requirement for those users who want to take advantage of this service. The concepts described herein may utilize these contact lists as a source for a method described for populating the Operator CSG List of devices to manage access to closed and hybrid femtocells.

[0073] In another example embodiment of methods and apparatuses for populating Operator CSG Lists, contact lists on WTRUs are used to populate the Operator CSG Lists. In one example method, the contact list 323 on the WTRU A 321 of the small cell network owner is used as the source of which users should be allowed access to the closed or hybrid small cell network 320. The use case for this may be a residential deployment of a closed or hybrid small cell network, owned by an individual or a small enterprise where the small business owner may deploy a closed or hybrid femtocell. An example network topology is shown in FIG. 3. While the H(e)NB Owner Server 315 is shown as being within the EPC 314, it should be noted that it could be on the public Internet 310. In addition, the H(e)NB Owner Server may also be in the EPC 314 as a function in an existing node, such as a MME or HSS (not shown).

[0074] Referring to the example as shown in FIG. 3, the user of WTRU A

321, may own the small cell network and may own the H(e)NB 322. WTRU A 321 may be a subscriber of the EPC 314 and WTRU A's H(e)NB 322 may be connected to the same EPC 314. The contact list of WTRU A 321 may include both WTRU B 331 and WTRU D 333. In this example, the contact list may not include WTRU C 332. WTRU B 331, WTRU C 332, and WTRU D 333 may be subscribers on the same mobile network, but WTRU D 333 may not be currently connected to the network. WTRU D 333 may be out of the service area, or the device may be powered off, or any of any other myriad of reasons may cause the device not to be on the network.

[0075] The message sequence chart (MSC) for this use case as described with respect FIG. 3 is shown in FIG 4. Referring to FIG. 4, at 401, the subscriber of WTRU A 491 may obtain an H(e)NB 492 and set it up as a closed or hybrid femtocell.

[0076] At 402, WTRU A 491 may connect to a server in the core network. This server may be the H(e)NB Owner Server 493. An association between WTRU A 491 and H(e)NB 492 may be registered. There may be some type of authentication between the WTRU A 491 and the server 493 in the core network. This may prevent unauthorized individuals from connecting to the server 493 and saying they "own" the femtocell. Any method for authentication may be used.

[0077] At 403, WTRU A 491 may inform the server to allow its contact list to populate the Operator CSG List to allow the contacts of WTRU A 491 to have access to H(e)NB 492. Both 402 and 403 may be done using a webpage published by the server 493. The web page may have a known IP address (or fully qualified domain name (FQDN)) and the end user may contact the server 493 using this information.

[0078] At 404, the server 493 may contact WTRU A 491 to request the contact list. The contact list may be stored on the universal integrated circuit card (UICC) of the device, in read-only memory (ROM), or in both.

[0079] At 405, the WTRU A 491 may send the contact list to the server

493.

[0080] At 406, the server 493 may interact with nodes in the EPC 494 to determine which of these contacts are subscribers to the EPC. The server 493 may do so by using the mobile phone number. In this case, it may be determined that both WTRU B 495 and WTRU D 497 are subscribers to this network. [0081] At 407, the H(e)NB Owner Server 493 and the EPC 494 may collaborate to update the network-based CSG list for both WTRU B 495 and WTRU D 497.

[0082] At 408, the server 493 may interact with the nodes in the EPC

494 to locate both WTRU B 495 and WTRU D 497. In this example, since only WTRU B 495 is connected to the EPC 494, at 409, the server 493 may push an update to the Operator CSG List on WTRU B 495, adding the ID of H(e)NB 492. WTRU B 495 may now have access to H(e)NB 492. The server 493 may remember that it has yet to update WTRU D 497 and may wait for WTRU D 497 to connect to the EPC 494. Once WTRU D 497 connects, the Operator CSG List of WTRU D 497 may be updated by the server 493.

[0083] At 410, WTRU D 497 may attach to the network.

[0084] At 411, the server 493 may interact with the EPC 494 to determine the location of WTRU D 497.

[0085] Once the location of WTRU D 497 is determined, at 412, the server 493 may push an update of the Operator CSG List to WTRU D 497, adding the ID of H(e)NB 492. WTRU D 497 may now have access to H(e)NB 492. Note that in this example, WTRU C 496 may not be updated since it is not a contact in WTRU A 491. Of course, WTRU A 491 may grant access to WTRU C 496 via existing conventions.

[0086] While not shown, it is possible for this process to happen periodically in the background. The server 493 may periodically request the contact list from WTRU A 491 and update the Operator CSG List on the appropriate WTRUs, either adding the H(e)NB 492 ID for new contacts, or removing the H(e)NB 492 ID for deleted contacts as well as updating the list stored within the EPC 494. Furthermore, while not shown, an HSS may be the existing core network element to interact with the H(e)NB Owner Server 493.

[0087] As an alternative, an entity, owned/managed by the operator or a reseller, could provide the registration service shown by steps 401 through 405. This entity may pull the contact list from the WTRU A 491 and kick off steps 406 through 4012 as shown, using the contact list retrieved from the WTRU A 491.

[0088] It should be noted that though the MSC depicted in Figure 4 shows messages and/or steps in a particular order, it should be recognized that not all messages and/or steps may be necessary and the particular order may be different. Furthermore, whereas steps and/or messages may be depicted as separate events, the steps and/or messages may be combined as a single event. Likewise, a single event may be broken out into multiple events. For example, 402 and 403 may be reversed in order or may be combined as a single event. As another example, 408 may be broken out into two events where in a first event the network-based CSG list may be updated for WTRU B and in a second event the network-based CSG list may be updated for WTRU D, or vice versa. In another example, 406, 407, and 408 may be restructured such that in a first event the mobile phone number may be associated to the IMSI for WTRU B, the network-based CSG list for WTRU B may be updated, and WTRU B may be located, and in a second event the mobile phone number may be associated to the IMSI for WTRU D, the network-based CSG list for WTRU D may be updated, and WTRU D may be located, or vice versa.

[0089] Additional embodiments of methods and apparatuses for populating Operator CSG Lists using contact lists from a social media site are described herein. The following are two example embodiments of methods for populating the Operating CSG Lists. In the first example method, the core network may interact directly with the social media site to populate the Operator CSG List of users who will be allowed access to the closed or hybrid small cell. In the second example method, the core network and social media site may work indirectly, via the WTRU, to populate the Operator CSG List of users who will be allowed access to the closed or hybrid small cell. In either solution, the social media site contact list of the WTRU of the small cell network owner may be used as the source of which users should be allowed access to the closed or hybrid femtocell. An example use case for this is a residential deployment of a closed or hybrid femtocell, owned by an individual or a small enterprise where the small business owner may be deploying a closed or hybrid femtocell. An example network topology is shown in FIG. 5. While the H(e)NB Owner Server 515 is shown as being within the EPC 514, it may be on the public Internet 510. The H(e)NB Owner Server 515 may also be in the EPC 514 as a function in an existing node, such as an MME or HSS.

[0090] Referring to the example as shown in FIG. 5, user A 521- A of

WTRU A 521, may own the small cell network 520 and may own the H(e)NB 522. WTRU A 521 may be a subscriber of the EPC 514 and WTRU A's H(e)NB 522 may be connected to the same EPC 514 via SeGW 513. User A 521-A may also be a member of a social media site, e.g., Linkedln. User A 521-A may be connected via Linkedln with User B 531-B and User D 533-D. User A 521-A may not be connected to User C 533-C via Linkedln. WTRU B 531, WTRU C 532, and WTRU D 533 are subscribers on the same macro network 530, but WTRU D 533 may not be currently connected to the network. WTRU D 533 may be out of the service area, may be powered off, or any of the myriad of other reasons may cause WTRU D 533 not to be on their network.

[0091] Example MSCs for the example case where the core network interacts directly with the social media site to populate the Operator CSG List of users who will be allowed access to the closed or hybrid small cell are shown starting in FIG. 6 and continuing in FIG. 7.

[0092] Referring to FIG. 6, at 601, the owner of WTRU A 691 obtains and installs H(e)NB 692 at home or at an enterprise as a closed or a hybrid H(e)NB. WTRU A 691 may have an application for accessing a social media contact list via the social media API, for example, a Linkedln API 698.

[0093] At 602, WTRU A 691 may connect to a server 693. This server

693 may be called the H(e)NB Owner Server 693. The association between WTRU A 691 and H(e)NB 692 may be registered. Some type of authentication may be used between the WTRU A 691 and the server 693 to prevent a fraudulent user from connecting to the server 693 and saying he "owns" the femtocell. Any authentication method may be used. Step 602 may be done using a webpage published by the server 693. The web page may have a known IP address or FQDN and the server may be contacted using this information.

[0094] At 603, the WTRU A 691 may communicate with the Linkedln

API 698 to log into the Linkedln account of the owner of the femtocell.

[0095] At 604, the Linkedln API 698 may provide a key to be used by the application on the WTRU A 691 to pull the Linkedln account's contact list.

[0096] At 605, WTRU A 691 may forward the key for pulling the contact list to H(e)NB Owner Server 693.

[0097] At 606, the H(e)NB Owner Server 693 may contact Linkedln and provide the key received at 605 to the Linkedln API 698.

[0098] At 607, the Linkedln API 698 may provide the user's contact list to H(e)NB 692.

[0099] As noted previously, although the depicted MSC shows messages and/or steps in a particular order, it should be recognized that not all messages and/or steps may be necessary and the particular order may be different. Furthermore, whereas steps and/or messages may be depicted as separate events, the steps and/or messages may be combined as a single event. Likewise, a single event may be broken out into multiple events.

[0100] The example method continues in FIG. 7. At 708, the server 793 may interact with nodes in the EPC 794 to determine which of the contacts are subscribers to the core network. It may do so by using the mobile phone numbers of the respective contacts. In this example, it is determined that both WTRU B 795 and WTRU D 797 are subscribers to EPC 794.

[0101] At 709, the H(e)NB Owner Server 793 and the EPC 794 may collaborate to update the network-based CSG list for both WTRU B 795 and WTRU D 797.

[0102] At 710, the server 793 may interact with nodes in the EPC 794 to locate both WTRU B 795 and WTRU D 797.

[0103] In this case, since only WTRU B 795 is connected to the EPC 794, at 711, the server 793 may push an update to the Operator CSG List on WTRU B 795, adding the ID of H(e)NB 792. WTRU B 795 may now have access to H(e)NB 792. The server 793 may remember that it has yet to update WTRU D 797 and may wait for WTRU D 797 to connect to the EPC 794. Once connected, the Operator CSG List may updated by the server 793.

[0104] At 712, WTRU D 797 may attach to the EPC 794.

[0105] At 713, the server 793 may interact with the EPC 794 to determine the location of WTRU D 797.

[0106] Once WTRU D 797 is located, at 714, the server 793 may push an update of the Operator CSG List to WTRU D 797, adding the ID of H(e)NB 792. WTRU D 797 may now have access to H(e)NB 792. WTRU C 796 may not be updated since it is not a contact in WTRU A 791. Nonetheless, WTRU A 791 may grant access to WTRU C 796 via existing conventions.

[0107] While not shown, it is possible for this process to happen periodically in the background. The server could periodically request the contact list from WTRU A 791 and update the Operator CSG List on WTRUs, either adding the H(e)NB 792 ID for new contacts, or removing the H(e)NB 792 ID for deleted contacts. It may be necessary for the user to periodically log into Linkedln since the key provided originally may have an expiration date and time. Furthermore, while not shown, an HSS may be the existing element of EPC 794 to interact with the H(e)NB Owner Server 793.

[0108] As noted previously, although the depicted MSC shows messages and/or steps in a particular order, it should be recognized that not all messages and/or steps may be necessary and the particular order may be different. Furthermore, whereas steps and/or messages may be depicted as separate events, the steps and/or messages may be combined as a single event. Likewise, a single event may be broken out into multiple events.

[0109] Example MSCs for the example embodiment where the core network and social media site work indirectly, via the WTRU, to populate the Operator CSG List of users who may be allowed access to the closed or hybrid small cell, start on FIG. 8 and continue on FIG. 9.

[0110] Referring to FIG. 8, at 801, the owner of WTRU A 791 may obtain and install H(e)NB 892 at home or at an enterprise as a closed or a hybrid H(e)NB. The steps for this embodiment may be similar to the steps described in the previous section. However, there may also be some differences. First, the WTRU A 891 may have an application for accessing the Linkedln contact list via the Linkedln API 898.

[0111] At 802, the WTRU A 891 may connect to a server in the core network. This server may be called the H(e)NB Owner Server 893. An association between WTRU A 891 and H(e)NB 892 may then be registered. Some type of authentication between the end user and the server 893 may be used. This may prevent a fraudulent user from claiming ownership of the femtocell. Any authentication method may be used. Step 802 may be done, for example, using a webpage published by the server 893. The web page may have a known IP address or FQDN and the WTRU A 891 may contact the server 893 using this information.

[0112] At 803, WTRU A 891 may be used to communicate with the

Linkedln API 898 to log into a Linkedln account.

[0113] At 804, the Linkedln API 898 may provide a key to be used by the application on the WTRU A 891 to pull the Linkedln account's contact list.

[0114] At 805, the application within the WTRU A 891 may contact

Linkedln and provide the key received at 804 to the Linkedln API 898.

[0115] At 806, the Linkedln API 898 may provide the Linkedln account's contact list to WTRU A 891.

[0116] Upon receipt of the contact list, at 807, the WTRU A 891 may forward it to the H(e)NB Owner Server 893.

[0117] The example embodiment continues in FIG. 9. At 908, the server

993 may interact with nodes in the EPC 994 to determine which of the contacts are subscribers to the core network. It may do so by using the mobile phone numbers of the respective WTRUs. In this example, it is determined that both WTRU B 995 and WTRU D 997 are subscribers to the EPC 994.

[0118] At 909, the H(e)NB Owner Server 993 and the EPC 994 may collaborate to update the network-based CSG list for both WTRU B 995 and WTRU D 997.

[0119] At 910, the server 993 may interact with nodes in the EPC 994 to locate both WTRU B 995 and WTRU D 997. [0120] In this case, since only WTRU B 995 is connected to the network, at 911, the server may push an update to the Operator CSG List on WTRU B 995, adding the ID of H(e)NB 992. WTRU B 995 may now have access to H(e)NB 992. The server 993 may remember that it has yet to update WTRU D 997 and may wait for WTRU D 997 to connect to the network. Once connected, the Operator CSG List is updated by the server 993.

[0121] At 912, WTRU D 997 may attach to the EPC 994.

[0122] At 913, the server 993 may interact with the EPC 994 to determine the location of WTRU D 997.

[0123] Once WTRU D 997 is located, at 914, the server 993 may push an update of the Operator CSG List to WTRU D 997, adding the ID of H(e)NB 992. WTRU D 997 may now have access to H(e)NB 992. WTRU C 996 may not be updated since it is not a contact in WTRU A 991. Nonetheless, WTRU A 991 may grant access to WTRU C 996 via existing conventions.

[0124] While not shown, it is possible for this process to happen periodically in the background. The server 993 could periodically request the contact list from WTRU A 991 and update the Operator CSG List on WTRUs, either adding the H(e)NB 992 ID for new contacts, or removing the H(e)NB 992 ID for deleted contacts. It may be necessary for the user to periodically log into Linkedln since the key provided originally may have an expiration date and time. Furthermore, while not shown, an HSS may be the element of EPC 994 to interact with the H(e)NB Owner Server 993.

[0125] An alternative to both the indirect and direct methods described above with respect to FIGs. 8 and 9 may use an entity, owned/managed by the operator or a reseller, to manage the collection of the Linkedln contacts from the Linkedln API. This may replace steps 801/901 through 807/907 for both the direct and Indirect methods. The remainder of the steps for either method would continue as shown and described.

[0126] As noted previously, although the depicted MSC shows messages and/or steps in a particular order, it should be recognized that not all messages and/or steps may be necessary and the particular order may be different. Furthermore, whereas steps and/or messages may be depicted as separate events, the steps and/or messages may be combined as a single event. Likewise, a single event may be broken out into multiple events.

[0127] Another alternative may include Linkedln providing the contact list directly to the H(e)NB Owner Server. Linkedln may be the agent that sells the small cell to the end user (the business owner, for example, who wishes to deploy it in their enterprise) and may coordinate access using the information Linkedln already has. Linkedln may share this information with the H(e)NB Owner Server which may then facilitate the update of the appropriate CSG lists.

[0128] Another alternative may include the H(e)NB Owner Server being located within and managed by the Linkedln domain. This may allow for a proprietary interface between the H(e)NB Owner Server and the Linkedln API for the passing of contact list information to the H(e)NB Owner Server. Once the Linkedln H(e)NB Owner Server has this contact list information, it may then work with the EPC to ensure the proper CSG lists are updated accordingly.

[0129] In another embodiment, a method and system is disclosed of populating an Operator CSG List using Small Cell Services. A femtozone is a small cell network as defined by the Small Cell Forum. A femtozone may be comprised of some number of femtocells greater than zero and a femtozone gateway which sits at the edge of the femtozone. There may be multiple femtozone gateways. The femtozone gate way (s) may sit between the mobile core network and the femtocells. The Small Cell Forum has defined a set of APIs that the femtozone gateway may expose. These APIs may allow for reporting of which users are a part of a femtozone, user mobility, sending SMS or MMS to specific end user devices, as well as a list of other functions. Missing from these APIs is the ability to query or modify CSG lists located on WTRUs or located within the core network.

[0130] Disclosed herein is an example interface and signals over that interface to query a femtozone as to its CSG list and add or remove individual subscribers from a femtozone's CSG list. Further disclosed is an interface and signals over that interface to query a femtozone as to the Allowed and Operator CSG lists located on WTRUs attached through the femtozone.

[0131] Motivations for using these interfaces are many and not all are described herein. Purely by way of example, however, the following points may be considered. The API exposed by the femtozone GW may allow third party entities to learn where a device has been, allows for the sending of messages to a specific device, and many other features, but it fails to allow the most basic function of a cellular network — connectivity. An interface extension is described that allows an outside entity a stake in what users can connect to the femtozone (or other femtozones). The API extension disclosed herein may be used in numerous ways. For example, the extension may allow the owner of a femtozone to configure the CSG list for the femtozones they own. In addition, the extension may allow the owner of a femtozone to configure individual devices, for example, the WTRUs of subscribers to their social media site.

[0132] An example network topology of yet another embodiment of a system configured to populate a CSG list is shown in FIG. 10. This topology may support the API extension used as noted above. Referring to the example as shown in FIG. 10, there may be n femtozones in this network. A femtozone may connect to the EPC 1014 via a respective femtozone GW. The first, Femtozone 1 1020-1, may be open, while the rest are either Closed or Hybrid or some combination thereof. The femtozones may be owned by the 3rd party application server, e.g., Linkedln 1011. Since Femtozone 1 1020-1 is open, WTRU A 1021-1 can attach to it without restriction. The other femtozones may be available to WTRU A 1021-1 after both WTRU A 1021-1 and the EPC 1014 are provisioned to allow WTRU A access to the Closed and Hybrid cells.

[0133] FIG. 11 depicts an MSC that describes example embodiment of a method to populate a CSG List in the context of femtozones. Referring to FIG. 11, at 1101, the Social Media Site 1199 may use an existing API to subscribe to the services provided by the femtozone gateway 1193-1, those services being the reporting of user activity, which may consist of the comings and goings of WTRUs, on the femtozone. Since the femtozone corresponding to femtozone gateway 1193-1 is open, WTRU A 1191 can attach without having to be on any CSG list.

[0134] At 1102, WTRU A 1191 may attach to the EPC 1194 using the

H(e)NB 1192 and gateway 1193-1 present in the first femtozone.

[0135] At 1103, the femtozone gateway 1193-1 may inform the Social

Media Site 1199 of the presence of WTRU A 1191 using the existing femtozone gateway API.

[0136] At 1104, the Social Media Site 1199 and the EPC 1194 may resolve the ID of WTRU A 1191, so that, at 1105, the Social Media Site 1199 can ascertain that WTRU A 1191 is a member of the site.

[0137] At 1106, the Social Media Site 1199 may use a new API to inform the gateway 1193-1 that WTRU A 1191 is to have access to all of the femtozones owned by the Social Media Site 1199. In this case, the Social Media Site 1199 may send the list of all the femtocells in femtozones 2 through n.

[0138] At 1107, the gateway 1193-1 may inform WTRU A 1191 to add these femtocells to the Allowed CSG List within WTRU A 1191.

[0139] At 1108, the WTRU A 1191 may update the Allowed CSG List with the list of femtocells received at 1107.

[0140] At 1109, the gateway 1193-1 may inform the EPC 1194 to add the association between WTRU A 1191 and the femtocells in femtozones 2 through n.

[0141] At 1110, the EPC 1194 may update the network-based CSG List with the information. It should be noted that the above method is applicable if the femtozone corresponding to femtozone gateway 1193-1 contains a hybrid femtocell.

[0142] As noted previously, although the depicted MSC shows messages and/or steps in a particular order, it should be recognized that not all messages and/or steps may be necessary and the particular order may be different. Furthermore, whereas steps and/or messages may be depicted as separate events, the steps and/or messages may be combined as a single event. Likewise, a single event may be broken out into multiple events. [0143] In yet another example embodiment of populating a CSG List, a mobile network may work in concert with another mobile network to allow for the updating of Operator CSG Lists of users when the subscribers are spread across several networks. An example topology for which this method applies is shown in FIG. 12.

[0144] The example network topology depicted in FIG. 12 includes core network EPC 1 1214-1, core network EPC 2 1214-2, small cell network 1220, macro network 1230, WTRU A 1221, and WTRU B 1231. The user of WTRU A 1221 may be the owner of H(e)NB 1222. WTRU A 1221 may be a subscriber of EPC 1 1214-1. H(e)NB 1222 may be connected to EPC 1 1214-1 via SeGW 1213-1. WTRU B 1231 may be connected to the macro network 1230 owned by EPC 2 12142-2. The user of WTRU B 1231 may be on the contact list 1223 of WTRU A 1221. WTRU B 1231 may be a subscriber of a different network than WTRU A 1221. The method provided herein introduces an interface between the H(e)NB Owner Server in each network to allow for the update of the Operator CSG List 1231-2 in WTRU B 1231.

[0145] An MSC depicting an example embodiment of a method for updating the Operator CSG List 1231-1 in WTRU B 1231 is shown in FIG. 13. Referring to FIG. 13, at 1301, the owner of WTRU A 1391 may obtain and install a H(e)NB 1392 at their premise in either closed or hybrid mode.

[0146] At 1302, WTRU B 1395 may attach to EPC 2 1394-2. Note that steps 1301 and 1302 may happen in either order.

[0147] At 1303, WTRU A 1391 may connect to a server in the core network. This server may be called the H(e)NB Owner Server 1393-A. An association between WTRU A 1391 and H(e)NB 1392. Some type of authentication may be used between the end user and the server in the core network. This may prevent fraudulently claiming ownership of the femtocell. Any method may be used for authentication.

[0148] At 1304, the WTRU A 1391 may inform the server 1393-A to allow its contact list to populate the Operator CSG List of WTRUs corresponding to contacts on the contact list of WTRU A 1391. Steps 1303 and 1304 may be done using a webpage published by the server 1393-A. The web page may have a known IP address or FQDN and the WTRU- A 1391 may contact the server using this information.

[0149] At 1305, the server 1393-A may contact WTRU A 1391 to request the contact list. The list may be stored on the UICC of the WTRU A 1391, in ROM, or in both.

[0150] At 1306, the device may send the contact list to the server 1393-

A.

[0151] At 1307, the server 1393-A may interact with nodes in the EPC 1

1394-1 to determine which of the contacts on the contact list of WTRU A 1391 subscribe to the EPC 1 1394-1. This may be determined by using the mobile phone number associated with each contact. In this case, it may be determined that WTRU B 1395 is not a subscriber of EPC 1 1349-1.

[0152] At 1308, the server 1393-A in EPC 1 1394-1 may contact the

H(e)NB Owner Server in all other mobile core networks, even though only the interaction with H(e)NB Owner Server 1394-2 is shown.

[0153] At 1309, H(e)NB Owner Server 1393-B may respond that WTRU

B 1395 is a subscriber to its network. While not shown, it should be understood that any other networks to which WTRU B 1395 is not a subscriber may not respond.

[0154] At 1310, the H(e)NB Owner Server 1393-A in EPC 1 1394-1 may send a signal to the EPC 2 1394-2, indicating that WTRU B's Operator CSG List should be updated to include the identity of H(e)NB 1392.

[0155] At 1311, the H(e)NB Owner Server 1393-B in EPC 2 1394-2 may locate WTRU B 1395.

[0156] Once WTRU B 1395 has been located, at 1312, the H(e)NB

Owner Server 1393-B may update the Operator CSG List with H(e)NB 1392.

[0157] At 1313, the H(e)NB Owner Server 1393-A may ensure that the network-based CSG list in EPC 1 1394-1 includes WTRU B 1395 in the list of devices allowed to attach to H(e)NB 1392.

[0158] While not shown, it is possible for this process to happen periodically in the background. The server may periodically request the contact list from WTRU A 1391 and interact with the servers on each network, updating the Operator CSG List on WTRUs, either adding the H(e)NB 1392 ID for new contacts, or removing the H(e)NB 1392 ID for deleted contacts as the contact list on WTRU A 1391 is updated.

[0159] As noted previously, although the depicted MSC shows messages and/or steps in a particular order, it should be recognized that not all messages and/or steps may be necessary and the particular order may be different. Furthermore, whereas steps and/or messages may be depicted as separate events, the steps and/or messages may be combined as a single event. Likewise, a single event may be broken out into multiple events.

[0160] An MSC depicting another example method for updating the

Operator CSG list on non- subscriber devices is shown in FIG. 14. In this method, the H(e)NB Owner Server 1493 in EPC 1 1494-1 may send an SMS message to WTRU B 1495, informing the user to update the Allowed CSG List that is under user control. In this example method, there may be no H(e)NB Owner Server in EPC 2 1494-2.

[0161] Referring to FIG. 14, at 1401, the user of WTRU A 1491 may obtain and install a H(e)NB 1492 at their premise in either closed or hybrid mode.

[0162] At 1402, WTRU B 1495 may attach to EPC 2 1494-2. Note that steps 1401 and 1402 may happen in either order.

[0163] At 1403, WTRU A 1491 may connect to a server in the core network. This server may be called the H(e)NB Owner Server 1493. An association between WTRU A 1491 and H(e)NB 1492 may be registered. Some type of authentication may be used between the end user and the server in the core network. This may prevent fraudulently claiming ownership of the femtocell. Any method may be used for authentication.

[0164] At 1404, WTRU A 1491 may inform the server 1493 to allow its contact list to populate the Operator CSG List of WTRUs used by contacts on the contact list of WTRU A 1491. Steps 1403 and 1404 may be done using a webpage published by server 1493. The web page may have a known IP address or FQDN and WTRU A 1491 may contact the server 1493 using this information. [0165] At 1405, the server 1493 may contact WTRU A 1491 to request the contact list. The list may be stored on the UICC of the WTRU A 1491, in ROM, or in both.

[0166] At 1406, the WTRU A 1491 may send the contact list to server

1493.

[0167] At 1407, the server 1493 may interact with nodes in EPC 1 1494-

1 to determine which contacts subscribe to EPC 1 1494-1. It may be determined by using the mobile phone number associated with the contacts. In this case, it may be determined that WTRU B 1495 is not a subscriber of EPC 1494-1. Steps 1401 through 1407 may be the same as those depicted in FIG. 3.

[0168] At 1408, the H(e)NB Owner Server 1493 in EPC 1 1494-1 may contact EPC 2 1494-2 to determine if WTRU B 1495 is a subscriber to EPC 2 1494-2. This step may use existing signaling but for a different purpose. Instead of signaling in a typical roaming scenario, this signaling may be used to determine the location of the WTRU B 1495 so its Allowed CSG List can be updated.

[0169] Assuming WTRU B 1495 is a subscriber on EPC 2 1494-2, at

1409, that network responds.

[0170] Upon receiving this response, the H(e)NB Owner Server 1493 may send a message, e.g., a SMS, to WTRU B 1495 via EPC 2 1494-2 as shown at 1410. This message may inform the user to add H(e)NB 1492 to the Allowed CSG List on WTRU B 1495.

[0171] At 1411, EPC 2 1494-2 may deliver this SMS to WTRU B 1495.

[0172] At 1412, upon receipt of the SMS, the WTRU B 1495 may update its Allowed CSG List.

[0173] At 1413, the H(e)NB Owner Server 1493 may ensure that the network-based CSG list in EPC 1 1494-1 includes WTRU B 1495 in the list of WTRUs allowed to attach to H(e)NB 1492.

[0174] As noted previously, although the depicted MSC shows messages and/or steps in a particular order, it should be recognized that not all messages and/or steps may be necessary and the particular order may be different. Furthermore, whereas steps and/or messages may be depicted as separate events, the steps and/or messages may be combined as a single event. Likewise, a single event may be broken out into multiple events.

[0175] It should be noted that several features may be put into place to preclude the user from being bombarded with text messages indicating that they have been granted access to some small cell network. The user may have an opt-out feature on their social media account, e.g. Linkedln, which would stop the social media account from providing their mobile number as part of the provided contact list.

[0176] The user may also have an opt-out for specific users or groups on their social media account, e.g., Linkedln, which may prevent the social media account from providing their mobile number as part of the provided contact list for specific requesting users. The user may also have an opt-out within the mobile core network so that even if the social media account, e.g., Linkedln, provided their mobile number, the H(e)NB Owner Server and EPC may collude to prevent this opted-out user from receiving the text message. Alternatively, an application may be placed on the WTRU that would automatically consume the text message and update the Allowed CSG List on the WTRU. In addition, any combination of the above may also be used.

[0177] In yet another embodiment of updating a CSG List, an example method is disclosed for removing contacts from the Operator CSG lists. In one example, if a small cell owner is the owner of an enterprise and an employee of that enterprise leaves, the small cell owner may remove the leaving employee's access to the small cell. Several example scenarios for removing the access to the small cell network are described.

[0178] In a first example method, the small cell network owner may remove that user from his or her contact list. The H(e)NB Owner Server may recognize this removal and update the Network-based CSG list by removing the link between the removed user and that small cell network. It may also push an update to the Operator CSG List in the device of the removed user. An example network topology for the above described embodiment including removing a contact is shown in Figure 15. [0179] An MSC depicting an example method of updating a CSG List in response to removing a contact is shown in FIG. 16. In FIG. 16, it is assumed that the owner of the small cell network and user of WTRU A 1691 has already registered and authenticated ownership of H(e)NB 1692 with the H(e)NB Owner Server 1693. It is also assumed that WTRU B 1695 has been previously granted access to H(e)NB 1692 and this is reflected in its Operator CSG List. It is also assumed that WTRU B 1695 is currently on the network.

[0180] Referring to FIG. 16, at 1601, WTRU B 1695 is removed from the contact list of WTRU A 1691. There may be many reasons that WTRU B 1695 may be removed from the contact list, such as the owner of WTRU B 1695 no longer being employed by the enterprise.

[0181] Steps 1602, 1603, 1604 and 1605 may occur periodically. The

H(e)NB Owner Server 1693 and WTRU A 1691 may periodically mutually authenticate as shown at 1602. At 1603, the H(e)NB Owner Server 1693 may request the contact list from WTRU A 1691. At 1604, WTRU A 1691 may respond with the contact list. Note that the contact list is now without WTRU B 1695. At 1605, the H(e)NB Owner Server 1693 may resolve the contact list identities to a network-based ID, such as international mobile subscriber identity (IMSI).

[0182] In this example, since WTRU B 1695 has been removed, at 1606, the H(e)NB Owner Server 1693 may determine that WTRU B 1695 is no longer in the contact list. Therefore, H(e)NB Owner Server 1693 removes WTRU B's access to H(e)NB 1692. H(e)NB Owner Server 1693 may do this at 1607 by collaborating with the EPC 1694 to remove the link between H(e)NB 1692 and WTRU B 1695 from the Network-based CSG list.

[0183] Continuing with the removal, the H(e)NB Owner Server 1693 may contact WTRU B 1695, directing it to remove H(e)NB 1692 from the Operator CSG list maintained within WTRU B 1695 as shown at 1608.

[0184] At 1609, WTRU B 1695 may remove H(e)NB 1692 from the

Operator CSG list.

[0185] In the above example method, the H(e)NB Owner Server 1693 and WTRU A 1691 may communicate periodically. In another example method, when WTRU A 1691 updates its contact list, it may contact the H(e)NB Owner Server 1693 to inform it that it has updated its contact list. If this is the case, steps 1603 through 1609 may then be informed. The WTRU A 1691 may automatically contact the H(e)NB Owner Server 1693 when the contact list is updated or the user of WTRU A 1691 may log in to the H(e)NB Owner Server 1693 informing it that the contact list has been updated. In this example method, the small cell network owner may remove a user from a contact list located on a social media site, e.g., Linkedln. Once the contact has been removed, the social media site may push a key to WTRU A 1691. This key may be forwarded to the H(e)NB Owner Server 1693 which may use it to retrieve the contact list from the social media site. Once retrieved, the H(e)NB Owner Server 1693 may resolve the contact list to network identities, e.g. IMSI, determine that WTRU B 1695 has been removed from the list of contacts, and effectuate the removal of access to H(e)NB 1692 by WTRU B 1695. An example network topology for the above described embodiment including removing a contact from a social media contact list is shown in FIG. 17.

[0186] As noted previously, although the depicted MSC shows messages and/or steps in a particular order, it should be recognized that not all messages and/or steps may be necessary and the particular order may be different. Furthermore, whereas steps and/or messages may be depicted as separate events, the steps and/or messages may be combined as a single event. Likewise, a single event may be broken out into multiple events.

[0187] An MSC depicting an example embodiment of a method of updating a CSG List based on the removal of a contact from a social media contact list is shown in FIG. 18. In this example, it is assumed that the owner of the small cell network and user of WTRU A 1891 has already registered and authenticated ownership of H(e)NB 1892 with the H(e)NB Owner Server 1893. It is also assumed that WTRU B 1895 has been previously granted access to H(e)NB 1892 and this is reflected in its Operator CSG List. It is also assumed that WTRU B 1895 is currently on the network. [0188] Referring to FIG. 18, at 1801, the owner of WTRU B 1895 is removed from the social media site 1899, e.g. Linkedln, contact list of the owner of WTRU A 1891.

[0189] At the conclusion of this removal, the social media site 1899 may send a key to WTRU A 1891 as shown at 1802. This key may then be forwarded at 1803 to the H(e)NB Owner Server 1893. At 1804, the H(e)NB Owner Server 1893 may contact the social media site 1899 and provide this key. The social media site 1899 may check the key, determine its validity, and dispatch the contact list to the H(e)NB Owner Server 1893 as shown at 1805.

[0190] At 1806, the H(e)NB Owner Server 1893 may work with EPC

1894 to resolve the contact list identities to network-based identities, for example IMSI.

[0191] At 1807, the H(e)NB Owner Server 1893 may determine that

WTRU B 1895 has been removed from the contact list and propagate this removal to both the EPC 1894 and to WTRU B 1895. At 1808, the EPC 1894 and H(e)NB Owner Server 1893 may remove the link between WTRU B 1895 and H(e)NB 1892, thereby preventing WTRU B 1895 from connecting to H(e)NB 1892. At 1809, the H(e)NB Owner Server 1893 may command WTRU B 1895 to remove H(e)NB 1892 from its Operator CSG List. At 1810, WTRU B

1895 may comply with the command and remove H(e)NB 1892.

[0192] As noted previously, although the depicted MSC shows messages and/or steps in a particular order, it should be recognized that not all messages and/or steps may be necessary and the particular order may be different. Furthermore, whereas steps and/or messages may be depicted as separate events, the steps and/or messages may be combined as a single event. Likewise, a single event may be broken out into multiple events.

[0193] It should be noted that the concept of managing access to a small cell network via social media sites is also applicable to Machine-to-Machine (M2M) use cases. Two example use cases are described in FIGs. 19 and 20. FIGs. 19 and 20 provide examples of methods used to apply this concept to an M2M system. [0194] FIG. 19 shows an example topology and an example of steps performed as part accessing an M2M sensor network-based on social media contacts. The topology shown in FIG. 19 may include the following:

• The owner of the sensor network 1921.

• The sensor network 1920, which may include an M2M Gateway 1922 and some number of sensors such as sensors 1923 and 1924. The cloud around the sensor network 1920 itself should not be interpreted to limit the scope of the sensor network 1920 to a small area. It may be over a large area. It could be a contiguous area or some number of non-contiguous areas. The size of the cloud is only used for illustration purposes.

• An EPC 1914 with an M2M Server 1915. The Server 1915 may manage the M2M gateway 1922 and control access to the sensors 1923 and 1924 under the M2M Gateway 1922.

• A social media site, such as Facebook, with an API 1911 available to query the site to get one's contacts/friends/colleagues. On this site, the owner of the sensor network may be friends with two colleagues, Colleague 1 1931 and Colleague 2 1932.

• Colleague 1 1931 and Colleague 2 1932, who may be subscribers on the cellular network and connected via a macrocell or femtocell 1930.

[0195] Prior to the steps highlighted in FIG. 19, it is assumed that the owner of the sensor network is recognized by the M2M Server 1915 within the EPC 1914. The owner may also control who has access to the sensor network 1920. Any method or means may be used. For example, the methods defined in the M2M standards may be used. In the example shown in FIG. 19, it is assumed that this access is managed by the M2M network, i.e., Gateway 1922, Server 1915, etc.

[0196] Referring to FIG. 19, in step 1, the owner of the sensor network may contact the M2M Server 1915 and may inform the Server 1915 that access to the sensor network 1920 is allowed for all of the owner's friends on Facebook. [0197] In step 2, the M2M Server 1915 may use the Facebook API 1911 to gain access to the owner of the sensor network friends list. As part of this step, the M2M Server 1915 may identify the owner of the sensor network 1921. The Facebook API 1911 may reply with the contact list. In this case, Colleague 1 1931 and Colleague 2 1932 may be included on the list.

[0198] In step 3, the M2M Server 1915 may resolve the identity of each entry on the friends list to an EPC identity. The M2M Server 1915 may update the list of who is allowed access to the sensor network with these identities, in this case the cellular identity of Colleague 1 1931 and Colleague 2 1932.

[0199] In step 4, the M2M Server 1915 may contact Colleague 1 1931 and Colleague 2 1932 to inform them they have access to the sensor network 1920 with the contact information needed by the two friends to reach the sensor network 1920. This contact may be done by using a notification mechanism. For example, Colleague 1 1931 and Colleague 2 1932 may be represented by, or have on their WTRUs, applications that are registered with the M2M Server 1915 and subscribe to the "Sensor Network Access List". Once access is granted based on their social media contact with the owner of the sensor network 1921, each colleague may get a notification that access was granted.

[0200] In step 5, Colleague 1 1931 and Colleague 2 1932 may access the sensor network 1920. When they contact the M2M Gateway 1922, the gateway 1922 may collaborate with the M2M Server 1915 to ensure that access is permitted. The access may be controlled by the access rights resource.

[0201] As an alternative, if Colleague 1 1931 and Colleague 2 1932 are not on the cellular network, for example, they are instead on a wired network, the methods shown are still applicable. As a method of identifying the friends, the MAC address may be used in place of a cellular based ID.

[0202] FIG. 20 shows an example topology and an example of steps performed for accessing an M2M gateway based on social media contacts. The topology shown in FIG. 20 may include the following: • The owner of the sensor network 2021.

• The sensor network 2020, which may include an M2M Gateway 2022 and some number of sensors such as sensor 2023, 2024, 2025, and 2027. The cloud around the sensor network 2020 itself should not be interpreted to limit the scope of the sensor network 2020 to a small area. It may be over a large area. It could be a contiguous area or some number of non-contiguous areas. The size of the cloud is only used for illustration purposes.

• An EPC 2014 including an M2M Server 2015. The M2M Server 2015 may manage the M2M gateway 2022 and control access to the sensors under the M2M Gateway 2022.

• A social media site, such as Facebook, with an API 2011 may be available to query the site to get one's contacts/friends/colleagues. On this site, the owner of the sensor network 2021 may be friends with two colleagues, Colleague 1 2026 and Colleague 2 2028.

• Colleague 1 2026 and Colleague 2 2028 may be subscribers on the cellular network and have portable sensors that are interested in accessing the sensor network 2020.

[0203] Prior to the steps shown in Figure 20, it may be assumed that the owner of the sensor network 2021 is recognized by the M2M Server 2015 within the EPC 2014. The owner 2021 also may control who has access to the sensor network 2020.

[0204] Referring to FIG. 20, in step 1, the owner of the sensor network

2021 may contact the M2M Server 2015 and inform the M2M Server 2015 that any friend from a social media account, e.g., Facebook, with sensors is allowed to connect to the sensor network 2020.

[0205] In step 2, the M2M Server 2015 may use the Facebook API 2011 to gain access to the owner of the sensor network friends list. As part of this step, the M2M Server 2015 may identify the owner of the sensor network 2021. The Facebook API 2011 may reply with the contact list. In this case, Colleague 1 2026 and Colleague 2 2028 may be included on the list. [0206] In step 3, the M2M Server 2015 may resolve the identity of each entry on the friends list to an EPC identity. The M2M Server 2015 may update the list of who is allowed access to the sensor network with these identities, in this case the cellular identity of Colleague 1 2026 and Colleague 2 2028.

[0207] In step 4, the M2M Server 2015 may contact Colleague 1 2026 and Colleague 2 2028 to inform them that their sensors 2025 and 2027, respectively, have access to the sensor network 2020 with the contact information needed by the two friends for their sensors to attach to the sensor network 2020.

[0208] In step 5, sensors 2025 and 2027 may connect to the sensor network by attaching to the M2M Gateway 2022.

[0209] As an alternative, if Colleague 1 2026 and Colleague 2 2028 are not on the cellular network, for example, they are alternatively on a wired network, the methods as described are still applicable. In another example, MAC addresses may be used as a method of identifying the friends in place of cellular based IDs.

[0210] Additional enhancements that may be applied, either in total, individually or in any combination, to any of the methods and systems disclosed heretofore are described.

[0211] A two-way contact verification enhancement may be implemented. In this enhancement, before a contact may be added as an allowed member of a closed or hybrid cell, that contact's contact list may be checked to ensure that the owner/administrator of the H(e)NB is also a contact. This may be considered a reciprocal contact where each user, e.g., the person who owns the H(e)NB and the person who is being considered for access, has the other as a contact. This enhancement may be applied whether the method used to populate the Operator CSG List is the end-user's contact list or the end-user's social media contact list. And it may also be applied to the CSG list kept within the core network.

[0212] A location context enhancement may also be implemented. In this enhancement, before a contact is added as an allowed member of a closed or hybrid cell, that contact's location is checked to ensure it is "near" the H(e)NB that access is being offered. The contact's location may be based on geophysical position or based on its cellular network position. For example, if the network knows the device is attached to a macrocell that is near the H(e)NB that access is being contemplated, then the network may effectuate the update of the CSG Operator list and the list within the core network. Otherwise, the network may not update the CSG Operator list or the list within the core network for this user for this H(e)NB.

[0213] As an example, if the owner of the H(e)NB uses this feature to auto-populate his or her contacts' CSG Operator lists, and that H(e)NB is located in New York then only contacts that are located in the same geographic area would be considered. So, for example, a user in Connecticut or Pennsylvania may be added, but a user from San Diego or Australia would not.

[0214] An opt-out enhancement may also be implemented. In this enhancement, a subscriber may opt-out of this feature, meaning the subscriber would not be added as a contact based on being another subscriber's contact, either on that user's contact list stored on a WTRU or that user's social media contact list. The selection of opting-out may be done within the core network since the opting-out user is a subscriber of the mobile network. It may also be done at the social media site, since the opting-out user is also a member of the social media site.

[0215] A two-way communications enhancement may also be implemented. In this enhancement, before a contact is added as an allowed member of a closed or hybrid cell, the network may be checked to determine if the users had contact. That contact may be text messages, voice calls or some type of interaction. This feature may ferret out certain contacts from being given access to a H(e)NB. Many people have contacts which may only be acquaintances, such as people who one may know or have been introduced to, but with whom ones does not have regular contact. This enhancement may prevent an overreach of adding to the CSG lists, both in subscriber devices as well as the core network, those people who one is only tangentially connected. [0216] An example use case of populating a CSG List is disclosed. The methods described above may be employed in the example use case described herein. In the example use case, the owner of a cafe may deploy a small cell network within her business. The small cell network may be made up of a femtocell. Since she may be located in a busy location, for example, a mall, the owner may wish to limit access to the small cell network to the owner's patrons. The owner also does not want to have to individually give her patrons the information needed to access the small cell network. The owner's cafe also has a social media presence on Facebook and has a number of followers.

[0217] With the methods described heretofore, the owner may log into the H(e)NB Owner Server and indicate that for her small cell network, she would like to provide access to those Facebook users who are following her cafe. Once she indicates this, the H(e)NB Owner Server communicates with the Facebook database, e.g., using the Facebook API, to gain access to the list of followers of her cafe. The H(e)NB Owner Server may resolve these social media IDs into cellular IDs, for example by using the mobile number on each follower's Facebook information. Once the cellular IDs have been ascertained, the H(e)NB Owner Server may update the CSG List maintained within the core network to reflect that the followers are allowed access to the cafe's small cell network. In addition, the H(e)NB Owner Server may update the Operator CSG List on the WTRUs of each follower. When a follower arrives at the cafe, his or her WTRU may attempt to connect through the small cell network of the cafe. Since the follower is on the access list within the core network, when the follower's WTRU attempts to connect, the core network will allow the WTRU to attach through the small cell network within the cafe.

[0218] While CSGs may not typically be implemented for macrocells, if they are implemented for macrocells, the methods presented heretofore may apply directly. Furthermore, while the terms "femtocells" or "small cells" have been used throughout, it should be understood that all embodiments apply to both femtocells and small cells and further that the methods and concepts described apply to other types of base stations, such as microcells, minicells, and picocells. It also applies to other local nodes within the cellular system, such as local gateways (LGW), small cell network gateways, and converged gateways (CGW). It should also be understood that the methods and concepts described heretofore may apply to UMTS, LTE, GSM, CDMA-2000, and LTE- Advanced cellular systems.

[0219] While the embodiments described herein depict the H(e)NB and

H(e)NB Owner Server as two distinct entities, it should be noted that these could be within the same physical device. Therefore, for example, in the various MSCs depicted and described above, the H(e)NB and H(e)NB server may be represented by a single entity, and thus, all messages and information sent to/from either the H(e)NB or H(e)NB server may be depicted and described as being sent to/from the single entity. Furthermore, the H(e)NB Owner Server described herein could also be co-located in the same device as an LGW, CGW, small cell network gateway, or femtozone gateway.

[0220] While the methods and concepts described heretofore relate to access to the cellular network elements, it should be understood that these methods and concepts apply to other technologies that may require some limitation to access to a system. For instance, the methods and concepts presented herein may also apply to a Dynamic Spectrum Management (DSM) deployment, a Machine-to-Machine (M-M) deployment and also apply to a WiMax system. The inventions in this disclosure also apply to a wired system (for example Ethernet-based), where there may be a central node that performs access control for devices located outside the central node, which may be owned by a 3rd party who wishes to grant access to users of these devices. The owner may have a social media account and wishes to grant access to his or her friends or colleagues. Furthermore, the methods and concepts described may also be applied to any resource, such as a printer, or even a file, where an Access Control List (ACS) is created or modified with the social media contacts of the owner of the resource or content file.

[0221] Proximity-based Services (ProSe) may be used in any of the example methods described heretofore. ProSe is a method of direct communication between WTRUs. There may be a ProSe Server/Function in the core network which allows for WTRUs to perform this direct communication. ProSe also provides for a method of discovery, allowing a device to be informed when another device is in proximity. Three example using ProSe are described herein.

[0222] In the first example, a WTRU's social media contacts may be to be used as the list of WTRUs to which the requesting WTRU wishes to know when any of the WTRUs are close to the requesting WTRU. Therefore, in the Proximity Request message sent by the requesting WTRU to the ProSe Server/Function, the message may indicate that it wishes to request proximity location of all of the requesting WTRU's social media contacts. The Server/Function may interact with the API from a social media site to get the list of contacts. It may then resolve these into cellular network identities. The Server/Function may then monitor the location of the various WTRUs and report to the requesting WTRU whenever any of the social media contacts are within close proximity by sending a Proximity Alert to the requesting WTRU. At which time, the WTRUs may then directly communicate. The processing associated with the Map Request/Response message can be modified to include the social media contact identity, so that the various IDs of a particular user may all be linked.

[0223] In a second example, a mapping function may be modified to use social media contact IDs in place of "a list of application-based identifiers," which may also be referred to as "friends." The list of social media contacts may be converted to "private expression codes."

[0224] In a third example, the list of "application-based identifiers" for the owner of a small cell network may be used to populate the CSG list for a particular small cell. The identifiers may be added to the CSG list which may reside in the mobile core network. The H(e)NB Owner Server may also contact each of the WTRUs who are to be given access to the particular small cell such that the Operator CSG List on each WTRU can be updated with the cell ID of that particular small cell.

[0225] Though the above disclosed example embodiments refer to

Linkedln or Facebook as examples of social media networks providing contact information, the source of contacts should not be restricted to social media networks. There are many alternatives which can also be used. Any medium which provides a contact list of individuals connected to or associated with an entity may be suitable. Such further examples include email server contact lists such as those used in Microsoft Outlook, Mozilla Thunderbird, Gmail, Barca, Pegasus Mail, Opera, etc. Contact Management Systems such as Kurlo, Open contacts, Dragonfly, Spicebird, Pimero, etc. may also be used. In addition to Facebook and Linkedln, other social media networks such as Twitter, Vine, Google+, Instagram, Path, Pinterest, Tumblr, Flickr, etc. may be used. Furthermore, Linux access control lists may be used. Contact lists from apps such as Whats App, Yick Yack, Snapchat, etc. may be used.

[0226] The above examples are by no means intended to limit the scope of which applications could be used to provide contact information used by this invention to manage the access to a small cell network.

[0227] Embodiments

1. A method for controlling access to a small cell, the method

comprising:

populating an operator closed subscriber group (CSG) list.

2. The method as in embodiment 1, wherein the small cell is a

closed femtocell.

3. The method as in embodiment 1, wherein the small cell is a hybrid femtocell.

4. The method as in embodiment 1, wherein the small cell is one of a home eNode B (H(e)NB), a microcell, a minicell, and a picocell.

5. The method as in embodiment 1, wherein a contact list on a wireless transmit/receive unit (WTRU) is used as a source for populating the Operator CSG list.

6. The method of embodiment 5, wherein the WTRU is a subscriber to a core network.

7. The method of embodiment 6, wherein the small cell is connected to the same core network. 8. The method of embodiment 6, wherein the core network is an evolved packet core (EPC) network.

9. The method as in any of the preceding embodiments, further comprising:

the WTRU connecting to a server.

10. The method as in embodiment 9, wherein the server is a H(e)NB server.

11. The method as in embodiment 9, wherein the server is within the core network.

12. The method as in embodiment 9, wherein the server is on the public internet.

13. The method as in embodiment 9, wherein the server is a function of a node in the core network.

14. The method of embodiment 13, wherein the node is a mobility management entity (MME).

15. The method of embodiment 13, wherein the node is a home subscriber server.

16. The method as in any of the preceding embodiments, further comprising:

the WTRU registering an association with the server.

17. The method of embodiment 16, wherein the association includes an authentication between the WTRU and the core network.

18. The method as in any of the preceding embodiments, further comprising:

the WTRU granting permission to the server to utilize a contact list on the WTRU to populate the CSG list, wherein the contact list contains a list of users.

19. The method of embodiments 17 and 18, wherein the

authentication and granting permission is facilitated by a webpage published on the server.

20. The method as in any of the preceding embodiments, further comprising: the server requesting the contact list from the WTRU.

21. The method as in any of the preceding embodiments, further comprising:

the WTRU sending the contact list to the server.

22. The method as in any of the preceding embodiments, further comprising:

the server determining which contacts on the contact list are

subscribers to the core network.

23. The method as in embodiment 22, wherein the mobile phone numbers of the contacts on the contact list are used to determine which contacts on the contact list are subscribers to the core network.

24. The method as in any of the preceding embodiments, further comprising:

the server and the core network updating the CSG list with the contacts that are determined to be subscribers to the core network.

25. The method as in any of the preceding embodiments, further comprising:

the server and the core network locating the contacts that are

determined to be subscribers to the core network.

26. The method as in any of the preceding embodiments, further comprising:

the server sending an update of the Operator CSG list to a contact that is determined to be a subscriber to the core network.

27. The method as in embodiment 26, wherein the update includes an identification (ID) of the small cell, wherein the ID provides the contact access to the small cell.

28. The method as in any of the preceding embodiments, further comprising:

the server detecting an attachment to the core network by a contact; the server determining the location of the attached contact; and the server sending an update of the Operator CSG list to the attached contact. 29. The method as in embodiment 28, wherein the update includes an ID of the small cell, wherein the ID provides the attached contact access to the small cell.

30. The method as in any of the preceding embodiments, wherein the method is performed periodically in the background.

31. The method as in any of the preceding embodiments, further comprising:

removing the small cell ID for contacts deleted from the WTRU; and updating the list in the core network.

32. A method for controlling access to a small cell, the method comprising:

populating an operator closed subscriber group (CSG) list.

33. The method as in embodiment 32, wherein the small cell is a closed femtocell.

34. The method as in embodiment 32, wherein the small cell is a hybrid femtocell.

35. The method as in embodiment 32, wherein the small cell is a home eNode B (H(e)NB).

36. The method as in embodiment 32, wherein a contact list from any suitable source such as a social media website, an email contact list, a contact management system, Linux access control lists, or apps on a WTRU is used as a source for populating the Operator CSG list.

37. The method of embodiment 36, wherein the WTRU is a

subscriber to a core network.

38. The method of embodiment 37, wherein the small cell is connected to the same core network.

39. The method of embodiment 37, wherein the core network is an evolved packet core (EPC) network.

40. The method as in any of the preceding embodiments, further comprising:

the WTRU connecting to a server, wherein the server may or may not be co-located with another device. 41. The method as in embodiment 40, wherein the server is a H(e)NB server, and the H(e)NB server may or may not be within the H(e)NB.

42. The method as in embodiment 40, wherein the server is within the core network, and wherein the server may be co-located with an LGW, CGW, small cell network gateway, or femtozone gateway.

43. The method as in embodiment 40, wherein the server is on the public internet.

44. The method as in embodiment 40, wherein the server is a function of a node in the core network.

45. The method of embodiment 44, wherein the node is a mobility management entity (MME).

46. The method of embodiment 44, wherein the node is a home subscriber server.

47. The method as in any of the preceding embodiments, further comprising:

the WTRU registering an association with the server.

48. The method of embodiment 47, wherein the association includes an authentication between the WTRU and the core network.

49. The method of embodiment 48, wherein the authentication and granting permission is facilitated by a webpage published on the server.

50. The method as in any of the preceding embodiments, further comprising:

the WTRU logging into a user's social media account.

51. The method as in any of the preceding embodiments, further comprising:

the social media account providing a key to the WTRU to be used for pulling the user's contact list from the social media account.

52. The method as in any of the preceding embodiments, further comprising:

the WTRU forwarding the key to the server.

53. The method as in any of the preceding embodiments, further comprising: the server pulling the contact list from the social media account using the key provided by the WTRU.

54. The method as in any of the preceding embodiments, further comprising:

the server determining which contacts on the contact list of the social media account are subscribers to the core network.

55. The method as in embodiment 54, wherein the mobile phone numbers of the contacts on the contact list are used to determine which contacts on the contact list are subscribers to the core network.

56. The method as in any of the preceding embodiments, further comprising:

57. The method as in any of the preceding embodiments, further comprising:

the server and the core network locating the contacts that are

determined to be subscribers to the core network.

58. The method as in any of the preceding embodiments, further comprising:

59. The method as in embodiment 58, wherein the update includes an identification (ID) of the small cell, wherein the ID provides the contact access to the small cell.

60. The method as in any of the preceding embodiments, further comprising:

the server detecting an attachment to the core network by a contact; the server determining the location of the attached contact; and the server sending an update of the Operator CSG list to the attached contact. 61. The method as in embodiment 60, wherein the update includes an ID of the small cell, wherein the ID provides the attached contact access to the small cell.

62. The method as in any of the preceding embodiments, wherein the method is performed periodically in the background.

63. The method as in any of the preceding embodiments, further comprising:

64. A method for controlling access to a small cell, the method comprising:

populating an operator closed subscriber group (CSG) list.

65. The method as in embodiment 64, wherein the small cell is a closed femtocell.

66. The method as in embodiment 64, wherein the small cell is a hybrid femtocell.

67. The method as in embodiment 64, wherein the small cell is a home eNode B (H(e)NB).

68. The method as in embodiment 64, wherein a contact list on a social media website or application of a WTRU is used as a source for populating the Operator CSG list.

69. The method of embodiment 68, wherein the WTRU is a

subscriber to a core network.

70. The method of embodiment 69, wherein the small cell is connected to the same core network.

71. The method of embodiment 69, wherein the core network is an evolved packet core (EPC) network.

72. The method as in any of the preceding embodiments, further comprising:

the WTRU connecting to a server.

73. The method as in embodiment 72, wherein the server is a H(e)NB server. 74. The method as in embodiment 72, wherein the server is within the core network.

75. The method as in embodiment 72, wherein the server is on the public internet.

76. The method as in embodiment 72, wherein the server is a function of a node in the core network.

77. The method of embodiment 76, wherein the node is a mobility management entity (MME).

78. The method of embodiment 76, wherein the node is a home subscriber server.

79. The method as in any of the preceding embodiments, further comprising:

the WTRU registering an association with the server.

80. The method of embodiment 79, wherein the association includes an authentication between the WTRU and the core network.

81. The method of embodiments 80, wherein the authentication and granting permission is facilitated by a webpage published on the server.

82. The method as in any of the preceding embodiments, further comprising:

the WTRU logging into a user's social media account.

83. The method as in any of the preceding embodiments, further comprising:

84. The method as in any of the preceding embodiments, further comprising:

the WTRU pulling the contact list from the social media account using the key provided by the social media account.

85. The method as in any of the preceding embodiments, further comprising:

the WTRU forwarding the contact list to the server. 86. The method as in any of the preceding embodiments, further comprising:

87. The method as in embodiment 86, wherein the mobile phone numbers of the contacts on the contact list are used to determine which contacts on the contact list are subscribers to the core network.

88. The method as in any of the preceding embodiments, further comprising:

89. The method as in any of the preceding embodiments, further comprising:

the server and the core network locating the contacts that are

determined to be subscribers to the core network.

90. The method as in any of the preceding embodiments, further comprising:

91. The method as in embodiment 90, wherein the update includes an identification (ID) of the small cell, wherein the ID provides the contact access to the small cell.

92. The method as in any of the preceding embodiments, further comprising:

the server detecting an attachment to the core network by a contact; the server determining the location of the attached contact; and the server sending an update of the Operator CSG list to the attached contact.

93. The method as in embodiment 92, wherein the update includes an ID of the small cell, wherein the ID provides the attached contact access to the small cell. 94. The method as in any of the preceding embodiments, wherein the method is performed periodically in the background.

95. The method as in any of the preceding embodiments, further comprising:

96. A method for controlling access to a group of femtozones, the method comprising:

populating an operator closed subscriber group (CSG) list.

97. The method as in embodiment 96, wherein a femtozone is comprised of n femtocells and a femtozone gateway, wherein the femtozone gateway sits at the edge of the femtozone.

98. The method as in embodiment 96, wherein the femtozones may be open, closed, hybrid, or some combination thereof.

99. The method as in embodiment 96, wherein a social media site or application uses an application program interface (API) to subscribe the services provided by a femtozone gateway.

100. The method of embodiment 99, wherein the services provided by a femtozone gateway include reporting user activity on the femtozone.

101. The method as in any of the preceding embodiments, further comprising:

a WTRU attaching to the core networking using a small cell and gateway present in the a first femtozone.

102. The method as in embodiment 101, wherein the small cell is a closed femtocell.

103. The method as in embodiment 101, wherein the small cell is a hybrid femtocell.

104. The method as in embodiment 101, wherein the small cell is a home eNode B (H(e)NB).

105. The method as in embodiment 101, wherein the small cell is an open femtocell. 106. The method as in any of the preceding embodiments, further comprising:

the gateway informing the social media site or application of the

WTRU's presence.

107. The method of embodiment 106, wherein the gateway informs the social media site using the API.

108. The method as in any of the preceding embodiments, further comprising:

the social media site or application and the core network resolving the ID of the WTRU so that the social media site or application may ascertain that the user of the WTRU is a member of the site.

109. The method as in any of the preceding embodiments, further comprising:

the social media site or application using an API to inform the gateway that the WTRU is to have access to all femtozones associated with the social media site or application.

110. The method as in embodiment 109, wherein the informing includes the social media site or application sending a list of all femtocells in the femtozones associated with the social media site or application to the gateway.

111. The method as in any of the preceding embodiments, further comprising:

the gateway informing the WTRU to add the list of all femtocells in the femtozones associated with the social media site or application to an allowed CSG list within the WTRU.

112. The method as in embodiment 111, wherein the informing includes the gateway sending a list of all femtocells in the femtozones associated with the social media site or application to the WTRU.

113. The method as in any of the preceding embodiments, further comprising:

the WTRU updating the allowed CSG list with the list of femtocells received by the gateway. 114. The method as in any of the preceding embodiments, further comprising:

the gateway informing the core network to add the association between the WTRU and the femtocells in the femtozones.

115. The method as in any of the preceding embodiments, further comprising:

the core network updating a network-based CSG list.

116. A method for updating Operator CSG lists of a plurality of WTRUs, wherein the WTRUs are spread across several networks.

117. The method as in embodiment 116, further comprising:

a first WTRU attaching to a first core network; and

a second WTRU attaching to a second core network.

118. The method as in embodiment 116, wherein the first WTRU is connected to a first small cell and the second WTRU is connected to a second small cell.

119. The method as in embodiment 118, wherein the first small cell and/or the second small cell is a closed femtocell.

120. The method as in embodiment 118, wherein the first small cell and/or the second small cell is a hybrid femtocell.

121. The method as in embodiment 118, wherein the first small cell and/or the second small cell is a home eNode B (H(e)NB).

122. The method as in embodiment 118, wherein the first WTRU is a subscriber to the first core network and the second WTRU is a subscriber to the second core network.

123. The method of embodiment 118, wherein the first small cell is connected to the first core network and the second small cell is connected to the second core network.

124. The method as in any of the preceding embodiments, wherein the first core network and/or the second core network is an evolved packet core (EPC) network.

125. The method as in any of the preceding embodiments, further comprising: the first WTRU connecting to a first server; and

the second WTRU connecting to a second server.

126. The method as in embodiment 125, wherein the first server and/or the second server is a H(e)NB server.

127. The method as in embodiment 125, wherein the first server and/or the second server is within the core network.

128. The method as in embodiment 125, wherein the first server and/or the second server is on the public internet.

129. The method as in embodiment 125, wherein the first server and/or the second server is a function of a node in the core network.

130. The method of embodiment 129, wherein the node is a mobility management entity (MME).

131. The method of embodiment 129, wherein the node is a home subscriber server.

132. The method as in any of the preceding embodiments, further comprising:

the first WTRU registering an association with the first server.

133. The method of embodiment 132, wherein the association includes an authentication between the first WTRU and the first core network.

134. The method as in any of the preceding embodiments, further comprising:

the first WTRU granting permission to the first server to utilize a contact list on the first WTRU to populate the CSG list, wherein the contact list contains a list of users.

135. The method of embodiments 133 and 134, wherein the

136. The method as in any of the preceding embodiments, further comprising:

the first server requesting the contact list from the first WTRU.

137. The method as in any of the preceding embodiments, further comprising: the first WTRU sending the contact list to the first server.

138. The method as in any of the preceding embodiments, further comprising:

the first server determining which contacts on the contact list are subscribers to the core network.

139. The method as in embodiment 138, wherein the mobile phone numbers of the contacts on the contact list are used to determine which contacts on the contact list are subscribers to the core network.

140. The method as in embodiment 139, wherein the second WTRU is not a subscriber to the first core network.

141. The method as in any of the preceding embodiments, further comprising:

the first server in the first core network contacts a plurality of servers in a plurality of core networks to determine if the second WTRU is a

subscriber to any of the plurality of core networks.

142. The method as in any of the preceding embodiments, further comprising:

the second server in the second core network responding to the first server in the first core network, wherein the response includes an indication that the second WTRU is a subscriber to the second core network.

143. The method as in any of the preceding embodiments, further comprising:

the first server in the first core network sending a signal to the second server in the second core network indicating that the second WTRU's Operator CSG list should be updated to include the ID of the first small cell.

144. The method as in any of the preceding embodiments, further comprising:

the second server in the second core network locating the second

WTRU.

145. The method as in any of the preceding embodiments, further comprising:

on a condition that the second server has located the second WTRU: the second server updating the Operator CSG list of the second WTRU with the ID of the first small cell.

146. The method as in any of the preceding embodiments, further comprising:

the first server confirming that the CSG list in the first core network includes the second WTRU in the list of devices allowed to access the first small cell.

147. The method as in any of the preceding embodiments, wherein the method is performed periodically in the background.

148. The method as in any of the preceding embodiments, further comprising:

the first server periodically requesting the contact list from the first WTRU; the first server interacting with a plurality of servers on a plurality of networks; and

the first server updating the CSG list on a plurality of WTRUs, wherein the updating includes adding small cell IDs for new WTRUs and removing small cell IDs for deleted contacts.

149. A method for updating Operator CSG lists of a plurality of WTRUs, wherein the WTRUs are spread across several networks.

150. The method as in embodiment 149, further comprising:

a first WTRU attaching to a first core network; and

a second WTRU attaching to a second core network.

151. The method as in embodiment 149, wherein the first WTRU is connected to a first small cell and the second WTRU is connected to a second small cell.

152. The method as in embodiment 151, wherein the first small cell and/or the second small cell is a closed femtocell.

153. The method as in embodiment 151, wherein the first small cell and/or the second small cell is a hybrid femtocell.

154. The method as in embodiment 151, wherein the first small cell and/or the second small cell is a home eNode B (H(e)NB). 155. The method as in embodiment 150, wherein the first WTRU is a subscriber to the first core network and the second WTRU is a subscriber to the second core network.

156. The method of embodiment 151, wherein the first small cell is connected to the first core network and the second small cell is connected to the second core network.

157. The method as in any of the preceding embodiments, wherein the first core network and/or the second core network is an evolved packet core (EPC) network.

158. The method as in any of the preceding embodiments, further comprising:

the first WTRU connecting to a first server; and

the second WTRU connecting to a second server.

159. The method as in embodiment 158, wherein the first server and/or the second server is a H(e)NB server.

160. The method as in embodiment 158, wherein the first server and/or the second server is within the core network.

161. The method as in embodiment 158, wherein the first server and/or the second server is on the public internet.

162. The method as in embodiment 158, wherein the first server and/or the second server is a function of a node in the core network.

163. The method of embodiment 162, wherein the node is a mobility management entity (MME).

164. The method of embodiment 162, wherein the node is a home subscriber server.

165. The method as in any of the preceding embodiments, further comprising:

the first WTRU registering an association with the first server.

166. The method of embodiment 165, wherein the association includes an authentication between the first WTRU and the first core network.

167. The method as in any of the preceding embodiments, further comprising: the first WTRU granting permission to the first server to utilize a contact list on the first WTRU to populate the CSG list, wherein the contact list contains a list of users.

168. The method of embodiments 166 and 157, wherein the

169. The method as in any of the preceding embodiments, further comprising:

the first server requesting the contact list from the first WTRU.

170. The method as in any of the preceding embodiments, further comprising:

the first WTRU sending the contact list to the first server.

171. The method as in any of the preceding embodiments, further comprising:

172. The method as in embodiment 171, wherein the mobile phone numbers of the contacts on the contact list are used to determine which contacts on the contact list are subscribers to the core network.

173. The method as in embodiment 172, wherein the second WTRU is not a subscriber to the first core network.

174. The method as in any of the preceding embodiments, further comprising:

the first server in the first core network contacts the second core networks to determine if the second WTRU is a subscriber on the second core network.

175. The method as in embodiment 174, wherein the determining includes determining the location of the second WTRU.

176. The method as in any of the preceding embodiments, further comprising: the second core network responding to the server in the first core network, wherein the response includes an indication that the second WTRU is a subscriber to the second core network.

177. The method as in any of the preceding embodiments, further comprising:

the first server in the first core network sending a short message service (SMS) message to the second core network to be delivered to the second WTRU, wherein the SMS messages indicates that the second WTRU's Operator CSG list should be updated to include the ID of the first small cell.

178. The method as in any of the preceding embodiments, further comprising:

the second server delivering the SMS message to the second WTRU.

179. The method as in any of the preceding embodiments, further comprising:

the WTRU receiving the SMS message from the second server; and the WTRU updating its allowed CSG list.

180. The method as in any of the preceding embodiments, further comprising:

181. The method as in any of the preceding embodiments, wherein the second WTRU may indicate that the second WTRU has been granted access to a small cell network, wherein this indication will prevent further SMS messages.

182. The method as in any of the preceding embodiments, wherein an application on the WTRU automatically consumes the text message and updates the allowed CSG list on the WTRU.

183. A method for removing contacts from an Operator CSG list, the method comprising:

a first WTRU registering ownership of a small cell with the small cell server; and the first WTRU authenticating ownership of a small cell with the small cell server.

184. The method of embodiment 182, wherein a second WTRU has previously been granted access to the small cell owned by the first WTRU.

185. The method as in any of the preceding embodiments, further comprising:

the first WTRU removing the second WTRU from a contact list on the first WTRU.

186. The method as in any of the preceding embodiments, further comprising:

the first WTRU and the server authenticating periodically;

the server requesting the contact list from the from the first WTRU; and

the WTRU sending the contact list to the server.

187. The method as in embodiment 186, wherein the contact list sent to the server from the WTRU does not include the second WTRU because the second WTRU was removed from the contact list on the first WTRU.

188. The method as in any of the preceding embodiments, further comprising:

the server resolving the contact list identities to a network-based identity (ID).

189. The method as in embodiment 188, wherein the network-based ID is an international mobile subscriber identity (IMSI).

190. The method as in any of the preceding embodiments, further comprising:

the server realizing that the second WTRU is no longer on the contact list of the first WTRU; and

the server removing the second WTRU's access to the small cell.

191. The method as in any of the preceding embodiments, further comprising:

the core network removes the link between the small cell and the second WTRU from the network-based CSG list. 192. The method as in any of the preceding embodiments, further comprising:

the server contacting the second WTRU with a direction to remove the small cell from the Operator CSG list maintained within the second WTRU.

193. The method as in any of the preceding embodiments, further comprising:

the second WTRU removing the small cell from the Operator CSG list of the second WTRU.

194. A method for removing contacts from an Operator CSG list, the method comprising:

a first WTRU registering ownership of a small cell with the small cell server; and

the first WTRU authenticating ownership of a small cell with the small cell server.

195. The method of embodiment 194, wherein a second WTRU has previously been granted access to the small cell owned by the first WTRU.

196. The method of embodiment 195, wherein the contacts are the user of a WTRU's contact on a social media site or application.

197. The method as in any of the preceding embodiments, further comprising:

the first WTRU connecting to the social media site; and

the first WTRU removing a contact from the social media site, wherein the removed contact is the operator of the second WTRU.

198. The method as in any of the preceding embodiments, further comprising:

the social media site sending a key for accessing the contact list to the first WTRU.

199. The method as in any of the preceding embodiments, further comprising:

the first WTRU forwarding the key for accessing the contact list to the server. 200. The method as in any of the preceding embodiments, further comprising:

the server contacting the social media site; and

the server providing the key to the social media site.

201. The method as in any of the preceding embodiments, further comprising:

the social media site determining the validity of the key; and

on a condition that the key is verified:

the social media site sending the key to the server.

202. The method as in any of the preceding embodiments, further comprising:

the server collaborating with the core network to resolve the contact list identities to network-based identities.

203. The method as in embodiment 202, wherein the network-based identities are international mobile subscriber identities (IMSIs).

204. The method as in any of the preceding embodiments, further comprising:

the server determining that the second WTRU has been removed from the contact list; and

on a condition that it is determined that the second WTRU has been removed:

the server determining that it must transmit the determination that the second WTRU has been removed to the core network and to the second WTRU.

205. The method as in any of the preceding embodiments, further comprising:

the core network updating the network-based CSG list; and

the core network and the server removing the link between the second WTRU and the small cell.

206. The method as in any of the preceding embodiments, further comprising: the server commanding the second WTRU to remove the small cell from the second WTRU's Operator CSG list.

207. The method as in any of the preceding embodiments, further comprising:

the second WTRU receiving the command from the server; and the second WTRU removing the small cell from its Operator CSG list.

208. The method as in any of the preceding embodiments, further comprising:

checking a WTRU's contact list to confirm that the owner of the small cell is also a contact, before a contact is added to the CSG list.

209. The method as in any of the preceding embodiments, further comprising:

checking a WTRU's location to ensure that the WTRU is near the small cell.

210. The method as in embodiment 209, wherein the location is determined based on geophysical position or the WTRU's cellular network position.

211. The method as in any of the preceding embodiments, wherein a subscriber may select not to be added as a contact based on the subscriber being another subscriber's contact.

212. The method as in any of the preceding embodiments, further comprising:

checking the network to determine if the first WTRU and the second WTRU had contact, before a contact is added as an allowed member of a small cell.

213. The method as in embodiment 212, wherein the contact may be a text message, a voice call, and/or a type of IP interaction.

214. A method for accessing a machine-to-machine (M2M) sensor network.

215. The method as in embodiment 214, wherein access to the M2M sensor network is based on social media account contacts of an owner of the M2M sensor network. 216. The method as in embodiment 215, wherein the owner of the M2M sensor network controls who has access to the M2M sensor network.

217. The method as in any of the preceding embodiments, further comprising:

an M2M server recognizing the owner of the M2M sensor network.

218. The method as in any of the preceding embodiments, further comprising:

the owner of the sensor network contacting the M2M server;

the owner of the sensor network informing the M2M server that access to the sensor network is allowed for contacts on the owner's social media account.

219. The method as in any of the preceding embodiments, further comprising:

the M2M server identifying the owner of the sensor network; and the M2M server using the social media account's application

programming interface (API) to gain access to the owner of the sensor network's social media contact list.

220. The method as in any of the preceding embodiments, further comprising:

the social media account's API providing the contact list to the M2M server.

221. The method as in any of the preceding embodiments, further comprising:

the M2M server resolving the identity of each contact on the social media contact list to a network identity;

the M2M server updating the access list of the sensor network with the network identities of each contact on the social media contact list; and

the M2M server contacting the contacts added to the access list during the update to inform the added contacts that they have access to the sensor network.

222. The method as in any of the preceding embodiments, further comprising: the added contacts accessing the sensor network.

223. The method as in any of the preceding embodiments, further comprising:

an M2M gateway collaborating with the M2M server to ensure the added contacts are granted access.

224. A method for accessing a machine-to-machine (M2M) gateway.

225. The method as in embodiment 224, wherein access to the M2M gateway is based on social media account contacts of an owner of the M2M sensor network.

226. The method as in embodiment 225, wherein the owner of the M2M sensor network controls who has access to the M2M gateway.

227. The method as in any of the preceding embodiments, further comprising:

an M2M server recognizing the owner of the M2M sensor network.

228. The method as in any of the preceding embodiments, further comprising:

the owner of the sensor network contacting the M2M server; and the owner of the sensor network informing the M2M server that access to the sensor network is allowed for contacts on the owner's social media account with sensors.

229. The method as in any of the preceding embodiments, further comprising:

230. The method as in any of the preceding embodiments, further comprising:

the social media account's API providing the contact list to the M2M server.

231. The method as in any of the preceding embodiments, further comprising: The M2M server resolving the identity of each contact on the social media contact list to a network identity;

232. The method as in any of the preceding embodiments, further comprising:

the added contacts accessing the sensor network.

233. The method of embodiment 232, wherein the accessing includes contacts attaching to the M2M gateway.

234. A method for direct communication between WTRUs using proximity-based services (ProSe), the method comprising:

a requesting WTRU sending a proximity request message to a ProSe server/function, wherein the proximity request message indicates that the requesting WTRU would like to request proximity location of the requesting device's social media account's contacts.

235. The method as in any of the preceding embodiments, further comprising:

the ProSe server/function acquiring the social media account's contacts; the ProSe server/function resolving the social media account's contacts into network identities;

the ProSe server/function monitoring the location of devices

corresponding to the social media account's contacts; and

the ProSe server/function sending a proximity alert to the requesting WTRU whenever any of the social media contacts are within a predetermined proximity.

236. The method as in any of the preceding embodiments, further comprising: the WTRU receiving a proximity alert, wherein the proximity alert indicates that a WTRU corresponding to a social media contact is within a close proximity; and

the WTRU directly communicating with the WTRU corresponding to the social media contact.

237. A method for populating an Operator CSG list from the contact list of a wireless transmit/receive unit (WTRU), the method comprising:

receiving an authorization message from the WTRU indicating that contacts on the contact list of the WTRU may access a small cell;

sending a request to the WTRU for the contact list;

receiving the contact list;

determining which contacts on the contact list are subscriber to a core network; and

updating the Operator CSG list with the contacts that are determined to be subscribers to the core network.

238. A base station configured to perform any of the methods of embodiments 1-237.

239. A network configured to perform any of the methods of

embodiments 1-237.

240. A wireless transmit/receive unit (WTRU) configured to perform any of the methods of embodiments 1-237.

241. An integrated circuit configured to perform any of the methods of embodiments 1-237.

242. An access point (AP) configured to perform any of the methods of embodiments 1-237.

243. A small cell configured to perform any of the methods of embodiments 1-237.

[0228] 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. In addition, 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 is:

1. A Home evolved Node B (H(e)NB) for populating a Closed

Subscriber Group (CSG) list, the H(e)NB comprising:

a receiver configured to receive an access contact list; and

a processor configured to update a network-based CSG list to allow one or more wireless transmit receive units (WTRUs) corresponding to respective one or more phone numbers from the access contact list to access the H(e)NB; wherein the access contact list includes at least one of a contact list residing on an owner WTRU, a social media network account contact list, an email account contact list, and an app account contact list.

2. The H(e)NB of claim 1, wherein the receiver is further configured to:

receive an association between the owner WTRU and the H(e)NB;

3. The H(e)NB of claim 2, further comprising a transmitter, wherein:

the receiver is further configured to receive a key for pulling the access contact list from a contact source, wherein the access contact list is associated with the owner WTRU; and

the transmitter is configured to transmit the key to the contact source;

4. The H(e)NB of claim 1, wherein the processor is further configured to:

determine one or more international mobile subscriber identities (IMSIs) based on respective the one or more phone numbers from the access contact list; and

update the network-based CSG list to allow the respective one or more WTRUs based on the one or more IMSIs.

5. The H(e)NB of claim 1, further comprising a transmitter configured to transmit an update to an Operator CSG list residing on each of the one or more WTRUs that are attached to a same core network as the H(e)NB.

6. A method of populating a Closed Subscriber Group (CSG) list, the method comprising:

receiving an access contact list; and

updating a network-based CSG list to allow one or more wireless transmit receive units (WTRUs) corresponding to respective one or more phone numbers from the access contact list to access a cell;

wherein the access contact list includes at least one of a contact list residing on an owner WTRU, a social media network account contact list, an email account contact list, and an app account contact list.

7. The method of claim 6, further comprising:

receiving an association between the owner WTRU and the cell;

8. The method of claim 7, further comprising:

receiving a key for pulling the access contact list from a contact source, wherein the access contact list is associated with the owner WTRU; and

transmitting the key to the contact source;

9. The method of claim 6, further comprising:

determining one or more international mobile subscriber identities

(IMSIs) based on respective the one or more phone numbers from the access contact list;

wherein the updating includes updating the network-based CSG list based on the one or more IMSIs.

10. The method of claim 6, further comprising transmitting an update to an Operator CSG list residing on each of the one or more WTRUs that are attached to a same core network the owner WTRU.

11. The method of claim 6, wherein the updating includes removing at least one WTRU from the network-based CSG list that does not have a corresponding phone number in the access contact list.

12. A wireless transmit receive unit (WTRU) configured to provide one or more contacts for populating a network-based Closed Subscriber Group (CSG) list of a small cell, the WTRU comprising:

a transmitter configured to transmit login information to log into an account, the account having a contact list including the one or more contacts; a receiver configured to receive a key corresponding to the account; the transmitter further configured to transmit the key to a server of the small cell to enable the server to receive the contact list and populate the network-based CSG List with identities corresponding to WTRUs owned by the one or more contacts.

13. The WTRU of claim 12, wherein the identities corresponding to the WTRUs are international mobile subscriber identities (IMSIs).

14. The WTRU of claim 12, wherein the account is one of a social media network account, an email account, and an app account.

15. The WTRU of claim 12, wherein the small cell corresponds to a Home evolved Node B (H(e)NB).