HK1220069B - Network assisted device-to-device discovery for peer-to-peer applications - Google Patents

Description

Network-assisted device-to-device discovery for peer-to-peer applications

Related applications

This application claims priority to and the benefit of U.S. Provisional Patent Application No. 61/841,230, filed on June 2, 2013, and also claims priority to and the benefit of U.S. Provisional Patent Application No. 61/986,492, filed on April 30, 2014, both of which are incorporated herein by reference in their entireties.

Technical Field

The present application relates to a device-to-device communication arrangement for peer-to-peer applications, and more particularly to a network-assisted device discovery in the device-to-device communication arrangement.

Background Art

Device-to-device (D2D) communication typically begins with a discovery process between devices. Unlike standard access point (AP) or base station (BS) discovery, where a device connects to any nearby access point (AP) or base station (BS), in D2D communication, a device searches for a specific device or type of device (e.g., a device with a desired service or content). This device discovery process typically represents a significant waste of resources, as it can take a significant period of time before a specific device or type of device is within range of the D2D communication.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 shows an example architecture of a cellular network.

FIG2 illustrates example reference points and interfaces for network-assisted D2D discovery.

FIG3 illustrates an example process for network-assisted D2D communication for P2P applications.

FIG4 illustrates another example process for network-assisted D2D communication for P2P applications.

FIG5 shows an example signaling diagram of user registration with a P2P application server.

FIG6 shows an example signaling diagram of a P2P reference registration to a D2D server.

FIG. 7 shows an example signaling diagram of a P2P service request, where a P2P application server and a D2D server are configured to communicate.

FIG8 shows an example signaling diagram of a P2P service request, where the P2P application server and the D2D server are not configured to communicate.

FIG9 illustrates an example process for network-assisted D2D discovery involving multiple D2D servers.

FIG10 shows an example signaling diagram for network-assisted D2D discovery involving a single D2D server.

FIG. 11 shows an example signaling diagram for obtaining device location updates.

FIG12 illustrates an example mobile device.

DETAILED DESCRIPTION

References in this specification to "an embodiment," "one embodiment," etc., mean that a particular feature, structure, or characteristic is described as included in at least one embodiment of the present invention. The appearances of these phrases in this specification are not necessarily all referring to the same embodiment.

As mentioned above, significant resources may be wasted in the D2D discovery process. Applicants have recognized that network assistance for D2D discovery can significantly reduce the amount of resources required for D2D discovery. For example, if the network is used to determine whether two devices are within range of D2D communication, the amount of time these devices spend searching for each other can be significantly reduced. The network can also notify the selected device that the other device wants to connect so that the two devices perform discovery simultaneously. However, the core network infrastructure currently does not provide proximity detection services. The present disclosure provides systems, methods, and devices for network-assisted device discovery and/or proximity detection. In one embodiment, the technology described herein provides for identifying users at the application level and identifying user devices at the D2D radio access technology (RAT) level. The technology described herein also provides for D2D discovery and communication for peer-to-peer (P2P) applications.

Network communications, particularly wireless communications, often use a control plane to control or coordinate transmissions between connected devices or radios, and a user plane to carry user data or payload data. The control plane may also be referred to as a control channel, etc. The user plane may also be referred to as a user channel, data channel, shared data channel, etc. In one embodiment, the D2D discovery process or proximity detection process can be performed on either the user plane or the control plane. In one embodiment, a network-assisted device discovery process retrieves device location information on the control plane via location services, calculates device proximity, and notifies relevant devices when they are in proximity (this can be for informational purposes only or to trigger direct connection establishment). This process can significantly save channel resources and device battery life by avoiding countless direct discovery attempts when devices are not in proximity. Unfortunately, as the number of devices using this service grows, this process can begin to overload the control plane, which can cause problems for operator networks. Therefore, to allow this process to scale, we also introduce a network-assisted device discovery process that relies on location services implemented on the user plane.

According to one embodiment, a mobile terminal may be configured to perform a network-assisted device discovery method. During the method, the mobile terminal registers with a D2D server. The mobile terminal receives an indication of one or more D2D-capable peer mobile terminals from a peer application server. The mobile terminal sends a D2D discovery request to the D2D server for network-assisted discovery of a selected mobile terminal from the one or more D2D-capable peer mobile terminals. The mobile terminal receives an alert when the mobile terminal is within a defined discovery range. In one embodiment, one or more of registering with the D2D server, receiving an indication of one or more D2D-capable peer mobile terminals, sending the D2D discovery request, and receiving the alert occurs on a user plane.

On the network side, the D2D server can be configured to perform a device discovery method to assist the mobile terminal. The D2D server registers multiple D2D-capable peer mobile terminals in response to a registration request from each of the multiple D2D-capable peer mobile terminals. The D2D server receives a D2D discovery request from a first mobile terminal for network-assisted discovery of a second mobile terminal. The D2D server sends a location service request to a location server or entity. For example, the location server or entity may include a Third Generation Partnership Project (3GPP) Secure User Plane Location (SUPL) Location Platform (SLP) or a Network Mobile Location Center (GMLC). When the second mobile terminal is within a defined discovery range, the D2D server sends a warning to the first mobile terminal. In one embodiment, one or more of registering multiple mobile terminals, receiving D2D discovery requests, sending location service requests, receiving location service responses, and sending warnings occurs on the user plane.

FIG1 illustrates an example architecture of a cellular network 100. Example network 100 includes base stations 102a and 102b and a mobile terminal 104 (also referred to herein as user equipment (UE)). The term "base station" as used herein is a broad term. As will be appreciated by those skilled in the art, in an Evolved Universal Terrestrial Radio Access Network (EUTRAN) (e.g., as used in the LTE architecture), base stations 102a and 102b may be evolved Node Bs (eNodeBs). However, in some contexts, the term "eNodeB" is broader than a traditional base station because an eNodeB generally refers to a logical node. The term "base station" as used herein includes base stations, NodeBs, eNodeBs, and/or other nodes specific to other architectures.

UE 104 can communicate with base station 102a using dedicated channels 106. Base stations 102a and 102b can be connected to respective radio network controllers (RNCs) 108a and 108b. Although not shown as such in FIG1 , it will be understood that each RNC 108 can control more than one base station 102. In one embodiment, RNC 108 can be integrated with base station 102. RNC 108 is connected to core network 110. In the LTE architecture, core network 110 is an evolved packet core (EPC).

In various embodiments, the core network 110 may include or be connected to a D2D server 112, an SLP 120, and/or a GMLC 116. Additionally, in some embodiments, a P2P application server 114 may be coupled to the cellular network 100 via a network 118 (e.g., the Internet). The D2D server 112 may be configured to facilitate network-assisted D2D device discovery, as described below. The P2P application server 114 may be configured to provide P2P content and/or P2P service information. The GMLC 116 may be configured to provide location information to peer UEs configured for D2D communication and may be configured to operate in the control plane. The SLP 120 may be configured to provide location information to peer UEs configured for D2D communication and may be configured to operate in the user plane. Although servers 112 and 114, GMLC 116, and SLP 120 are depicted as distinct entities, it should be understood that one or more of these entities may be hosted on the same physical server and/or implemented as a single server providing multiple services.

2 is a schematic diagram illustrating example reference points and interfaces for a network-assisted D2D discovery process over a cellular network 200. Network 200 includes a core network 110, which includes or communicates with a D2D server 112 and an SLP 120. D2D server 112 communicates with a P2P application server 114 and communicates with UE 104 via EUTRAN 202. D2D server 112 includes an SLP proxy 204 for interfacing with/communicating with SLP 120. For clarity, some components of network 200 have been omitted.

The P2P application server 114 communicates with the UE 104 via the PC1 reference point. The P2P application server 114 may include a third-party application server corresponding to an application for the P2P service. In FIG2 , the PC1 reference point represents a logical connection between the UE 104 and the P2P application server 114 via the EUTRAN 202, the core network 110, and/or the Internet. In one embodiment, the PC1 reference point may include a logical connection via another access network such as a wireless local area network (WLAN). The PC1 reference point may be used to provide communication between the UE and the P2P application server 114. For example, the UE 104 may register with the P2P application server 114, receive an indication of one or more device-to-device capable peer UEs from the P2P application server 114, or perform any other communication with the P2P application server 114 via the PC1 reference point.

P2P application server 114 communicates with D2D server 112 via the PC2 reference point. The PC2 reference point may include a connection between D2D server 112 and P2P application server 114 via core network 110 and/or one or more intermediate networks (e.g., the Internet). In one embodiment, the PC2 reference point may allow D2D server 112 to directly receive and respond to proximity requests from P2P application server 114, or to send or retrieve P2P or D2D identifiers. Similarly, any other communications between P2P application server 114 and D2D server 112 may occur over the PC2 reference point.

D2D server 112 communicates with UE 104 via the PC3 reference point. In Figure 2, the PC3 reference point represents a logical connection between UE 104 and D2D server 112 via EUTRAN 202, and may also be a connection via other access networks such as WLAN. In one embodiment, the PC3 reference point may be used to register UE 104 with D2D server 112, send discovery requests, receive alerts, and so on. Similarly, any other communication between UE 104 and D2D server 112 may be conducted over the PC3 reference point.

The Le/L1 interface represents an interface or reference point between the SLP proxy 204 and the SLP 120 for the D2D server 112. For example, the SLP proxy 204 may allow the D2D server 112 to request location information for one or more UEs (e.g., the UE 104 and UEs selected for a D2D connection with the UE 104) from the SLP 120. In one embodiment, the D2D server 112 sends a location service request to the SLP 120 using the SLP proxy 204 and receives a location service response over the Le/L1 interface, which may include the location of the UE. Similarly, any other communications between the D2D server 112 and the SLP 120 may occur over the Le/L1 interface.

D2D server 112 may communicate with one or more other D2D servers via a PC6 reference point. The PC6 reference point may include a logical connection to D2D server 112 via core network 110 and/or any other intermediate network. For example, the PC6 reference point may include a logical connection to a D2D server corresponding to UE 104 for which UE 104 has requested an auxiliary connection in a D2D session. The other UE may include a UE connected to the same core network 110, a core network of another network operator, or any other network. For example, the other UE and/or D2D server may be located in a different Home Public Land Mobility Network (HPLMN) than UE 104. D2D server 112 may send and/or receive requests for location updates and/or receive location updates from another D2D server. In one embodiment, each of the PC1, PC2, PC3, Le/L1, and PC6 reference points or interfaces operates in the user plane of the core network or Evolved Packet System (EPS). For example, messages sent over one or more of the PC1, PC2, PC3, Le/L1, and PC6 reference points may include user plane, data channel, and/or shared data channel messages. In one embodiment, messages sent over one or more of the PC1, PC2, PC3, Le/L1, and PC6 reference points may include control plane and/or control channel messages.

FIG3 illustrates an example process for network-assisted D2D communication for P2P applications. In some embodiments, a user may access a P2P application server (e.g., P2P application server 114) to access P2P content and/or service information. In such an embodiment, at 302, the user (using UE A) may register with one or more P2P application servers whose P2P services and/or content information the user is interested in.

At 304, the user may register a P2P application with the D2D server. For example, the user or UE A may provide the D2D server with a P2P application ID and associated application-specific D2D settings (e.g., discovery permissions) for each P2P application that the user wants to use in the D2D communication arrangement. In one embodiment, the D2D server maintains a record of the user's registered P2P application IDs associated with the user's UE's permanent device identifier (e.g., International Mobile Subscriber Identity (IMSI)).

At 306, the user may request a P2P service from the P2P application server. In some embodiments, the user may indicate a preferred P2P content source, a preferred connectivity method (e.g., D2D communication layout, etc.), etc. In response to the request, the P2P application server may return a list of peer UEs configured to provide the requested P2P service. In some embodiments, the list of peer UEs may be filtered based on preference parameters provided by the user.

At 308, the user may request network-assisted D2D discovery. In one embodiment, the user may select a UE from a list of peer UEs to connect to and receive P2P services. The D2D server may assist the UE in establishing a D2D connection in response to the request.

FIG4 illustrates an example method for assisting a UE in establishing a D2D connection. The method is used to establish a D2D connection between UE A and UE B, devices having different D2D servers (D2D Server A and D2D Server B) and SLPs (SLP A and SLP B, respectively), and includes a D2D request/response and alert process. For example, the method can be used when the user of UE A and/or the user of UE B desires to establish a D2D connection. Note that while the method of FIG4 and the associated discussion indicate the use of SLPs to determine device location, the use of GMLC and associated modifications are considered encompassed by the present disclosure.

At 402, UE A registers with D2D server A, and at 404, UE B registers with D2D server B. At some point after registration, one or both UE A and UE B (or their respective users) may wish to establish a D2D connection with each other. At 406, one or both UE A and UE B may send a discovery request or proximity request to assist in connecting to the other UE. Furthermore, at 406, one or more of D2D server A and D2D server B may request location updates for both UE A and UE B. For example, in one scenario, UE A sends a proximity request to D2D server A requesting that it be alerted of its proximity to UE B (possibly indicating a time window during which the request is valid). In response, D2D server A requests location updates for both UE A and UE B. These location updates can be periodic, based on trigger conditions, or a combination of both. To request location updates for UE A, D2D server A may contact SLP A. To request a location update for UE B, D2D server A may contact D2D server B, which in turn sends a request for a location update for UE B to SLP B.

At 408, location reporting is performed as requested. For example, SLP A may determine the location of UE A and report the location to D2D server A. D2D server A may then forward the reported location of UE A to D2D server B. Similarly, SLP B may determine the location of UE B and report the location to D2D server B. D2D server B may then forward the reported location of UE B to D2D server A. In one embodiment, location reporting is performed based on the information or restrictions provided in the discovery request at 406. For example, location reporting may be performed only during a specified time window, or at an indicated time period, and/or in response to an indicated trigger condition. In response to the location reporting at 408, or whenever the D2D servers receive a location update for a UE, they may perform a proximity analysis to determine whether UE A and UE B are close enough for D2D communication. In one embodiment, only one D2D server performs the proximity analysis for a given UE pair.

When a D2D server discovers that UE A and UE B are in proximity, the D2D server sends a proximity alert to its corresponding UE at 410. For example, when D2D server A detects that UE A and UE B are in proximity, it notifies UE A of the proximity of UE B. D2D server A notifies D2D server B of the proximity, which in turn can notify UE B of the detected proximity. After receiving the proximity alert, UE A and UE B can enter discovery mode to establish a D2D connection.

As discussed above, location updates can be provided based on triggering conditions, time periods, or a combination of both. In one embodiment, the D2D server or other entity can indicate how often location updates should be received. For example, the D2D server can request location updates every few seconds or within any other update period. The update period can be selected to reduce the load on the D2D server or other network entity.

In one embodiment, a D2D server can indicate trigger conditions or warning conditions regarding when a location update should be sent to the D2D server. For example, D2D server A can determine an approximate border area between UE A and UE B and request that D2D server B (and therefore SLP B) and SLP A only send a location update if/if UE B or UE A crosses into or is on the border area. Based on these instructions, a reporting entity (e.g., a D2D server or SLP) can perform a location update and report the UE's location to the corresponding D2D server when the UE crosses into or is on the border area. In response to the trigger condition being met, the D2D server can then send a modified trigger condition. For example, after the UE has crossed the border area, the D2D server can then only send a location update if/if the UE leaves the border area. The D2D server can then wait to see if the UE leaves the border area or if another UE enters the border area. If necessary, the D2D server can update the "border area" based on the UE's exited location. The process ends when the discovery window expires or both UEs enter the border area. If both UEs enter the boundary area, the D2D server may redefine a smaller boundary area or simply request periodic location updates for the UEs until the UEs are in proximity.

3 and 4 above are described in more detail below. Note that while the following examples may specify using SLP or GMLC to determine device location, modifications to create embodiments using alternative location services or entities are considered encompassed by this disclosure.

Figure 5 shows an example signaling diagram for user registration with a P2P application server. In one embodiment, signaling can be performed using the PC1 reference point. At 502, a user, who may be using UE A or a separate computing device, can send a P2P registration request to the P2P application server. In various embodiments, the P2P registration request can include the user's P2P application ID, a list of P2P application-specific services, and/or content that the user wants to share, as well as permissions associated with the services and/or content (e.g., what peers can access the content/services), and a D2D server identifier. In one embodiment, the P2P registration request can be sent manually by the user or partially or fully automatically by the P2P application running on UE A. In some embodiments, after the user has initiated registration with the P2P server, the user can subsequently log in to the P2P server and update the information.

The P2P application server may provide a P2P registration response at 504. For example, the P2P application server may indicate whether the registration was successful.

Figure 6 shows an example signaling diagram for P2P application registration with a D2D server. In one embodiment, signaling can be performed using the PC3 reference point. In some embodiments, a UE (e.g., UE A) that subscribes to a network operator's network-assisted D2D service can be automatically registered with the D2D server during network registration. During this initial registration process, the D2D server can store D2D capabilities (e.g., WiFi Direct, Bluetooth, Advanced LTE, etc.), D2D permissions (e.g., enabling or disabling discovery, friend list, etc.), and/or the UE's permanent device identifier (e.g., IMSI). Initially, P2P application-specific information may not be registered with the D2D server.

When a user decides to enable a P2P application to use network-assisted D2D communication, at 602, the UE may send a P2P application registration request to the D2D server. The P2P application registration request may include, for example, the P2P application ID, the device ID, and/or any specific D2D permissions. For example, there are generally two types of UEs in D2D communication: open and restricted. A UE with open access will allow any UE to discover and connect to it. A UE with restricted access will provide a type of UE or a list of UEs that can access it. In various embodiments, the D2D server may associate the UE type with the user's P2P application ID or the UE's device ID. In various embodiments, the P2P application request may be sent manually by the user, automatically by the P2P application, or a combination of both.

At 604, the D2D server may provide a P2P application registration response. For example, the D2D server may indicate whether the P2P application registration is successful.

In some embodiments, the P2P application server and the D2D server may be configured to communicate to facilitate network-assisted D2D communication. Figure 7 shows an example signaling diagram for a P2P service request, where the P2P application server and the D2D server are configured to communicate.

At 702, UE A sends a P2P service request to a P2P application server (e.g., in response to a user accessing a P2P application on UE A). The P2P service request may include, for example, an indication of a subset of users (e.g., a friend list) from whom the user wants to retrieve content or with whom the user wants to engage in P2P services (e.g., gaming, file sharing, instant messaging, chat, content streaming, etc.). The P2P service request may also include a desired P2P connectivity layout (e.g., D2D, infrastructure, etc.). In response to the P2P service request, the P2P application server may create a list of possible peer UEs that meet the specifics of the user's request and are willing to share P2P content and/or services with the user. At 704, if D2D is a possible communication mechanism for the peer, the P2P application server sends a proximity request to the D2D server. In an example embodiment, the proximity request may include the user's P2P application ID and the P2P application IDs of the possible peer users. Additionally, the proximity request may include server identifiers of the D2D servers associated with the potential peer UE (if these servers are different from the user's D2D servers).

In response to the proximity request, the D2D server verifies the location and D2D capabilities of the potential peer UE. In one embodiment, the D2D server may contact various other D2D servers associated with the potential peer UE. At 706, the D2D server may then send a proximity response to the P2P application server. The proximity response may include, for example, the P2P application IDs of potential peer UEs that share a common D2D technology with UE A and are within a defined proximity of UE A (e.g., an estimated D2D communication range based on the D2D technology). In one embodiment, the communications at 704 and 706 are performed over the PC2 reference point.

At 708, the P2P server may provide a P2P service response to the user (e.g., via UE A). In various embodiments, the P2P service response may include a list of possible peer users (e.g., identified by P2P application IDs). In one embodiment, the list may be filtered, organized, or annotated using search filters provided by the user (e.g., friend list, P2P connection method, etc.).

FIG8 shows an example signaling diagram of a P2P service request, where the P2P application server and the D2D server are not configured to communicate.

At 802, UE A sends a P2P application service request to a P2P application server (e.g., in response to a user accessing a P2P application on UE A). The P2P application service request may include, for example, an indication of a subset of users (e.g., a friend list) with whom the user wants to engage in P2P services. The P2P application service request may also include a desired P2P connection layout (e.g., D2D, infrastructure, etc.).

At 804, the P2P server may provide a P2P service response to UE A. In various embodiments, the P2P service response may include a list of possible peer users (e.g., identified by P2P application IDs) and, in some embodiments, the D2D server associated with each D2D-capable peer UE. In one embodiment, the list may be filtered, organized, or annotated using additional search filters provided by the user (e.g., friend list, P2P connection method, etc.).

At 806, if there are D2D-capable peer UEs in the list provided by the P2P server, the UE may send a proximity request to the D2D server. The proximity request may include the P2P application ID associated with each D2D-capable peer UE and, in some embodiments, the D2D server ID associated with each D2D-capable peer UE.

At 808, in response to the proximity request, the D2D server may return a subset of D2D-capable peer UEs that share a common D2D technology with UE A and are within a defined proximity range. After receiving the list of possible peer UEs, the UE may select one or more possible peer UEs to connect to in a D2D communication arrangement.

FIG9 illustrates an example process for network-assisted D2D discovery involving multiple D2D servers. At 902, a UE may request assistance from a D2D server to discover (and potentially connect to) one or more peer UEs during a given time window. If the peer UEs have different D2D servers, the D2D server associated with UE A may request location and D2D permission information from the D2D server associated with the peer UE.

At 904, a D2D server associated with UE A and one or more peer UEs may request periodic location reports for UE A and one or more peer UEs from a GMLC (or SLP). In one embodiment, if the peer UEs are associated with different D2D servers, a location request may be sent from the server to the GMLC. The D2D server may determine from the locations of UE A and one or more peer UEs whether the UEs are within proximity for D2D communication. In response to determining that the UEs are within proximity, the D2D server may alert UE A and/or one or more peer UEs. Similar to the location request, if the peer UEs are associated with different D2D servers, a proximity alert may be sent from the corresponding D2D server. In one embodiment, if the UE has requested network assistance for post-D2D connection establishment discovery, the D2D server may provide assistance as described below.

Figure 10 shows an example signaling diagram for network-assisted D2D discovery involving a single D2D server. At 1002, UE A may send a D2D discovery request to a D2D server. In some embodiments, the D2D discovery request may include a P2P application ID associated with one or more peer UEs, and in some embodiments, may include the D2D server associated with each D2D-capable peer UE. For example, in the event that the D2D server cannot communicate with the P2P server, the D2D server may be given the D2D server name associated with the peer UE. Alternatively, the D2D server may ping every D2D server in the entire network to determine which D2D server manages a specific peer UE. It should be noted that a UE may request assistance in discovering multiple peer UEs in the same message. The D2D discovery request may also include an indication that the UE wishes to participate in D2D communications after being alerted to the proximity of one or more peer UEs.

If UE A does not have permission to discover peer UEs, the D2D server may request permission in real time (at 1004) or simply return a rejection notification. The discovery permission request may include, for example, the P2P application ID of UE A. At 1006, the peer UE may respond with an indication of whether permission is granted and whether there is a time limit on the permission.

At 1008 , the D2D server sends a D2D discovery response to UE A to indicate whether UE A has permission to discover any of the one or more requested peer UEs.

The D2D server may request location services from the GMLC at 1010. The location services request may include a permanent identifier associated with UE A (eg, IMSI), permanent identifiers associated with one or more peer UEs, a time period for discovery, and/or the like.

At 1012, the GMLC may provide a location service response that includes the location of UE A and the location of each of the one or more peer UEs. In one embodiment, the GMLC may provide additional location service responses to the D2D server periodically, based on a trigger, a threshold, or any time the location of the UE changes.

In one embodiment, if UE A requests discovery alerts only when one or more peer UEs are within the D2D discovery range, the D2D server may send a discovery alert to UE A at 1014. The discovery alert may include application IDs of the one or more peer UEs.

In another embodiment, if UE A has requested network-assisted D2D connection establishment, the D2D server may send a discovery warning message at 1014 and 1016 to each UE that may be involved in the D2D communication. In some embodiments, the discovery warning message may include an application ID (for user identification) and a permanent or temporary link layer ID (for connection establishment) for each other UE that may be involved in the D2D communication. In one embodiment, the temporary link layer ID may be assigned by the D2D server. The discovery warning message may also include other auxiliary information for the D2D connection establishment process, such as timing, D2D roles (for example, in WiFi Direct, one UE is the group owner and other UEs are guests), etc.

In some embodiments, the P2P application may not be associated with or communicate with a P2P application server. However, despite this, the P2P application may support network-assisted D2D communication.

For each application that a user wants to enable using network-assisted D2D, the UE can register the P2P application ID and application-specific D2D setting parameters (e.g., discovery permissions) with the D2D server. The D2D server may know the UE's device identifier (e.g., IMSI) and may map the UE's device identifier to the user's P2P application ID.

A user may request assistance in discovering a specific user (and possibly establishing a D2D connection with the specific user) by sending a D2D discovery request to a D2D server that includes the desired user's P2P application ID and the D2D server name (if the desired user has a separate D2D server). If the user/UE does not have information about the desired user's D2D capabilities and/or D2D server name, the D2D server may resolve the D2D server name based on the P2P application ID (e.g., by querying all local D2D servers).

If the desired user is available for D2D communication with the requesting user, the D2D server may assist in user discovery and possibly connect directly with the desired user, otherwise, the D2D server may respond with a failure notification.

In some embodiments, the GMLC may be replaced by the SLP in the processes of Figures 9 and 10 for discovery assistance performed on the user plane.

FIG11 illustrates one possible signal flow for device location updates using the SUPL architecture. This example is for a network-initiated, immediate location request in proxy mode from the Secure User Plane Location Architecture (as defined by the Open Mobile Alliance, Version 2.0, approved on April 17, 2012 (OMA-AD-SUPL-V2_0-20120417-A), the entire contents of which are incorporated herein by reference). See OMA-AD-SUPL-V2_0-20120417-A, for example, at FIG9 . The signal flow may vary somewhat between embodiments depending on the type of SUPL location update used (periodic, triggered, or a combination thereof). In some cases, the signal flow begins with a location request from an SLP agent (e.g., SLP agent 204 or UE) to SLP 120.

The signal flow illustrates communication between an SLP proxy (also referred to as a SUPL proxy), a home SLP (H-SLP), and a UE. The SLP proxy may include, for example, an SLP proxy included in a D2D server or other device. The H-SLP may include an SLP within an HPLMN that hosts a D2D server that hosts the SLP proxy. The UE may include a mobile terminal configured to connect to the HPLMN.

In the signal flow, the SLP proxy issues a Mobile Location Protocol (MLP) Standard Location Immediate Request (SLIR) message to the H-SLP at 1102. At 1104, the H-SLP initiates a SUPL session with the UE by sending a User Plane Location Protocol (ULP) SUPL Initiate (INIT) message. This message contains the requested positioning method and the SUPL Position Center (SPC) address. When the UE receives the ULP SUPL INIT, it establishes a secure connection to the H-SLP at 1106. At 1108, the UE establishes a secure connection to the H-SLP and sends a ULP SUPL Positioning (POS) INIT message to begin the positioning session with the H-SLP. This message contains UE capabilities. The H-SLP then determines the positioning method needed to determine the UE's location at 1110 and exchanges several subsequent ULP SUPL POS messages containing the positioning protocol being used (i.e., Radio Resource Location Service (LCS) Protocol (RRLP), Radio Resource Control (RRC), and/or Telecommunications Industry Alliance 801 Positioning Service (TIA-801)). When the position calculation is complete, the H-SLP sends a ULP SUPL END message to the UE at 1112 to notify it of the end of the SUPL session. The UE then releases the secure connection to the H-SLP. The H-SLP sends the position estimate back to the SLP proxy in a Mobile Location Platform (MLP) Standard Location Immediate Answer (SLIA) message at 1114.

Figure 12 illustrates an example mobile device, such as a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a cell phone, or another type of mobile wireless device. The mobile device can include one or more antennas configured to communicate with a transmitting station, such as a base station (BS), an evolved Node B (eNB), a baseband unit (BBU), a remote radio head (RH), a remote radio equipment (RRE), a relay station (RS), a radio equipment (RE), or another type of wireless wide area network (WWAN) access point. The mobile device can be configured to communicate using at least one wireless communication standard including 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and Wi-Fi. The mobile device can communicate using separate antennas for each wireless communication standard or a shared antenna for multiple wireless communication standards. The mobile device can communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and/or a WWAN.

FIG12 also provides a diagram of a microphone and one or more speakers that can be used for audio input and output from a mobile device. The display screen can be a liquid crystal display (LCD) screen or other types of display screens, such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen can use capacitive, resistive, or another type of touch screen technology. An application processor and a graphics processor can be coupled to an internal memory to provide processing and display capabilities. A non-volatile memory port can also be used to provide data input/output options to the user. The non-volatile memory port can also be used to expand the storage capacity of the mobile device. A keyboard can be integrated with the mobile device or wirelessly connected to the mobile device to provide additional user input. A virtual keyboard can also be provided using a touch screen.

Example

The following examples are directed to other embodiments.

Example 1 is a UE configured to utilize D2D communication for a P2P application. The UE includes a transceiver configured to transmit and receive signals, and a processing unit. The processing unit is configured to cause the UE to register with a D2D server. The processing unit is configured to receive an indication of one or more D2D-capable peer UEs from the P2P application server. The processing unit is configured to cause the UE to send a D2D discovery request to the D2D server for network-assisted discovery of a selected UE from the one or more D2D-capable peer UEs. The processing unit is further configured to cause the UE to receive an alert when the selected UE is within a defined discovery range. Sending the D2D discovery request and receiving the alert include transmitting and receiving on a user plane.

In Example 2, the processing unit of Example 1 is further configured to cause the UE to send a proximity request to the D2D server and receive an indication of one or more D2D-capable peer UEs within a defined range.

In Example 3, the processing unit of any of Examples 1-2 is further configured to cause the UE to send a P2P registration request in response to a user request to register with the P2P application server.

In Example 4, the P2P registration request of any of Examples 1-3 includes at least one of: an application layer identifier for the user, an indication of provided P2P services, content, or permissions, and a D2D server name.

In Example 5, the D2D server of any of Examples 1-4 includes sending a D2D registration request.

In Example 6, the D2D registration request of any of Examples 1-5 includes at least one of: one or more application layer identifiers for users associated with the UE, D2D permissions, D2D capabilities, and a device identifier.

In Example 7, the D2D discovery request of any of Examples 1-6 includes at least one of: an application layer identifier for a user associated with the selected UE, an identifier for a D2D server associated with the selected UE, and a time window for discovery.

In Example 8, the processing unit of any of Examples 1-7 is further configured to cause the UE to receive a discovery permission request from the D2D server. The discovery permission request includes an application layer identifier for a peer UE requesting a D2D connection with the UE. The processing unit is further configured to provide a discovery permission response in response to the discovery permission request.

Example 9 is a D2D server for assisting device discovery in a D2D communication configuration for P2P applications. The D2D server includes a processing unit and a memory coupled to the processing unit. The memory stores instructions that, when executed by the processing unit, cause the D2D server to register multiple D2D-capable peer mobile terminals in response to a registration request from each of the multiple D2D-capable peer mobile terminals. The instructions also cause the D2D server to receive a D2D discovery request from a first mobile terminal over a data channel for network-assisted discovery of a second mobile terminal. The instructions also cause the D2D server to send a location service request to a 3GPP SLP. The instructions also cause the D2D server to receive a location service response from the SLP. The instructions also cause the D2D server to send a warning to the first mobile terminal over the data channel when the second mobile terminal is within a defined discovery range.

In Example 10, the registration request from each of the plurality of peer D2D capable mobile terminals of Example 9 includes at least one of: an application layer identifier, a D2D permission, a D2D capability, and a device identifier.

In Example 11, the instructions of any of Examples 9-10 further cause the D2D server to provide, in response to the proximity request, a list of mobile terminals configured for D2D communication that are proximate to the first mobile terminal.

In Example 12, the proximity request of any of Examples 9-11 is received from the first mobile terminal.

In Example 13, the proximity request of any of Examples 9-12 is received from a P2P application server from which the first mobile terminal has requested P2P service.

In Example 14, the instructions of any of Examples 9-13 further cause the D2D server to send a discovery permission request to the second mobile terminal in response to receiving the D2D discovery request.

In Example 15, the location service request of any of Examples 9-14 includes a device identifier of the first mobile terminal.

In Example 16, the instructions of any of Examples 9-15 further cause the D2D server to send an alert to the second mobile terminal when the first mobile terminal is within the defined discovery range.

In Example 17, the sending of the warning to the second mobile terminal of Example 16 includes sending the warning to a D2D server corresponding to the second mobile terminal.

In Example 18, the sending the location service request of any of Examples 9-17 includes sending the location service request including one or more alert conditions.

In Example 19, the instructions of any of Examples 9-18 further comprise determining a boundary area for triggering location reporting, wherein the one or more alert conditions include defining the boundary area as a criterion for reporting the location of the mobile terminal.

Example 20 is a non-transitory computer-readable storage medium having instructions stored thereon that, when executed by a processor, cause the processor to perform a method for network-assisted discovery of a peer user equipment (UE) in a D2D communication arrangement for a P2P application. The method includes communicating on a control channel to configure wireless communication of a first UE. The method includes performing assisted D2D discovery at the first UE via a shared channel. The method includes sending, by the first UE, a P2P service request to a first server. The method includes receiving, from the first server, a P2P application indicator of at least one D2D-capable peer UE. The method includes sending, to a second server, a request for network-assisted discovery of a selected UE from the at least one D2D-capable peer UE. The method also includes receiving an alert from the second server when the selected UE is within a defined discovery range.

In Example 21, the first server of Example 20 includes a P2P application server and the second server includes a D2D server.

In Example 22, the first server and the second server of any of Examples 20-21 are hosted on a single physical server.

In Example 23, the method of any of Examples 20-22 also includes registering one or more of the following with the first server: an application layer identifier of the first UE, an indication of a P2P service, content, or authority provided by the first UE, and an indication of a D2D server associated with the first UE.

Example 24 is a method for D2D communication for a P2P application. The method includes registering with a D2D server. The method includes receiving an indication of one or more D2D-capable peer UEs from the P2P application server. The method includes sending a D2D discovery request to the D2D server for network-assisted discovery of a selected UE from the one or more D2D-capable peer UEs. The method includes receiving an alert when the selected UE is within a defined discovery range. Sending the D2D discovery request and receiving the alert include sending and receiving over a user plane.

In Example 25, the method of Example 24 includes sending a proximity request to a D2D server and receiving an indication of one or more D2D capable peer UEs within a defined range.

In Example 26, the method of any of Examples 24-25 further comprises sending a P2P registration request in response to a user request to register with the P2P application server.

In Example 27, the P2P registration request of any of Examples 24-26 includes at least one of: an application layer identifier for the user, an indication of provided P2P services, content, or rights, and a D2D server name.

In Example 28, the D2D server of any of Examples 24-27 includes sending a D2D registration request.

In Example 29, the D2D registration request of any of Examples 24-28 includes at least one of: one or more application layer identifiers for users associated with the UE, D2D permissions, D2D capabilities, and a device identifier.

In Example 30, the D2D discovery request of any of Examples 24-29 includes at least one of: an application layer identifier for a user associated with the selected UE, an identifier for a D2D server associated with the selected UE, and a time window for discovery.

In Example 31, the method of any of Examples 24-30 further includes receiving a discovery permission request from the D2D server. The discovery permission request includes an application layer identifier for a peer UE requesting a D2D connection with the UE. The processing unit is further configured to provide a discovery permission response in response to the discovery permission request.

Example 32 is a method for assisting device discovery in a D2D communication arrangement for a P2P application. The method includes registering a plurality of D2D-capable peer mobile terminals in response to a registration request from each of the plurality of D2D-capable peer mobile terminals. The method includes receiving a D2D discovery request from a first mobile terminal for network-assisted discovery of a second mobile terminal over a data channel. The method includes sending a location service request to a 3GPP SLP. The method includes receiving a location service response from the SLP. The method includes sending an alert to the first mobile terminal over the data channel when the second mobile terminal is within a defined discovery range.

In Example 33, the registration request from each of the plurality of peer D2D capable mobile terminals of Example 32 includes at least one of: an application layer identifier, a D2D permission, a D2D capability, and a device identifier.

In Example 34, the method of any of Examples 32-33 further includes providing, in response to the proximity request, a list of mobile terminals configured for D2D communication in proximity to the first mobile terminal.

In Example 35, the proximity request of any of Examples 32-34 is received from the first mobile terminal.

In Example 36, the proximity request of any of Examples 32-35 is received from a P2P application server from which the first mobile terminal has requested P2P service.

In Example 37, the method of any of Examples 32-36 further includes sending a discovery permission request to the second mobile terminal in response to receiving the D2D discovery request.

In Example 38, the location service request of any of Examples 32-37 includes a device identifier of the first mobile terminal.

In Example 39, the method of any of Examples 32-38 further includes sending an alert to the second mobile terminal when the first mobile terminal is within the defined discovery range.

In Example 40, the sending of the warning to the second mobile terminal of Example 39 includes sending the warning to a D2D server corresponding to the second mobile terminal.

In Example 41, the sending the location service request of any of Examples 32-40 includes sending the location service request including one or more alert conditions.

In Example 42, the method of any of Examples 32-42 further includes determining a boundary area for triggering location reporting, wherein the one or more alert conditions include defining the boundary area as a criterion for reporting the location of the mobile terminal.

Example 43 is a method for network-assisted peer user equipment (UE) discovery in a D2D communication arrangement for P2P applications. The method includes communicating on a control channel to configure wireless communication of a first UE. The method includes performing assisted D2D discovery at the first UE via a shared channel. The method includes sending, by the first UE, a P2P service request to a first server. The method includes receiving, from the first server, a P2P application indicator of at least one D2D-capable peer UE. The method includes sending, to a second server, a request for network-assisted discovery of a selected UE from the at least one D2D-capable peer UE. The method also includes receiving an alert from the second server when the selected UE is within a defined discovery range.

In Example 44, the first server of Example 43 includes a P2P application server and the second server includes a D2D server.

In Example 45, the first server and the second server of any of Examples 43-44 are hosted on a single physical server.

In Example 46, the method of any of Examples 43-45 also includes registering one or more of the following with the first server: an application layer identifier of the first UE, an indication of a P2P service, content, or authority provided by the first UE, and an indication of a D2D server associated with the first UE.

Various techniques or aspects or portions thereof may be in the form of program code (i.e., instructions) embodied in a tangible medium, such as a floppy disk, CD-ROM, hard disk, non-transitory computer-readable storage medium, or any other machine-readable storage medium, wherein when the program code is loaded and executed by a machine such as a computer, the machine becomes an apparatus for practicing the various techniques. In the case of executing program code on a programmable computer, the computing device may include: a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be: RAM, EPROM, flash drive, optical drive, hard disk drive, or other medium for storing electronic data. The base station and mobile station may also include a transceiver module, a counter module, a processing module, and/or a clock module or timer module. One or more programs that can implement or utilize the techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high-level procedural programming language or an object-oriented programming language to communicate with the computer system. However, if desired, the program(s) can be implemented in assembly language or machine language. In any case, the language can be a compiled and interpreted language and can be combined with hardware implementations.

The techniques described above can be implemented by programmable circuitry or configured by software and/or firmware, or they can be implemented entirely by dedicated hardwired circuitry, or a combination of these forms. Such dedicated circuitry (if any) can be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.

The software or firmware for implementing the technology described herein can be stored on a machine-readable storage medium and can be executed by one or more general-purpose or special-purpose programmable microprocessors. As used herein, the term "machine-readable medium" includes any mechanism capable of storing information in a form accessible by a machine (a machine can be, for example, a computer, a network device, a cellular phone, a PDA, a manufacturing tool, any device with one or more processors, etc.). For example, machine-accessible media include recordable/non-recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.).

The term "logic" as used herein can include, for example, dedicated hard-wired circuitry, software and/or firmware in combination with programmable circuitry, or combinations thereof.

Although the present disclosure includes references to specific example embodiments, it will be appreciated that the claims are not limited to the described embodiments, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded as illustrative rather than realistic.

Claims (27)

1. A computer-readable storage medium storing instructions that, when executed by one or more processors of a server, cause the one or more processors to perform the following operations: Receive an application registration request for the application from the first user equipment (UE); Process a proximity request from the first UE to perform network assistance in discovering the second UE, wherein the proximity request includes one or more of an application identifier corresponding to the application and an application layer identifier for a user associated with the second UE; In response to the proximity request from the first UE, which is to perform network assistance in discovering the second UE, a location service request is sent to the Secure User Plane Location Platform (SUPL) (SLP). Receive a location service response from the SLP; and When the second UE is within the defined discovery range of the first UE, a proximity warning is sent to the first UE, wherein the proximity warning includes auxiliary information to assist in the discovery of the second UE, wherein the auxiliary information includes a specified peer group owner and a permanent link layer identifier corresponding to the second UE. 2. The computer-readable storage medium of claim 1, wherein the instructions further cause the one or more processors to request a location update for the second UE from a second server corresponding to the second UE. 3. The computer-readable storage medium of claim 2, wherein the instructions further cause the one or more processors to receive an indication of the location of the second UE from the second server corresponding to the second UE. 4. The computer-readable storage medium of claim 1, wherein the instructions further cause the one or more processors to process the registration request, wherein the registration request corresponding to the first UE includes a permanent link layer device identifier corresponding to the first UE. 5. The computer-readable storage medium of claim 1, wherein the proximity warning includes auxiliary information to assist in the discovery of the second UE, wherein the auxiliary information includes: The temporary link layer identifier corresponding to the second UE. 6. The computer-readable storage medium of claim 1, wherein the proximity request further comprises... The time window used for discovery. 7. A user equipment (UE) configured to use direct communication for peer-to-peer applications, comprising: A transceiver configured to transmit and receive signals; and A processing unit configured to cause the UE to perform the following operations: Registering an application with a peer application server, wherein the processing unit is configured to cause the UE to send an application registration request to register the application with the peer application server; The transceiver is used to send a proximity request to the mobile communication network for network assistance in discovering a peer UE, wherein the proximity request includes one or more of an application identifier corresponding to the application and an application layer identifier for a user associated with the peer UE. Communicating with the Secure User Plane Location Platform (SUPL) to enable the SLP to assess the location of the UE; and The processing unit receives a proximity warning from the mobile communication network, wherein the mobile communication network sends the proximity warning when it determines, based on a location service response from the SLP, that the peer UE is within the defined discovery range of the UE, wherein the proximity warning includes auxiliary information to assist in the discovery of the peer UE, and wherein the processing unit is further configured to enable the UE to discover the peer UE based on the auxiliary information, wherein the auxiliary information includes a designated peer group owner for direct communication and a permanent link layer identifier corresponding to the peer UE. 8. The UE of claim 7, wherein the UE and the peer UE are registered with different servers for proximity services. 9. The UE of claim 7, wherein the processing unit is further configured to cause the UE to send a registration request to the mobile communication network to register the UE for the proximity service. 10. The UE of claim 9, wherein, in order to send the registration request, the processing unit is configured to send a link layer identifier for the UE for direct discovery and communication. 11. The UE of claim 7, wherein the application registration request includes the application identifier and an identifier corresponding to the UE. 12. The UE of claim 7, wherein the proximity request further includes: a time window for the proximity request. 13. The UE of claim 7, wherein the auxiliary information includes a temporary link layer identifier for the peer UE. 14. A computer-readable storage medium storing instructions that, when executed by one or more processors of a user equipment (UE), cause the one or more processors to perform the following operations: Generate an application registration request for the server, wherein the application registration request is used to register the application with the peer application server; Generate a proximity request for the server to perform network assistance in discovering peer UEs, wherein the proximity request includes one or more of an application identifier corresponding to the application and an application layer identifier for a user associated with the peer UE. Communicating with the Secure User Plane Location Platform (SUPL) to enable the SLP to assess the location of the UE; and Decode a proximity warning from the server, wherein the proximity warning is sent when the server detects that the peer UE is within the defined discovery range of the UE based on a location service response from the SLP, wherein the proximity warning includes auxiliary information to assist in the discovery of the peer UE, wherein the instruction further causes the one or more processors to discover the peer UE based on the auxiliary information, wherein the auxiliary information includes a designated peer group owner for direct communication and a permanent link layer identifier corresponding to the peer UE. 15. The computer-readable storage medium of claim 14, wherein the UE and the peer UE are registered with different servers for proximity services. 16. The computer-readable storage medium of claim 14, wherein the instructions further cause the one or more processors to prepare a registration request to be sent to the server for registering the UE with respect to a proximity service. 17. The computer-readable storage medium of claim 16, wherein the registration request includes the UE's link layer identifier for direct discovery and communication. 18. The computer-readable storage medium of claim 14, wherein the application registration request includes the application identifier and an identifier corresponding to the UE. 19. The computer-readable storage medium of claim 14, wherein the proximity request further comprises: a time window for the proximity request. 20. The computer-readable storage medium of claim 14, wherein the auxiliary information includes a temporary link layer identifier for the peer UE. 21. An apparatus for a user equipment (UE) configured to use direct communication for peer-to-peer applications, comprising: Processor, the processor being configured to: Registering an application with a peer application server, wherein the processor is configured to format an application registration request to register the application with the peer application server; Prepare a proximity request to be sent to the mobile communication network for network assistance in discovering a peer UE, wherein the proximity request includes one or more of an application identifier corresponding to the application and an application layer identifier for a user associated with the peer UE. Communicating with the Secure User Plane Location Platform (SUPL) to enable the SLP to assess the location of the UE; and Processing a proximity warning from the mobile communication network, wherein the proximity warning is sent by the mobile communication network when the mobile communication network detects that the peer UE is within the defined discovery range of the UE based on a location service response from the SLP, wherein the proximity warning includes auxiliary information to assist in the discovery of the peer UE, wherein the processor is further configured to enable the UE to discover the peer UE based on the auxiliary information, wherein the auxiliary information includes a designated peer group owner for direct communication and a permanent link layer identifier corresponding to the peer UE. 22. The apparatus of claim 21, wherein the UE and the peer UE are registered with different servers for proximity services. 23. The apparatus of claim 21, wherein the processor is further configured to: prepare a registration request to be sent to the mobile communication network for registering the UE with respect to a proximity service. 24. The apparatus of claim 23, wherein the registration request includes the UE's link layer identifier for direct discovery and communication. 25. The apparatus of claim 21, wherein the application registration request includes the application identifier and an identifier corresponding to the UE. 26. The apparatus of claim 21, wherein the proximity request further comprises: a time window for the proximity request. 27. The apparatus of claim 21, wherein the auxiliary information includes a temporary link layer identifier for the peer UE.