Inter-device communication authorization and data sniffing in wireless communication systems

Systems and methods for user equipment (UE) for inter-device communication authorization and data sniffing in wireless communication systems are provided. A UE may communicate directly with another UE over a direct inter-device communication link when they are located in proximity. The UE may receive data sniffing related parameters corresponding to the inter-device communication link from a network entity, e.g. a mobile management entity (MME). The UE may store data exchanged over the inter-device communication link in a buffer and upload the stored data to a secure server in a network periodically or upon receiving a request from the network. Long term evolution (LTE) downlink or uplink radio resources may be used for the data exchange over the inter-device communication link.

TECHNICAL FIELD

The present disclosure generally relates to communications in wireless communication systems, and more particularly, to inter-device communication authorization and data sniffing in wireless communication systems.

BACKGROUND

In wireless networks such as Long Term Evolution (LTE) and LTE-Advanced communication networks, a user equipment (UE) may communicate with other UEs via a base station and an evolved packet core (EPC) network. For example, a UE may send data packets to its serving base station on an uplink. The serving base station may forward the data packets to the EPC network and the EPC network may forward the data packet to another base station or to the same base station that is serving another UE. Data transfer between the UEs is routed through the base station and the EPC. The communication between the UEs is controlled by the policies set by the operator administering the network.

The UEs may communicate directly with each other using other radio access technology (RAT), such as, wireless local area network (WLAN) or Bluetooth when the UEs are located in close proximity and have access to the other RAT. However, this multi-RAT communication requires the availability of the other RAT and the capability of the UEs to operate in the other RAT. Moreover, handover from cellular technology to other RATs may result in service interruption and dropped calls.

DETAILED DESCRIPTION

The present disclosure is directed to systems, methods, and apparatuses for inter-device communication in cellular wireless communication systems. In the current cellular communication system, data transfer between UEs has to be routed through a base station and a core network. When UEs located in close proximity communicate with each other, it would be advantageous for the UEs to communicate via a direct inter-device communication link between them, instead of transferring the data via a network. By providing a direct inter-device communication link between the UEs, improved overall spectral efficiency may be achieved. Moreover, the direct link between the UEs requires lower transmit power at the UE compared to transmitting to the base station, thereby resulting in battery savings at the UEs. Additionally, communicating over the direct link between the UEs may improve quality of service (QoS).

Although the UE may be able to communicate over a direct communication link using another RAT, such as, WLAN, Bluetooth, etc., it requires availability of the services of the other RAT and also requires implementation of the other RAT at the UE. Furthermore, service interruptions and dropped calls may result from switching or handover between different RATs. Therefore, it may be advantageous to enable communications over the inter-device communication link using the same cellular radio access technology and operating in the same radio band.

Reference will now be made in detail to example approaches implemented according to the disclosure; the examples are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

FIG. 1illustrates an example cellular wireless communication system100in which systems and methods consistent with this disclosure may be implemented. The cellular network system100shown inFIG. 1includes one or more base stations (i.e.,112aand112b). In the LTE example ofFIG. 1, the base stations are shown as evolved Node Bs (eNBs)112aand112b, although base stations operate in any wireless communications system, including for example, macro cell, femto cell, relay cell, and pico cell. Base stations are nodes that can relay signals for mobile devices, also referred to herein as user equipment, or for other base stations. The base stations are also referred to as access node devices. The example LTE telecommunications environment100ofFIG. 1includes one or more radio access networks110, core networks (CNs)120, and external networks130. In certain implementations, the radio access networks may be Evolved Universal Terrestrial Radio Access Networks (EUTRANs). In addition, core networks120may be evolved packet cores (EPCs). Further, as shown, one or more mobile electronic devices102a,102boperate within the LTE system100. In some implementations, 2G/3G systems140, e.g., Global System for Mobile communication (GSM), Interim Standard 95 (IS-95), Universal Mobile Telecommunications System (UMTS) and Code Division Multiple Access (CDMA2000) may also be integrated into the LTE telecommunication system100.

In the example LTE system shown inFIG. 1, the EUTRAN110includes eNB112aand eNB112b. Cell114ais the service area of eNB112aand Cell114bis the service area of eNB112b. User equipment (UEs)102aand102boperate in Cell114aand are served by eNB112a. The EUTRAN110can include one or more eNBs (e.g., eNB112aand eNB112b) and one or more UEs (e.g., UE102aand UE102b) can operate in a cell. The eNBs112aand112bcommunicate directly to the UEs102aand102b. In some implementations, the eNB112aor112bmay be in a one-to-many relationship with the UEs102aand102b, e.g., eNB112ain the example LTE system100can serve multiple UEs (i.e., UE102aand UE102b) within its coverage area Cell114a, but each of UE102aand UE102bmay be connected to one serving eNB112aat a time. In some implementations, the eNBs112aand112bmay be in a many-to-many relationship with the UEs, e.g., UE102aand UE102bcan be connected to eNB112aand eNB112b. The eNB112amay be connected to eNB112bsuch that handover may be conducted if one or both of the UEs102aand102btravels, e.g., from cell114ato cell114b. The UEs102aand102bmay be any wireless electronic device used by an end-user to communicate, for example, within the LTE system100.

The UEs102aand102bmay transmit voice, video, multimedia, text, web content and/or any other user/client-specific content. The transmission of some content, e.g., video and web content, may require high channel throughput to satisfy the end-user demand. In some instances, however, the channel between UEs102a,102band eNBs112a,112bmay be contaminated by multipath fading due to the multiple signal paths arising from many reflections in the wireless environment. Accordingly, the UEs' transmission may adapt to the wireless environment. In short, the UEs102aand102bmay generate requests, send responses or otherwise communicate in different means with Evolved Packet Core (EPC)120and/or Internet Protocol (IP) networks130through one or more eNBs112aand112b.

In some implementations, the UEs102aand102bmay communicate over an inter-device communication link when they are located in close proximity to one another, without routing the data through the eNB112a. The boundary of the distance of the inter-device communication link may be limited by the transmission power of the UEs. In one example, close proximity could be a few meters. In another example, close proximity could be tens of meters. It is also possible that in certain circumstances, the close proximity may mean larger distance such as hundreds of meters. For example, the UEs102aand102bmay communicate directly over the inter-device communication link104, instead of communicating with each other through their links with the eNB112a, i.e.,106and108respectively. The inter-device communication link may also be referred to as a device-to-device (D2D) communication link. The UEs102aand102bmay simultaneously maintain an active communication link with the eNB112asuch that the UEs102aand102bmay still receive messages from the eNB or other UEs, when communicating with each other over the direct inter-device link.

Examples of UEs include, but are not limited to, a mobile phone, a smart phone, a telephone, a television, a remote controller, a set-top box, a computer monitor, a computer (including a tablet computer such as a BlackBerry® Playbook tablet, a desktop computer, a handheld or laptop computer, a netbook computer), a personal digital assistant (PDA), a microwave, a refrigerator, a stereo system, a cassette recorder or player, a DVD player or recorder, a CD player or recorder, a VCR, an MP3 player, a radio, a camcorder, a camera, a digital camera, a portable memory chip, a washer, a dryer, a washer/dryer, a copier, a facsimile machine, a scanner, a multi-functional peripheral device, a wristwatch, a clock, a game device, etc. The UE102aor102bmay include a device and a removable memory module, such as a Universal Integrated Circuit Card (UICC) that includes a Subscriber Identity Module (SIM) application, a Universal Subscriber Identity Module (USIM) application, or a Removable User Identity Module (R-UIM) application. Alternatively, the UE102aor102bmay include the device without such a module. The term “UE” can also refer to any hardware or software component that can terminate a communication session for a user. In addition, the terms “user equipment,” “UE,” “user equipment device,” “user agent,” “UA,” “user device,” and “mobile device” can be used synonymously herein.

A radio access network is part of a mobile telecommunication system which implements a radio access technology, such as Universal Mobile Telecommunications System (UMTS), CDMA2000 and 3rd Generation Partnership Project (3GPP) LTE. In many applications, the Radio Access Network (RAN) included in an LTE telecommunications system100is called an EUTRAN110. The EUTRAN110can be located between the UEs102a,102band EPC120. The EUTRAN110includes at least one eNB112aor112b. The eNB can be a radio base station that may control all, or at least some, radio related functions in a fixed part of the system. One or more of eNB112aor112bcan provide radio interface within their coverage area or a cell for the UEs102a,102bto communicate. The eNBs112aand112bmay be distributed throughout the cellular network to provide a wide area of coverage. The eNBs112aand112bmay directly communicate with one or more UEs102a,102b, other eNBs, and the EPC120.

The eNBs112aand112bmay be the end point of the radio protocols towards the UEs102a,102band may relay signals between the radio connection and the connectivity towards the EPC120. The communication interface between the eNB and the EPC is often referred to as an S1 interface. In certain implementations, EPC120is a central component of a core network (CN). The CN can be a backbone network, which may be a central part of the telecommunications system. The EPC120can include a mobility management entity (MME), a serving gateway (S-GW), and a packet data network gateway (PGW). The MME may be the main control element in the EPC120responsible for the functionalities comprising the control plane functions related to subscriber and session management. The SGW can serve as a local mobility anchor, such that the packets are routed through this point for intra EUTRAN110mobility and mobility with other legacy 2G/3G systems140. The S-GW functions may include user plane tunnel management and switching. The PGW may provide connectivity to the services domain comprising external networks130, such as the IP networks. The UEs102a,102b, EUTRAN110, and EPC120are sometimes referred to as the evolved packet system (EPS). It is to be understood that the architectural evolvement of the LTE system100is focused on the EPS. The functional evolution may include both EPS and external networks130.

Though described in terms ofFIG. 1, the present disclosure is not limited to such an environment. In general, cellular telecommunication systems may be described as cellular networks made up of a number of radio cells, or cells that are each served by a base station or other fixed transceiver. The cells are used to cover different locations in order to provide radio coverage over an area. Example cellular telecommunication systems include Global System for Mobile Communication (GSM) protocols, Universal Mobile Telecommunications System (UMTS), 3GPP Long Term Evolution (LTE), and others. In addition to cellular telecommunication systems, wireless broadband communication systems may also be suitable for the various implementations described in the present disclosure. Example wireless broadband communication systems include IEEE 802.11 WLAN, IEEE 802.16 WiMAX network, etc.

FIG. 2illustrates an example access node device200consistent with certain aspects of this disclosure. The access node device200includes a processing module202, a wired communication subsystem204, and a wireless communication subsystem206. The processing module202can include one or more processing components (alternatively referred to as “processors” or “central processing units” (CPUs)) operable to execute instructions associated with managing IDC interference. The processing module202can also include other auxiliary components, such as random access memory (RAM), read only memory (ROM), secondary storage (for example, a hard disk drive or flash memory). Additionally, the processing module202can execute certain instructions and commands to provide wireless or wired communication, using the wired communication subsystem204or a wireless communication subsystem206. One skilled in the art will readily appreciate that various other components can also be included in the example access node device200without departing from the principles of the present disclosure.

FIG. 3illustrates an example user equipment device300consistent with certain aspects of the present disclosure. The example user equipment device300includes a processing unit302, a computer readable storage medium304(for example, ROM or flash memory), a wireless communication subsystem306, a user interface308, and an I/O interface310.

The processing unit302may include components and perform functionality similar to the processing module202described with regard toFIG. 2. The wireless communication subsystem306may be configured to provide wireless communications for data information or control information provided by the processing unit302. The wireless communication subsystem306can include, for example, one or more antennas, a receiver, a transmitter, a local oscillator, a mixer, and a digital signal processing (DSP) unit. In some implementations, the wireless communication subsystem306may receive or transmit information over a direct inter-device communication link. In some implementations, the wireless communication subsystem306can support MIMO transmissions.

The user interface308can include, for example, one or more of a screen or touch screen (for example, a liquid crystal display (LCD), a light emitting display (LED), an organic light emitting display (OLED), a microelectromechanical system (MEMS) display, a keyboard or keypad, a tracking device (e.g., trackball, trackpad), a speaker, and a microphone).

The I/O interface310can include, for example, a universal serial bus (USB) interface. One skilled in the art will readily appreciate that various other components can also be included in the example UE device300.

For UEs to communicate over a direct inter-device communication link, an inter-device communication link is enabled between the UEs. The direct inter-device communication link allows data exchange between the UEs, without routing the data through the base station and the core network. Descriptions will now be made about methods for the inter-device communication authorization and data sniffing in the wireless communication system, according to certain examples of the present disclosure.

During an inter-device communication, a UE may maintain an active link with its serving eNB or an associated eNB and simultaneously communicate with the eNB while communicating with other UEs over the inter-device link. As will be described later, this simultaneous communication enables the network to establish a secure communication link between the UEs to sniff data packets exchanged over the direct inter-device communication link for selective data monitoring.

The inter-device communication capability may be assigned by a network operator, e.g., with an approval from an appointed authority. For example, such an authority may be a government agency, such as homeland security/ministry of defense based on the jurisdiction. The appointed authority may also be an employer who supplies devices to the employees. The network can sniff data exchanged over the inter-device link from an on-going inter-device communication link or from data transmitted over a previously established inter-device call when necessary. The sniffed data may be loaded to a network server for further evaluation by the authority. The data sniffing function can be enabled by the network without knowledge of the user using the device. This process of data sniffing may be authorized by a government telecommunication authority, such as Federal Communications Commission (FCC) and may be disabled on certain authorized devices.

The network may enable or disable this data sniffing function in the UE at any time. In one alternative, the data sniffing could be done in real-time manner. For example the data exchanged over the inter-device communication link could be directly transferred to the network server for analysis. In another example, some properties about the exchanged data over the inter-device communication link may be transferred to the network, e.g., the IDs of the transmitter and receiver, the amount of data, the type of the data, etc. In yet another example, only part of the exchanged data over the inter-device communication link may be transferred to the network server. In yet another example, the exchanged data could be pre-processed and the processed results may be delivered to the network server. The network could configure the data sniffing operations and the parameters to the UE.

In another alternative, the network could pre-configure the data sniffing operations and relevant parameters. The network may also configure the reporting operations and relevant parameters. For example, the network may configure the UE to report all the data calls over the inter-device communication link with the relevant IDs, and to report the data at a particular interval. For example, the reporting period could be set to be daily. The UE then records the data calls over the in-device communication link and report to the server every day. This pre-configuration could be dynamically updated by the network. The network could also define some reporting events. Whenever a reporting event is triggered, the UE could start the corresponding reporting operation. For example, the reporting event could be whenever UE communicates with a particular UE, the exchanged data should be stored and transmitted to the network server. In general, the reporting could be event based or period based. The reporting could also be request-based. For example, whenever there is a request from the network for data sniffing, the UE may perform accordingly. The data sniffing function may be separately defined from the reporting operation.

The network may enable/disable/configure/reconfigure the data sniffing functions in the UE and its relevant parameters. Normally these messages are NAS messages. Further, in some implementation, only one UE involved in the inter-device communication is configured with the data sniffing function while the other UE is not. In some other implementations, both UEs may be configured with the data sniffing function. The user may not be aware that the data sniffing function is running on the UE. The incurred charge to transfer the sniffed data to the network server may not be billed to the user, which makes the operation mostly transparent to the user. However, in some instances, the user may have the choice to disable the data sniffing function in the UE, for example, some particular authorized users. To disable this function, the user may need special password and authority.

FIG. 4illustrates an example cellular wireless communication system400supporting data sniffing of an inter-device communication link, in accordance with an example of the present disclosure. UEs, UE0, UE1 and UE2 are connected to the LTE EPC via Cell-S and Cell-N. UE0 and UE1 are connected to the EPC via Cell-S and UE2 is connected to the EPC via Cell-N. As shown inFIG. 4, data exchanged between devices UE1 and UE0 can be sniffed by the LTE network from either UE1 or UE0 or both via Cell-S402and the data can be delivered to a secure server. The data may be encrypted by the device before delivering it to the secure server. Similarly, the data exchanged between UE0 and UE2 can be retrieved from either UE0 via Cell-S402or UE2 via Cell-N404. The sniffed data can be routed to a secure server in the Core Network406for further evaluation.

The data sniffing function may be initiated during the inter-device call setup. Generally the activation or deactivation of the data sniffing function is not visible to the user operating the device. Data exchanged during the inter-device call is stored by default in a secure buffer within the device. The secure buffer may be similar to one used to store various encryption and security keys. These secure buffers are not accessible to the user using the device. This data may be stored in a non-volatile memory such as, EEPROM, such that the data is available even after the device loses power, the data is erasable when the timer for data storage expired, and the memory is rewritable when new data arrives. Controls for erasing or rewriting data contained in this memory are not available to the user operating this device, and generally cannot be overridden.

FIG. 5illustrates a flow diagram of an example method500for triggering data sniffing of an inter-device communication link, in accordance with an example of the present disclosure. In the illustrated example, a network entity may receive a non-access stratum (NAS) request message from a user equipment (UE) for initiating an inter-device communication link; and send a NAS response message to the UE for establishing the inter-device communication link, the NAS response message including one or more data sniffing related parameters corresponding to the inter-device communication link. A UE may receive a NAS message from a network entity, the NAS message including one or more data sniffing related parameters corresponding to an inter-device communication link; store data exchanged over the inter-device communication link in a buffer; and upload the stored data to a secure server in a network.

As shown inFIG. 5, UE0 sends a NAS message to a MME via the serving eNB to initiate a direct D2D link with UE1 at502. As an example, the NAS message to initiate the direct D2D link with other UEs may be called a D2D Link Establishment Request message. The D2D Link Establishment Request message may include specific information for the direct communication link, for example, bandwidth requirements, data rate information, quality of service (QoS) information, time duration, etc., for the direct inter-device communication link. The NAS message may also include information of the other UE involved in the direct inter-device communication link. For example, the NAS message may include the UE identification (ID) information of the other UE, i.e., UE1, in the illustrated example. The UE ID may be, e.g., a phone number or the device PIN number etc.

After receiving the NAS message from UE0, the MME may forward the UE request to the HSS in a D2D Link Establishment Request message at504. The communication interface between the MME and the HSS may be referred to as an S6a interface. The MME may also include information about the UE in the D2D Link Establishment Request message sent to the HSS at504.

After receiving the message from the MME, the HSS may check the QoS requirements requested by the UE for the inter-device communication link and send a D2D Link Establishment Response message to the MME at506. HSS may check the device capabilities to verify whether the UE/device is authorized to establish a direct inter-device communication link with another device. If the UE is authorized to communicate directly with another UE, the UE may support the data sniffing functionality. If the HSS responds negatively to the MME, the MME may send a NAS D2D Link Establishment Response message to UE0 with a negative acknowledgment, indicating an unsuccessful establishment of the inter-device communication link. In the NAS message, the MME may also indicate the cause for the rejection. Consequently, UE0 may re-initiate the inter-device communication link based on the cause.

If the HSS responds positively to the MME at506, indicating an acceptance of the UE0's request for a direct communication link with UE1, the MME may subsequently send a D2D Initialization Request message to UE0's serving eNB at508for enabling the direct communication link between UE0 and UE1. The communication interface between the MME and the eNB is referred to as an S1 interface. The MME may include the QoS requirements of the direct communication link between UE0 and UE1 in the D2D Initialization Request message. The eNB may check the QoS requirements of the requested inter-device link and available radio resources at the eNB. The eNB may then determine whether the direct communication link between UE0 and UE1 can be enabled based on the QoS requirements with the available radio resources. The D2D Initialization Request message at508may also include information about the data sniffing function. For example, this message may include an indication whether or not data sniffing is enabled, whether or not data packet sniffing is enabled at multiple devices, etc. If data filtering is enabled, specifics of the data filtering function may also be included in this message. The Serving eNB may consider this information to determine the radio resources required to support this inter-device call. Correspondingly, the eNB may send a D2D Initialization Request Acknowledgement message to the MME at510, including a positive or negative acknowledgement. The eNB may include reasons for rejecting the D2D initialization request in the D2D Initialization Request Acknowledgement message when a negative acknowledgement is sent to the MME.

If the MME receives a positive acknowledgement from the eNB at510, the MME may send a D2D Link Establishment Response message with a positive acknowledgment to UE0 at512, indicating an acceptance of the request from UE0 to initiate a direct communication link with UE1. The NAS D2D Link Establishment Response message may also include an identification for the D2D link and one or more data sniffing related parameters corresponding to the inter-device communication link, such as indicators indicating the enablement of data sniffing, timers for uploading the data exchanged over the inter-device communication link, the secure server descriptor, data filtering functions, and so on. For example, the message may indicate a limit on the length of time the transmitted packets should be stored in the buffer. After the timer expires the stored packets can be erased and new packets can be stored. It may be the responsibility of the network to request the data to be uploaded to the server before the timer expires. In another scenario, the message may indicate the time intervals in which the stored packets have to be uploaded to the server. In another scenario, the network may also indicate that device should forward a compressed version of the data packets. For example, the packet may be searched for specific words or sentences according to predefined rules and the result of that search may be uploaded to the server.

In addition to these timers which define the times for uploading the data exchanged over the direct inter-device communication link, the network may also send a special encryption key to the device. The device may encrypt the stored data before sending it to the secure server. The encryption key and/or timer may be updated any time after initiating the inter-device call. Other NAS messages may also be used to transmit the data sniffing related parameters to the UE. For example, the data sniffing related parameters may be transmitted to the UEs after the data exchange over the inter-device communication link has started. In some implementations, the network may also send updated data sniffing related parameters to the UEs after the data exchange over the inter-device communication link has started. The D2D Link Establishment Response message512may also be sent to UE1 if the network decides to sniff the data from UE1 instead of, or in addition to, from UE0. If the NAS message at512does not contain the data sniffing descriptors, the UE may assume that the data need not be stored in the secure buffer and uploaded to a secure server.

When the eNB determines that the direct communication link between UE0 and UE1 may be enabled, the eNB may send RRC message D2D Connection Setup to UE0 at514. The eNB may use the Cell radio network temporary identity (C-RNTI) of UE1 to send this RRC message to UE1 at514. The D2D Connection Setup message may include transmission parameters for the direct communication link, such as a C-RNTI of UE1, temporary transmit point identifications for each UE communicating over the inter-device communication link, minimum and maximum transmit power levels for transmitting over the inter-device communication link, a device-to-device radio network temporary identity (DD-RNTI) for identifying the direct inter-device link, a transmit power step for the direct inter-device link, a guard time for the direct inter-device link, etc.

After receiving the RRC D2D Connection Setup message, the UE starts a timer T at516. In the NAS D2D Link Establishment Response message, the MME may include a device-to-device identification (D2D-ID), Tdump, Tsend—min, Tsend—max, and the secure server descriptor in the message. The D2D-ID is a unique ID for the D2D communication link. Tdumpis a timer for dumping the IP packets exchanged between the devices which are stored in a secure location within the device. Tsend—min,Tsend—maxare timers indicating time limits for uploading the data to a secure server in the network. The message may include either Tsend—min, Tsend—maxor Tdump. Tsend—maxindicates the maximum time delay for the data exchanged between the devices to be uploaded to the secure server and Tsend—minindicates the minimum time delay for the data exchanged between the devices to be uploaded to the secure server. When Tsend—min, Tsend—maxis not included in the NAS D2D Link Establishment Response message, the UE may assume that the network may request data transfer at a later time before the timer Tdumpexpires. Once the timer Tdumpexpires, the data stored in the secure buffer may be erased. The secure server descriptor may include all the relevant information to access and upload the data to the secure server. The secure server descriptor may include, the IP address of the server, an encryption key for encrypting the data for upload, etc. In case of any power interruptions to the device the stored data may be uploaded to the secure server after device powers-up. In another alternative, the timer T may be started for each data packet.

Subsequent to starting the timer T at516, UE1 may send a D2D Connection Setup Response message to the eNB at518, indicating a successful reception of the D2D Connection Setup message. In some implementations, the eNB may also send an RRC message D2D Connection Setup to UE1 which includes the similar information such as DD-RNTI. Subsequent to receiving the D2D Connection Setup message from the eNB, UE1 may also send a D2D Connection Setup Response message to the eNB, indicating a successful reception of the D2D Connection Setup message.

After receiving the D2D Connection Setup Response message from both UE1 and UE1 or the UE which initiated the D2D call, i.e. UE0, the eNB may initiate a device handshake procedure with UE1 and UE1 at520. During this procedure, the UEs identify each other and initiate link parameter tuning such that a reliable communication link can be established between the UEs. The transmit parameters, such as transmit power, modulation and coding scheme, etc, for direct inter-device communication link are obtained during this step. For example the transmit power for this link may be set such that the transmission from the UEs does not interfere with ongoing network-device communications and other device-to-device communication links.

Upon successful completion of the device handshake procedure, the eNB may send a D2D Initialization Response message to the MME at522, indicating a completion of the device handshake procedure. Subsequently, the MME may communicate QoS requirements of the direct inter-device link to the S-GW at524. Upon successful completion of the device handshake procedure, the eNB may also determine and communicate specifics regarding resources to be used for the inter-device link to UE1 and UE1. The network assisted inter-device communication between UE1 and UE1 may then be conducted over the direct inter-device communication link at526.

The UE may store data packets transmitted or received over the direct inter-device communication link in a secure buffer at528. The size of the buffer may depend on the type of application, the timers set by the network, etc. In general a maximum size of the buffer may be defined, e.g., in relevant standards documents (for the UEs supporting the direct inter-device communication) and the timers at the network may be set based on the required QoS and the available buffer size at the UE. This may also depend on the number of simultaneous inter-device calls a UE is participating. To reduce the size of the buffer required at a UE, the network may only indicate that either the transmitting or receiving UE is to store the data packets. To further reduce the size of buffer, the network may indicate that a filtered version or a representation of the data packets to be stored and transmitted to a secure server. For example, the filter can be a word look up in the data packets. These compressed statistics related to the data packets can be sent with very less radio resources to the secure server. Alternatively, the data packets which don't pass the security-sensitivity test, may be stored and an alert may be sent to the secure server. The secure server may, in turn, ask for the full data packet for further evaluation. The UE may upload the stored data to a secure server in a network periodically or upon receiving a request from the network. For example, when the timer T is greater than the value of Tsend—min, the UE may set up uplink transmission and data transfer to the secure server in the network at530. If Tsendis included in the NAS message, and If T>Tsend—min: The UL transmission is setup, and data is transferred to a secure server in the network until T=Tsend—max, at which point the buffer and timer are reset. If Tdumpis included in the NAS message and If T≧Tdump: the stored data packets are deleted and the buffer may be overwritten with new data packets. The timer T is also reset. If T<Tdump: If a NAS message is received to upload the data to the server, UE may start uploading the data to the server until T=Tdump.

In some implementations consistent with the present disclosure, the network may access the exchanged data by sending a NAS data retrieving message to the UE for triggering the UE to upload data stored in the secure buffer to the secure server. Then the UE may send the data stored in the secure buffer within the UE to the secure server via the S-GW upon receiving such message from the network. The UE may obtain the required UL radio resource grant to upload the data to the secure server. The network may indicate to the serving eNB that the data sniffing function is enabled. The serving eNB may include this requirement in the radio resource reservation for the UEs in the direct communication. The serving eNB may determine whether the same data is to be sniffed from multiple devices or from just one device in reserving the radio resources. The serving eNB may also consider whether the actual data packets, or a filtered version of the data packets, are to be uploaded. The specifics of the data filtering function may be indicated by the network to the serving eNB and the UEs. Various data filtering functions may be defined in the standards and the index of the data filtering function may be included in the NAS message and the D2D Init Request message to the eNB.

This data transfer procedure between the UE and the secure server may be transparent to the user. In other words, the user of the UE should not be able to notice, or to interrupt this data transfer. The device supporting the data sniffing functionality may automatically send a request for UL radio resource grant such that the data can be uploaded before Tsend—maxexpires. In addition the data may be automatically erased after a predetermined time period so as to prevent any memory overflow problems within the secure buffer location. If the UE is in an RRC_IDLE state, the network may send appropriate RRC messages to bring the UE into a RRC_ACTIVE state.

To establish a secure communication over the inter-device link, the data exchange over the inter-device link may be encrypted. For example, the serving eNB may derive an additional encryption key K′eNBfor the inter-device link. The serving eNB may send the additional encryption key K′eNBto all the UEs participating in the inter-device communication, in the already encrypted and integrity protected RRC message over the eNB-to-UE link. This encryption key may then be used for the inter-device communication. This key may not be refreshed during the call unless the parent key is refreshed.

The systems and methods described above may be implemented by any hardware, software or a combination of hardware and software having the above described functions. The software code, either in its entirety or a part thereof, may be stored in a computer readable memory.

While the above detailed description has shown, described, and pointed out the fundamental novel features of the disclosure as applied to various implementations, it will be understood that various omissions and substitutions and changes in the form and details of the system illustrated may be made by those skilled in the art, without departing from the intent of the disclosure. Although certain illustrated examples in this disclosure may show only two UEs, the described systems and methods for the inter-device communications can be applied to more than two UEs without departing from the scope of the present disclosure.