IDENTIFIERS FOR PROXIMITY SERVICES

Abstract

Various systems and methods for providing identifiers for proximity services are described herein. A proximity server to provide identifiers for proximity services comprises: a receiving module to receive from a requester user equipment (UE) at a proximity services server, a request to connect the requester UE to a connection UE, the request including a user-defined proximity identifier that identifies the connection UE; a permission module to confirm permission for the requester UE to connect to the connection UE; and an output module to, based on the confirmation, provide a first link layer identifier (LLID) to the connection UE for use in direct discovery between the requester UE and the connection UE.

Description

RELATED APPLICATION

This application claims priority to U.S. Provisional Application Ser. No. 61/809,157, filed Apr. 5, 2013, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

Embodiments described herein generally relate to device-to-device communications and in particular, to identifiers for proximity services.

BACKGROUND

Wireless communication systems include Long Term Evolution (LTE) and LTE-Advanced (LTE-A) standards, developed by the 3rd Generation Partnership Project (3GPP). Device-to-device (D2D) communication is a technology component being developed for LTE-A. In D2D communication, user equipment (UE) transmit data to one another using a direct cellular link instead of using a base station (BS).

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which:

FIG. 1 is a block diagram illustrating data and control flow, according to an embodiment;

FIG. 2 is a block diagram illustrating data and control flow, according to an embodiment;

FIG. 3 is a block diagram illustrating a proximity server to provide identifiers for proximity services, according to an embodiment;

FIG. 4 is a flowchart illustrating a method for providing identifiers for proximity services, according to an embodiment;

FIG. 5 is an illustration of an example configuration of a communication network architecture, according to an embodiment;

FIG. 6 is a block diagram illustrating a mobile device 600, upon which any one or more of the techniques (e.g., methodologies) discussed herein may be performed;

FIG. 7 illustrates a block diagram of an example machine upon which any one or more of the techniques (e.g., methodologies) discussed herein may be performed; and

FIG. 8 illustrates a functional block diagram of an example machine (e.g., a user equipment (UE)) in accordance with an embodiment.

DETAILED DESCRIPTION

For proximity services, such as device-to-device discovery or communications, to function properly, UEs must be able to identify themselves and proximate peer devices. In the Wi-Fi Direct® standard, UEs advertise their permanent MAC IDs (media address control identification) during Device Discovery. However, there is no current mechanism for E-UTRA (Evolved Universal Terrestrial Radio Access) direct discovery/communications. Further, in the case of wireless local area network (WLAN) direct communication, W-Fi Direct® uses the UE's permanent MAC ID, which is undesirable given that it makes it impossible for the UE to remain anonymous when advertising its presence during Direct Discovery.

In this document, several mechanisms of UE identification for the purposes of proximity services for both E-UTRA and WLAN direct communications are provided. These mechanisms are illustrated in the context of two system architectures: one where the application servers are co-located with the proximity services server and one where the application servers are separate entities.

FIG. 1 is a block diagram illustrating data and control flow, according to an embodiment. In the embodiment illustrated in FIG. 1, an application server is incorporated into each respective proximity server 100, 102. In the case of a single application/proximity server, the user may define their own proximity services identifier, which is shared among friends for use in establishing “buddy lists” at the proximity server 100, 102. A buddy list is used to indicate which other users are allowed to discover and/or communicate directly with the user.

Each UE 104, 106 may register with their respective proximity services server 100, 102 and provide proximity services information (e.g. discovery permissions, buddy lists, available sharing content, authorized applications, etc.). The users of the respective UEs 104, 106 may designate a proximity services ID that may be used with all proximity services-enabled applications. Alternatively, the users may designate an application identifier (App ID) per proximity services-enabled application. It is this proximity services ID or App ID that a user shares with other users to form buddy lists for a given application.

In return, the proximity server 100, 102 provides the respective UE 104, 106 with a Link Layer ID (LLID) to be used for Direct Discovery. This LLID may be long-term or renewed every time the user engages in Direct Discovery. The latter option allows a UE to remain anonymous during Direct Discovery to all UEs who have not been given the mapping between the UE's proximity services ID and LLID in that moment.

In an example where a user is looking for another specific user to form a connection, UE A 104 and UE B 106 may register with their respective proximity servers 100, 102 and designate their proximity services IDs (e.g., ProSeA and ProSeB, for proximity services ID for UE A and B, respectively). The users of UE A and UE B know each other, thus they share their proximity services IDs and list each other as “buddies” with their respective proximity servers 100, 102. When the user of UE A decides he wants to connect directly with the user of UE B, he sends a request to his proximity server 100 for temporary LLIDs for his identifier (ProSeA) and ProSeB for the purpose of Direct Discovery (arrow 1). Proximity server A 100 sends the request on to proximity server B 102 identifying UE A's proximity services ID and a temporary LLID for UE A 104 (arrow 2). At arrow 3, proximity server B 102 confirms UE A's permission to discover UE B 106 based on the proximity services IDs, and creates a temporary LLID for UE B. The proximity server B 102 then forwards the temporary LLID to UE B 106 (arrow 4A) and proximity server A 100 (arrow 4B). In addition, proximity server B 102 may propose a common Direct Discovery period. At arrow 5, proximity server A 100 forwards the temporary LLID for UE B (and potentially the common Direct Discovery period) to UE A 104. At arrow 6, UE A 104 and UE B 106 engage in Direct Discovery using their temporary LLIDs.

In the case that the application server and proximity server are separate entities, the process of identifying UEs is slightly more complicated. In this next section, two potential mechanisms are described: one where the UE is identified between the application and proximity servers via a proximity services ID and another where it is identified by its permanent public ID.

When a user subscribes to proximity services, it is assigned a permanent identifier, referred to as the proximity services ID, along with authentication credentials. The proximity services ID may be encoded in a way that it identifies both the user and the PLMN to which it is subscribed (e.g. user@operator.com), and may also include a reference identifying the proximity server (e.g. user@proseserver.operator.com). Alternatively, an existing permanent identifier can be used as the proximity services ID (e.g. MSISDN or SIP URI). The proximity services ID is used by the user to assert its identity when authenticating with the proximity server.

When registering with an application server (there may be many of which he is a member), the user designates or is designated an application ID (App ID). Then, if/when an application is authorized by the operator and subscriber to use proximity services, the UE provides the application server with his proximity services ID (so the application server can determine which proximity server the user belongs to) and authenticates with the proximity server via the application server. If the authentication is successful, the application server stores the proximity services ID (in association with the user's App ID) for future reference. Note that all communication between the UE and the proximity server is relayed via the application server. With separate application and proximity servers, all application-related information (such as buddy lists, available sharing content, etc.) is housed at the application server, while proximity services-related information (such as discovery permissions, registered application servers, etc.) is housed at the proximity server. When a user wants to add a friend to his buddy list, he updates this information at the application server. The proximity service works only with buddies who have a proximity services ID associated with their App ID. Later, when the user wants to connect directly with or simply discover his friend, his UE can either send the request to his application server, which confirms they are buddies, and forwards the request to his buddy's proximity server. Alternatively, the user's UE can send the request directly to his proximity server, which forwards it to his buddy's proximity server.

FIG. 2 is a block diagram illustrating data and control flow, according to an embodiment. Two user equipment UE A 200 and UE B 202 may connect with an application server 204, which relays information to the proximity server A 206 or proximity server B 208. The user of UE A 200 signs into the application server 204 using its application ID (AppID A) and provides its proximity services ID (ProxID A) (arrow 1A). The application server 204 extracts the PLMN ID from ProxID A and contacts user A's proximity server A 206 (arrow 2A). The UE A 200 may then transparently authenticate with proximity server A 206 via the application server 204 (arrow 3A). At arrow 4A, the proximity server A 206 indicates to the application server 204 that the authentication was successful and the application server 204 stores the ProxID A identifier in association with the application from UE A 200. Similarly, the user of UE B 202 may sign into the application server 204 using an application ID (AppID B), providing its proximity services ID (ProxID B), and perform authentication (arrows 1B-4B).

At arrow 5, the user of UE A 200 requests to download specific content via his proximity services-enabled application. The App Server checks to see which users have the requested content as well as the required proximity services permissions (e.g., allowing UE A to connect directly with them), and forwards their ProxIDs to proximity server A 206 (along with UE A's ProxID A). The proximity server A 206 determines if any of the identified UEs are in proximity of UE A 200 and confirms that UE A 200 has permission to discover them (by contacting their respective proximity servers) and returns this information to the application server 204. The application server 204 then delivers this information to UE A 200 via the application (arrow 6).

The user of UE A 200 confirms which user he wants to connect to an application executing on UE B 202 and the application server 204 forwards this request to proximity server B 208 (e.g., with a message “ProxID A of PLMNA wants to connect to ProxID B” in arrow 7).

Proximity server B 208 reconfirms that ProxID A is permitted to discover ProxID B, creates a temporary LLID for UE B 202 (LinkB), and forwards this LLID (and potentially a common discovery period) to proximity server A 206. Proximity server A 206 creates a temporary LLID for UE A (LinkA), forwards this LLID to proximity server B 208 (which forwards it to UE B), and forwards the LLID and proposed discovery period to UE A. At arrow 11, UE A 200 and UE B 202 engage in Direct Discovery using their temporary LLIDs, LinkA and LinkB.

FIG. 3 is a block diagram illustrating a proximity server 300 to provide identifiers for proximity services, according to an embodiment. The proximity server 300 includes a receiving module 302, a permission module 304, and an output module 306. The receiving module 302 may receive from a requester user equipment (UE) at a proximity services server, a request to connect the requester UE to a connection UE, the request including a user-defined proximity identifier that identifies the connection UE.

In an embodiment, to receive the request to connect the requester UE to the connection UE, the receiving module 302 is to receive the request from an application server, which initially received the request from the requester UE. In an embodiment, to receive the request to connect the requester UE to the connection UE, the receiving module 302 is to receive the request from a second proximity services server, which initially received the request from the requester UE, and wherein the second proximity services server provides the requester UE a second LLID for use in direct discovery between the requester UE and the connection UE. In an embodiment, the output module 306 is to provide the second LLID to the connection UE. In an embodiment, the request includes an indication that the request is for direct discovery.

In an embodiment, the user-defined proximity identifier is encoded to identify a user of the connection UE and the public land mobile network (PLMN) of the connection UE.

In an embodiment, the user-defined proximity identifier includes at least one of a Mobile Station International Subscriber Directory Number (MSISDN) or a Session Initiation Protocol (SIP) uniform resource identifier (URI) of the connection UE.

The permission module 304 may confirm permission for the requester UE to connect to the connection UE.

The output module may, based on the confirmation, provide a first link layer identifier (LLID) to the connection UE for use in direct discovery between the requester UE and the connection UE. In an embodiment, the output module is to provide a common direct discovery period to the requester UE after confirming permission that the requester UE can connect to the connection UE.

In an embodiment, the first and second LLIDs are configured for one-time use, and wherein the proximity server renews the first and second LLIDs in response to a later request by the requester UE to connect to the connection UE.

FIG. 4 is a flowchart illustrating a method 400 for providing identifiers for proximity services, according to an embodiment. At block 402, a request to connect the requester UE to a connection UE is received from a requester UE at a proximity services server, the request including a user-defined proximity identifier that identifies the connection UE.

In an embodiment, receiving the request to connect the requester UE to the connection UE comprises receiving the request from an application server, which initially received the request from the requester UE.

In an embodiment, receiving the request to connect the requester UE to the connection UE comprises receiving the request from a second proximity services server, which initially received the request from the requester UE, and wherein the second proximity services server provides the requester UE a second LLID for use in direct discovery between the requester UE and the connection UE. In a further embodiment, the method 400 includes providing the second LLID to the connection UE.

In an embodiment, the request includes an indication that the request is for direct discovery.

In an embodiment, the user-defined proximity identifier is encoded to identify a user of the connection UE and the public land mobile network (PLMN) of the connection UE.

In an embodiment, the user-defined proximity identifier includes at least one of a Mobile Station International Subscriber Directory Number (MSISDN) or a Session Initiation Protocol (SIP) uniform resource identifier (URI) of the connection UE.

At block 404, permission for the requester UE to connect to the connection UE is confirmed.

At block 406, based on the confirmation, a first link layer identifier (LLID) is provided to the connection UE for use in direct discovery between the requester UE and the connection UE.

In an embodiment, the method includes providing a common direct discovery period to the requester UE after confirming permission that the requester UE can connect to the connection UE.

In an embodiment, the first and second LLIDs are configured for one-time use, and wherein the method comprises renewing the first and second LLIDs in response to a later request by the requester UE to connect to the connection UE.

FIG. 5 is an illustration of an example configuration of a communication network architecture 500, according to an embodiment. Within the communication network architecture 500, a carrier-based network such as an IEEE 802.11 compatible wireless access point or a LTE/LTE-A cell network operating according to a standard from a 3GPP standards family is established by network equipment 502. The network equipment 502 may include a wireless access point, a Wi-Fi hotspot, or an enhanced or evolved node B (eNodeB) communicating with communication devices 504A, 504B, 504C (e.g., a user equipment (UE) or a communication station (STA)). The carrier-based network includes wireless network connections 506A, 506B, and 506C with the communication devices 504A, 504B, and 504C, respectively. The communication devices 504A, 504B, 504C are illustrated as conforming to a variety of form factors, including a smartphone, a mobile phone handset, and a personal computer having an integrated or external wireless network communication device.

The network equipment 502 is illustrated in FIG. 5 as being connected via a network connection 514 to network servers 518 in a cloud network 516. The network servers 518, or any one individual server, may operate to provide various types of information to, or receive information from, communication devices 504A, 504B, 504C, including device location, user profiles, user information, web sites, e-mail, and the like. In an embodiment, a location server is included in the network servers 518, where the location server is used in an emergency situation to execute a NILR process and request a location report from a communication device 504. The techniques described herein enable the determination of the location of the various communication devices 504A, 504B, 504C, with respect to the network equipment 502.

Communication devices 504A, 504B, 504C may communicate with the network equipment 502 when in range or otherwise in proximity for wireless communications. As illustrated, the connection 506A may be established between the mobile device 504A (e.g., a smartphone) and the network equipment 502; the connection 506B may be established between the mobile device 504B (e.g., a mobile phone) and the network equipment 502; and the connection 506C may be established between the mobile device 504C (e.g., a personal computer) and the network equipment 502.

The wireless communication connections 506A, 506B, 506C between devices 504A, 504B, 504C may utilize a Wi-Fi or IEEE 802.11 standard protocol, or a protocol such as the current 3rd Generation Partnership Project (3GPP) long term evolution (LTE) time division duplex (TDD)-Advanced systems. In an embodiment, the cloud network 516 and network equipment 502 comprise an evolved universal terrestrial radio access network (EUTRAN) using the 3rd Generation Partnership Project (3GPP) long term evolution (LTE) standard and operating in time division duplexing (TDD) mode. The communication devices 504A, 504B, 504C may include one or more antennas, receivers, transmitters, or transceivers that are configured to utilize a Wi-Fi or IEEE 802.11 standard protocol, or a protocol such as 3GPP, LTE, or TDD-Advanced or any combination of these or other communications standards.

Antennas in or on the communication devices 504A, 504B, 504C may comprise one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some embodiments, instead of two or more antennas, a single antenna with multiple apertures may be used. In such embodiments, each aperture may be considered a separate antenna. In some multiple-input multiple-output (MIMO) embodiments, antennas may be effectively separated to utilize spatial diversity and the different channel characteristics that may result between each of the antennas and the antennas of a transmitting station. In some MIMO embodiments, antennas may be separated by up to 1/10 of a wavelength or more.

In some embodiments, the communication device 504A may include one or more of a keyboard, a display, a non-volatile memory port, multiple antennas, a graphics processor, an application processor, speakers, and other mobile device elements. The display may be an LCD screen including a touch screen. The communication device 504B may be similar to communication device 504A, but does not need to be identical. The communication device 504C may include some or all of the features, components, or functionality described with respect to communication device 504A.

A base station, such as an enhanced or evolved node B (eNodeB), may provide wireless communication services to communication devices, such as communication device 504A. While the exemplary communication system 500 of FIG. 5 depicts only three communication devices 504A, 504B, 504C any combination of multiple users, devices, servers and the like may be coupled to network equipment 502 in various embodiments. For example, three or more users located in a venue, such as a building, campus, mall area, or other area, and may utilize any number of mobile wireless-enabled computing devices to independently communicate with network equipment 502. Similarly, the communication system 500 may include more than one network equipment 502. For example, a plurality of access points or base stations may form an overlapping coverage area where devices may communicate with at least two instances of network equipment 502.

Although communication system 500 is illustrated as having several separate functional elements, two or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including digital signal processors (DSPs), and/or other hardware elements. For example, some elements may comprise one or more microprocessors, DSPs, application specific integrated circuits (ASICs), radio-frequency integrated circuits (RFICs) and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some embodiments, the functional elements of system 500 may refer to one or more processes operating on one or more processing elements.

Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A computer-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a computer-readable storage device may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media. In some embodiments, system 500 may include one or more processors and may be configured with instructions stored on a computer-readable storage device.

FIG. 6 is a block diagram illustrating a mobile device 600, upon which any one or more of the techniques (e.g., methodologies) discussed herein may be performed. The mobile device 600 may include a processor 610. The processor 610 may be any of a variety of different types of commercially available processors suitable for mobile devices, for example, an XScale architecture microprocessor, a Microprocessor without Interlocked Pipeline Stages (MIPS) architecture processor, or another type of processor. A memory 620, such as a Random Access Memory (RAM), a Flash memory, or other type of memory, is typically accessible to the processor 610. The memory 620 may be adapted to store an operating system (OS) 630 as well as application programs 640. The OS 630 or application programs 640 may include instructions stored on a computer readable medium (e.g., memory 620) that may cause the processor 610 of the mobile device 600 to perform any one or more of the techniques discussed herein. The processor 610 may be coupled, either directly or via appropriate intermediary hardware, to a display 650 and to one or more input/output (I/O) devices 660, such as a keypad, a touch panel sensor, a microphone, etc. Similarly, in an example embodiment, the processor 610 may be coupled to a transceiver 670 that interfaces with an antenna 690. The transceiver 670 may be configured to both transmit and receive cellular network signals, wireless data signals, or other types of signals via the antenna 690, depending on the nature of the mobile device 600. Further, in some configurations, a GPS receiver 680 may also make use of the antenna 690 to receive GPS signals.

FIG. 7 illustrates a block diagram of an example machine 700 upon which any one or more of the techniques (e.g., methodologies) discussed herein may be performed. In alternative embodiments, the machine 700 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 700 may operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the machine 700 may act as a peer machine in peer-to-peer (P2P) (or other distributed) network environment. The machine 700 may be a personal computer (PC), a tablet PC, a Personal Digital Assistant (PDA), a mobile telephone, a web appliance, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.

Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules are tangible entities capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside (1) on a non-transitory machine-readable medium or (2) in a transmission signal. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.

Accordingly, the term “module” is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as respective different modules at different times. Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

Machine (e.g., computer system) 700 may include a hardware processor 702 (e.g., a processing unit, a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 704, and a static memory 706, some or all of which may communicate with each other via a link 708 (e.g., a bus, link, interconnect, or the like). The machine 700 may further include a display device 710, an input device 712 (e.g., a keyboard), and a user interface (UI) navigation device 714 (e.g., a mouse). In an example, the display device 710, input device 712, and UI navigation device 714 may be a touch screen display. The machine 700 may additionally include a mass storage (e.g., drive unit) 716, a signal generation device 718 (e.g., a speaker), a network interface device 720, and one or more sensors 721, such as a global positioning system (GPS) sensor, camera, video recorder, compass, accelerometer, or other sensor. The machine 700 may include an output controller 728, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR)) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

The mass storage 716 may include a machine-readable medium 722 on which is stored one or more sets of data structures or instructions 724 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 724 may also reside, completely or at least partially, within the main memory 704, within static memory 706, or within the hardware processor 702 during execution thereof by the machine 700. In an example, one or any combination of the hardware processor 702, the main memory 704, the static memory 706, or the mass storage 716 may constitute machine-readable media.

While the machine-readable medium 722 is illustrated as a single medium, the term “machine readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that configured to store the one or more instructions 724.

The term “machine-readable medium” may include any tangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine 700 and that cause the machine 700 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine-readable medium examples may include solid-state memories, and optical and magnetic media. Specific examples of machine-readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

The instructions 724 may further be transmitted or received over a communications network 726 using a transmission medium via the network interface device 720 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine 700, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A computer-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a computer-readable storage device may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media.

FIG. 8 illustrates a functional block diagram of an example machine 800 (e.g., a user equipment (UE)) in accordance with an embodiment. The UE 800 may include physical layer circuitry 802 for transmitting and receiving signals to and from eNBs using one or more antennas 804. UE 800 may also include processing circuitry 806 that may include, among other things a channel estimator. UE 800 may also include a memory 808. The processing circuitry may be configured to determine several different feedback values discussed below for transmission to the eNB. The processing circuitry may also include a media access control (MAC) layer 810.

In some embodiments, the UE 800 may include one or more of a keyboard, a display, a non-volatile memory port, multiple antennas, a graphics processor, an application processor, speakers, and other mobile device elements. The display may be an LCD screen including a touch screen.

The one or more antennas 804 utilized by the UE 800 may comprise one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some embodiments, instead of two or more antennas, a single antenna with multiple apertures may be used. In these embodiments, each aperture may be considered a separate antenna. In some multiple-input multiple-output (MIMO) embodiments, the antennas may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result between each of antennas and the antennas of a transmitting station. In some MIMO embodiments, the antennas may be separated by up to 1/10 of a wavelength or more.

Although the UE 800 is illustrated as having several separate functional elements, two or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including digital signal processors (DSPs), and/or other hardware elements. For example, some elements may comprise one or more microprocessors, DSPs, application specific integrated circuits (ASICs), radio-frequency integrated circuits (RFICs) and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some embodiments, the functional elements may refer to one or more processes operating on one or more processing elements.

Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer-readable storage medium, which may be read and executed by at least one processor to perform the operations described herein. A computer-readable storage medium may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a computer-readable storage medium may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media. In these embodiments, one or more processors of the UE 800 may be configured with the instructions to perform the operations described herein.

In some embodiments, the UE 800 may be configured to receive OFDM communication signals over a multicarrier communication channel in accordance with an OFDMA communication technique. The OFDM signals may comprise a plurality of orthogonal subcarriers. In some broadband multicarrier embodiments, eNBs (including macro eNB and pico eNBs) may be part of a broadband wireless access (BWA) network communication network, such as a Worldwide Interoperability for Microwave Access (WiMAX) communication network or a 3rd Generation Partnership Project (3GPP) Universal Terrestrial Radio Access Network (UTRAN) Long-Term-Evolution (LTE) or a Long-Term-Evolution (LTE) communication network, although the scope of the inventive subject matter described herein is not limited in this respect. In these broadband multicarrier embodiments, the UE 800 and the eNBs may be configured to communicate in accordance with an orthogonal frequency division multiple access (OFDMA) technique. The UTRAN LTE standards include the 3rd Generation Partnership Project (3GPP) standards for UTRAN-LTE, release 8, March 2008, and release 10, December 2010, including variations and evolutions thereof.

In some LTE embodiments, the basic unit of the wireless resource is the Physical Resource Block (PRB). The PRB may comprise 12 sub-carriers in the frequency domain×0.5 ms in the time domain. The PRBs may be allocated in pairs (in the time domain). In these embodiments, the PRB may comprise a plurality of resource elements (REs). A RE may comprise one sub-carrier×one symbol.

Two types of reference signals may be transmitted by an eNB including demodulation reference signals (DM-RS), channel state information reference signals (CIS-RS) and/or a common reference signal (CRS). The DM-RS may be used by the UE for data demodulation. The reference signals may be transmitted in predetermined PRBs.

In some embodiments, the OFDMA technique may be either a frequency domain duplexing (FDD) technique that uses different uplink and downlink spectrum or a time-domain duplexing (TDD) technique that uses the same spectrum for uplink and downlink.

In some other embodiments, the UE 800 and the eNBs may be configured to communicate signals that were transmitted using one or more other modulation techniques such as spread spectrum modulation (e.g., direct sequence code division multiple access (DS-CDMA) and/or frequency hopping code division multiple access (FH-CDMA)), time-division multiplexing (TDM) modulation, and/or frequency-division multiplexing (FDM) modulation, although the scope of the embodiments is not limited in this respect.

In some embodiments, the UE 800 may be part of a portable wireless communication device, such as a PDA, a laptop or portable computer with wireless communication capability, a web tablet, a wireless telephone, a wireless headset, a pager, an instant messaging device, a digital camera, an access point, a television, a medical device (e.g., a heart rate monitor, a blood pressure monitor, etc.), or other device that may receive and/or transmit information wirelessly.

In some LTE embodiments, the UE 800 may calculate several different feedback values which may be used to perform channel adaption for closed-loop spatial multiplexing transmission mode. These feedback values may include a channel-quality indicator (CQI), a rank indicator (RI) and a precoding matrix indicator (PMI). By the CQI, the transmitter selects one of several modulation alphabets and code rate combinations. The RI informs the transmitter about the number of useful transmission layers for the current MIMO channel, and the PMI indicates the codebook index of the precoding matrix (depending on the number of transmit antennas) that is applied at the transmitter. The code rate used by the eNB may be based on the CQI. The PMI may be a vector that is calculated by the UE and reported to the eNB. In some embodiments, the UE may transmit a physical uplink control channel (PUCCH) of format 2, 2a or 2b containing the CQI/PMI or RI.

In these embodiments, the CQI may be an indication of the downlink mobile radio channel quality as experienced by the UE 800. The CQI allows the UE 800 to propose to an eNB an optimum modulation scheme and coding rate to use for a given radio link quality so that the resulting transport block error rate would not exceed a certain value, such as 10%. In some embodiments, the UE may report a wideband CQI value which refers to the channel quality of the system bandwidth. The UE may also report a sub-band CQI value per sub-band of a certain number of resource blocks which may be configured by higher layers. The full set of sub-bands may cover the system bandwidth. In case of spatial multiplexing, a CQI per code word may be reported.

In some embodiments, the PMI may indicate an optimum precoding matrix to be used by the eNB for a given radio condition. The PMI value refers to the codebook table. The network configures the number of resource blocks that are represented by a PMI report. In some embodiments, to cover the system bandwidth, multiple PMI reports may be provided. PMI reports may also be provided for closed loop spatial multiplexing, multi-user MIMO and closed-loop rank 1 precoding MIMO modes.

In some cooperating multipoint (CoMP) embodiments, the network may be configured for joint transmissions to a UE in which two or more cooperating/coordinating points, such as remote-radio heads (RRHs) transmit jointly. In these embodiments, the joint transmissions may be MIMO transmissions and the cooperating points are configured to perform joint beamforming.

The example embodiments discussed herein may be utilized by wireless network access providers of all types including, but not limited to, mobile broadband providers looking to increase cellular offload ratios for cost-avoidance and performance gains, fixed broadband providers looking to extend their coverage footprint outside of customers' homes or businesses, wireless network access providers looking to monetize access networks via access consumers or venue owners, public venues looking to provide wireless network (e.g., Internet) access, or digital services (e.g. location services, advertisements, entertainment, etc.) over a wireless network, and business, educational or non-profit enterprises that desire to simplify guest Internet access or Bring-Your-Own-Device (BYOD) access.

Additional Notes & Examples

Example 1 includes subject matter (such as a device, apparatus, or machine) comprising an apparatus to provide identifiers for proximity services, including a proximity server comprising: a receiving module to receive from a requester user equipment (UE) at a proximity services server, a request to connect the requester UE to a connection UE, the request including a user-defined proximity identifier that identifies the connection UE; a permission module to confirm permission for the requester UE to connect to the connection UE; and an output module to, based on the confirmation, provide a first link layer identifier (LLID) to the connection UE for use in direct discovery between the requester UE and the connection UE.

In Example 2, the subject matter of Example 1 may optionally include, wherein to receive the request to connect the requester UE to the connection UE, the receiving module is to receive the request from an application server, which initially received the request from the requester UE.

In Example 3, the subject matter of any one or more of Examples 1 to 2 may optionally include, wherein to receive the request to connect the requester UE to the connection UE, the receiving module is to receive the request from a second proximity services server, which initially received the request from the requester UE, and wherein the second proximity services server provides the requester UE a second LLID for use in direct discovery between the requester UE and the connection UE.

In Example 4, the subject matter of any one or more of Examples 1 to 3 may optionally include, wherein the output module is to provide the second LLID to the connection UE.

In Example 5, the subject matter of any one or more of Examples 1 to 4 may optionally include, wherein the request includes an indication that the request is for direct discovery.

In Example 6, the subject matter of any one or more of Examples 1 to 5 may optionally include, wherein the user-defined proximity identifier is encoded to identify a user of the connection UE and the public land mobile network (PLMN) of the connection UE.

In Example 7, the subject matter of any one or more of Examples 1 to 6 may optionally include, wherein the user-defined proximity identifier includes at least one of a Mobile Station International Subscriber Directory Number (MSISDN) or a Session Initiation Protocol (SIP) uniform resource identifier (URI) of the connection UE.

In Example 8, the subject matter of any one or more of Examples 1 to 7 may optionally include, wherein the output module is to provide a common direct discovery period to the requester UE after confirming permission that the requester UE can connect to the connection UE.

In Example 9, the subject matter of any one or more of Examples 1 to 8 may optionally include, wherein the first and second LLIDs are configured for one-time use, and wherein the proximity server renews the first and second LLIDs in response to a later request by the requester UE to connect to the connection UE.

Example 10 includes subject matter for proximity services (such as a method, means for performing acts, machine readable medium including instructions that when performed by a machine cause the machine to performs acts, or an apparatus configured to perform) comprising: receiving from a requester user equipment (UE) at a proximity services server, a request to connect the requester UE to a connection UE, the request including a user-defined proximity identifier that identifies the connection UE; confirming permission for the requester UE to connect to the connection UE; and based on the confirmation, providing a first link layer identifier (LLID) to the connection UE for use in direct discovery between the requester UE and the connection UE.

In Example 11, the subject matter of Example 10 may optionally include, wherein receiving the request to connect the requester UE to the connection UE comprises receiving the request from an application server, which initially received the request from the requester UE.

In Example 12, the subject matter of any one or more of Examples 10 to 11 may optionally include, wherein receiving the request to connect the requester UE to the connection UE comprises receiving the request from a second proximity services server, which initially received the request from the requester UE, and wherein the second proximity services server provides the requester UE a second LLID for use in direct discovery between the requester UE and the connection UE.

In Example 13, the subject matter of any one or more of Examples 10 to 12 may optionally include, providing the second LLID to the connection UE.

In Example 14, the subject matter of any one or more of Examples 10 to 13 may optionally include, wherein the request includes an indication that the request is for direct discovery.

In Example 15, the subject matter of any one or more of Examples 10 to 14 may optionally include, wherein the user-defined proximity identifier is encoded to identify a user of the connection UE and the public land mobile network (PLMN) of the connection UE.

In Example 16, the subject matter of any one or more of Examples 10 to 15 may optionally include, wherein the user-defined proximity identifier includes at least one of a Mobile Station International Subscriber Directory Number (MSISDN) or a Session Initiation Protocol (SIP) uniform resource identifier (URI) of the connection UE.

In Example 17, the subject matter of any one or more of Examples 10 to 16 may optionally include, providing a common direct discovery period to the requester UE after confirming permission that the requester UE can connect to the connection UE.

In Example 18, the subject matter of any one or more of Examples 10 to 17 may optionally include, wherein the first and second LLIDs are configured for one-time use, and wherein the method comprises renewing the first and second LLIDs in response to a later request by the requester UE to connect to the connection UE.

The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments that may be practiced. These embodiments are also referred to herein as “examples.” Such examples may include elements in addition to those shown or described. However, also contemplated are examples that include the elements shown or described. Moreover, also contemplate are examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

Publications, patents, and patent documents referred to in this document are incorporated by reference herein in their entirety, as though individually incorporated by reference. In the event of inconsistent usages between this document and those documents so incorporated by reference, the usage in the incorporated reference(s) are supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.

In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to suggest a numerical order for their objects.

The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with others. Other embodiments may be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is to allow the reader to quickly ascertain the nature of the technical disclosure, for example, to comply with 37 C.F.R. §1.72(b) in the United States of America. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. However, the claims may not set forth every feature disclosed herein as embodiments may feature a subset of said features. Further, embodiments may include fewer features than those disclosed in a particular example. Thus, the following claims are hereby incorporated into the Detailed Description, with a claim standing on its own as a separate embodiment. The scope of the embodiments disclosed herein is to be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1. A proximity server to provide identifiers for proximity services, the proximity server comprising:

a receiving module to receive from a requester user equipment (UE) at a proximity services server, a request to connect the requester UE to a connection UE, the request including a user-defined proximity identifier that identifies the connection UE;

a permission module to confirm permission for the requester UE to connect to the connection UE; and

an output module to, based on the confirmation, provide a first link layer identifier (LLID) to the connection UE for use in direct discovery between the requester UE and the connection UE.

2. The proximity server of claim 1, wherein to receive the request to connect the requester UE to the connection UE, the receiving module is to receive the request from an application server, which initially received the request from the requester UE.

3. The proximity server of claim 1, wherein to receive the request to connect the requester UE to the connection UE, the receiving module is to receive the request from a second proximity services server, which initially received the request from the requester UE, and wherein the second proximity services server provides the requester UE a second LLID for use in direct discovery between the requester UE and the connection UE.

4. The proximity server of claim 3, wherein the output module is to provide the second LLID to the connection UE.

5. The proximity server of claim 1, wherein the request includes an indication that the request is for direct discovery.

6. The proximity server of claim 1, wherein the user-defined proximity identifier is encoded to identify a user of the connection UE and the public land mobile network (PLMN) of the connection UE.

7. The proximity server of claim 1, wherein the user-defined proximity identifier includes at least one of a Mobile Station International Subscriber Directory Number (MSISDN) or a Session Initiation Protocol (SIP) uniform resource identifier (URI) of the connection UE.

8. The proximity server of claim 1, wherein the output module is to provide a common direct discovery period to the requester UE after confirming permission that the requester UE can connect to the connection UE.

9. The proximity server of claim 1, wherein the first and second LLIDs are configured for one-time use, and wherein the proximity server renews the first and second LLIDs in response to a later request by the requester UE to connect to the connection UE.

10. A method for providing identifiers for proximity services, the method comprising:

receiving from a requester user equipment (UE) at a proximity services server, a request to connect the requester UE to a connection UE, the request including a user-defined proximity identifier that identifies the connection UE;

confirming permission for the requester UE to connect to the connection UE; and

based on the confirmation, providing a first link layer identifier (LLID) to the connection UE for use in direct discovery between the requester UE and the connection UE.

11. The method of claim 10, wherein receiving the request to connect the requester UE to the connection UE comprises receiving the request from an application server, which initially received the request from the requester UE.

12. The method of claim 10, wherein receiving the request to connect the requester UE to the connection UE comprises receiving the request from a second proximity services server, which initially received the request from the requester UE, and wherein the second proximity services server provides the requester UE a second LLID for use in direct discovery between the requester UE and the connection UE.

13. The method of claim 12, further comprising providing the second LLID to the connection UE.

14. The method of claim 10, wherein the request includes an indication that the request is for direct discovery.

15. The method of claim 10, wherein the user-defined proximity identifier is encoded to identify a user of the connection UE and the public land mobile network (PLMN) of the connection UE.

16. The method of claim 10, wherein the user-defined proximity identifier includes at least one of a Mobile Station International Subscriber Directory Number (MSISDN) or a Session Initiation Protocol (SIP) uniform resource identifier (URI) of the connection UE.

17. The method of claim 10, further comprising providing a common direct discovery period to the requester UE after confirming permission that the requester UE can connect to the connection UE.

18. The method of claim 10, wherein the first and second LLIDs are configured for one-time use, and wherein the method comprises renewing the first and second LLIDs in response to a later request by the requester UE to connect to the connection UE.

19. A machine-readable medium including instructions for providing identifiers for proximity services, which when executed by a machine, cause the machine to:

receive from a requester user equipment (UE) at a proximity services server, a request to connect the requester UE to a connection UE, the request including a user-defined proximity identifier that identifies the connection UE;

confirm permission for the requester UE to connect to the connection UE; and

based on the confirmation, provide a first link layer identifier (LLID) to the connection UE for use in direct discovery between the requester UE and the connection UE.