U.S. patent application number 14/141236 was filed with the patent office on 2014-10-09 for identifiers for proximity services.
The applicant listed for this patent is Kerstin Johnsson, Alexandre Saso Stojanovski. Invention is credited to Kerstin Johnsson, Alexandre Saso Stojanovski.
Application Number | 20140301270 14/141236 |
Document ID | / |
Family ID | 51654383 |
Filed Date | 2014-10-09 |
United States Patent
Application |
20140301270 |
Kind Code |
A1 |
Johnsson; Kerstin ; et
al. |
October 9, 2014 |
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.
Inventors: |
Johnsson; Kerstin; (Palo
Alto, CA) ; Stojanovski; Alexandre Saso; (Paris,
FR) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Johnsson; Kerstin
Stojanovski; Alexandre Saso |
Palo Alto
Paris |
CA |
US
FR |
|
|
Family ID: |
51654383 |
Appl. No.: |
14/141236 |
Filed: |
December 26, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61809157 |
Apr 5, 2013 |
|
|
|
Current U.S.
Class: |
370/328 |
Current CPC
Class: |
H04W 72/0413 20130101;
H04L 67/28 20130101; H04W 72/0473 20130101; H04W 52/244 20130101;
H04W 76/11 20180201; H04W 84/12 20130101; H04W 4/80 20180201; H04L
67/16 20130101; H04W 4/00 20130101; H04W 76/14 20180201; H04W 52/10
20130101; H04W 4/021 20130101; H04W 72/042 20130101 |
Class at
Publication: |
370/328 |
International
Class: |
H04W 76/02 20060101
H04W076/02 |
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.
Description
RELATED APPLICATION
[0001] 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
[0002] Embodiments described herein generally relate to
device-to-device communications and in particular, to identifiers
for proximity services.
BACKGROUND
[0003] 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
[0004] 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:
[0005] FIG. 1 is a block diagram illustrating data and control
flow, according to an embodiment;
[0006] FIG. 2 is a block diagram illustrating data and control
flow, according to an embodiment;
[0007] FIG. 3 is a block diagram illustrating a proximity server to
provide identifiers for proximity services, according to an
embodiment;
[0008] FIG. 4 is a flowchart illustrating a method for providing
identifiers for proximity services, according to an embodiment;
[0009] FIG. 5 is an illustration of an example configuration of a
communication network architecture, according to an embodiment;
[0010] 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;
[0011] 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
[0012] FIG. 8 illustrates a functional block diagram of an example
machine (e.g., a user equipment (UE)) in accordance with an
embodiment.
DETAILED DESCRIPTION
[0013] 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.RTM. 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.RTM. 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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).
[0023] 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).
[0024] 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).
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] The permission module 304 may confirm permission for the
requester UE to connect to the connection UE.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] In an embodiment, the request includes an indication that
the request is for direct discovery.
[0037] 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.
[0038] 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.
[0039] At block 404, permission for the requester UE to connect to
the connection UE is confirmed.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.).
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] 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.
[0068] 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.times.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.times.one
symbol.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
[0077] 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
[0078] 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.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] 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.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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.
[0095] 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.
[0096] 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.
[0097] 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.
[0098] 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.
[0099] 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. .sctn.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.
* * * * *